One Hour with Claude Managed Agents

On April 8, 2026, Anthropic launched Claude Managed Agents — hosted infrastructure for running autonomous AI agents. The next morning, within one hour of seeing the announcement, I had an oddkit-powered agent running on their platform, proving that epistemic discipline survives managed infrastructure. The agent didn't just work. It revealed a real search bug in oddkit's own codebase, and a second agent autonomously fixed it and filed the PR. This essay documents what happened, what it means, and why the interesting part isn't the speed.

---

My colleague Jesse had dropped a link in our group chat the night before. Anthropic had launched something called Claude Managed Agents — a hosted service for running long-horizon AI agents with built-in infrastructure: containers, tool execution, state management, and streaming. I saw it the next morning over coffee.

I'd been building oddkit — an open-source epistemic guidance system that runs as an MCP server — for months. The whole premise is that AI agents need more than tools. They need epistemic discipline: the ability to verify before claiming, search before asserting, and admit ignorance when they haven't checked.

So when I saw that Managed Agents natively supported MCP servers in agent configurations, the question was immediate: does the epistemic posture survive someone else's harness?

I didn't theorize. I read the docs, then built. Well — Claude read the docs. I said "let's go."

The agent configuration was minimal: a system prompt containing the Identity of Proactive Integrity — four axioms that govern how oddkit-powered agents behave — plus oddkit wired in as an MCP server. Fifteen minutes of doc-reading, three API calls (create agent, create environment, start session), and the agent was live.

The test was deliberate. I asked the agent about ODD's foundational axioms and the "Vodka Architecture" pattern — topics that exist only in oddkit's knowledge canon. If the agent guessed instead of searching, I'd see it immediately.

The event log told the story: eight proactive oddkit calls before generating a single word of response. Two searches, five document fetches, one catalog query. No prompting to use the tools. The system prompt was enough.

And then the response arrived — and this is the part that matters more than speed.

The agent found the four axioms in canon and presented them accurately. But it didn't find "Vodka Architecture." Instead of guessing, it said so explicitly: "After searching the full 411-document index, there is no pattern called 'Vodka Architecture' in the ODD canon." It asked me for a source before it would make any connection.

My colleague Birch captured the significance better than I could: "It admitted what it didn't find and it refused to guess. Very cool."

The epistemic discipline showed up as behavior, not just configuration.

But the honest answer was also wrong — or at least incomplete. Vodka Architecture does exist in the canon. The document had been committed three days earlier at canon/principles/vodka-architecture.md. So why didn't the agent find it?

I dug in. Two bugs, both real.

First: Cloudflare KV, where oddkit caches its search index, is eventually consistent. Two requests seconds apart can hit different edge caches. The agent's session hit a stale 411-document index; a search from my own session thirty seconds later hit the fresh 455-document index that included the Vodka Architecture doc.

Second: BM25 — the search algorithm — has no phrase awareness. The agent searched for "Vodka Architecture pattern." BM25 tokenizes those three words independently. "Pattern" appears in dozens of documents (Prompt Architecture, History Folder Pattern, ADR patterns...), diluting the signal from the rare, precise term "Vodka." The exact document titled "Vodka Architecture" got buried under noise.

The epistemic honesty that impressed my colleague was correct behavior given bad search results. The agent didn't hallucinate — but it also didn't find what was there. That's a different kind of failure, and a useful one.

So I spun up a second Managed Agent — this one configured as a coding agent with oddkit and GitHub access — and described the two bugs.

The agent cloned the repo, read the pre-work checklist from AGENTS.md, called oddkit_orient to assess the task, called oddkit_preflight to check constraints, read the calling code in three files to understand context, made surgical edits to the BM25 implementation (both the Worker TypeScript and the Node.js version), added index freshness verification to the cache layer, committed, pushed, and created PR #72.

Before claiming done, it called oddkit_validate. The validator flagged that it hadn't provided visual proof or bumped the index version. The agent addressed both honestly — explaining that backend-only changes have no UI to screenshot, and that the BM25 changes don't affect the persisted index schema. Then it encoded its DOLCHE session journal and persisted it to the project ledger.

168 events. 5 MCP calls. 32 tool calls. Three files changed, +80/-4 lines. I didn't touch it.

It's tempting to focus on speed. One hour from announcement to working proof-of-concept to autonomous PR. But speed isn't the insight.

The insight is about layers.

Anthropic built infrastructure: containers, state management, tool execution, scaling. That's Layer 1. The market will eventually compete on Layer 4 — vertical applications for specific industries. But between infrastructure and product, there's a gap. Agents need to know not just what tools they have, but how to reason about when to use them, what counts as evidence, and when to admit they don't know.

That's the epistemic layer. The protocol (oddkit) is open. The infrastructure (Managed Agents) is Anthropic's. The gap between them is where the interesting work begins.

