Two agents are a prompt problem; forty are a distributed system

An engineering write-up published on dev.to under the byline tamizuddin, originally posted to tamiz.pro, argues that agent-to-agent coordination is "a distributed systems problem dressed in conversational clothing" ^[1][2]. That framing matters because the failure modes it names, resource contention, unbounded fan-out, and prompt injection flowing across trust boundaries between agents, only appear after the demo works ^[5].

The author separates the difficulty into three compounding parts: communication complexity, orchestration overhead on top of an already non-deterministic LLM layer, and cost and latency multiplication ^[3]. The last one is the easiest to underestimate. Every inter-agent message is a potential model call ^[4], and the worked example, three agents in round-robin exchanging five messages each, produces 15 or more invocations for a single user request [c5b]. Read the arithmetic back and the implication is that spend tracks the edges in your communication graph, not the count of agents on your org chart ^[1].

Hermes, as described, treats coordination as message passing with typed interaction protocols, on the theory that delegation, result synthesis, and conflict resolution are predictable patterns that should be declared rather than allowed to emerge from conversation ^[6]. It splits agents into stateless parallel workers doing narrow jobs such as retrieval, code execution, and validation, and stateful sequential specialists handling reasoning steps that depend on prior results ^[7].

The load-bearing constraint is that workers never talk to workers. All inter-agent traffic goes through the orchestrator, which enforces a directed acyclic communication graph, which the author credits with preventing combinatorial message growth and making the execution plan auditable ^[8]. Around that sit a static routing table with dynamic load balancing, typed message queues per agent group, and a result aggregator that does a deterministic merge before any LLM reconciliation ^[9]. That ordering is the interesting detail: reconciliation by model is the fallback, not the default path.

State sharing is handled by reference, not by copy. Messages carry an optional contextRef pointing at a shared context blob and a TTL in seconds, alongside a typed envelope of delegation, result, conflict, or escalation ^[10]. Results report output, tools used, tokens consumed, confidence, and citations ^[11]; conflict handling has a vote payload carrying agent id, confidence, and reasoning ^[12]. The author's defence of this boilerplate is operational rather than aesthetic: when a call fails at 3 AM you want structured error propagation, not a reasoning trace you have to parse out of prose ^[13].

One thing to be straight about. LobeHub is named in the headline and set up as the second distinctive approach whose architectural decisions reveal the design space ^[1][14], but the supplied text breaks off mid-sentence at "The cost model is where Hermes" and never describes LobeHub's coordination or state-sharing choices ^[15]. On the evidence here this is one implementation examined, not two compared, and the claim that these are the choices which survive dozens of concurrent agents rests on assertion rather than reported numbers.

What to watch: whether the acyclic constraint holds once specialists need to revisit a worker's output, since that is where a DAG turns into a loop; whether the missing cost-model section quantifies the orchestrator as a bottleneck rather than just a chokepoint for audit; and what happens to in-flight work when a shared context blob outlives or undershoots its TTL ^[8][10].