kxbnb

Fair question. Those three are hosting services for stock OpenClaw — you sign up, they spin up an instance, you get a Telegram bot. That's it.

We built something different.

Every agent gets a real Chromium browser running on a virtual display. You can watch it work through a VNC viewer right in the dashboard. None of those services have this — they're text-in/text-out.

Each workspace runs up to 10 agents, each with its own browser and filesystem. Agents can spawn sub-agents to break up complex tasks. Every workspace is an isolated Docker container with dropped capabilities and security policies, not a shared Node process.

Those services give you a chatbot you talk to on Telegram. We give you an agent with a browser, a shell, a scheduler, and the ability to actually do things on the internet — and you can watch it do them.

More on what's under the hood: https://claw42.com/features

Docs if you want to dig in: https://claw42.com/docs

I built Axiomo because every AI code review tool I tried kept solving the wrong problem. They all want to be a second developer on your PR, catching lint issues and suggesting refactors. That's not what makes review hard.

What makes it hard is context. Who wrote this, have they worked in this area before, what are they actually trying to do, and where should I focus?

Axiomo generates a structured Signal for every PR that answers those questions. Contributor context, intent, risk drivers, CI evidence, focus files. No auto-generated code suggestions. No comment spam. Just the stuff that helps you actually review instead of skim and approve.

Stack is Next.js on Vercel, Neon for Postgres, Resend for email. GitHub integration. Would love feedback on the approach and what your review workflow looks like.

The framing of craft vs. slop misses something important: most production software quality problems aren't about aesthetics or elegance, they're about correctness under real-world conditions.

I've been using AI coding tools heavily for the past year. They're genuinely useful for the "plumbing" - glue code, boilerplate, test scaffolding. But where they consistently fail is reasoning about system-level concerns: authorization boundaries, failure modes, state consistency across services.

The article mentions AI works best on "well-defined prompts for already often-solved problems." This is accurate. The challenge is that in production, the hard problems are rarely well-defined - they emerge from the interaction between your code and reality: rate limits you didn't anticipate, edge cases in user behavior, security assumptions that don't hold.

Craft isn't about writing beautiful code. It's about having developed judgment for which corners you can't cut - something that comes from having been burned by the consequences.

The "independence" point resonates. We've seen this pattern in policy enforcement too - the system that generates behavior shouldn't be the same one that validates it.

What I'm curious about is how the feedback loop handles ambiguity. When the review agent flags something and the coding agent "fixes" it, there's a risk of the fix being technically compliant but semantically wrong. The coding agent optimizes for passing review, not necessarily for correctness.

Have you seen this create adversarial dynamics, where coding agents learn to game the review criteria rather than actually improving code quality?

Cool project. The agent shorthand/jargon detection is a unique angle - I haven't seen other tools focus on that specifically.

Re: your question about observability pain points - the one I keep hitting is visibility at the external API boundary. Most agent observability (including OTEL-based traces) shows what the agent intended to send, but not necessarily what actually hit the wire when calling external services.

When an agent makes a tool call that hits Stripe, Shopify, or any third-party API, you want to see the actual HTTP request/response - not just the function call in your trace. Especially for debugging "works locally, fails in prod" scenarios or when the vendor says "your request was malformed."

I built toran.sh for this - transparent proxy that captures wire-level requests to external APIs. Complements tools like InsAIts since you get the inter-agent communication view and the external boundary view.

What's your take on capturing outbound API calls vs focusing on agent-to-agent communication?

The "output validation not just input validation" point is underrated. Most guardrails focus on what goes into the model, but the real risk is what comes out and gets executed.

We're working on similar problems at keypost.ai - policy enforcement at the tool-calling boundary for MCP pipelines. Different angle (we're more focused on access control and rate limits than hallucination detection per se) but same philosophy of deterministic enforcement.

Question: how do you handle the tension between semantic enforcement and false positives? In our experience, too-strict semantic rules block legitimate use cases, but too-loose lets things through. Any patterns that worked for calibrating that?

Nice execution on the replay testing with semantic diff - that's a pain point that's hard to solve with just metrics.

One thing I've noticed building toran.sh (HTTP-level observability for agents): there's a gap between "what the agent decided to do" (your trace level) and "what actually went over the wire" (raw requests/responses). Especially with retries, timeouts, and provider failovers - the trace might show success but the HTTP layer tells a different story.

Do you capture the underlying HTTP calls, or is it primarily at the SDK/trace level? Asking because debugging often ends up needing both views.

Your framing of the problem resonates - treating the LLM as untrusted is the right starting point. The CAR spec sounds similar to what we're building at keypost.ai.

On canonicalization: we found that intercepting at the tool/API boundary (rather than parsing free-form output) sidesteps most aliasing issues. The MCP protocol helps here - structured tool calls are easier to normalize than arbitrary text.

On stateful intent: this is harder. We're experimenting with session-scoped budgets (max N reads before requiring elevated approval) rather than trying to detect "bad sequences" semantically. Explicit resource limits beat heuristics.

On latency: sub-10ms is achievable for policy checks if you keep rules declarative and avoid LLM-in-the-loop validation. YAML policies with pattern matching scale well.

