The five levels: a capability ladder

“Build an agent” is not a spec. It is a category, and the systems inside that category differ from each other by more than an order of magnitude in cost, complexity, and time-to-production.

The taxonomy in this chapter gives you a way to be specific. Five levels, each adding exactly one capability to the one below it. Once you can say “we need a Level 2, not a Level 3,” scoping conversations get dramatically shorter.

We are going to walk one product idea up all five rungs so you can see the shape of each.

The running example

You work at a mid-size company. Every quarter, a small internal team spends a miserable week assembling a competitive intelligence brief: what did our four main competitors ship, what did they price it at, what are customers saying, and what should we do about it.

It is knowledge work. It is repetitive but not identical each time. It requires pulling from sources that change. It ends in a document a human reads and acts on.

Perfect candidate. Let us see what it looks like at each level.

Level 0: The Core Reasoning System

A language model on its own. No tools, no memory, no connection to anything live. It answers from what is in its weights.

This is not an agent. It is the component an agent is built around — the reasoning core, in isolation.

What it can do for our brief: a surprising amount, actually. Ask it “what dimensions should a competitive brief in the audio hardware market cover, and what’s a good structure for it?” and you will get a genuinely useful answer, because that is a question about established practice and its training data is full of established practice. It can draft the template. It can explain what a price-laddering strategy is. It can critique your outline.

What it fundamentally cannot do: tell you anything that happened after its training cutoff. Ask it “what did Competitor B announce last Tuesday” and it will either decline or invent something. The invention is the dangerous case, because an unconnected model has no way to distinguish “I remember this” from “this is the most plausible-sounding thing.”

Complexity cost: approximately zero. One API call, one prompt, no infrastructure.

When Level 0 is the right answer: more often than people admit. If the task is transformation, explanation, drafting, classification, or reformatting — operations on text you already have — you do not need tools. Adding them is pure overhead.

How you know you have outgrown it: the moment a correct answer requires a fact the model could not have memorized. That is the whole test.

Saying it out loud. Level 0 is just the model on its own — no tools, no memory, nothing live. It’s not an agent, it’s the reasoning core an agent gets built around. And it’s the right answer more often than people admit: if the job is drafting, explaining, classifying, or reformatting text you already have, tools are pure overhead. The test for when you’ve outgrown it is a single sentence — the moment a correct answer needs a fact the model couldn’t have memorized. And the failure mode at Level 0 isn’t refusing, it’s inventing, because an unconnected model has no way to tell “I remember this” apart from “this is the most plausible-sounding thing.”

Level 1: The Connected Problem-Solver

Add tools. The model can now reach outside its own weights: search the web, query a database, hit an API, run a retrieval-augmented generation (RAG) lookup over your internal documents.

This is the first level that is genuinely an agent, because now the loop matters. The model requests information, receives it, and reasons over what came back.

Our brief at Level 1: you give the agent a web search tool and an internal-docs retrieval tool. You ask: “What did Competitor B announce in the last quarter?” It searches, reads results, and synthesizes an answer grounded in what it actually found rather than what it half-remembers.

You run it four times, once per competitor, and paste the outputs into your template yourself.

What it still cannot do: plan. Level 1 handles “answer this question, possibly by looking something up.” It does not handle “produce this document,” because that requires decomposing a large goal into a sequence of sub-questions and managing what it learned along the way. You are still the planner. The agent is a very good research assistant that you have to direct one query at a time.

Complexity cost: moderate, and this is the biggest single jump in the ladder in terms of what you now have to worry about. You have introduced tool schemas that must be described well enough for a model to use correctly. You have introduced failures that are not model failures — the API is down, the search returns garbage, the database times out. You have introduced a security surface, because content the tool returns goes into the model’s context and can therefore influence its next decision.

When Level 1 is the right answer: most production agents in 2026 are Level 1, and most of them should be. Question answering over your own data, support agents that look things up, internal assistants that query systems of record. If the shape of the task is “answer well, grounded in real data,” stop here.

