Agent Architecture

What You Need to Know

Every agentic system starts from one decision: who owns the control flow. Anthropic's taxonomy has three tiers. What separates the tiers is who decides the next step. An augmented LLM is a single model call with retrieval, tools and memory added. A workflow is a system where LLM calls and tools are orchestrated through predefined code paths. An agent is a system where the model directs its own process and tool usage. Domain 1 starts with this decision. When you place a system in the right tier, the construction work in 1.2 is clear. No SDK configuration fixes a system in the wrong tier.

This lesson uses one made-up example throughout: a company that sells invoicing software. Its developers publish each release in the same way every time: run the tests, build the package, publish the release notes. When a customer reports an invoice with a wrong total, the developers do not investigate it in the same way every time. The fault could be in the tax rules, the rounding or the currency conversion, and each check depends on the last result.

The Three Tiers

The augmented LLM is the basic building block, and most problems need nothing more.

In a workflow, you write the control flow and the model executes inside it, as in the company's release steps. The path cannot differ from the one you wrote, so a workflow is predictable, testable and cheaper per run.

In an agent, the model decides each next step from environment feedback until the goal is met. A diagnostic agent reads the result of the tax-rule check and picks the next check itself. An agent gives you flexibility. Its costs are latency, token spend, more chances of error, and the need for guardrails, which the workflow never had. A guardrail is a check that can stop an action.

Choosing Between Workflow and Agent

Anthropic's guidance is to find the simplest solution possible and add complexity only when it demonstrably improves outcomes. The practical test is whether you can predict the path. Steps that are known in advance and repeat for every input, like the release steps, belong in a workflow. When the number of steps is unknown and each decision depends on the last, like the wrong invoice total, an agent is worth its cost.

A system can be put in the wrong tier in two ways. An agent on a fixed pipeline pays agent costs for flexibility the task never uses. A workflow with fixed steps that is used for an open-ended investigation fails the first time the real path differs from the coded one. Cost and latency are part of this decision: an agent's extra spend has to give you something the workflow could not deliver.

Supervisor Hierarchies and Subagents

A context window is everything the model can reference when it generates a response. When one context window cannot hold the task, the system uses the orchestrator-workers shape. A lead agent (the manager or supervisor) decomposes the goal, spawns specialised subagents and synthesises their results. A subagent is a worker that a lead agent spawns and briefs. The company's lead agent might ask each subagent to search one module of the product for calls to an old rounding function. Anthropic's multi-agent research system is the reference implementation. In its basic form, every result returns through the lead agent. For large outputs, Anthropic's post on that system recommends a bypass. The subagents store their work in external systems and return lightweight references to the lead agent. This bypass prevents the loss of information between stages. It also means that the system does not copy large outputs through the conversation history.

Subagents do not share memory. A subagent starts with a new context window. That window does not contain the lead agent's conversation. The lead agent sends the subagent only the delegation prompt, the message that briefs it. Every file path, error message, decision and convention the subagent needs must be in that delegation prompt. The subagent does not see anything agreed earlier in the lead agent's own conversation. If a developer tells the lead agent to ignore test files, a module subagent never sees that rule unless its delegation prompt states it. A design that assumes shared memory cannot work.

One exception, as of October 2026, is a fork. A forked subagent inherits the whole conversation so far. Fork mode lets Claude start a fork on its own. From Claude Code v2.1.302, fork mode is on by default, including in the Agent SDK and in non-interactive -p runs. To stop forks, add Agent(fork) to the deny rules in your permission settings. To turn fork mode off, set CLAUDE_CODE_FORK_SUBAGENT to 0. Every other subagent starts with a new context window, so the delegation prompt is the only way to give it information. This includes every custom subagent that you define.

