Notes from a Weekend with Anthropic’s Managed Agents

TLDR: Anthropic’s Managed Agents collapsed two to three months of agent infrastructure into an afternoon. But if you want to serve external customers, you’re building the billing, auth, and metering layer yourself. The runtime is ready. The business model primitives aren’t.

I wanted to get my hands dirty with Anthropic’s Managed Agents, so I built something in my domain — a financing contract analyzer. Upload an MCA or term loan PDF, get an APR calculation, predatory term detection, and a plain English breakdown. It works beautifully — for internal use. But if you’re thinking about building a product on top of Managed Agents that serves external customers, you’ll hit a wall fast.

Here’s what I learned.

Managed Agents give you a pre-built agent runtime. You configure an agent (model, system prompt, tools), an environment (container), and a vault (credentials). Then you create sessions — ephemeral conversations where the agent does work. Anthropic hosts everything. You don’t build an agent loop, you don’t manage tool execution, you don’t run containers.

If you’ve been following my posts about agent architecture, you’ll recognize the pattern immediately. When Anthropic published their engineering post on how they built this, I had the same reaction I described in that piece — it’s the same abstraction every time. Session log (durable state), harness (stateless processor), sandbox (ephemeral compute). The execute(name, input) → string interface doesn’t care if the sandbox is a container, a phone, or a Pokémon emulator. Their words, not mine. And they’re right — that interface will outlast every specific implementation behind it.

The architecture is explicitly designed for impermanence. They talk about Sonnet 4.5 exhibiting “context anxiety” as it sensed the context window running out — so they built context resets into the harness. Then Opus 4.5 just... didn’t have that problem. The resets became dead weight. So they built the system so the harness itself is cattle, not a pet. If it crashes, a new one boots up, reads the append-only session log, and resumes. The invariant isn’t any specific harness behavior — the invariant is that harnesses need to be replaceable.

This is elegant and simple. Sessions will always need to be durable, sandboxes disposable, harnesses replaceable. The interfaces between them are the product. Everything else is implementation detail.

Before I get into what I built on top of Managed Agents, it’s worth being concrete about what I didn’t have to build. Because the list is long.

The agent loop. Without Managed Agents, I’d be writing the orchestration code myself — the while loop that calls the model, parses tool-use responses, routes each tool call to the right handler, feeds results back, and loops until the model signals it’s done. You also handle retries when the model produces a malformed tool call, timeouts when a tool hangs, graceful degradation when a tool is unavailable, and the weird edge cases where it tries to call a tool that doesn’t exist or calls the right tool with wrong arguments. This is the code that every agent framework exists to abstract away. With Managed Agents, I create a session, send a message, and the harness runs the loop. I never see it.

Container orchestration. My agent reads dense legal PDFs and runs code to process them. That code needs to execute somewhere sandboxed — you do not want untrusted LLM-generated code running on your application server. Without Managed Agents, I’m provisioning Docker containers, managing their lifecycle, handling cold start latency, dealing with OOMs and crashes, and cleaning up after sessions end. Managed Agents gives me an environment that provisions on demand and dies when it’s done. Cattle not pets — and I didn’t have to build the ranch.

The security boundary. My MCP server has API credentials. The vault stores OAuth tokens. In a DIY setup, I’d need to architect the isolation so that code the model generates can never reach those credentials — because one prompt injection that reads environment variables and an attacker has your tokens. Anthropic’s design puts credentials in a vault outside the sandbox, proxied through a dedicated layer. The model calls MCP tools through the proxy but never sees the underlying tokens. Building this yourself is doable, but it’s easy to get subtly wrong. And “subtly wrong” in security means catastrophically wrong.

Context management. A 40-page MCA agreement with dense legal language eats a context window fast, especially when you’re stuffing in tool results from six MCP calls. Without Managed Agents, I’d be implementing my own compaction strategy, managing prompt caching, and making hard decisions about what to keep when context fills up mid-analysis. Managed Agents handles caching and compaction automatically.

Session durability and crash recovery. If my agent loop crashes mid-analysis — network blip, container OOM, upstream timeout — I lose everything unless I’ve built my own event log. Managed Agents stores every event in an append-only session log outside the harness. If the harness dies, a new one boots, reads the log, and resumes. Building this myself means implementing event sourcing for an agent framework — a month to get right and a weekend to get dangerously wrong.

SSE streaming. Streaming the model’s responses back to the customer in real time — interleaving text, tool-use events, and status updates — is its own project. Managed Agents gives me a /stream endpoint that handles all of it.

Add all of that up and you’re looking at two to three months of infrastructure work before you write a single line of domain logic. Managed Agents collapsed that to an afternoon.

That velocity is why the multi-tenant gap is worth writing about. If the platform were mediocre, I’d just move on.

The agent reads financing PDFs, extracts contract terms, calls an MCP server I deployed on Cloud Run for precise financial math (APR calculations, predatory term detection, market benchmarks), then explains everything in plain English. The goal is output that a small business owner can actually understand — no legal jargon, no ambiguity about what a contract actually costs.

