Autonomy is earned. This is the order you earn it in.

The stalls we have run into, in our own builds and in the research corpus we maintain, did not come from model quality. They came from something built in the wrong order, and almost always the same something: autonomy arrived before the machinery that makes autonomy survivable. A demo that works once is a model doing a party trick. A system you can leave running is a model inside a harness, inside a loop, behind a gate, under a budget, on a runtime somebody else maintains. Add the primitive underneath and the context it sees, and that is seven decisions, in order. This note is the order, what each step buys you, and the question that tells you whether you have cleared it or just skipped it.

The build order for production agents.

Read the ladder below as a permissions system rather than a checklist. Each rung is a thing you build, and clearing it is what grants you the right to build the next one. Skipping is possible and common. It just relocates the cost to production, where it is paid in incidents instead of in weeks.

In order, the seven are: pick the simplest primitive, build the harness, engineer the context, gate on evals, run the right loop, design cost and termination, then buy the orchestration layer. Autonomy sits on top of all seven.

Do you actually need an agent?

The first decision is the one most often skipped, because "we are building an agent" is what got the project funded. There are two rungs below the word. Function calling is a model producing a structured call against a schema you defined, and your code decides what happens next. Tool calling adds a loop where the model chooses among tools and reads back results. An agent is that loop plus the model deciding its own control flow: what to do next, and when it is finished.

Each step up buys generality and sells three things to pay for it. Latency, because a control loop runs more model calls than a single structured call does. Predictability, because control flow the model owns is control flow you cannot enumerate in advance. Money, for the same reason. We wrote the vocabulary out in the glossary note, and the operational rule has not changed since: escalate at a structural constraint, never at an aspiration.

What each rung actually buys.

Rung two, the harness. LangChain's framing is the cleanest short version we have seen: an agent is a model plus a harness, where the harness is everything that is not the model.[1] System prompts, tool definitions and their descriptions, the filesystem and sandbox it runs in, the orchestration logic, the hooks and middleware, memory and search, planning and self-verification. It is a vendor's article, so take the taxonomy and leave any claim about outcomes. The taxonomy is the useful part, because it turns "the agent misbehaved" into a question with a location: which harness component was supposed to prevent that, and was it built?

The reason it comes before autonomy is mundane. Autonomy is the right to act without a human reading the output first. You cannot responsibly grant that right to a system whose actions are not logged, whose tools are not bounded, and whose state is not inspectable. Build the guardrails, memory, tools, and logs, then delegate one stage further and see what happens. The alternative is granting autonomy and discovering the harness requirements from the incident report.

Rung three, context. The harness's hardest job is deciding what the model gets to see. Anthropic frames this as finding the smallest set of high-signal tokens that produce the outcome you want, and notes that recall degrades as the window fills, a problem bigger windows do not solve.[2] Being first-party, this is them describing their own system's behavior, which is the tier where a vendor claim is worth the most. The practical shape is three habits: pull data at runtime instead of pre-loading everything, keep tool sets minimal and non-overlapping, and decide deliberately how you compact a long run. Their test for tool design is the one we steal most often. If a person cannot say which of two tools to use, the model cannot either.

Memory is the same problem at a longer time scale, and it has its own discipline now: what gets written, what gets managed, what gets read back. We went through that in the memory note, and the short version is that a bounded window turns notes into working memory rather than reference material.

Rung four, the gate. Evals are what make every rung above this one changeable. Without them, swapping a model, editing a prompt, or adding a tool is a coin flip you cannot score, so teams stop touching a working system and it rots in place. The shape that survives contact with a real schedule is two-tier: a fast structural tripwire that runs in CI on every change, then comprehensive semantic suites that run less often. Ours is deliberately small, six lines, described in the eval suite note, and small is the point. An eval suite nobody runs is documentation.

Two things belong in the suite that teams routinely leave out. Score the action rate, meaning how often the agent actually did something, and score termination, meaning whether it stopped. Task success alone hides both of the failure modes in the next section.

Rung five, the loop. Ng's framing is that AI-assisted building runs as nested feedback loops at different time scales: the agent iterating on its own work in minutes, the developer steering and re-specifying over tens of minutes to hours, and external feedback from real users over hours to days or weeks.[3] This is a practitioner's considered opinion, not a study, and the intervals are his own experience. We keep it anyway because it is diagnostic. Most wasted effort in an agent project is effort spent in the wrong loop: hand-QA-ing output the agent could check itself, or polishing an inner loop when the target it is converging on is wrong. His reframing of human "taste" as a context advantage is the more useful half. The human stays in the loop for exactly as long as the human knows something the system does not, which also tells you when a step becomes automatable.

