Don't Draw Agent Architecture as an Org Chart

Don't split an Agent into a bunch of subagents right out of the gate. Let one model finish the work in the same window first; only when something really hits a wall, let test data speak.

A company built a customer service Agent, then hung a dozen "expert subagents" on it by business line: one for orders, one for shipping, one for refunds, one for accounts. The division-of-labor diagram was crystal clear.

As soon as it went live, it fell apart. Users' questions never obediently occupy one box — ask one cross-domain question, and the request gets shuttled between several subagents. Every handoff, the previous subagent only passes a compressed summary; the tone of the outward-facing reply depends entirely on which expert gets the last word; stack enough layers, and the user waits ages just for the agents to "hold a handoff meeting" internally.

This is a real case from an enterprise practice retrospective published by Anthropic's applied AI team on October 22, 2026. They didn't say "subagents are useless," but they pierced a layer of paper: many companies make Agents increasingly complex merely by copying their own departmental org chart; the task itself never needed that many layers.

Everyone used to react to a requirement by asking: "How many subagents should this Agent be split into?" This retrospective flips the question: "On what grounds do you split?"

Below, following that question, we talk through three things: when you should actually keep subagents, how to safely fold back subagents you've already split out, and how multiple teams work together after the fold. The underlying source code for the specific framework is in the further reading at the end.

Subagents buy isolation, and pay a telephone-tax

First, let's say plainly what a "subagent" actually is.

A subagent is not a "model that understands the business better." It's really just a model running in a brand-new chat window. It has its own independent system prompt and tools, cannot see anything from the main conversation before it, and relies entirely on the outer dispatcher (coordinator) to assign tasks and relay messages. Splitting out a subagent buys three things:

• Clean window (context isolation): The subagent can't see the noise of the main conversation — good for independent research or black-box acceptance.
• Can run concurrently (parallelism): Several independent subtasks can each open a new window and run at the same time.
• Clean permission management (permission boundary): Different subagents get different tools, without crossing boundaries.

But the ledger has a second side. Every subagent you split out is a three-part "telephone tax": every handoff compresses the process into a secondhand summary, and details are lost in that compression; each subagent runs its own round of prompts and model calls, and the time doubles as you stack layers; each team maintains its own prompts and tests, and in the end nobody is responsible for the final result the user actually receives.

The main loop (also called the single loop later) takes a different path: no splits, only one model from start to finish holding the same context window. Each round, the model decides which tools to call, an outer runtime framework (the Harness) executes them concurrently, and stuffs the raw results back into the same window; the model looks at the results and decides its own next step — keep researching, ask the user, or answer directly. The runtime framework only manages the round cap, budget, and write confirmations externally.

Dimension	Splitting subagents	Single loop (only one main loop)
Memory & context	Separate windows per subagent; handoffs rely on summaries, easy to lose details	Same window; raw data from earlier steps is available later anytime
Parallelism	Naturally suited to multiple windows running independently	Parallelism via multiple tool calls in one round, results return to the same window
Latency & cost	Nested loops with handoffs, usually slower and more expensive	Fewer intermediate handoff rounds, usually faster and cheaper
Team maintenance	Each team owns its prompts and local tests, easy to squabble	One owner for the main prompt and end-to-end experience
Biggest risk	Handoff distortion, runaway subagents, fragmented tone	Window too full, poorly designed prompts and tools

In one sentence: splitting out subagents fundamentally trades "information loss in handoffs" and "slower" for "window isolation, concurrency, and permission isolation." Whether that's a good deal depends on the task, not on how pretty the architecture diagram looks.

Why Agents grow into department org charts

The easiest trap for a large company building an Agent is carving territory by department.

The starting point is usually humble: the company wants a unified-entry super-Agent that ties all product capabilities together. But orders belong to group A, shipping to group B, accounts to group C. What's the least offensive way forward? Each group builds its own subagent in a silo, and the platform group finally adds a "master dispatcher" (orchestrator) on top, or wraps each group's Agent as an MCP tool and hangs it onto the main Agent.

That arrangement is the most administratively convenient, but in the system it explodes into five problems:

