Wiring the Wrong Shape - Matching Coordination Topology to Task Dependency

The problem

I built a loan-underwriting task around thirty synthetic applications, each carrying a hidden ground-truth approve-or-deny label, and ran them through four agents: Credit-Check, Income-Verification, Risk-Scoring, Decision. The task has a strictly sequential dependency shape whether or not the architecture respects it. Risk-Scoring needs Income-Verification's confirmed figure before it can produce a meaningful score. Decision needs a locked risk score before it can produce a meaningful outcome. There's no version of this task where those dependencies aren't real.

So, deliberately, to see what would happen, I wired the four agents as decentralized peers instead: all four reading and writing a shared blackboard state asynchronously, waking and acting whenever they had something to contribute, with no supervisor enforcing any order between them. This is the mesh shape, the one that gets pitched as more resilient because there's no single coordinator to become a bottleneck or a single point of failure.

What actually happened is that Risk-Scoring sometimes fired before Income-Verification had finished, because nothing in a mesh topology stops an agent from acting the moment it wakes up and sees something in shared state that looks like enough to work with. Decision sometimes fired on an incomplete or stale risk score for the same reason. The result was premature, wrong approve-or-deny outcomes on applications where the underlying data, read in the right order, would have decided correctly. I measured premature-decision rate, the share of applications where Decision acted before its upstream dependencies were actually marked complete, alongside decision accuracy against the ground-truth labels I'd seeded, and both numbers were bad in the specific way that matters most: the errors clustered on exactly the applications where timing mattered.

Risk-Scoring did exactly what Risk-Scoring does with whatever data was sitting in shared state at the moment it woke up; the agent behaved correctly given what it saw. The failure is a mismatch between the coordination shape I chose and the actual dependency structure of the task, and no amount of making any individual agent smarter fixes a mismatch at that level. A mesh built for independent parallel subtasks was racing four agents against a hidden dependency order none of them had any way to see, because nothing in the architecture told them the order existed.

The pattern

The fix is to map the task's real dependency structure, strictly sequential or genuinely decomposable into independent pieces, before choosing a coordination topology at all. Picking a shape because it sounds more resilient or more modern, and hoping the task happens to fit it, is how the mismatch above happens in the first place. I restructured the identical four agents and the identical thirty applications under a centralized Supervisor node that explicitly invokes each agent in dependency order and only advances to the next one after the prior step's output is validated as complete. Credit-Check runs. Income-Verification runs and gets validated. Risk-Scoring only fires once Income-Verification's output is confirmed complete. Decision only fires once Risk-Scoring is locked in.

Because Credit-Check through Decision is strictly sequential, the task's own dependency graph is what calls for a centralized supervisor here. Running the same thirty applications through this structure, premature-decision rate dropped to zero, because no step can fire before its dependency is satisfied when something is actually enforcing that order, and decision accuracy came back in line with the ground-truth labels across all thirty applications. Nothing about the agents themselves changed between the two versions. The only thing that changed was whether the coordination shape matched what the task actually required.

The validating evidence for this lines up more cleanly than I expected going in. Independent production commentary from 2026 reports that free mesh topology mostly survives in real deployments as a controlled subroutine running inside a supervisor, seldom as the outer architecture of a whole system, and that mesh coordination itself tends to hold up for something like three to eight tightly coupled agents before the combinatorial growth in connections between them, on the order of N times N minus one over two, makes the whole thing unmanageable to reason about. Supervisor and hierarchical topology shows up repeatedly as the practical default specifically for tasks with a real, decomposable, dependency-ordered structure, which describes a large share of the workflows I actually see teams trying to build. Stronger still, an unstructured "bag of agents," a group with no designed coordination topology at all, has been measured amplifying errors up to 17.2 times a single-agent baseline, and the fix that gets reported alongside that number is a supervisor that suppresses the amplification. That's this exact mechanism, arrived at independently, at a scale I didn't test myself.

The October 17 Mixture of Experts episode added a second independent datapoint from a different angle. A study the panel discussed found that teams of agents cost two to five times as much to run as a single agent without consistently better results, with orchestration overhead, latency, and error propagation across handoffs absorbing the gains that parallelism was supposed to deliver. That is the same mechanism as the 17.2 times error amplification, seen through cost where the earlier figure came through accuracy: every handoff between agents is a place where an error or a delay can enter. The practical reading is that a topology earns its coordination overhead only when the task's dependency structure calls for it, and a single agent remains the baseline against which any topology has to justify itself.

Design considerations

Matching topology to task shape is a one-time upfront mapping, and its guarantee is narrower than it sounds. Getting it right still leaves room for two agents, each running correctly under a properly matched topology, to independently commit to plans that turn out to jointly conflict once combined. A perfectly chosen supervisor topology can still produce a double booking, two agents each making an individually reasonable commitment that collides with the other one, if nothing checks the two plans against each other before either one executes. Choosing the right shape for the task's dependency structure is a separate problem from keeping everything running inside that shape coherent with everything else running inside it, and matching the topology only solves the first one.

There's also a real cost to defaulting to a supervisor everywhere out of caution. A task that's genuinely decomposable into independent pieces, where agents aren't waiting on each other's outputs at all, loses real parallelism when it's forced through a centralized gatekeeper that makes every agent wait its turn regardless of whether a dependency actually exists. The mapping step matters in both directions. It's just as much a mistake to force a genuinely independent, parallelizable task through a strictly sequential supervisor as it is to let a strictly sequential task run loose in a mesh. The map comes first specifically so the topology decision is grounded in the task's actual dependency structure instead of a coin flip between "resilient-sounding" and "cautious-sounding" defaults.

The real limit of mesh topology, even where it does fit, is the connection growth I mentioned above. A task that's genuinely decomposable into three or four independent pieces is a reasonable fit for a mesh. A task that's decomposable into fifteen or twenty independent pieces is a different problem entirely, because the number of connections between peers grows quadratically with the agent count, and a mesh that was manageable at four agents becomes something nobody can actually reason about at fifteen. Decomposability alone makes mesh the right answer only at a scale, and that scale has a ceiling I'd rather know about before building past it.