Case study

Transformers: a swarm of narrow agents, not one clever one

HackFest idea · in development

One clever agent, or a swarm of narrow ones?

The tempting way to build an agent for a real job is one powerful model with access to everything, told to "figure it out." It demos well and fails badly: when its answer is wrong, you can't tell which part of its reasoning broke, so you can't fix it — you can only reprompt and hope. A confident wrong answer is worse than no answer.

Transformers is the other bet — a HackFest idea I'm building out, shaped by researching how existing agent swarms are designed. Split the job into narrow, verifiable agents that each do one thing, run them in parallel, and let an orchestrator synthesize their findings into one result. No single agent reasons over the whole picture, and the human keeps every decision. It's a fresh design, not a write-up of any one production system.

A trigger dispatches the swarm, which fans out to narrow specialist agents working in parallel — each owning one task — whose outputs are synthesized into a single result. Trigger Swarm dispatches Agent A Agent B Agent C Synthesis One result
Narrow agents work in parallel; an orchestrator synthesizes one result

Why narrow beats clever

The whole point is verifiability. Each agent owns one narrow task and can be tested on its own. When one misbehaves, you find it and fix that one agent, instead of rewriting a monolith's prompt and praying. Capability is easy; a piece you can trust because you can test it is the hard, valuable part.

  One clever agent (rejected) Swarm of narrow agents (chosen)
Debuggability Reprompt and hope Test each agent in isolation
Failure mode Confident wrong answer Honest partial picture
Trust Low — can't tell what failed High — failures are localized
Repairability Rewrite the prompt Fix one agent
Monolith vs swarm: why narrow agents win

Agents that fail honestly

One rule matters more than any framework choice: an agent that can't get its data says so. The missing piece is carried forward as a known gap, never papered over with a plausible guess. The synthesis returns an honest partial picture rather than a confident, complete-looking fabrication — and that's what makes a swarm trustworthy enough to rely on.

An agent attempts a retrieval. On success it feeds the synthesis as evidence; on failure it explicitly reports the gap, which still feeds the synthesis. Either way the result is an honest partial picture, never a fabricated summary. attempt retrieval success failure → reports gap synthesis honest partial picture never a fabricated summary as evidence gap is evidence too
A failed retrieval still feeds synthesis as a reported gap — the output is honest, never invented

Where it came from, where it's going

It began as a HackFest idea — a small bet that a swarm of narrow specialists beats one clever generalist on what matters in practice: debuggability, honest failure, and a clean line between what the machine does and what a human decides. The design is shaped by researching how existing agent swarms work — a fresh take, not a write-up of any one production system. I'm building it out now.

More to come as it takes shape.