1. Handoffs lose details (context management): Subagents don't share complete records; after two or three handoffs, the user's original intent and preconditions are gone.
2. Runaway subagents (subagent proliferation): Every group ships its own subagent, ending up with hundreds of overlapping Agents, no unified standard, and when something breaks, nobody knows who owns it.
3. Frankenprompt: Every team stuffs a couple of "must obey this rule" clauses into the main prompt; the rules conflict, and the Agent talks as if several different people are taking turns.
4. Each group optimizes its own score, nobody owns the total result (local Eval): Each group benchmarks against its own small slice of test sets. Individually, every subagent scores 95, but chained together, the user still can't get things done — what gets reported up to management is a pile of inflated local scores.
5. Slow (latency): Layer after layer of model calls and waiting for summaries. Anthropic mentions a customer that cut runtime roughly in half (about 2x faster) by switching a multi-agent architecture to a single loop.

This is Conway's law reincarnated in the Agent era: the shape of your company's departmental walls is the shape your Agent architecture takes.

Each team guards a subagent, and what the user experiences is the seam between departments: the refund expert doesn't know what the shipping expert just looked up, the shipping expert doesn't know how the account expert judged things, and a user's single question collides with three transfers in the background.

Team division itself isn't wrong. What's wrong is drawing "who maintains the code" directly as "how many models a request has to cross at runtime." Users don't care how many departments your company has; they care whether a single question gets answered and the job gets done.

Why the single loop suddenly suffices

Without splitting subagents, how do you stuff dozens or hundreds of business rules and tools into one model? The answer is simple: one main loop, plus "look at the directory first, then open the book when needed" (what the original calls progressive disclosure).

• skill (check the methods on demand): Normally the context only holds a few lines of "skill directory" (each skill's name and one-sentence description); when the model decides it's relevant, it loads the full operating instructions.
• tool search (search tool definitions on demand): No need to jam all tool parameter formats into the system prompt up front; keep only tool names and descriptions, and when actually calling a tool, fetch its full definition ad hoc.

Figure 1: Comparing splitting subagents by org chart with "main loop + progressive disclosure" at runtime. The former loses details and stacks latency in cross-agent handoffs; the latter keeps context in the same window and controls growth with on-demand loading.

Why does this work better now? Three reasons, each more concrete than the last.

First, no secondhand messages means the answer is complete. In long tasks, the raw data from earlier steps stays in the main window, so the model can refer back and tie clues together at any point. A subagent only hands back a summary, and a single sentence missing from that summary is forever invisible to the main model.

Second, the "window can't fit" worry is solved by on-demand loading. The most common reason people used to split subagents was "too many business rules and tools, one prompt can't hold them all." Now, with only a directory attached and the body loaded on demand, the system prompt gets much thinner — Anthropic used this approach to cut Claude Code's system prompt by more than 80% while on a stronger model.

Third, the models got smarter themselves. Starting with Opus 4.5, the complexity a model can hold steady in one loop far exceeds what many teams expect; newer models even ship with thinking that can't be turned off, so the model itself keeps notes and re-checks as it works.

The third point deserves the highlight: many subagents in your system were never built for today's task; they were built as a patch for yesterday's old model. Old models couldn't remember long instructions or re-check themselves, so you needed external frameworks to walk them step by step; once the model upgrades, the crutches you built go from "helping" to "blocking."

In helping enterprises review options, Anthropic often sees a "five-layer nesting doll" design (Figure 2, left): the request enters, passes through a master dispatcher, then an intent classifier, then a hardcoded five-step inference pipeline, then buckets by user segment, and finally reaches a recommendation branch. Looks extremely rigorous, but most of those boxes exist to babysit an older model. With today's approach: 1 clear system prompt + 4 to 5 lightweight data tools + a strict output guardrail — one loop handles the vast majority of scenarios.

Figure 2: Anthropic's original animation — wrapping a model in 5 rigid layers of orchestration (left) is worse than converging to 1 loop: 1 clear system prompt + 4–5 lightweight data tools + strict output guardrails (right).

Of course, a single loop isn't a free win from writing a few prompt lines. It demands you spend effort on the sharp end: keep the system prompt clean, write skill and tool descriptions precisely (otherwise the model won't know when to open them), and prune the window's history regularly. Plainly put, it's redirecting the energy you used to spend on "drawing orchestration diagrams and tuning subagent handoffs" into polishing prompts, tools, and guardrails.

When you should still keep subagents