Isolation is also the benefit. Intermediate tool calls, their results and large file reads stay inside the subagent. Only its final message returns to the lead agent. A research subagent can read dozens of files while the lead agent's context grows by the size of a summary. Separate context windows let subagents run in parallel and add to the total reasoning capacity. Anthropic reported that a lead agent with parallel subagents outperformed a single agent by 90.2% on its internal research evaluation. Parallel work helps only when the subtasks are independent, as the module searches are. Writing a fix depends on its diagnosis. Splitting dependent work across parallel subagents makes it necessary again to coordinate the dependent steps and adds token cost.

When a multi-agent system behaves incorrectly, first check the lead agent for the cause of the failure. Vague delegation prompts produce duplicated work and gaps. Overlapping task boundaries produce near-identical outputs. If the lead agent spawns a dozen subagents for a simple query, the failure is in how the lead agent scales effort. It is not incompetence in the subagents. The fix is almost always a better delegation prompt. Every time, give each subagent an explicit objective, an output format, tool guidance and clear task boundaries.

Other Multi-Agent Shapes

Claude Code also offers a structure in which teammates send messages directly to each other, called agent teams. In a team, one session leads. Each teammate works in its own context window and sends messages directly to the others. As of September 2026, agent teams are experimental and disabled by default. CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 enables them. They need an interactive session, so Agent SDK and -p runs never spawn teammates. The docs reserve subagents for quick, focused workers that return their results, like the module searches. Teams are for teammates who need to share findings, challenge each other and coordinate on their own. They cost more tokens, because each teammate is a separate Claude instance. Even ordinary subagents are not always isolated. Subagents that Claude named when it spawned them can send messages to each other.

Dynamic workflows do the opposite. They move the plan into code. Claude writes a script that orchestrates many subagents. The script decides what runs next. It holds the loop, the branching and the intermediate results, so Claude's context holds only the final answer. The docs recommend a dynamic workflow when a task needs more agents than one conversation can coordinate. That means dozens to hundreds of agents per run. A team, by comparison, has a few long-running peers. Dynamic workflows also suit orchestration that you want in the form of a script that you can read and rerun. The tier depends on who decides the next step. Here the script decides, so the orchestration is a workflow again.

Claude Managed Agents (sub-skill 1.2) has a supervisor structure of its own. As of September 2026, a coordinator agent declares a roster of agents that it can delegate to. It delegates one level only. If the roster references an agent that has its own roster, the create or update request fails with a validation error. A roster lists at most 20 unique agents. But the coordinator can call several copies of each agent, within the session's thread limit. All of them share the session's sandbox and filesystem, and each runs in its own context-isolated thread.

In the exam

The exam tests the placement decision directly. It takes its vocabulary from one source: Anthropic's "Building effective agents". The wrong options make the difference between the tiers unclear. The exam penalises both kinds of wrong placement equally. If a question names a fixed, auditable, high-volume process, the workflow is the correct answer. The fact that the exam tests most in this sub-skill is that subagents do not share memory. Options that rely on implicit shared state are always wrong. When a question says only "a subagent", answer for a custom subagent, which starts fresh from its brief. Forks are on by default in current releases, but the custom subagent is the case the exam tests.

Exam Traps

Practice Scenario

Build Exercise

Sources

• Building effective agents — Anthropic engineering, the canonical taxonomy and the simplest-solution rule
• How we built our multi-agent research system — Anthropic engineering, orchestrator-workers in production and its failure modes
• Subagents in the SDK — Claude Docs, context isolation mechanics and the delegation prompt as the only channel
• How the agent loop works — Claude Docs, the loop that agents run and workflows avoid
• Create custom subagents — Claude Docs, forks, fork mode defaults and named subagents that message each other
• Orchestrate teams of Claude Code sessions — Claude Docs, agent teams: experimental peer sessions that message each other directly
• Orchestrate subagents at scale with dynamic workflows — Claude Docs, a script that holds the plan and the intermediate results
• Multiagent orchestration — Claude Docs, Managed Agents coordinator rosters and one-level delegation