Saying it out loud. Level 1 is where it actually becomes an agent, because you add tools and now the loop means something — it asks for information, gets it back, and reasons over what came back. This is where most production agents live in 2026, and most of them should stay there: question answering over your own data, support bots that look things up, internal assistants hitting a system of record. What it still can’t do is plan — you’re the planner, feeding it one query at a time. And it’s the biggest jump in the ladder for what you now have to worry about, because you’ve inherited a whole class of non-model failures — the API is down, search returns garbage — plus a security surface, since whatever a tool returns lands in the context and can steer the next decision.

Level 2: The Strategic Problem-Solver

Add planning and deliberate context management.

The capability that emerges here is what the whitepaper calls context engineering: the agent actively deciding what information to carry forward, what to discard, and how to shape the next query based on what the last one returned.

That phrase sounds abstract until you watch it happen. A Level 1 agent given “find a coffee shop halfway between my office and my client’s office” will search for “coffee shop halfway between…” and get nothing useful. A Level 2 agent recognizes it has two sub-problems: first compute the midpoint, then search near the midpoint. It calls a maps tool, gets back “Millbrae, CA,” and constructs a new query from that output — coffee shop in Millbrae, CA, min_rating=4.0 — where the 4.0 came from noticing the user said “good.”

That construction step is the whole level.

Our brief at Level 2: you give it the goal, once. “Produce this quarter’s competitive brief covering these four competitors.”

It plans: four competitors, four dimensions each, then a synthesis section, then recommendations. It works through them, and — critically — it manages what it accumulates. After researching Competitor A it does not carry sixty thousand tokens of raw search results forward into the Competitor B research; it distills what it found into a compact summary and carries that. When it gets to the synthesis section, it is reasoning over four clean summaries, not four dumps.

You get a draft document.

What it still cannot do well: the quality ceiling is the model’s ability to be good at every part of the job simultaneously. The same system prompt has to make it a decent researcher, a decent analyst, and a decent writer. Those pull in different directions, and past a certain scope the instructions start to conflict with each other.

Complexity cost: significant, and mostly in places that surprise people.

Trajectories get long, so cost per run climbs steeply — and unlike Level 1, you cannot easily predict how long a trajectory will be. Failures get subtle: the agent researched three competitors well and one badly, and the output looks uniformly confident. Debugging requires reading traces, because “the answer was wrong” no longer localizes to a single call. You now genuinely need a step cap and a token budget, because a planning agent that gets confused can loop for a very long time while looking busy.

When Level 2 is the right answer: the goal takes multiple dependent steps, and the steps depend on findings rather than on fixed branches. Research tasks, multi-system investigations, anything where “it depends what you find” is the honest description.

Saying it out loud. Level 2 adds planning and, more importantly, context engineering — the agent deciding what to carry forward and what to throw away. The example that makes it click: ask for a coffee shop halfway between two offices. A Level 1 agent searches that phrase and gets nothing. A Level 2 agent sees two sub-problems, calls a maps tool, gets “Millbrae, CA” back, and builds a new query out of that output. Constructing the next query from the last result is the whole level. The cost is that trajectories get long and unpredictable, and the failures get subtle — it researched three competitors well and one badly, and the output looks uniformly confident. That’s why a step cap and a token budget stop being optional here.

Level 3: The Collaborative Multi-Agent System

Stop building one agent that does everything. Build several specialists and have them work together.

The mental model is an org chart. A coordinator agent receives the goal, decomposes it, and dispatches sub-missions to specialist agents — treating those agents much the way a single agent treats tools, except that the thing on the other end can plan and push back rather than just return a value.

Our brief at Level 3:

A BriefCoordinator receives the goal. It dispatches four parallel missions to ResearchAgent instances, one per competitor, each with a narrow system prompt tuned for finding and verifying facts and a strict instruction to cite sources. It sends the collected findings to an AnalystAgent whose entire job is spotting patterns across competitors. It sends the analysis to a WriterAgent tuned for house voice and document structure. A CriticAgent reviews the draft against a rubric — are all claims sourced, is anything speculative stated as fact, does it answer the original brief — and sends it back for revision if not.