Earlier I said subagents buy "window isolation, concurrency, permission boundaries," but one of these is a fake need: you don't need to split subagents for permissions alone (permission checks can go directly into the tool code; more on that in the next section).

After removing permissions, only three conditions genuinely justify keeping subagents at runtime. Split if you meet one; if you meet none, fold the subagent back into the main loop (the original calls it "fold"):

1. The single loop really degrades in measured performance because the window is too full (context bloat causing measurable performance degradation).
2. Several subtasks must run concurrently and their intermediate process can be thrown away (need parallelism and the window is use-and-discard).
3. Too many tools cause the model to keep picking wrong, or the rules in your system prompt conflict (tool selection degradation or instruction conflict).

Note the word "measured" in the first one. It's not that you look at the prompt and think it's long; you have an Eval (evaluation set) proving that accuracy actually drops when combined.

If these three conditions are truly met and you must split subagents, don't immediately draw a big net; start with a "one generator + one verifier" or a simple orchestrator-subagent pattern. When you split, hold one iron law: split by "do they need to see the same context," not by "business role."

Splitting by role (refunds one, shipping one, accounts one) is most intuitive, but it's all a "telephone game," and every handoff distorts more. What's genuinely worth splitting out is work that doesn't need the backstory and only returns a short conclusion — like independently researching a side thread, or doing black-box verification.

Take a coding Agent as the clearest example (Figure 3): if you split by role into "1 writes features → 2 writes unit tests → 3 reviews code," every handoff loses background, and the unit-test writer (2) has no idea why the code author (1) made those tradeoffs. By contrast, splitting by context boundary means writing features and writing unit tests both look at the same code context, so they should stay in the same Agent and get done in one pass — only the verifier (running the tests and reporting pass/fail) gets split out, because running tests and reading errors doesn't require knowing how the code was originally conceived.

Figure 3: Anthropic's original — splitting by problem type (top) loses context on every handoff; splitting by context boundary (bottom) has the same Agent write features and unit tests, and only splits out a Verifier that doesn't need implementation context.

If you already have a bunch of subagents running in production and don't dare delete and rewrite everything at once, there's a stable transitional move: downgrade subagents to tool calls.

Do it this way: only the main Agent talks to the user from start to finish; when a subagent is needed, the main Agent calls it like a normal API, requiring it to return both the conclusion and the key evidence in a fixed schema, and only passes the microphone to the subagent when it must do multi-turn back-and-forth with the user directly. This doesn't require rewriting subagents immediately, and it can first pull a test baseline; but it's only transitional — underneath, you're still running an extra model round, and the latency and summary loss haven't disappeared.

How to fold subagents back: write the exam first, change one at a time

The most practical part of this playbook is the three-step convergence path (Figure 4) and an operating sequence that won't crash production.

Figure 4: Anthropic's original animation — three paths to fewer subagents: (1) Merge subagents that share context; (2) main Agent calls them as tools; (3) fold prompts into skills and API calls into tools.

When you actually start, follow these three steps strictly:

Step one: write the exam before touching code (build an Eval). The platform group holds an end-to-end Eval that tests the complete process; each business group, when handing in a skill, also attaches a few targeted mini-problems. Don't be scared of the word Eval — even picking 10 most typical real user questions (golden samples) is enough to start.

Initially, you can score the final reply with a rubric. Before the orchestrator is dismantled, also look at "did it dispatch to the right subagent"; after folding back to the main loop, look at "did it open the right skill, call the right tool." But going forward, the core exam must be "did the user's task actually get done" (task-completion Eval) — routing accuracy is only a process measure; getting the thing done is the hard criterion.

Step two: start with the subagents that are always glued together. Look at the production call logs: if a large number of requests are "immediately call expert B right after expert A," those two are already doing work on the same chain and looking at the same data. Merge such tightly coupled pairs first.

Step three: fold one at a time, run each problem at least twice. Extract the subagent's prompt into a skill, turn the API-call actions into MCP tools, then compare before and after with the same exam. Don't only look at the total score — go problem by problem to see which ones "flip" (one that used to pass suddenly fails).

Anthropic once caught a typical flip while modifying a customer service Agent: after merging a subagent into the main Agent, response speed did improve, but one previously passing problem failed — the main Agent happened to have the "check order" tool, checked the order, and replied on gut feeling, skipping the step that originally said "go to the shipping expert to verify the delivery date." Even sneakier, that problem failed only once every two runs.