Curious about your CAR spec - are you treating it as a normalization layer before policy evaluation, or as the policy language itself?

Interesting approach to the instruction bloat problem. The composable skills idea makes sense - 500 tokens vs 10K is a real difference.

One thing I'd be curious about: how do you think about security when skills auto-provision based on stack detection? If a skill gets compromised upstream, the auto-sync could propagate it quickly.

We're working on policy enforcement for MCP at keypost.ai and thinking about similar trust questions - what should be allowed to load/execute vs what needs explicit approval.

The insight about environment attacks vs. model attacks is critical. "The model functioned correctly, yet the overall agent system remained compromised because it trusted its tools' outputs."

This is why I've been focused on boundary visibility. Agents are opaque until they hit real tools - and if you can't see what's actually being sent/received at each boundary, you can't detect manipulation.

We built toran.sh to provide that inspection layer - read-only proxies that show the actual wire-level request/response. Doesn't prevent attacks, but makes them visible.

Curious what detection mechanisms you're recommending alongside the attack framework?

Nice work - the "deploy-friendly guardrails" framing resonates. Too many MCP tools assume local dev only.

To your question about what bites first: in our experience at keypost.ai, the order is usually:

1. *Auth* - OAuth token refresh edge cases, especially when agents run long tasks that span token expiry 2. *Rate limits* - not having them, then having them but too coarse (per-tool vs per-endpoint vs per-argument) 3. *Observability* - specifically, correlating agent intent with actual tool calls when debugging why something failed 4. *Sandboxing* - usually comes up after the first "oops" moment

One pattern we've found useful: separating "can this identity call this tool" (auth) from "should this specific call be allowed" (policy). They're often conflated but have different failure modes and different owners (security team vs product team).

Curious how you're handling policy in PolyMCP - is it config-driven or code-driven?

The middleware proxy approach unop mentioned is the right pattern - you need an enforcement point the agent can't bypass.

At keypost.ai we're building exactly this for MCP pipelines. The proxy evaluates every tool call against deterministic policy before it reaches the actual tool. No LLM in the decision path, so no reasoning around the rules.

Re: chrisjj's point about "fix the program" - the challenge is that agents are non-deterministic by design. You can't unit test every possible action sequence. So you need runtime enforcement as a safety net, similar to how we use IAM even for well-tested code.

The human-in-the-loop suggestion works but doesn't scale. What we're seeing teams want is conditional human approval - only trigger review when the action crosses a risk threshold (first time deleting in prod, spend over $X, etc.), not for every call.

The audit trail gap is real. Most teams log tool calls but not the policy decision. When something goes wrong, you want to know: was it allowed by policy, or did policy not cover this case?

We're building this at keypost.ai - the enforcement point is a proxy that sits between the agent and MCP servers. Tool calls go through the proxy, get evaluated against policy, and either pass or get blocked before reaching the actual tool.

The key insight: policy evaluation has to happen outside the agent's context. If the agent can reason about or around the policy, it's not really enforcement. So we treat it like a firewall - deterministic rules, no LLM in the decision path.

What we've found works: - Argument-level rules, not just tool-level ("github.delete_branch is fine, but only for feature/* branches") - Rate limits that reset on different windows (per-minute for burst, per-day for cost) - Explicit rule priority for when constraints conflict

The audit trail piece is critical too. Being able to answer "why was this blocked?" after the fact builds trust with teams rolling this out.

Curious what failure modes people have actually hit - is it more "agent tried something it shouldn't" or "policy was too restrictive and blocked legitimate work"?

Nice approach - fail-closed decision logging is the right default. Too many systems treat audit as best-effort, which defeats the purpose when you're investigating an incident.

The framework-agnostic design makes sense for adoption. One thing we've found tricky at keypost.ai is policy composition - when you have overlapping constraints (rate limits + role-based access + cost caps), determining which rule "wins" needs explicit precedence. Does SudoAgent have opinions on conflict resolution, or is that left to the Policy implementation?

Also curious about the human approval latency in practice - do you see teams using it for truly synchronous gates, or more as a "review queue" pattern where work gets batched?

The pain of failures that are "hard to reason about once things went async" is real. Centralizing the retry/failover logic makes sense.

One pattern I've found useful: having a read-only view of what's actually hitting the wire before any retry logic kicks in. When you can see the raw request/response as it happens, you can tell whether the issue is your payload, the provider throttling, or something in between.

We built toran.sh for this - it's a transparent proxy that shows exactly what goes out and comes back in real-time. Different layer than what you're doing (you handle the orchestration, we just show the traffic), but they complement each other.

Curious how you handle visibility into what's actually being sent during partial stream failures?

The noise problem is real. Most observability tools optimize for "capture everything" which leads to exactly this waste.

We took a different approach with toran.sh - instead of instrumenting your entire stack, you create a read-only proxy for a specific upstream API. You see exactly what's being sent and received, nothing else. No SDK, no log parsing, just the raw request/response for that one integration.

Works well for debugging third-party API issues where you need to see what actually hit the wire, not what your code thought it sent.