Four common patterns show up here, and they compose:

Coordinator — a manager routes sub-tasks to the right specialist and aggregates results. Best for non-linear work.
Sequential — an assembly line, where each agent’s output is the next one’s input. Best when the stages are genuinely ordered.
Iterative refinement — a generator produces, a critic evaluates against a rubric, and the loop repeats until the critic passes it or a cap is hit. This is the single most reliable quality lever at this level.
Human-in-the-loop — a deliberate pause for a person to approve before something consequential happens. Not optional for anything irreversible.

What you actually gain: each agent’s instructions get short and coherent again. The researcher’s prompt says nothing about writing style. The writer’s prompt says nothing about search strategy. You can evaluate and improve each specialist independently, which is the real win — Level 2’s monolithic prompt is nearly impossible to improve without regression, because every edit affects everything.

What you gain that you did not want: everything gets harder to see. A failure could be in any agent, or — much more commonly — in the handoff between two of them. The coordinator summarized the research findings before passing them along, and the summary dropped the one detail the analyst needed. That class of bug is genuinely hard, and it is the dominant failure mode of multi-agent systems.

Costs multiply rather than add. Five agents each running a five-step trajectory is twenty-five model calls, plus coordination overhead, and each specialist re-reads its own accumulated context.

Latency compounds too, unless you deliberately parallelize the parts that can be parallelized — which introduces its own concurrency bugs.

Complexity cost: high. This is where you stop being able to develop without an evaluation harness and a trace viewer. Not “should have one.” Cannot function without one.

When Level 3 is the right answer: when a single agent’s instructions have become self-contradictory, when different sub-tasks genuinely need different models or different tool permissions, or when you want independent quality gates.

When it is not: when someone reached for it because it sounded sophisticated. The honest test is whether you have tried and failed to make a Level 2 agent work. A well-built Level 2 beats a badly-built Level 3 nearly every time, and multi-agent systems fail in ways that are much harder to explain to your users.

Saying it out loud. Level 3 is when you stop building one agent that does everything and build specialists that work together — a coordinator dispatching sub-missions, roughly the way a single agent uses tools, except the thing on the other end can plan and push back. The real win isn’t cleverness, it’s that each prompt gets short and coherent again, so you can evaluate and improve one specialist without regressing the others. The dominant failure mode is not inside any agent — it’s the handoff, where the coordinator summarizes findings before passing them on and the summary drops the one detail the next agent needed. Costs multiply rather than add: five agents at five steps each is twenty-five model calls. My honest test for whether you’re ready is whether you’ve tried and failed to make a Level 2 work, because a well-built Level 2 beats a badly-built Level 3 nearly every time.

Level 4: The Self-Evolving System

The system extends its own capabilities. It notices a gap — a tool it does not have, a skill nobody gave it — and creates what it needs.

Our brief at Level 4: The coordinator is working on the brief and reasons: “I should include social sentiment for each competitor’s new launch, but I have no tool that reads social platforms.”

Instead of failing or silently omitting the section, it invokes a capability-creation tool: build me something that queries social APIs for a keyword, scores sentiment, and returns a summary. A new tool — or a whole new specialist agent — is generated, tested against a small verification harness, and registered. The brief now has a sentiment section, and next quarter that capability already exists.

More modestly and more realistically, Level 4 shows up as systems that improve their own context. The critic agent flags the same problem in three consecutive briefs. A learning process observes that pattern, generalizes it into a new rule, and writes it into the writer’s instructions permanently. Next quarter the writer does not make that mistake. That is self-evolution, and it is much more achievable than autonomous tool synthesis.

Complexity cost: research-grade. Every hard problem from Level 3, plus the question of how you review, test, and secure code that a model wrote and deployed without a human reading it. Plus the question of what happens when the system’s self-modifications drift somewhere you did not intend, which is not a hypothetical.

