By the end of this chapter you understand what it means to let a loop run on someone else's infrastructure, the handful of building blocks it is made of, and, honestly, when this is worth reaching for and when it is not.
AVATAR OPENER · ~90s
Watch: a loop that runs on hosted infrastructure instead of on your machine
HeyGen avatar · generated, consistent presenter
This is the top of the ladder, and it is the most technical chapter in the course, so let me be plain about what it is for. Everywhere so far, when you built a loop, it ran where you were: your machine, your session, you nearby. That is right for almost everything. But some jobs need to run for a long time, or survive a hiccup, or run many at once, or keep going when your laptop is closed. For those, you let the loop run on hosted infrastructure. That is a managed agent.
The idea is small once you see it. You already know the agent loop: the model reasons, uses a tool, gets a result, reasons again, until done. A managed agent is that exact loop, running inside a container on Anthropic's infrastructure instead of on your computer. You do not run the loop yourself and you do not babysit it. You define it, start it, and read what it did.
A loop on your machine
You run it, you watch it, it lives as long as your session does. Perfect for hands-on work you are steering, which is most of what you do.
Result: full visibility, but it stops when you do.
VS
A loop on hosted infrastructure
It runs in a managed container: long-running, able to survive a hiccup, able to run many in parallel, keeps going when you are away.
Result: it outlives your session, at the cost of some visibility.
A managed agent is the same loop you already understand, running somewhere that does not switch off when you do.
You stop running the loop and start commissioning it. You write what done means, hand it off, and read the result, the way you would with a capable contractor.
THE BUILDING BLOCKS
Underneath, a managed agent is assembled from a few named parts. You do not need to master the machinery to understand the shape, and the shape is what tells you whether this is the right tool.
The agent
The definition: what this agent is, what tools it has, how it should behave. Written once, run many times. The blueprint.
A session
One individual run of that agent on one task. You can start many sessions from the same agent, each working independently.
The environment
The sandbox it runs in: a contained space with the tools and access it needs and firm limits on what it can reach. Safety by boundary.
The outcome check
A rubric plus a grader that define and check what "done" actually means, so the agent works toward a real standard, not just "finished".
Two of these are worth dwelling on because they change how you work. First, you interact with a running agent by sending it events and reading its events back, rather than sitting in a live loop watching every step. It is more like exchanging messages with a worker than looking over their shoulder. Second, and this is the genuinely powerful part, done is defined by a rubric and checked by a grader. You write down what a good result looks like, and a separate check scores the agent's work against it, so the agent can keep going until it actually meets the bar instead of stopping when it feels finished. That is the Roast Me discipline and the locked-goal discipline, made automatic.
One honest caveat, since this is the course that refuses to oversell: the grader is itself a model, so it can be fooled, and an agent can learn to satisfy the grader rather than the goal. Automated grading raises the floor. It does not remove your need to spot-check real output before you trust an unattended agent with anything that matters.
WHEN THIS IS WORTH IT, AND WHEN IT IS NOT
Here is the honest part, because the temptation at the top of a ladder is to climb it just because it is there. Most of your work does not need a managed agent, and reaching for one when a manual loop would do just adds distance between you and the work.
Can you run it yourself?
If a loop on your machine, or a scheduled Cowork task, does the job, do that. It is simpler and you keep full sight of it.
Does it need to outlive you?
Long runs, surviving failures, many in parallel, running while you are away. If none of these, you do not need hosting.
Then reach for hosted
When the job genuinely needs to run long, reliably, at scale, or unattended, a managed agent is the right and worth-it move.
The rule is the same one that has run through this whole part: match the tool to the job, and prefer the simpler tool. A managed agent earns its complexity when the job truly needs to run for a long time, keep going through a stumble, run in many copies at once, or continue while you are not there. It does multi-agent work too, a coordinator handing pieces to specialists, and for sensitive actions you can require a human to approve before it proceeds. All real, all powerful, and all more than most jobs need. If your honest answer to "does this need to outlive my session" is no, you are done at the previous chapters.
Decide if a job needs a managed agent
I have a job I am considering running as a hosted, managed agent
instead of a loop on my machine.
The job: [describe it].
Help me decide honestly. Ask me:
- Does it need to run longer than a normal session?
- Does it need to survive a failure and keep going?
- Does it need to run in many copies at once?
- Does it need to run while I am away, unattended?
If the answer to all of those is no, tell me plainly that a manual
loop or a scheduled task is the better, simpler choice, and do not
talk me into the fancier tool. If yes, sketch the smallest managed
agent that would do it: its definition, its sandbox, and how I would
define "done" with a rubric.
Three of your four answers are no. This job runs for a few minutes,
once a day, and you are around when it does.
So you do not need a managed agent. A scheduled task from the last
part does this more simply and keeps you closer to it. Reach for
hosting only if this grows into something that must run for hours,
or survive failures, or fan out into many at once.
A managed agent is genuinely a real thing to build, and it needs everything from this technical part together: the terminal, a project, the loop thinking, the cost awareness. The companion repo has the smallest useful example under managed-agents/, one agent that does one real job end to end, defined, sandboxed, and graded. Clone it to see the shape in the flesh. But treat it as the ceiling of the ladder, not the default rung. You climb here only when the job below genuinely reaches for it.
NOW YOU TRY · EVALUATE
Decide honestly whether a job needs hosting
Take one ambitious job you have imagined automating, ideally one where you were tempted to reach for the most powerful option. Use the decision prompt above. Answer the four questions honestly: does it need to run long, survive failure, run in parallel, or run unattended? Let the honest answer decide. If it does not need hosting, name the simpler tool that fits instead. If it does, sketch the smallest managed agent that would do it.
Right if you can say, for one real job, whether it genuinely needs a managed agent, and you chose the simplest tool that actually fits rather than the most powerful one available.
Show the worked solution
The drill works when you talk yourself OUT of the fancy option as readily as into it, because that judgment is the real skill at the top of a ladder. Say the tempting job is "an agent that runs my whole content pipeline." It sounds like exactly what managed agents are for. But answer the four questions honestly and it often comes apart. Does each piece need to run for hours? Usually not, most steps are minutes. Does it need to survive failures unattended? Maybe the nightly gather does, but the drafting is something you want to review anyway. Does it need many parallel copies? No, you are one person with one pipeline. Does it need to run while you are away? Only the collection step, not the parts where your judgment is the point. So the honest answer is a split: the overnight gather-and-summarise genuinely benefits from running hosted and unattended, and that one piece is a fair managed agent, small, sandboxed, with a clear "done" rubric. The rest is better as scheduled Cowork tasks and hands-on loops where you stay close. That decomposition, hosting the one piece that truly needs it and keeping the rest simple, is a far better outcome than building one giant managed agent to run everything, which would put distance between you and exactly the steps where your taste is the value. The ceiling of the ladder is powerful. The skill is climbing to it only for the job that actually lives up there.
WATCH FOR
✗You reach for a managed agent because it is the most powerful option. Power is not the goal, fit is. If a manual loop or scheduled task does the job, use that and stay closer to the work.
✗You define the agent but not what "done" means. Without a rubric and a grader it stops when it feels finished, not when it meets the bar. Define done explicitly and let it be checked.
✗You give the hosted agent broad access. It runs unattended, so the sandbox matters more, not less. Contain it tightly and require human approval for sensitive actions.
✗You build one giant agent to run everything. Host only the piece that truly needs to run long or unattended. Keep the judgment-heavy steps as simpler tools you stay close to.
WHAT YOU LEARNED
The takeaways
A managed agent is the agent loop you already know, running on hosted infrastructure instead of your machine, so it can outlive your session.
It is built from a few parts: the agent (the definition), a session (one run), the environment (its sandbox), and an outcome check (a rubric and grader that define done).
You commission it rather than run it: send it events, read its events back, and let a grader hold its work to a real standard.
Reach for it only when the job genuinely needs to run long, survive failures, run in parallel, or run unattended. Otherwise a manual loop or scheduled task is simpler and better.
The skill at the top of the ladder is restraint: host the one piece that truly needs it, keep the judgment-heavy steps close, and never build more agent than the job requires.
Your project · know the ceiling
For one ambitious job in your thread project, decide honestly whether it needs hosting, and pick the simplest tool that fits. That closes Part Five and the technical climb. You now know the whole ladder, from a free single-model council to a hosted agent. Part Six brings it home to the thing that outlasts every tool: keeping it honest, starting with Founder Mode as a real operating system.
The top of the ladder is the most impressive rung and the one to reach for least often. A managed agent is real power, worth it exactly when a job must run long, survive, scale, or run without you. The operator move is not climbing to the top. It is knowing which rung the job actually needs.