Juan Piaggio · 2026-08-10 · 7 min read · ai · agents · workflow
Once you have decomposed a monolithic agent into specialists, a new question arrives that nobody warns you about: when do you stop? Every additional agent is another prompt to maintain, another handoff to debug, and another place a workflow can stall. Decomposition is not free, and past a point it stops paying.
This is about the second decision, not the first. Assume you have already accepted that one giant agent buckles under a real product's variety. The question now is operational: how many specialists, drawn on which lines, and what does it cost you to run them.
The benefits of specialization get discussed constantly. The costs less so, and they are concrete.
Latency compounds serially. Three agents in sequence, each thinking for four seconds, is a twelve-second workflow. That is fine for overnight batch triage and unacceptable for anything a human is waiting on. Parallelize what you can, but a genuine dependency chain sets a floor you cannot optimize away.
Every handoff is a lossy interface. When agent A summarizes its findings for agent B, detail is dropped. Sometimes the dropped detail is exactly what B needed. This is the multi-agent equivalent of a microservice boundary drawn in the wrong place, and it produces the same symptom: a bug that lives in neither component.
Cost multiplies, quietly. Each specialist re-reads shared context. A three-agent workflow can consume more tokens than the monolith it replaced, per item, forever. This is why per-workspace cost caps and per-agent circuit breakers matter more in a mesh than in a single-agent system — the runaway case is a coordination loop, not one expensive call.
Debugging requires a graph, not a log. With one agent you read a transcript. With five you need to know which one touched the item, in what order, and what each received. Without that, a stalled workflow is genuinely hard to diagnose. In Meshworq every step shares a correlation ID through the audit ledger, so a decision can be reconstructed end to end rather than inferred from scattered logs.
Add an agent when a responsibility is genuinely different. Not when a prompt is getting long.
A useful heuristic: split on differences in authority, context, or risk tolerance — not on differences in topic.
Classifying a ticket and closing a ticket are different jobs by that test. One reads and labels; the other mutates state and needs human approval above a risk threshold. Different authority, different risk tolerance, real seam.
Classifying a bug and classifying a feature request are not. Same authority, same context, same risk. Two agents there gets you two prompts that drift apart and a router that has to decide which to call — pure overhead in exchange for nothing.
Applying the test to a typical delivery workflow gives you three or four specialists, not ten:
That last one is easy to forget and disproportionately valuable. Most agentic systems are event-driven and therefore blind to the absence of events. An item that nobody touched generates nothing to react to, and neglect is one of the most common ways an AI workflow fails in production. A scheduled sweep is what notices.
Agile teams have a cadence, and orchestration works better when it respects it instead of running against it.
Continuous: intake and routing. These should fire the moment work arrives, because their whole value is compressing the gap between "reported" and "owned."
Human-paced: execution proposals. These accumulate in an approval queue, and reviewers clear them when they clear them. Risk scoring is what makes that queue tractable — the score rises as an item's confidence falls and as it sits unattended, so the ordering reflects what actually needs a person rather than arrival time. SLA timers escalate the ones that stall.
Scheduled: sweeps, aligned to your ceremonies. A pass before standup that surfaces stuck items is worth more than the same pass at 3am, because it lands where the team is already looking.
The instinct to make everything real-time is worth resisting. An agent that proposes work faster than the team can absorb it does not accelerate delivery, it grows a queue. Match the agent's cadence to the human cadence downstream of it.
A few reliable indicators that the mesh has outgrown its usefulness:
Any of these is a sign to merge two specialists back together. Consolidation is a normal maintenance operation, not an admission that decomposition was wrong. The right number of agents changes as the product does.
Multi-agent orchestration earns its keep when responsibilities differ in authority, context, or risk tolerance — and costs you latency, lossy handoffs, tokens, and debugging difficulty when they do not. Most delivery workflows need three or four specialists plus a scheduled sweep for the work that goes quiet. Match each agent's cadence to the humans downstream, keep a correlation ID across every handoff so the graph is readable, and merge specialists back together when the seams stop paying. The goal was never more agents. It was the smallest set whose jobs genuinely do not overlap.