What You Actually Get When You Stop Building Your Own Agent Loop
A walkthrough of Claude Managed Agents, the workshop demo, and why this changes what a small team can ship.
Three key takeaways
- Managed Agents are a set of API endpoints that hand you the parts of an agent platform most teams end up rebuilding badly: sandboxes, tool harness, retries, memory, multi-agent coordination, observability, and credential vaulting.
- The primitives split into four things you actually configure: agents (the template), environments (the sandbox), sessions (the running conversation), and events (the stream both directions). Everything else hangs off those.
- Outcomes are the underrated feature. You hand Claude a rubric, it iterates against it, criticizes its own work, and only stops when the rubric is satisfied. That single primitive replaces a lot of orchestration code.
A workshop room at Code with Claude London 2026. The presenter asks who has heard the phrase "Claude Managed Agents" today. Most hands go up. Then he asks who actually knows what it is. Most hands drop.
That gap is the whole point of this article. There is a fair amount of marketing language floating around the announcement, and underneath it there is a concrete API with concrete primitives. If you have ever built an agent on top of the raw Anthropic API, or built one on top of a framework that wraps it, you already know the work that vanishes when you use this. If you have not, the workshop walkthrough is the clearest way to see what is now off your plate.
I am going to walk through the demo the presenter ran, but with the bits that matter for production work pulled forward. The full talk is linked at the end.
What Managed Agents actually is
The presenter put it bluntly. Managed Agents is a set of API endpoints. You can call them with any Anthropic API key today. They give you access to a production ready agent and the primitives around it, so you pick what you need and build your product on top.
The list of things you no longer have to build yourself is long. Giving Claude access to a computer. Credential vaults for injecting MCP authentication for your end users. The tool calling harness with retries and error recovery. Memory and context management. Multi-agent coordination. A developer console with live debugging views into what every agent is doing right now.
Each of those is a small project on its own. Sandbox lifecycle alone, done well, eats a quarter. Credential rotation done securely is the kind of thing that ends up on a roadmap for six months and then gets shipped half finished. The framing "we built the boring scaling parts so you can build your product" sounds like a slide, but in this case the slide matches the API surface.
There are four primitives to learn.
Agents, environments, sessions, events
An agent is a template. You define a system prompt. You define which skills it has access to. You define which tools, which MCP servers, and which permission rules apply per tool. File read might autoexecute, but executing bash or hitting your production database via MCP requires explicit user approval. That permission layer is where security teams will spend the most time, and it is the right place for them to spend it.
An environment is the sandbox template. Does the container have network access? Are there packages preinstalled from npm or pip? Which sandbox infrastructure runs it. Anthropic ships their own, and as of the same event you can bring your own through Cloudflare, Modal, or Vercel, or run your own sandboxing fleet. That matters when you have private data inside a VPC that should never leave it.
A session is an ongoing conversation between you and Claude on that agent and that environment. It is the equivalent of opening a new chat in claude.ai or starting a Claude Code session in your terminal, except you own it through the API. When you create a session you can pass in GitHub repositories or files that should be preloaded into the container, and those get downloaded and provisioned for you.
An event is the unit on the wire. Events go both ways.
User events are what your application sends in. Text, images, documents, interrupts to stop Claude when it drifts, tool results for tools you executed on your side, confirmations for human in the loop steps. And outcomes, which I will get to in a moment, because those are the most interesting thing in the entire API.
Agent events are what Claude sends back. Messages, compaction notifications when its context window is getting recompressed, tool calls it is making, and multi-agent coordination signals when it decides to spawn helper agents.
Session events tell you about the lifecycle of the session itself. Retries, errors, idling, termination. Span events tell you when long operations are starting and ending, so you can show the user that Opus 4.7 is generating a fifteen page document and is not actually stuck.
That is the entire mental model. Four primitives. Two directions of event flow.
Outcomes are the part to pay attention to
Here is the line from the talk that should make you sit up.
"You can also define outcomes which allow you to like essentially pass us either a file or like a blob of text that you wrote that is almost like a spec that Claude will like try to do a first pass at implementing or doing the thing that the spec defines. And then it will launch, it will essentially enter a mode where it tries to iterate and check its work against that rubric over and over again until it finds that it can actually satisfy that rubric."
In other words, you write the rubric. Claude builds the answer. Then Claude grades itself against your rubric. Then it iterates. Then it grades itself again. It loops until it passes or until you stop it.
This is the pattern most teams build by hand after their first three weeks with an agent. They notice the model gets close, then drifts, then needs to be told to verify. They wire up an evaluator. They write a critic prompt. They handle the back and forth. It is the kind of thing that takes a sprint to get right, and another sprint to make reliable.
Outcomes make it a single event you submit. The model knows what mode it is in. The session reports when outcome processing starts and ends. The work is visible in the console. You get to focus on writing the rubric, which is where your domain expertise lives, instead of on writing the loop, which is plumbing.
The demo used it on a deal evaluation task. Three companies, Bridgewell Dynamics, Norwood Automation, and Acme Robotics, with data scattered across Linear and uploaded files. The rubric was a paragraph of natural language asking Claude to investigate, criticize its own findings, and return only when satisfied. That was enough to kick off four sub agents, each with their own context windows and tools, doing web research and file reads in parallel and reporting back to the coordinator.
The demo, with the parts that matter
The workshop started in a starter repo with a stubbed chat UI. The presenter ran the dev server, hit a missing endpoint for listing sessions, and implemented it live by hand. The implementation was three lines.
``typescript const sessions = await client.beta.sessions.list(); return sessions.data; ``
That is the entire list endpoint. The retrieve endpoint was similar. The chat UI lit up with all the sessions in the workspace, each showing the agent name, the connected MCPs, the tools available, and the metadata you would expect.
For the streaming chat view he stopped writing code and switched to Claude Code. The talk had a neat observation that is worth pulling out.
"Claude Code ships by default with the Claude API skill, which makes Claude really really good at using all of the Anthropic APIs. Specifically the managed agents APIs that we have. And that's really all you have to do to make Claude really really good at using this thing."
So the workflow is, you tell Claude Code the to-dos in your repo, it reads the API skill, it implements the streaming endpoint and the send endpoint, and you carry on with the demo. The presenter said openly that he had built the original demo the same way, on stage, with Claude helping. Claude builds your Claude.
That is a small detail with a large implication. Onboarding to this API does not require reading the entire reference. The reference is already inside Claude Code. You give it a goal, it knows the endpoints.
Multi-agent without the orchestrator soup
In the running demo, the main agent spawned four sub agents to work on the deal evaluation. The console view showed each one as a horizontal lane. Each had its own context window. Each could call tools. Each reported back to the coordinator. You could click into any agent and see the individual events, the tool inputs, the tool outputs, the timing.
Multi-agent done badly looks like a graph diagram with twelve boxes and arrows everywhere and someone presenting it like it is an achievement. Multi-agent done well looks boring. One coordinator. A handful of specialists with focused tools. A clear way to inspect what each one is doing. The console view in the demo is exactly that, and the API matches.
Credential vaults are the other piece that quietly does a lot. You provision MCP authentication tokens once. They are stored with Anthropic. When Claude wants to use the Linear MCP or the Figma MCP, the tokens get injected into the request without ever entering Claude's context window. Your end users never see them. Claude never sees them. They just work.
MCP tunnels handle the other direction. You have a private MCP server inside your VPC that should never be exposed on the public internet. You set up a tunnel. Claude reaches the MCP through that tunnel. Your 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 you would have picked a framework and inherited its bugs. A remote host for it. Context management. State transition handling. Recovery logic. Skill and MCP integration. A durable storage layer for sessions and events. A sandboxing fleet, probably on Cloudflare, with logic that reacts to what Claude is doing. End user authentication, securely and reliably.
Every one of those is a real project. Most teams ship one or two of them and then 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 are the parts you stop owning.
There is a tradeoff. You are running on a managed surface. Your sandbox lifecycle, your retry behavior, your tool calling harness are all opinionated. If your product needs to deviate from those opinions, you will hit a wall. The escape hatch is self-hosted environments, which give you back the sandbox layer without forcing you to give up the rest. That is enough flexibility for most teams. It will not be enough for teams that need to do something genuinely strange with execution.
When to use it, when not to
Use Managed Agents when your product is the experience on top of the agent. You are building a deal flow tool, an internal copilot, a customer facing agent, a domain specific workflow. You want to spend your time on the rubric, the tools you expose, the data you connect, the UI your users see.
Do not use Managed Agents when your product is the agent platform itself. If you are building an agent framework, an evaluation harness, or research infrastructure that needs the raw model interface, the managed surface gets in the way. Use the SDK directly.
The interesting middle case is teams that have already built half of a platform internally. The question becomes whether to keep maintaining what you have or migrate to the managed surface and put your engineers on product work. The answer depends on how much of your internal platform is load bearing and how much is technical debt waiting to be sunset.
Observability is not optional, and it ships in the box
The developer console has a sessions view per agent. You click into a running session and you see what is happening live. Coordinator at the top. Sub agents as parallel lanes underneath. Each tool call expanded with its input and output. Each one timed, so when something is slow you can see exactly which call is slow.
I have built observability for agent systems three times. Each time it took weeks, ended up with gaps, and made debugging just barely tolerable. The console here is the version you would have built if you had another quarter to spend on it. The events listing, the multi-agent lane view, the per tool timing, and the live updating state are all there.
There is one other small but real thing. Agents are versioned. If you change a system prompt or add a tool and regret it, you roll back to a previous version. Nothing is deleted. That sounds obvious until you remember how many prompt management systems out there are basically a single text file with no history.
The skill side and what it adds
Skills are the connective tissue. The presenter mentioned that Claude Code ships with the Claude API skill by default, which is what made the live coding part go fast. The same idea applies to your own skills. You write a skill that captures how your team does a thing, you attach it to an agent, and any session on that agent now knows how to do it.
The split between agents and skills matters. 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 can build a skill once and use it across multiple agents. You can update a skill and every agent that references it picks up the update on the next session.
That is the boring composition that ends up mattering. You do not have to put everything into the system prompt. You do not have to 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 your product surface.
Where this goes
The agent definition concept is doing the same job that plugins are starting to do across the Claude ecosystem. The presenter said as much in response to a question about plugins. They are working on it. The two ideas are close. Expect them to converge.
Memory stores are quietly important. Every session reads from and writes to a memory store. Every new session gets to start better than the one before it. You can inspect what Claude remembers. You can edit those memories if Claude got something wrong. You can seed memories before a session starts. This is the boring, useful version of long term memory, and it is in the API today.
The combination of outcomes, multi-agent coordination, memory stores, and skills is what makes the platform feel like a real platform rather than a chat interface with extras. You can build a system that knows your workflows, runs them in parallel, grades its own output against your standards, and gets better at your job over time.
That is a different product than a chatbot. It is the product a lot of teams have been trying to build for two years and giving up on because the plumbing kept eating their roadmap.
The plumbing is done. The interesting work is now what you do with it.
Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.
This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.
My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.
Source talk: Build a production-ready agent with Claude Managed Agents at Code with Claude London 2026. https://youtu.be/jWWsLe4Gh5Y