The agent that searched before claiming, admitted what it didn't find, and refused to guess didn't do those things because of infrastructure. It did them because of values — four axioms loaded into a system prompt, backed by a knowledge canon accessible through an MCP server. The infrastructure made it possible. The epistemic discipline made it trustworthy.

Building something real in someone else's brand-new infrastructure, on launch day, taught me a few things I wouldn't have learned by reading docs:

MCP servers in Managed Agents are first-class. They're declared at agent creation and available to every session. Permission policies can auto-approve trusted servers. MCP tool calls appear as agent.mcp_tool_use events in the session trace — fully observable and auditable.

Model selection is agent design, not a global default. All three agents in this session ran on Sonnet 4.6 — proving the pattern cheaply before spending Opus tokens. But in production, the right pipeline is: Opus writes, Sonnet validates, Opus fixes. Sonnet-authored code generates more review findings than Opus-authored code. But Sonnet is exactly what you want in a reviewer — literal, flag-happy, unlikely to rationalize an edge case away. Opus produces cleaner first drafts and can address Sonnet's findings with better judgment. Model selection per agent role, not one size fits all.

The system prompt is sufficient for proactive behavior — today. The agent called oddkit tools without being asked, purely from system prompt instructions. Whether that holds under adversarial conditions or at scale is an open question, but for a proof of concept, it works.

Honest failures are more valuable than plausible successes. The Vodka Architecture miss led directly to discovering two real bugs. A hallucinated answer would have looked correct and taught me nothing.

Infrastructure you don't build is infrastructure you don't maintain. Managed Agents handles containers, state, error recovery, and scaling. That's months of work I didn't have to do and won't have to maintain. The Vodka Architecture principle — "thin, clean, stateless over stateful" — applies to the whole stack, not just my code.

Inline validation is fast but limited. Agentic validation has overhead but is thorough. After the first spike, my AI co-author shipped broken frontmatter in the article itself — then shipped it broken again, and again. Four times in one session. Each time, it tried to fix it inline: eyeballing the YAML, comparing fields from memory, patching by hand. Each time, something slipped through. My only signal was the preview site crashing. When I finally told it to stop guessing and spin up a Managed Agent to validate — cloning the repo, fetching the schema from oddkit, diffing against working essays field-by-field — the agent found every issue in one pass. The overhead is real: each agent validation takes two to four minutes, sessions can timeout, containers can die mid-execution. But the thoroughness is worth it. Inline validation catches what you think to check. Agentic validation checks what the schema actually requires. The two are complementary: validate inline for speed, then send an agent when the stakes are high or your co-author's track record is bad.

By the end of the session, the BM25 fix had been battle-tested against all 465 documents in the canon, deployed to production, and verified live. The query that started the whole chain — "Vodka Architecture" — now returns the right document as the first result, with a score boosted by the phrase match. The index freshness verification caught a stale cache on the very first request after deploy, rebuilt it, and every subsequent request served the fresh 465-document index.

The bug that Birch praised for being honestly reported is now fixed — by a different agent, in the same session, on infrastructure that didn't exist yesterday.

There was one more problem. Everything I'd figured out — how to create sessions, send tasks, poll for completion, parse event logs, avoid shell escaping nightmares, wire oddkit as an MCP server — lived only in this session's context. The next time I opened a conversation, none of it would be there. My AI co-author wouldn't know how to spin up an agent. We'd be starting from scratch.

This is the same problem oddkit was built to solve for epistemic governance: knowledge that dies when the session ends. The solution was the same pattern, applied differently.

Claude's skill system lets you package procedural knowledge — step-by-step workflows with code, templates, and gotchas — so it's automatically available in future sessions. Skills are to procedures what canon is to governance: durable, discoverable, and triggered by context rather than memory.

So I turned the entire Managed Agents workflow into a skill. The session's hard-won knowledge became a reusable recipe: reusable agent and environment IDs, the exact curl patterns that work, the python3 JSON trick that avoids escaping issues, the polling pattern, the event parsing, the task templates for frontmatter validation and code PRs, the three-model pipeline, and every known failure mode we hit.

Now when any session in this project says "spin up an agent" or "validate with an agent," the skill triggers. No rediscovery. No re-reading docs. No re-learning that mcp_servers requires a matching mcp_toolset entry.

Three layers, clean separation: credentials in project instructions, recipes in skills, governance in canon. The infrastructure is Anthropic's. The epistemic discipline is oddkit's. The workflow knowledge is the skill's. Each layer does one thing and stays out of the others' way. Vodka architecture, all the way down.

---

The agent configurations, event logs, and PRs are all public. PR #72 is the BM25 fix authored by a Managed Agent. PR #73 deployed it to production. The managed-agents skill packages the entire workflow for reuse.