When Level 4 is the right answer: in production, in 2026, almost never — with one important exception. The narrow form of Level 4, where the system refines its own prompts and few-shot examples based on captured human feedback, is real, deployable, and enormously valuable. The broad form, where the system writes and ships its own tools unsupervised, is frontier work.

Systems like Google’s AI co-scientist and DeepMind’s AlphaEvolve are the public examples of the broad form. Note what they have in common: a cheap, automatic way to verify a candidate solution. AlphaEvolve works because you can run the algorithm it wrote and measure whether it is faster. Self-evolution needs a ground truth to evolve toward, and most business problems do not have one.

Saying it out loud. Level 4 is the system extending its own capabilities — noticing it lacks a tool and building one. In production, in 2026, that broad form is almost never the right answer. But there’s a narrow form that absolutely is: the system refining its own prompts and few-shot examples from captured feedback, so when the critic flags the same problem three briefs running, that becomes a permanent rule in the writer’s instructions. The thing to notice about the public examples of the broad form, like AlphaEvolve, is what they share — a cheap, automatic way to verify a candidate. Self-evolution needs a ground truth to evolve toward, and most business problems just don’t have one.

Choosing your level

The ladder is not an aspiration. Nothing about Level 3 is better than Level 1 except its ability to handle problems Level 1 cannot.

Here is the sizing table.

Level	Adds	Typical build	Ongoing cost	You need it when
0 — Core reasoning	Nothing; bare model	Hours	One call	The task is pure text transformation
1 — Connected	Tools	Days to weeks	A few calls per request	Correct answers need live or private facts
2 — Strategic	Planning, context management	Weeks	Long, variable trajectories	The path depends on what you find
3 — Collaborative	Specialist agents	Months	Multiplied trajectories	One prompt can’t hold all the roles
4 — Self-evolving	Capability creation	Research project	Unbounded until constrained	You have automatic verification

Three rules I would hand a team starting out.

Start one level below where you think you need to be. The instinct is always to over-scope, and the over-scoped version takes four times as long and works worse. Build the Level 1, ship it, and let the failures tell you what Level 2 needs to fix. You will be wrong about what those failures are.

Level up only when you hit a wall you can name. “The agent keeps forgetting what it learned in step 2 by the time it reaches step 6” is a wall with a name, and it tells you exactly which Level 2 capability you need. “It feels like it should be multi-agent” is not a wall.

Each level up needs its own operational tooling before it needs its code. Level 2 needs step caps and cost budgets. Level 3 needs traces and per-agent evals. Level 4 needs a verification harness before it needs a tool-writer. If you build the capability before the instrumentation, you get a system nobody can debug, and it will be quietly retired within six months.

Saying it out loud. The ladder isn’t an aspiration — nothing about Level 3 is better than Level 1 except its ability to handle problems Level 1 can’t. So my advice is to start one level below where you think you need to be, ship it, and let the failures tell you what to add, because you’ll be wrong about which failures you get. Level up only when you hit a wall you can name: “it forgets what it learned in step 2 by the time it reaches step 6” is a wall with a name; “it feels like it should be multi-agent” isn’t. And each level needs its instrumentation before its code — step caps and budgets for Level 2, traces and per-agent evals for Level 3, a verification harness for Level 4. Build the capability before the instrumentation and you get a system nobody can debug, which gets quietly retired within six months.

What you should be able to do now

Place any agent system you encounter on the 0–4 ladder and justify the placement by naming the capability that distinguishes it from the level below.
Describe what one specific product idea looks like at each level, and identify the exact limitation that forces a move to the next rung.
Estimate the cost and complexity delta of moving your own project up a level, in terms of model calls, latency, and required tooling.
Recognize the two most common scoping mistakes — over-scoping to Level 3 by default, and building a level’s capability before its instrumentation.
Distinguish the achievable narrow form of Level 4 (self-refining context from feedback) from the frontier form (autonomous tool synthesis).

Production Agent Engineering — A Practical Guide