When NOT to Add Another Claude Agent

Summary:

1. The default answer to “should I add another agent” is no, and the exam grades that instinct.
2. Multi-agent systems use about 15x the tokens of a chat, so the task value has to justify the cost.
3. Delegation is a config line (the Agent tool), not a model upgrade.
4. You get a decision table for single call vs workflow vs multi-agent, plus the two bugs that fail candidates.

Claude multi-agent architecture patterns look impressive in benchmarks, so the reflex is to reach for them. The architect’s judgment the certification actually grades is the opposite: knowing when a single call or a plain workflow beats the fan-out. Agentic Architecture and Orchestration is 27% of the exam, the single heaviest domain, and one trap runs hotter here than anywhere else. It’s called constrain, don’t add, and the wrong answer keeps reaching for more agents, a bigger window, more tools.

When should you actually add another agent?

Rarely, and only when the task’s value clears the cost. Multi-agent systems earn their keep on heavy parallelization, work that exceeds a single context window, and interfacing with many complex tools. Everything else is cheaper and more reliable as one call or a sequential workflow. The people who built a production multi-agent system put a number on the cost:

There is a downside: in practice, these architectures burn through tokens fast. In our data, agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats. For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance. Anthropic, How we built our multi-agent research system

So price the fan-out before you build it:

# Before you fan out, price it. Multi-agent ~15x the tokens of a single chat.
def worth_fanning_out(task_value_usd, single_agent_cost_usd):
    projected = single_agent_cost_usd * 15   # Anthropic's measured multiple
    return task_value_usd > projected        # fan out only if the value clears the cost

Single call, workflow, or multi-agent?

Match the shape to the task, not to what benchmarks well:

The tell for a wrong answer is an option that fans out tightly coupled work, or spins up a seven-agent system to replace a working single call. That’s constrain, don’t add in the wild: added complexity that doesn’t demonstrably improve the outcome.

Why won’t my coordinator delegate?

Because delegation is gated by the Agent tool, and it’s usually missing. A coordinator can define subagents perfectly and still do everything itself if that tool isn’t in its allow-list:

from claude_agent_sdk import ClaudeAgentOptions

# Subagents defined, but no way to reach them:
options = ClaudeAgentOptions(
    allowed_tools=["Read", "Edit"],       # no "Agent" -> the lead silently does it all
    agents={"reviewer": reviewer_agent},
)

# The one-line fix. The delegation gate is a config line, not the model.
options.allowed_tools.append("Agent")

This is the trap in miniature: the wrong answer says “switch to a more capable model,” but a smarter model still can’t call a tool it isn’t allowed. The fix is a string in a list, not an upgrade.

The runaway loop that burns your budget

The second classic bug is terminating an agent loop by parsing its prose. It works in the demo and fails in production the first time the model changes a word:

# Anti-pattern: decide when to stop by reading the model's text.
while True:
    msg = agent.step()
    if "let me" not in msg.text:   # any phrasing change breaks this
        break
    process(msg)

The model already tells you its intent through a structured signal. Key the loop on that instead, and keep an iteration cap only as a backstop:

# Terminate on the structured signal, never on parsed prose.
while msg.stop_reason == "tool_use":   # the model wants to act again
    process_tool_calls(msg)
    msg = agent.step()
# stop_reason == "end_turn" -> the model is done

Parsing text for “done” or “let me” is the exact anti-pattern the exam plants as a wrong answer. So is treating the iteration cap as the primary stop signal. The right answer reads stop_reason.

What should you actually do?

• If a scenario offers “add a subagent” or “use a bigger window” as a fix → suspect it. The heaviest domain rewards the smaller, calibrated move.
• If your coordinator won’t delegate → add Agent to allowed_tools before you touch the model or the descriptions.
• If your loop sometimes never stops → terminate on stop_reason, not on parsed text, and cap iterations only as a safety net.
• If the task is tightly coupled or well-defined → do not fan out. A single agent or workflow is more reliable and far cheaper.

The bottom line

• The strongest architect answer is usually the least dramatic one. When an option adds agents, tools, or tokens, treat it as guilty until proven necessary.
• Multi-agent is a 15x-token bet. Make it only for high-value, parallelizable work that won’t fit one context window.
• Two bugs fail more candidates than any concept: a coordinator that can’t delegate (missing Agent tool) and a loop that terminates on text (should be stop_reason). Learn both cold.