Multi-Agent Architectures: overview

A Larkspur outage request crosses operations and billing, and later turns may remain with one specialist. You will compare fixed dependencies, supervisor decisions and handoffs, then count their costs across the conversation. The tutorials cover supervisor control, hierarchical teams, handoffs and swarms.

The running example is the Larkspur Cloud handbook from T5.1 to T5.3, split between three specialist RAG agents. The billing agent holds billing, cancellation, refunds and promotional credits; the operations agent holds the availability guarantee, incidents, server sizing and reboots; the data agent holds exports and retention. Three requests come back on every page and in the lab: How long does a refund take? (billing), My server went down last night. Do I get service credits? (operations, then billing) and Can I export my data after I cancel my plan? (data).

• Split one agent when it has more tools or sources than one prompt can choose among well. A team makes more model calls (the 35.1 notebook's specialist team costs roughly four times the monolith's), so measure it against the single agent on the same requests.
• The five LangGraph architectures share one primitive, Command(goto=..., update=...): a node writes to state and names the next node. They differ in who decides what runs next.
• A supervisor decides every step and takes control back. On the outage request that costs 5 model calls, 3 of them routing, and buys one place to log, test and cap every decision.
• A hierarchy nests compiled team graphs under a top supervisor. With three specialists it only adds overhead (7 calls for the same request); it pays off when one supervisor would face too many workers.
• A handoff is a tool that returns Command(goto=..., graph=Command.PARENT). A swarm stores active_agent per thread, so a follow-up costs 1 call against 3 for the supervisor. Nothing ends a handoff loop except recursion_limit, whose default is 10,007 steps.

Both graphs answer the outage request with the same two specialists. The supervisor decides before each specialist and once more to finish, so it spends 3 of its 5 model calls on routing. In the swarm, triage routes once and each agent hands the work on itself: 3 calls. Every architecture in this module sits somewhere between these two, and the choice is about who holds control after an agent finishes.

Who routes, and what it costs: open the file in a browser. Pick the outage request and step through the four architectures: the router (T9.3) is cheapest at 2 calls and never asks billing about the credits. Then pick Supervisor and Swarm in turn and move the follow-up slider to 3: the supervisor reaches 14 calls, the swarm 6, because every follow-up goes straight to the active agent.

• Before: T7.3 introduced routing and orchestrator-worker as workflow patterns; here the workers are whole agents. T8.3 added human approval gates, which 35.3 puts inside a supervisor loop. T9.3 routed each question to one knowledge base once; the supervisor is that router run in a loop at the agent level. T10.1's checkpointers and threads are what let a swarm remember its active agent.
• Next: T11.2 covers other ways agents share work: blackboards, debate, STORM and parallel agents. T11.3 builds full multi-agent systems and hardens them against edge cases and errors.

• Split one agent only when its tools or sources are too many to choose among well, and measure the team against the single agent on the same requests.
• Let the model choose the next agent, and let a pure function in code read that typed choice and a counter. The loop ends where the code says, whatever the model says.
• A supervisor pays a routing call per specialist plus one to finish; a swarm pays one routing call per thread and then follows active_agent. Pick by whether conversations stay with one specialist and whether you need one decision log.
• Pass recursion_limit on every run and add a counter cap to any graph that can cycle; test both with a stub or scripted model.