That lesson is real:

• Faster is not better. Removing one handoff can quietly remove a check that used to live in that handoff.
• Run each problem at least twice. Model performance is noisy; passing a single run may just be luck.

So before each merge, the exam must include business chains that often run together in production, plus red-line rules that must never be crossed; every problem should be run at least twice.

Figure 5: Subagent retention judgment and the gradual-fold loop. First pass the three measurable retention conditions, then use "fold one + multi-round end-to-end Eval" to catch hidden task flips.

How multiple teams write one Agent together

Folding subagents back into the main loop isn't the platform group "taking power." Rather, what each business team delivers changes — previously each group handed in a "person" (an independent subagent); now each group hands in "craft" and "tools":

Deliverable type	What goes inside	Operating iron rule
MCP tools	Real actions like querying live data, calling APIs, changing state	Group by "what the user wants to do," not one tool per backend endpoint; once the resident tool definitions exceed 30–50, the model starts choosing wrong
skill	The team's operating steps, judgment rules, handling methods	Each team assigns a single responsible owner (DRI), attaches targeted mini-tests, periodically cleans up dead rules nobody uses
Knowledge base	Static materials like policy clauses, metric definitions, product descriptions	Hang behind a search tool or put inside skill attachments for on-demand lookup; don't pre-search in code and hardwire the output into the system prompt

The tools row offers a very practical heuristic: when the resident tool definitions in the system prompt exceed 30–50, the model's tool-selection accuracy drops. Above that count, either merge low-level endpoints by user intent or turn on tool search so the model searches on demand.

Here's an engineering trick worth copying: write hard "must do A before B" rules directly into the tool code.

For example, the earlier "checked order but forgot to check shipping" problem: instead of repeating instructions in the prompt like "Before refunding, always check shipping!", add a line inside the create_refund tool itself — if there's no shipping verification result, the tool doesn't execute and instead returns an instruction the model can read:

{
  "ok": false,
  "error_code": "PRECONDITION_REQUIRED",
  "message": "Shipping status not verified. Please call get_shipping_status(order_id) first to obtain the delivery_date and delivery status, then call this tool again with a shipping_check_id."
}

Permission control works the same way: you don't need a separate Agent for normal users vs. admins; let the tool check the current user's identity in code, and if permission is missing, return a clear reason for denial. Using tool return values to steer the model on the spot means one main loop can comfortably handle different flows and different permissions.

To save manual labor, Anthropic also built a set of helper utilities internally (open-sourced in the single-agent-loop-kit at the end of the article): use /skill-creator and /skill-doctor to write skills and find which skills sit around costing money unused; use /claude-api build-eval to quickly spin up the first exam set; then use prompt-audit to catch outdated instructions written for old models, combined with hillclimb (auto-iterate to improve scores) and cost-optimize (calculate cost reductions) running in rounds.

After this change, team division becomes clean: each business group goes from "operating an independent subagent" to "maintaining its own skills, tools, and knowledge base"; a small central platform group guards the main system prompt and the end-to-end master exam, and any new skill or tool added by any group has to pass the master exam before going live.

Figure 6: The post-fold multi-team co-building model. Business teams deliver and maintain their capability modules and specialized Evals; the central team holds the main system prompt and end-to-end quality.

Don't treat heuristic numbers as iron laws

Let me say the ugly part up front: Anthropic's article is a retrospective of its own enterprise customers, not a neutral third-party benchmark. The customers are anonymous; the "2x faster" comes from one customer's comparison; the "80% prompt cut" is their internal record of fixing their own Claude Code; the "30–50 tools" is a range of experience. Use these numbers to see the direction of evolution, but don't treat them as universal laws.

Nor is the single loop a silver bullet. All steps run in the same window, and long tasks will eventually hit the context ceiling; if skill and tool descriptions are vague, the model will fail to "open the manual" at the critical moment.

So the safest conclusion is not "never use subagents," but: don't treat subagents as the factory default. Get one loop to work through the task; only when you genuinely hit a measurable bottleneck, split; and after splitting, periodically use the Eval to check whether it's still worth keeping.

