What You Actually Get When You Stop Building Your Own Agent Loop
Hey,
Last week I had a long conversation with a CTO who told me his team had spent four months on what he called "the agent platform" and they still were not in production. None of those four months had been spent on their actual product. They had been spent on sandboxes, retry logic, credential handling, a custom evaluator, and an observability layer that mostly worked.
He was not happy about it. I understood why.
Then I watched a workshop talk from Code with Claude London 2026 that walked through Claude Managed Agents end to end, and I realized that almost every line of code that team had written was now an API endpoint they could call from any Anthropic key. I want to walk you through what that means in practice, because I think a lot of teams are about to face the same question this CTO is facing.
Three key takeaways
- Managed Agents replaces the parts of an agent platform most teams rebuild badly. Sandboxes, retries, memory, multi-agent, credential vaults, observability.
- The four primitives are agents, environments, sessions, events. Everything else hangs off those.
- Outcomes are the feature you should look at first. You write a rubric, Claude iterates against it, criticizes its own work, and only stops when the rubric is satisfied. That single thing replaces a lot of orchestration code.
What it actually is
A set of API endpoints. You can call them today with any Anthropic key. They hand you a production ready agent and the parts around it. You pick what you need, ignore the rest, and build your product on top.
The list of things you no longer build yourself is long. Sandbox lifecycle. Credential vaults for MCP authentication. The tool calling harness with retries and error recovery. Memory and context management. Multi-agent coordination. A developer console with live debugging.
Each of those is a project on its own. Doing sandbox lifecycle well eats a quarter. Doing credential rotation securely is the kind of thing that ends up on a roadmap for six months and ships half finished. The boring infrastructure work that nobody puts on a product demo is the work this API takes off your team.
The four primitives
An agent is a template. System prompt, skills, tools, MCP servers, permissions per tool. You can decide that file read autoexecutes but bash needs explicit user approval. That permission layer is where your security team will spend the most time, and it is the right place for them to spend it.
An environment is the sandbox template. Network access yes or no, packages preinstalled, which infrastructure runs it. Anthropic ships their own. You can also bring your own through Cloudflare, Modal, Vercel, or run your own fleet. That matters when private data should not leave your VPC.
A session is the ongoing conversation. Same idea as opening a new chat in claude.ai, except you own it through the API. You can preload GitHub repositories or files into the container at session creation.
An event is the wire format, both directions. User events go in, agent events come out, session events tell you about lifecycle, span events tell you when long operations start and end.
Two directions of event flow. Four primitives. That is the entire mental model.
The outcome event is the part that matters
Here is the line from the talk that should make you pay attention.
"You can also define outcomes which allow you to like essentially pass us either a file or like a blob of text that is almost like a spec that Claude will try to do a first pass at implementing. And then it will essentially enter a mode where it tries to iterate and check its work against that rubric over and over again until it can actually satisfy that rubric."
You write the rubric. Claude builds the answer. Claude grades itself. Claude iterates. Claude grades itself again. It loops until it passes.
Most teams build this by hand. They notice the model gets close, then drifts, then needs verification. They wire up an evaluator. They write a critic prompt. They handle the back and forth. It takes a sprint to get right and another to make reliable.
Outcomes make it one event you submit. You focus on writing the rubric, which is where your domain expertise lives, instead of writing the loop, which is plumbing.
The demo used it on a deal evaluation task. Three companies, data scattered across Linear and uploaded files, a paragraph of natural language asking Claude to investigate, criticize its findings, and return only when satisfied. That was enough to kick off four sub agents working in parallel.
The live demo, briefly
The workshop started in a starter repo. The presenter implemented the list sessions endpoint in three lines.
``typescript const sessions = await client.beta.sessions.list(); return sessions.data; ``
The retrieve endpoint was similar. The chat UI lit up with all the sessions in his workspace.
For the streaming chat view he stopped writing code and switched to Claude Code. He pointed out something worth pulling out.
"Claude Code ships by default with the Claude API skill, which makes Claude really good at using all of the Anthropic APIs. Specifically the managed agents APIs."
The workflow is, you tell Claude Code the to-dos in your repo, it reads the API skill, it implements the endpoints, you carry on. The presenter said openly that he built the original demo the same way. Claude builds your Claude.
Onboarding to this API does not require reading the entire reference. The reference is already inside Claude Code.
Multi-agent that does not look insane
In the running demo the main agent spawned four sub agents to work on the deal evaluation. The console showed each as a parallel lane. Each had its own context window. Each could call tools. Each reported back to the coordinator. You could click into any one and see its events, tool inputs, tool outputs, timing.
Multi-agent done well looks boring. One coordinator. A handful of specialists with focused tools. A clear way to inspect each. The console view is exactly that.
Credential vaults handle the secrets. You provision MCP tokens once. They live with Anthropic. When Claude wants to use the Linear MCP or the Figma MCP, the tokens get injected without ever entering Claude's context window. Your end users never see them. Claude never sees them.
MCP tunnels handle the inverse. Private MCP servers inside your VPC, exposed to Claude through a secure tunnel, never reachable on the public internet. Private data sources stay inside your perimeter and Claude still gets to use them.
What this replaces
Toward the end of the talk the presenter listed what you would have built yourself.
Your own agent loop, or a framework with its bugs. A remote host. Context management. State transitions and recovery. Skill and MCP integration. Durable storage for sessions and events. A sandboxing fleet that reacts to Claude. End user authentication, secure and reliable.
Every one of those is a real project. Most teams ship one or two and duct tape the rest. The honest version of "we built it for you" is that the parts that are easy to start and hard to finish stop being yours.
There is a tradeoff. The managed surface is opinionated. If your product needs to deviate, the escape hatch is self-hosted environments, which give back the sandbox layer without giving up everything else. Enough flexibility for most teams. Not enough for teams doing something genuinely strange with execution.
When to use it, when not to
Use Managed Agents when your product is the experience on top. A deal flow tool, an internal copilot, a customer facing agent, a domain specific workflow. You spend your time on the rubric, the tools, the data, the UI.
Skip it when your product is the agent platform itself. Frameworks, evaluation harnesses, research infrastructure. Use the SDK directly.
The hard middle case is teams that have already built half a platform internally. The question becomes whether to keep maintaining what you have or migrate and put your engineers on product work. The answer depends on how much of your platform is load bearing and how much is technical debt waiting to be sunset.
Observability that ships
The developer console has a sessions view per agent. You click into a running session and see it happen live. Coordinator at the top, sub agents in parallel lanes, every tool call expanded with input, output, and timing.
Agents are versioned. Change a prompt or a tool and regret it, you roll back. Nothing is deleted. That sounds obvious until you remember how many prompt management systems are basically a text file with no history.
Memory stores are quietly important. Every session reads from and writes to a memory store. New sessions start better than the one before. You can inspect what Claude remembers. You can edit memories if Claude got something wrong. You can seed memories before a session starts. This is long term memory as a boring useful primitive, in the API today.
Skills are the connective tissue
The split between agents and skills matters and it is worth a paragraph on its own. Agents are templates with system prompts, tools, permissions, and MCP connections. Skills are reusable units of know how that any agent can pick up. You write a skill once. You attach it to multiple agents. You update a skill and every agent picks up the update on the next session.
That is the composition that ends up mattering. You do not stuff everything into a system prompt. You do not fork an agent definition every time you want a new capability. You build a vocabulary of skills, you build a small set of agents, and the combinations cover most of what your product needs to do.
The presenter pointed out that Claude Code ships with the Claude API skill by default. That is why his live coding was fast. The same trick works for your team. Build a skill that captures how your team does a thing, attach it to the right agent, and every session inherits that know how. Skills compound. Agents do not.
What the on stage moment told me
There is one part of the workshop that stuck with me longer than any of the API details. The presenter said openly that he had built the demo by asking Claude Code to build it for him. He repeated the trick on stage, gave Claude the to-dos, watched it work, and joked while waiting for Opus to finish.
The interesting thing is not that he used Claude to build with Claude. The interesting thing is that the workflow was visibly normal. He did not introduce it as a gimmick. He used it the way you would use a colleague. That is the shape of how this API gets adopted. Not as a thing you study, but as a thing you ask Claude Code to use for you.
If you are starting from zero with Managed Agents, that is the lowest cost first step. Open Claude Code in an empty repo. Ask it to scaffold a small agent that does one thing your team cares about. Watch what it produces. Use the developer console to inspect the session. You will learn more in twenty minutes that way than from a week of reading docs.
The shape of the question
That CTO with four months sunk in a platform asked me whether he should keep going or migrate. I told him to write down the parts of his platform that were load bearing for his product, the parts that were customizations of standard infrastructure, and the parts that were just rebuilds of common patterns. Then to map each row against what Managed Agents now does.
He came back the next day with most of the rows marked as rebuilds. That made the answer easier than he wanted it to be.
If you are in the same position, do the same exercise. Be honest about which rows are actually your product and which rows are infrastructure you have been carrying. The infrastructure rows are now an API call.
The plumbing is done. The interesting work is what you do with it.
Reply and tell me where you are with this. Have you built your own agent platform? Are you on the fence? What is the part you would not give up? I read every reply.
Marco