I Added More AI Agents to the Problem. Nothing Changed.
Adding multi-agent complexity to an LLM support system yielded identical performance scores and safety metrics compared to a single agent.
Stock photo for illustration only, not from the actual event
- A developer experimented with building a multi-agent support system and compared it to a baseline.
- Eval suite grading showed every single property score remained completely unchanged at 100% equivalence.
- Costs included increased production types, longer code lines, and extra orchestration hops.
- The structural multi-agent setup is kept in the repo to enforce automated build equivalence tests.
Declaring that a team considered multi-agent architecture and rejected it due to complexity is perhaps the most self-satisfied sentence in software architecture. Because such claims are notoriously unfalsifiable, they remain immensely popular in technical discussions.
Motivated by this, part 12 of an ongoing series on building an LLM-powered support agent involved actually building the exact multi-agent structure claimed to be unnecessary. The setup included a triage agent for routing, a refund specialist owning order tools and approval gates, a knowledge specialist answering from the corpus, and a coordinator holding them together.
Stock photo for illustration only, not from the actual event
Both architectural versions implement the exact same interface, allowing the evaluation suite to grade them blindly. Running the architectural comparison command via Gradle produced concrete evaluation metrics.
Not a single scenario changed its verdict, and not a single property moved by even a thousandth. Counting from the source code, the cost of this expansion turned one production type into five, grew 91 lines of code into 127, and increased orchestration hops from one to two. On an LLM stack where each agent triggers model calls, a single user request doubles its model invocation count.
Contextual analysis highlights that for single-turn tasks involving one customer message, a single lane, sub-second execution, and a small tool set, delegation acts as a handoff with nothing substantial to hand over. This contrasts sharply with heavy subagents chewing through dozens of files where parallel work genuinely pays off.
The routing decision is simply intent classification, a task the single agent handled since post six. Once routed, the specialists execute the exact same scoping check, policy engine, and risk gate in the identical sequence, dictated strictly by business requirements rather than code duplication. Eligibility cannot be evaluated before confirming order ownership.
The structural multi-agent model built here differs from autonomous runtime-negotiating agents. While runtime negotiation provides role-specific prompts and parallel execution, it doubles model calls, adds latency, and introduces a failure mode where two agents disagree on customer intent.
To keep the decision grounded in evidence rather than mere taste, an Architecture Decision Record (ADR) was established alongside a MultiAgentEquivalenceTest. This test runs both architectures on every build, asserting zero difference so that future architectural debates are triggered by failing test assertions rather than arguments.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment