Anthropic described Managed Agents as “a suite of composable APIs for building and deploying cloud-hosted agents at scale.” For general-purpose apps that’s one kind of interesting. For vertical-domain tooling that needs regulated outputs — and that already has a protocol and a registry behind it — it’s a different kind.

This post is about what I’m planning to build on top of that infrastructure, why the compliance use case is the right place to start, and what’s already built versus what isn’t.

The distribution problem

I’ve spent the last year building robot-md: a CLI, a Python package, an MCP server, a protocol, a registry. The stack works. Bob (my SO-ARM101) is registered, signed, and compliance status returns “no blockers” on his manifest today.

The problem is that all of this is do-it-yourself. You pip install robot-md, you run init, you wire the MCP server into whatever agent surface you’re using, you learn the emit-* commands. For developers, that’s fine — the Claude Code plugin and the dispatcher lower the barrier considerably, and the three-tier UX (--yes / guided / slash-command) was designed to get someone from “robot on desk” to “LLM driving it” in under fifteen minutes.

But compliance work doesn’t usually happen at a terminal. The person responsible for an EU AI Act submission at a robotics company is probably a compliance engineer or a product manager, not the developer who wired up the MCP server. They need a hosted, managed surface that takes their robot’s repo as input and hands back signed attestation artifacts. They don’t want to install a CLI.

That’s the gap Managed Agents fills.

What Compliance-bot does

The design is straightforward. Point Compliance-bot at a robot repository — either a GitHub URL or a local path — and it runs the following sequence:

1. robot-md validate ROBOT.md — confirms the manifest is schema-valid.
2. robot-md compliance status ROBOT.md — runs a multi-section pre-flight: local state (manifest, signing keypair, apikey, audit chain, incidents log), compliance artifacts (verified signatures on each packet), RRF registry (endpoint reachable, RRN resolvable, rcan_version match), submission readiness (one row per emit-*), and first-motion readiness (eleven checks covering HiTL gates, joint velocity caps, kinematics, etc.). Surfaces any blockers.
3. robot-md emit-fria ROBOT.md — produces a signed FRIA packet (RCAN §22).
4. robot-md emit-benchmarks ROBOT.md — produces a signed safety-benchmark packet (RCAN §23).
5. robot-md emit-ifu ROBOT.md — produces a signed IFU packet (RCAN §24 / EU AI Act Art. 13(3)).
6. robot-md incidents record … — produces a signed incident-report packet (RCAN §25 post-market monitoring / Art. 72).
7. robot-md emit-eu-register ROBOT.md — produces a signed EU-register packet (RCAN §26 / Art. 49).

Each packet is signed with the robot’s pqc-hybrid-v1 key (Ed25519 + ML-DSA-65). Each signed artifact is POSTed to its /v2/robots/<rrn>/<kind> endpoint on RRF (the §26 EU-register packet is the special case — it’s keyed by RMN, the manifest number, at /v2/models/<rmn>/eu-register). On success, the bot returns a bundle URL summarizing the submitted artifacts.

The whole flow — validate → compliance check → five signed submissions → bundle URL — replaces what is currently a multi-command sequence that a developer has to learn and run correctly. For a compliance engineer doing this for a fleet of robots, or doing it on a quarterly cadence, having a managed agent that runs the sequence correctly and produces auditable output is a meaningful reduction in friction.

The open-core split

robot-md-dispatcher is already on PyPI. It’s the BYOK Agent SDK reference implementation: you supply your own Anthropic API key, the agent runs on your host, the primitives are the same robot-md CLI commands. That’s the OSS path. Developers who want to run compliance workflows on-prem, from CI, or from a Slack bot can wire up the dispatcher against the emit-* commands today.

The hosted Compliance-bot Managed Agent is the convenience layer for everyone who isn’t going to do that wiring. Same five emit-* commands. Same signed artifacts. Same RRF endpoints. Different operational story: you go to robotmd.dev, click “run compliance check,” authenticate, point it at your repo. Done.

The two paths aren’t in conflict. OSS builds trust; the hosted layer earns revenue; both run on the same underlying protocol. A user who starts with the hosted agent and wants more control can switch to the dispatcher without changing their manifest or their robot’s identity.

What the workflow looks like in practice

Let me be concrete about why this is hard without a managed surface.

Say you’re a small robotics company. You ship an arm manipulator — call it a high-risk AI system under Article 6 of the EU AI Act because it operates physically near humans. Your compliance timeline has “submit FRIA and EU register by Q3 2026” as a checkpoint.

Without this tooling, you’re looking at something like:

1. A compliance engineer writes the FRIA as a Word document based on a template from a consulting firm.
2. A developer exports the technical documentation in some format.
3. A legal team reviews both and reconciles them with the product spec.
4. Someone figures out where to submit the EU register entry and what format it expects.
5. You repeat this every time the software version changes materially, because the Act requires you to keep the documentation current.

That process is documented nowhere end-to-end. Every company reinvents it. It takes weeks the first time and multiple days on every subsequent update.

With the Compliance-bot flow, steps 1-4 become: write ROBOT.md (which your developer writes once, at setup, and keeps current in git), run Compliance-bot, get the bundle URL. Step 5 — re-running on software updates — is a CI hook or a monthly cron job. The FRIA content lives in the manifest’s fria block, not in a Word document that’s already out of date before the ink dries.

The thing that makes this work is that ROBOT.md is already part of the robot’s development workflow, not a separate compliance artifact. If you’re using robot-md to drive the arm from Claude Code, you’re already editing the manifest when the hardware changes. The compliance artifacts are a derivative of that — they get generated from the manifest, not authored separately.

That’s the user story for Compliance-bot. It’s not “I will automate your legal review.” It’s “I will generate the correctly-formatted, signed, machine-verifiable version of the documentation you’re already maintaining.”

Why compliance is the right wedge

Distribution. Managed Agents is a catalog play: Anthropic is building infrastructure for vertical agents, and the catalog is where those agents get discovered. Compliance tooling for physical-AI systems is a narrow enough vertical that it has a real audience (robotics platform engineers, product teams at companies shipping autonomous systems) and a clear enough deliverable (signed §22-26 artifacts) that it doesn’t need to be explained from first principles every time.

Protocol moat. I wrote the RCAN spec. The RCAN §22-26 chapters define the packet schemas. The RRF endpoints were built to accept those packets. The emit-* commands were built to produce them. There’s no other tooling that produces this specific set of artifacts in this format, because the format is the spec and I wrote the spec. A Compliance-bot competitor that doesn’t have the same protocol history would have to build a different workflow against different endpoints, and their users would be on a different registry. The moat isn’t “we’re faster” or “we have more features” — it’s that the open protocol and the open registry are both ours.

Open-core economics. OSS earns the developer audience. The hosted agent earns revenue from the compliance-engineer audience. Both feed RRF growth: more robots registered, more artifacts submitted, more leaderboard data. Revenue from the hosted layer funds the protocol work and the RRF infrastructure. That’s the loop.

What’s already built, and what isn’t

To be precise:

Already shipped:

• The five emit-* commands work in robot-md v1.4.0.
• RRF’s §22-26 endpoints accept signed packets and return registry URLs.
• robot-md-mcp bundles the CLI for any MCP-aware agent surface.
• robot-md-dispatcher on PyPI is the BYOK on-prem path.
• robot-md compliance status runs the five-point pre-flight check.
• The /managed-agents/ page on robotmd.dev is live with a waitlist (Cloudflare Workers KV-backed).

In flight:

• RRF §27 (spatial-eval counter-sign endpoint) — PR #73 merged today (Cloudflare deploy succeeded). The compliance bundle now gains a sixth artifact in production: a registry-attested spatial-intelligence score.

Not built yet:

• Compliance-bot itself. The application is submitted to Managed Agents beta. If access lands, the OSS dispatcher becomes the reference implementation and the hosted Compliance-bot becomes the flagship. Until access lands, the hosted agent is a design, not a deployment.

Not claiming:

• Notified-body integration. That requires a certification partner and a submission process that doesn’t exist yet for software-based robotics stacks. This is years out, not quarters.

That last point is worth sitting with for a minute. The Compliance-bot produces artifacts that match what a future notified body would want to see. It’s building the paper trail before the paper trail is required. But it isn’t the same thing as getting a CE mark. I said the same thing in the capabilities and compliance post; I’ll keep saying it.

This is the moment

Anthropic is investing in Managed Agents. The catalog is new. Vertical agents in regulated markets are exactly the kind of thing a curated catalog is for — they have narrow scope, a defined deliverable, and an audience that will actually pay for a managed surface rather than cobbling one together from CLIs.

robot-md has the underlying protocol. RRF has the registry infrastructure. The emit-* commands work. The missing piece is the hosted layer, and Managed Agents is where that hosted layer gets built.

If you’re at a robotics company and your compliance calendar has “EU AI Act submission” on it for H2 2026 or H1 2027, the waitlist is at robotmd.dev/managed-agents/. Sign up now; I’ll reach out as soon as beta access lands and the bot is ready for a real run.