CCDV-F 1.1 — Agent architecture and tradeoffs

Choosing an architecture

What does the task actually need?

One well-scoped answer
Single callAdd retrieval or examples first
Known, fixed steps
WorkflowPredictable, cheap, testable
Steps vary by input
AgentModel picks the next tool
Wide parallel search
Manager + subagentsHighest cost, most capability

Work down the list and stop at the first row that fits. Anthropic's own guidance is to find the simplest solution and add complexity only when it demonstrably pays for itself.

Workflow or agent: the line Anthropic draws

“Building effective agents” splits agentic systems into two kinds. In a workflow, LLM calls and tools are orchestrated through predefined code paths — your code decides what happens next. In an agent, the model dynamically directs its own process and tool use, keeping control of how the task gets done. Both use a model; the difference is who holds the steering wheel.

That single distinction answers most architecture questions. Workflows give predictability and consistency for well-defined tasks. Agents are the better option when flexibility and model-driven decision-making are needed at scale. The cost side is just as blunt: agentic systems trade latency and cost for better task performance, and agents add the risk of compounding errors — one bad step feeding the next.

Who decides the next step

Workflow — your code decides

Steps are written down in advance
Same input takes the same path
Easy to unit-test and to price
A new kind of input needs new code

Agent — the model decides

The model chooses the next tool from context
Handles inputs nobody anticipated
Needs guardrails, budgets and a stopping rule
Higher latency and token cost per task

Notice what changes and what does not. Both designs call a model and both can call tools. Only the location of the control flow moves.

The five workflow patterns worth naming

Before you build an agent, check whether one of the composable workflow patterns already covers the case. The exam uses their names, and each has a signature situation:

Pattern	What it does	Reach for it when
Prompt chaining	Each call processes the previous call's output	The task splits into fixed subtasks and you can trade latency for accuracy
Routing	Classify the input, then send it to a specialised follow-up	Inputs fall into distinct categories handled better separately
Parallelization	Sectioning splits independent subtasks; voting runs the same task several times	You need speed, or several attempts for confidence
Orchestrator-workers	A central model breaks down the task, delegates, and synthesises	You cannot predict the subtasks in advance
Evaluator-optimizer	One call generates, another critiques, repeat	Clear criteria exist and feedback measurably improves the output

Two of these are frequently confused. Parallelization runs subtasks you decided on when you wrote the code. Orchestrator-workers runs subtasks the orchestrator invents after seeing the input — that is the whole difference, and it is also the line between a workflow and a manager-style agent.

Worked example · A claims desk that did not need an agent

A motor insurer processes about 4,000 claim emails a day. Every claim is one of four types, each with its own extraction rules, and the team wants Claude to file them automatically.

The proposal on the table. An agent with tools for reading the mailbox, querying the policy database and writing to the claims system, left to work each email out for itself.
What the inputs actually look like. The team samples 200 emails. All of them are windscreen, third-party, theft or personal-injury claims. Nothing else has arrived in two years.
The architecture that fits. Routing: one cheap classification call decides the type, then one of four specialised prompt chains extracts the fields that type needs and validates them against a schema.
What that buys. Each path is testable on its own, cost per claim is known to the penny, and a mis-filed claim can be traced to one branch rather than to a decision the model made mid-run.
Where the agent goes instead. The 3% of emails the classifier is unsure about get escalated to an agent that has a broader tool set and can ask a human.

Takeaway: Predictable inputs mean a workflow. Keep the agent for the residue that the workflow cannot categorise — that is a routing workflow with an agent as one branch, not an agent with a router bolted on.

Manager and supervisor hierarchies

A manager (or supervisor, or lead, or orchestrator — the words are interchangeable) is an agent whose main tool is the ability to start other agents. Anthropic's research system works exactly this way: a lead agent analyses the query, forms a strategy, and spawns subagents that search different aspects in parallel; each returns findings, and the lead synthesises them. A separate citation agent then attaches sources before the answer goes out.