The tool orchestration is the best part. I defined six MCP tools — APR calculator, predatory term detector, market benchmark lookup, payment schedule generator, and a couple of others. I didn’t tell the agent which tools to call or in what order. It read the PDF, figured out the product type, called the right tools in the right sequence, and synthesized the results. The whole system — MCP server, managed agent, eval suite — took a day.

The eval suite is worth mentioning. I built automated evals using DeepEval with LLM-as-a-judge — feed the agent a contract PDF, compare its output against known correct extractions, and let a second model score accuracy, completeness, and readability. Because Managed Agents handles the entire session lifecycle, I can spin up eval sessions programmatically, run a batch of contracts through, and collect structured results without managing any of the agent infrastructure myself. The feedback loop from “change the system prompt” to “see eval results across 20 contracts” is tight enough that I was iterating on prompt quality the same afternoon I built the system.

The quality isn’t the problem. The problem is what happens when you want to put that output in front of paying customers.

The architecture makes assumptions that are reasonable for the stated use case — and limiting if you’re trying to build a product on top of it.

Everything is scoped to the account. The agent, environment, vault, and sessions all live under one Anthropic API key. Whoever’s key creates the session pays for the model usage. There’s no parameter on the session creation endpoint to bill to a different key or account. The rate limits — 60 creates per minute, 600 reads per minute — are per organization. The session’s metadata field accepts arbitrary key-value pairs, but there’s no structured usage data coming back: no token counts per session, no cost attribution, no webhook when a session completes.

This isn’t a bug. The docs position Managed Agents as best for “long-running tasks and asynchronous work” with “minimal infrastructure.” The engineering post talks about enterprise customers wanting to connect agents to resources in their own VPC. The design intent is clear — this is infrastructure for teams running agents against their own problems, not for platforms running agents on behalf of end users.

But the moment you want to serve external customers, you need answers to questions the platform doesn’t address: Who pays for this session? How do I track their usage? How do I enforce per-customer rate limits? How do I isolate their data?

The solution I landed on is a proxy. A FastAPI service on Cloud Run that sits between the customer and the Managed Agent. The proxy holds my Anthropic API key, creates sessions on behalf of customers, and streams responses back. Customers never touch Anthropic’s API directly. The Managed Agent has no idea it’s serving multiple customers.

What I wanted:

Customer → Managed Agent (billed to customer)

What I got:

Customer → My Proxy → Managed Agent → My MCP Server
              |
        Auth, metering,
        billing — all mine

Here’s what the proxy actually handles: self-serve API key registration backed by Firestore, request authentication and validation, session creation using my API key, SSE response streaming back to customers, per-session usage logging for billing reconciliation, and automated extraction evals. None of this is particularly complex on its own. But it adds up to a full multi-tenancy layer — the exact infrastructure that Managed Agents was supposed to let me skip.

And that’s the tension. Managed Agents abstracts away the agent runtime complexity. The harness, the sandbox, the session log — all handled. But the business complexity doesn’t disappear. It moves to a different layer. You haven’t removed the hard problem, you’ve relocated it from “how do I run an agent” to “how do I run a business on top of someone else’s agent.”

The complexity is conserved. It always is.

I think about this through the Stripe Connect analogy. Stripe’s core product was great for direct merchants — one account, one API key, process payments. Then platforms showed up wanting to process payments on behalf of their users. Stripe’s answer was Connect: platforms create connected accounts, each with separate billing, sharing the platform’s integration.

Managed Agents needs its version of this. Here’s what that could look like:

Per-session billing attribution. The session creation endpoint already accepts metadata. Add a first-class billing_account field that lets me create the agent and environment in my account but attribute usage to a customer-provided API key or sub-account. The customer gets simpler onboarding (they just need an Anthropic key, not a full agent setup), and I don’t need a proxy for billing purposes.

Organization-level delegation. Let me create sub-accounts or workspaces under my organization, each with their own billing and rate limits, but sharing agent definitions. This is the Connect model — the platform owns the agent configuration, the sub-account owns the usage. Anthropic already has organization-level concepts in their API; extending them to support delegation is an incremental step, not a rearchitecture.

Usage events. Even if I eat the cost, give me a webhook or structured callback with token counts per session when the session hits idle or terminated. Right now I’d have to parse the SSE event stream and count tokens myself. The session object already tracks status — adding a usage field with input/output token counts would be trivial relative to the value it unlocks. Every developer building a proxy layer is solving this same problem independently right now.

Per-customer rate limiting. The current rate limits are per organization. If I’m running sessions for 50 customers through one API key, one noisy customer can burn my rate limit for everyone. Let me set per-session or per-metadata-key throttles.

None of these require rethinking the architecture. The decoupled design is the right foundation. This is about adding business primitives on top of infrastructure primitives that already work.

If anyone from Anthropic is reading this :) please add these to the platform. Every developer who ships a multi-tenant product on Managed Agents becomes a distribution channel that drives API usage at scale. You want us building products on this thing.

For internal tools, Managed Agents is ready today. Go use it. For multi-tenant products, plan on building a proxy — auth, billing, metering, rate limiting are all yours for now.

It’s a beta product and Anthropic iterates fast. The architecture underneath is the right foundation. For now, the abstraction covers the hard technical problems and leaves the hard business problems to you. If you’ve been building software long enough, you know that’s how platforms always start.