That's also why the whole piece keeps coming back to Eval. Talking about architecture is easy to turn into aesthetic appreciation of diagrams: some people feel a diagram full of boxes and arrows is only "enterprise-grade architecture" when it's covered in boxes and arrows; others think minimalism is high-end. Eval's role is to drag the debate back to earth: throw the same 10 real problems at each version, and the data decides which version gets more done, which is faster, and which doesn't flip on tricky queries.

Putting it into a project: five actions and an evaluation card

Compress the whole method into five steps you can act on tomorrow:

1. New projects default to a single loop. Don't draw a multi-agent orchestration diagram first. Write one clear system prompt, add 4–5 lightweight tools, add output guardrails, and get the loop running.
2. First collect 10 real exam questions (Eval). Cover the user's most common main flows and the red lines that must never be crossed. Run each problem at least twice.
3. Don't split unless one of the three retention conditions is met. Only when one of "window overflow and measured degradation," "must be parallel and process is disposable," or "tool selection errors or rule conflicts" is confirmed do you split a subagent.
4. For existing subagents, first call them as tools, then fold them one by one. Fold one at a time, and watch hard for any previously passing problem that flips.
5. When the model upgrades, rerun the exam. Many subagents and dead rules are crutches for the previous generation of models; after a new model ships, remove the old crutches that don't improve scores.

Here's an evaluation card you can copy directly into your project docs, and fill out before deciding the fate of any subagent:

# Subagent Retention Evaluation Card

- Subagent name:
- Bottleneck it solves: context bloat / parallelism / tool selection degradation or instruction conflict (choose one, with measured evidence)
- Candidate form after fold: skill / MCP tool / knowledge base / keep as is
- End-to-end Eval: task count ≥ 10, each run ≥ 2 times
- Score before fold:
- Score after fold:
- Flipped tasks:
- Conclusion: keep / fold / observe further

Filled example (a construction based on the customer-service scenario above, not original measured data):

# Subagent Retention Evaluation Card

- Subagent name: shipping-specialist (shipping lookup and chase subagent)
- Bottleneck it solves: none (originally split by department; 70% of production traffic calls orders/refunds serially, no independent parallel need)
- Candidate form after fold: extract rules into `shipping-policy` skill, merge API into `get_shipping_status` MCP tool
- End-to-end Eval: 15 golden cross-order/shipping/refund cases, each run 3 times
- Score before fold: 13/15 passed (avg latency 11.4s)
- Score after fold: 12/15 first round (avg latency 5.8s); 14/15 after adding a hard precondition check in the refund tool for shipping status
- Flipped tasks: first round, in the "shipped but not signed, request refund" case, failed 1/3 times to call `get_shipping_status`; fixed after adding a hard precondition in the tool
- Conclusion: fold

What stays are the verification methods, not the architecture diagram

Agent architecture has no once-and-for-all standard answer, but there's an order that can't go wrong: let one loop finish the task, then let evaluation data tell you where it really hits a wall.

Subagents aren't the original sin; splitting by default without asking why is. Your company's org chart can decide which team maintains which tool, but it must never decide that a user's single question gets kicked between several models.

The original ends with a line worth putting on the team whiteboard:

"measure, change one thing at a time, and keep what holds up."

First get the data, change only one thing at a time, and keep only what actually stands up to the test. Models get stronger every few months, and the reason you had to split today may be gone by next quarter; what ultimately remains is that set of verification methods, not a diagram full of boxes.

References and verification

• Original: Diane Sarkis, "Building agents: When to fold subagents into your main agent loop", Claude by Anthropic, 2026-10-22. https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop
• Migration toolkit (official from Anthropic): single-agent-loop-kit, https://github.com/anthropics/single-agent-loop-kit
• Original figures: Figure 2 (a7cb2cf08bfcef461166310c0c55f28b72c33b0d.gif), Figure 3 (cd4b9c4417d5ba31776e8aa79e204966c08c6a43.png), Figure 4 (ed6bd97496ffdab88763806d9e14f1ec61ed9254.gif) all archived from Anthropic's original at assets.claude.com; Figures 1, 5, 6 are this article's accompanying Chinese structural diagrams.
• Verification: All direct quotes in this article were transcribed word-for-word against the original on 2026-10-27; customer cases and data are as stated in the original, which does not provide named customers or independently reproducible raw experiments; this article treats it as a "vendor practice observation," not an independent benchmark.