Academy

When one agent isn't enough

When a single agent buckles under the weight of too many responsibilities, you have to split the work — without losing the shared context.

The Felesh team 4 min

A capable agent handles its initial scope reliably. You provide a system prompt, grant access to a few tools, and it executes. But as you pile more operational responsibilities into a single context, it begins to slip. It drops early constraints, calls the right tool with the wrong arguments, or quietly contradicts a policy it adhered to three turns ago. When one context window is forced to act as a planner, a domain expert, and an executor all at once, reasoning degrades. The natural engineering instinct is to split the work across many specialised, tightly scoped agents.

One context carrying three jobsThe request is purchase order PO-7740: 40 pallets, spend cap 25k, EU suppliers only. A single agent holds everything in one context window: the two rules from turn 1, the plan from turn 4, fourteen rate lookups and clause 9.2 from turn 9, and the call at turn 15. It is acting as planner, domain expert and executor at once. The context fills; the two early rules are struck through, and the call goes out as place_order with quantity 400 instead of 40, ignoring the cap.PO-7740 · 40 pallets · cap 25kone context windowfullt1 rule: spend cap 25kt1 rule: EU suppliers onlyt4 plan: split across 3 millst9 14 rate lookups, clause 9.2t15 call place_order(qty=400)asked 40, sent 400, cap ignoredplannersplits the orderdomain expertreads clause 9.2executorcalls place_order
Planner, domain expert and executor all share one context, so the earliest rules are the first dropped and the call goes out with the wrong arguments.

Once an operation outgrows a single agent, the system requires a defined structural shape. You must establish clear boundaries around who makes routing decisions, who does the actual work, and who keeps the entire asynchronous process balanced. In agentic systems, this topology has an established name: the CWD pattern. We map out this baseline architecture in the anchor read below.

Coordinator, workers, delegatorPurchase order PO-7740, 40 pallets, enters the coordinator, which decides who gets which part. It sends three parts to three workers: the price worker checks the 25k cap and returns 21.6k, under cap; the freight worker books 40 pallets and returns a slot booked on Tuesday; the clause worker reads clause 9.2 and finds no conflict. All three workers sit inside the delegator’s frame, which keeps the flow level: three parts, three workers, nobody waiting.PO-7740 · 40 palletscoordinatordecides who gets whatdelegatorbalances the flowprice workerchecks 25k cap21.6k: under capfreight workerbooks 40 palletsslot booked Tueclause workerreads clause 9.2no conflict3 parts, 3 workers, nobody waiting
The coordinator decides who gets which part, each worker does one part, and the delegator keeps the whole flow level.

Deploying multiple agents is an architectural choice, not an automatic upgrade. Community design findings consistently show that a multi-agent system carries roughly an order-of-magnitude-plus more token cost than a single agent handling the same input. It introduces latency, requires rigorous state management across handoffs, and is strict overkill for simple or medium tasks. Often, one well-prompted agent remains the right answer. Moving from a single context to a distributed system is a ladder of fit, not of better.

One agent against many, on the same inputA comparison on the same input, PO-7740. Tokens: one agent is the baseline, 1x; many agents cost roughly 10x or more. Latency: one agent takes one pass; many agents add a wait per handoff. State: one agent holds it in one context; many agents must save it across handoffs. Fit: one agent suits simple and medium tasks; many agents suit work too big for one. Often one well-prompted agent is still the right answer.same inputone agentmany agentstokens1×10×+latencyone passa wait per handoffstateone contextsaved each handofffitssimple, mediumtoo big for oneoften one well-prompted agent is still the right answer
A multi-agent system costs roughly an order of magnitude more tokens than one agent on the same input, plus latency and handoff state, so one well-prompted agent often stays the answer.

When the workload genuinely demands multiple agents, this series covers how to sequence, trace, and secure them: