Multi-agent systems

Per the OpenAI guide, you split one agent into many when - and only when - one of these holds:

• Complex conditional logic - the instructions have grown so many branching if-this-then-that paths that prompts become unmaintainable and the model starts missing branches.
• Tool overload - and here is the subtle part: overlap matters more than count. Some agents manage 15+ distinct, clearly separated tools without trouble; others struggle under 10 whose descriptions blur into each other. If the model keeps picking the wrong-but-similar tool, splitting by domain gives each agent a small, unambiguous toolbox.

Neither trigger firing? Stay single. A bigger toolbox, better tool docs (b2's ACI craft), or a plan step (b5) is almost always the cheaper fix.

You have heard this melody before. b1: try a workflow before an agent. b3: the five workflow patterns hand over autonomy one notch at a time. b5: add planning only when one-shot answers fall short. Multi-agent is the same dial turned one more notch - and the same discipline applies: escalate deliberately, with a named reason. Your homework tonight literally asks you to write that reason down in one sentence before you are allowed to go multi.

When a split trigger genuinely fires, many agents buy you three things one agent cannot:

• Context isolation - each specialist gets a clean context window for its sub-task instead of wading through everything the whole job has accumulated. This is b4's lesson wearing a new coat: protect the context, protect the agent.
• Parallelism - independent sub-tasks (the analyst pulling June numbers, another specialist pulling ticket themes) can run at the same time instead of in sequence.
• Separation of permissions - the writer has no tools at all, so it cannot touch data; only the analyst can query, and nobody here can send email. Smaller toolboxes per agent mean smaller blast radius - which is exactly where b7's guardrails pick up.

The taxonomy is not abstract - it ships as primitives you can import:

• OpenAI Agents SDK - its named primitives include Agents, Handoffs, Guardrails, Sessions, Tracing. "Agents as tools" gives you the manager pattern; "handoffs" gives you the decentralized one. Guide and SDK map 1:1.
• Claude Agent SDK - ships subagents as a primitive alongside built-in tools, hooks, MCP, permissions, sessions, skills and plugins. A subagent is the manager shape: a specialist the parent invokes and whose result it synthesizes.
• LangGraph - subgraphs let you nest one graph inside another, which is how it expresses specialist crews. Positioning lesson in b9.
• crewAI - the "Practical Multi AI Agents" short course builds whole crews this way; same two shapes underneath.

# the Daybreak review crew - manager pattern
import anthropic
client = anthropic.Anthropic()

def analyst(task: str) -> str:
    """Specialist 1: has the Daybreak query tools (your b2 loop, reused)."""
    return run_loop(                     # the tool loop you built in b2
        system="You are Daybreak's analyst. Report tool-verified numbers only.",
        tools=DAYBREAK_TOOLS,            # query_sales · top_products · subscription_status
        user=task)

def writer(brief: str) -> str:
    """Specialist 2: no tools - turns the analyst's brief into prose."""
    msg = client.messages.create(
        model="claude-opus-5", max_tokens=1024,
        system="You write Daybreak's monthly reviews. Use only numbers from the brief.",
        messages=[{"role": "user", "content": brief}])
    return msg.content[0].text

CREW = {"ask_analyst": analyst, "ask_writer": writer}
MANAGER_TOOLS = [
    {"name": "ask_analyst",
     "description": "Delegate a numbers question. Returns tool-verified Daybreak figures.",
     "input_schema": {"type": "object",
                      "properties": {"task": {"type": "string"}}, "required": ["task"]}},
    {"name": "ask_writer",
     "description": "Delegate prose. Give it every number it needs - it has no tools.",
     "input_schema": {"type": "object",
                      "properties": {"brief": {"type": "string"}}, "required": ["brief"]}},
]

# the manager is just b2's loop - two of its "tools" happen to be agents
messages = [{"role": "user", "content": "Write the June 2026 monthly review."}]
while True:
    r = client.messages.create(
        model="claude-opus-5", max_tokens=2048,
        system="You are the Daybreak review manager. Delegate, then synthesize one answer.",
        tools=MANAGER_TOOLS, messages=messages)
    if r.stop_reason != "tool_use":
        break                            # no more delegation - the review is done
    messages.append({"role": "assistant", "content": r.content})
    messages.append({"role": "user", "content": [
        {"type": "tool_result", "tool_use_id": b.id,
         "content": CREW[b.name](**b.input)}   # the "tool" runs a whole agent
        for b in r.content if b.type == "tool_use"]})
print(r.content[0].text)

Read the last comment twice: the "tool" runs a whole agent. That single line is the entire manager pattern. Everything else on this page you already built in b2.

Honesty check: "write the June review" can also be done with b3's prompt chaining workflow - step 1 query, step 2 write, in fixed order, no manager deciding anything. For this exact task the fixed pipeline is cheaper, fully predictable, and easier to test - when the fixed pipeline is enough, prefer it. The manager earns its keep only when the decomposition varies per request: "compare June to May and only interview the analyst twice if something looks off" is where a fixed chain starts sprouting the conditional logic that triggers the split. Same discipline as b1: autonomy is bought, not free.