Nice approach using the base URL feature as the interception point. That's the same pattern we've been using at toran.sh for API observability - swap a URL and you get visibility without SDK changes.

The "searchable logs of all conversations" piece is interesting. We focused more on the real-time view (watching requests as they happen during debugging) rather than historical search. Curious if you find yourself using the live view vs searching through logs more often?

One thing we ran into: when agents chain multiple API calls, having just the raw logs isn't enough - you need to correlate which calls came from which task/session. Did you add any grouping/correlation to LLMWatcher?

This is the exact problem we're seeing with MCP adoption too - powerful tool access with zero restrictions by default.

The "tool chaining" attack class is particularly nasty because each individual action looks benign. Read file? Fine. Send email? Fine. But the combination is exfiltration.

We're working on deterministic policy enforcement for agent pipelines at keypost.ai - the idea is you define what tools can do (not just whether they can be called), so "email tool can only send to @company.com" becomes a hard boundary the agent can't reason around.

The tricky part is making policies that are specific enough to block attacks but general enough to not break legitimate workflows. Curious what patterns you found that would be hardest to catch with simple allow/deny rules?

Good question. The boundary problem shows up most clearly with third-party API integrations - Stripe, Twilio, Shopify, etc.

The pattern we see: an agent makes an API call, gets a 400 or unexpected response, and the developer has no visibility into what was actually sent. The agent's logs show "called Stripe API" but not the actual payload that triggered the error. Vendor support says "the request was malformed" but the agent's internal state looks fine.

With https://toran.sh, we create a read-only inspection endpoint bound to a single upstream API. The agent points at our URL instead of the vendor's, and we proxy everything through while capturing the raw request/response. No SDK, no code changes to the agent - just swap the base URL.

The instrumentation approach is intentionally minimal: we don't try to understand the semantics of the calls, just show exactly what bytes hit the wire. Teams can then add policy enforcement (via https://keypost.ai or similar) once they actually understand what their agents are doing.

Curious about AxonFlow's approach to custom HTTP integrations - do you intercept at the network layer or require explicit tool registration?

Great execution on this - the argument-level blocking is the key insight. The all-or-nothing permission model is exactly why MCP adoption stalls in production.

We've been working on a similar problem at https://keypost.ai, coming at it from the policy enforcement angle - rate limits, cost caps, and access control rules that sit in-path. The challenge we keep hitting is rule composition: when you have multiple constraints (e.g., "can use github.delete but only on branches matching feature-*, and only 3x per hour"), the config can get unwieldy fast.

Curious how you're handling rule definitions in Armour - is it purely argument pattern matching, or are you thinking about stateful rules (like rate limits or quotas)?

Really glad to see more people building in this space. The MCP security story needs a lot more attention.

The "signed transaction, not a log stream" framing is exactly right. Logs are optimistic - you assume they're complete and unmodified. Receipts are pessimistic - you verify before trusting.

We've been thinking about a related problem at toran.sh: capturing what an agent actually sent to external APIs (and what came back) without trusting the agent's self-reported logs. Different angle - we focus on the API request/response level rather than the decision/action level - but the same underlying insight: the source of truth needs to be outside the agent's control.

The Ed25519 + canonical JSON approach is clean. Question: how are you handling schema evolution? If the receipt format changes, older receipts still need to verify but newer tooling might expect different fields.

Congrats on the 1.0 launch! The workflow and agent composition primitives look well-designed.

Curious about the observability story - when agents make tool calls, how do you debug what actually got sent to external APIs? We've found that's often the hardest part of agent development - the "it works locally but fails in production" debugging loop.

Great to see more production-ready agent frameworks emerging. Will be following the project!

Nice work on Fence! The network/filesystem restriction approach is exactly what's needed for running untrusted commands safely.

We're working on similar containment problems but at the API/MCP layer at keypost.ai - enforcing what outbound calls an agent can make rather than what local filesystem/network it can access. The two layers complement each other well.

The "restrictions as code" pattern is powerful. Are you thinking about extending to other resource types (API calls, token budgets, etc.)?

Really cool approach to the containment problem. The insight about "capping the blast radius of a confused agent" resonates - decision fatigue is real when you're constantly approving agent actions.

The exfiltration controls are interesting. Have you thought about extending this to rate limiting and cost controls as well? We've been working on similar problems at keypost.ai - deterministic policy enforcement for MCP tool calls (rate limits, access control, cost caps).

One thing we've found is that the enforcement layer needs to be in-path rather than advisory - agents can be creative about working around soft limits. Curious how you're handling the boundary between "blocked" and "allowed but logged"?

Great work shipping this - the agent security space needs more practical tools.

This resonates. "Type safety is not enough - bugs in downstream services can silently break your API contracts" is something I've hit repeatedly.

Your approach of schema-first with observability layer makes sense. Schema gives you the contract, metrics give you truth about what's actually happening.

Building something adjacent at toran.sh - API observability focused on agent workloads. Similar motivation: see actual traffic, not just trust the schema.

Question: how are you handling observability for services that call external APIs? The internal → external boundary is where I've found the most surprising failures.