The two ways it fails once it is running.

Rung six is where most of our failure-mode field notes land, and for a reason. Cost and termination are not operational concerns to be added after launch. They are design primitives, because both production failure poles are failures of the same missing thing: a bounded notion of enough.

The idle pole has a name now, idle-drift, from a long-horizon benchmark (a preprint, cited and tiered in that note) where one model sat idle for weeks of simulated time while its status reports stayed coherent; we went through it in the stalled-agent note. We wrote the runaway version up as a postmortem and the design answer as a planner with a confidence budget. The instrumentation that makes either tractable is per-step spend, sorted by spend rather than by call volume, which is the point of treating cost as a first-class metric. The order matters here too: instrument first, then gate or truncate or downgrade the model tier or cache, and put every one of those changes through the eval gate from rung four. Cost work without evals is how a system gets cheaper and quietly worse.

Build or buy the orchestration layer.

Rung seven, the runtime. If a packaged product already does the whole task, buy it: this ladder is for the work no product covers. Once you are building, the build-versus-buy question is rarely about the agent. It is about the runtime underneath it. Default to a maintained orchestration framework and build a custom one only at a hard wall. The cost of custom is not writing it. Writing it is a pleasant fortnight. The cost is the maintenance surface and the bus factor: a runtime only your team understands, which your team now owns forever, against a framework whose upgrades arrive from somebody else's payroll. The custom-orchestrator note makes that case at length.

Auditing a project you inherited.

Run the ladder as an audit. Most projects that feel stuck are sitting on an unbuilt rung, and the symptom rarely points at it. You do not have to be the engineer to run this pass: five questions, and the answers tell an owner or an ops lead which rung is open.

1. Ask what happens if the agent is wrong at 3am.

   If the answer involves a person noticing, the autonomy exceeds the harness. That is rung two, and no rung above it can make up for it. Log surface, tool bounds, and inspectable state come before the next delegation, not after the next incident.

   do · locate the missing harness component before adding capability
2. Ask when the prompt last changed, and how anyone knew it helped.

   A team that has stopped touching a working agent is a team without an eval gate. Rung four. Build the fast structural tripwire first: it runs on every change and it is what makes the system editable again.

   do · get a CI-speed eval suite in place before the next prompt edit
3. Ask for the cost of the single most expensive run last month.

   Not the average, and not the total. If nobody can produce it in a minute, per-step spend is not instrumented, and rung six is open. Sort by spend, not by call volume: the expensive path is rarely the busy one.

   do · instrument per-step cost before negotiating any model contract
4. Ask what the agent does when it cannot succeed.

   "It keeps trying" and "it stops and tells someone" are different products. If termination was never designed, you own both failure poles and have measured neither. Add both to the eval suite in the same week.

   do · write down the stop condition, then score it
5. Ask whether a function call would have done it.

   Worth asking even of a system already in production. Some deployed agents are a control loop wrapped around a task that never branches, and collapsing one back down a rung buys back latency, predictability, and margin at once.

   do · re-test rung one against the behavior you now have data for

What this does not license.

This is doctrine, which is a weaker thing than evidence and should be read as one. It is our ordering, drawn from our own builds and a corpus we maintain, and we have not run the experiment that would test it: two teams, same brief, one building in this order and one not. Nobody has, as far as we know. What we can say is narrower. Each expensive failure mode our field notes work through maps to a rung that was missing, and the rungs are ordered by which skip tends to surface first. Those notes are illustrative worked examples, so this is a consistency check on the doctrine, not a test of it.

The sources carry their own limits, and they are not interchangeable. The harness taxonomy is a vendor describing a landscape it sells into, so it is vocabulary rather than evidence. The context guidance is first-party, which makes it strong about that vendor's models and an assumption about anyone else's. The loops framing is one practitioner's experience with his own projects, and the time bands in particular are illustrative. We use all three because they converge from different directions, not because any one of them establishes the order.

Two boundaries on the doctrine itself. It is a build-and-execution story, so it underweights the runtime control plane that wraps a deployment: the tool interface standard, the multi-provider gateway, layered guardrails, and observability. Those are load-bearing in our own stack and they are not rungs in this ladder, which is a gap in the ladder rather than a statement about their importance. And the whole thing is written for agents that do work inside systems you control. An agent acting on a customer's behalf in public adds obligations this note does not cover at all.

If you are partway up this ladder and want an outside read on which rung is open, the contact form is the fastest way in. Tell us what the agent does and what it costs, and we will send back a written assessment of where the order broke, free.