Lead agent with parallel subagents

Lead agentplans, delegates, synthesises

Subagent Asupplier filings
Subagent Bnews coverage
Subagent Cpricing data
Citation passattach sources

Each spoke has its own context window and its own tool budget. Only the spoke's final message travels back along the edge — never its intermediate searches.

The published numbers are worth carrying into the exam. Agents use roughly four times the tokens of a chat interaction, and multi-agent systems about fifteen times. Token usage alone explained about 80% of the variance in performance on the research evaluation, and a multi-agent system with Opus as lead and Sonnet as subagents outperformed a single Opus agent by 90.2% on that internal benchmark. Read those two facts together: the architecture wins because it spends more, in parallel, on tasks where spending more helps.

Worked example · Due diligence at a law firm

A firm reviewing a target company must check 900 contracts for change-of-control clauses, unusual indemnities and assignment restrictions before a Friday deadline.

Why a single agent struggles. One context window cannot hold 900 contracts, and reading them in sequence takes longer than the deadline allows.
The manager's job. A lead agent decides the split — by contract type, not by alphabet — writes a brief for each subagent stating the objective, the output format, which tools to use and where its scope ends, and records that plan to a file so it survives compaction.
The subagents' job. Each reads its allocated contracts in its own context and returns a structured list of findings with contract IDs, not the contract text.
The synthesis. The lead merges the lists, spots that indemnity wording clusters in one acquired subsidiary, and produces the memo.
The safeguards. A spend cap on the whole query, a concurrency limit on subagents, and findings written to storage so a crashed subagent can be re-run alone.

Takeaway: The manager pattern earned its keep because the work was genuinely separable and read-only. Vague briefs are the documented failure mode — “research the supplier base” produces duplicated effort, while an explicit objective, format, tool guidance and boundary does not.

What subagents are actually for

A subagent is not just a second copy of the model. In the Agent SDK it is a separate agent instance with its own conversation, and it buys four specific things: context isolation (its tool calls and intermediate results stay inside it; only its final message returns to the parent), parallelization (independent subtasks finish in the time of the slowest, not the sum), specialised instructions (a system prompt full of expertise that would be noise in the main agent), and tool restriction (a reviewer given only Read, Grep and Glob cannot modify anything).

Context isolation is the one that changes designs. A subagent that reads forty files adds one summary to the parent's context, not forty files. That is why subagents appear in the documentation as a context-management technique as much as an orchestration one — the point is taken further in 1.3 and in the context-engineering objective in Domain 6.

Escalating complexity, one rung at a time

cheapest and most predictable at the top

Single callprompt, retrieval, examples
Workflowchaining, routing, parallelization
Single agentmodel-driven tool loop
Manager + subagentsparallel, isolated context

Each rung costs more per task than the one above it. Move down only when you can say what the rung above cannot do.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Starting with a multi-agent design because the task sounds hard	Start at the cheapest rung and move down only when you can name what the rung above cannot do.
Using an agent where the inputs fall into a few known categories	Route to specialised workflows and keep the agent for the uncategorisable remainder.
Splitting work across subagents that need to see each other's findings	Keep dependent work in one context; parallelise only genuinely independent subtasks.
Delegating with a one-line brief such as “look into the supplier issue”	State the objective, the output format, the tools to use and the boundary of the subtask.
Treating higher token spend as a defect of multi-agent systems	Price it deliberately: the extra spend is what buys the parallel breadth, so use it where breadth pays.

You should now be able to

State the difference between a workflow and an agent in terms of who controls the next step.
Name the five workflow patterns and match each to the situation it suits.
Decide when an orchestrator or manager hierarchy is justified, and when shared context rules it out.
Explain the four benefits subagents provide, starting with context isolation.
Argue the latency, cost and predictability tradeoffs of each architecture to a non-specialist stakeholder.

Agent architecture and tradeoffs