One Agent, Many Skills — or Many Agents, One Orchestrator?

Source: A live-recorded build — same spec, same task-tracker app, two architectures.

Part 1 (above): the single-agent build, end to end. Part 2: the multi-agent version and the side-by-side comparison, coming soon. Code for Option A: github.com/narenmak17/single-vs-multi-agent-poc.

Where this came from

I was building an agent for real work. Hit a wall:

One agent with a few skills — or several smaller agents behind something that routes between them?

Both felt defensible. “Feels more proper” isn’t a reason though — it’s a vibe. So instead of guessing, I built the thing both ways and watched what actually changed.

Quick detour — isn’t this just microservices vs. monolith?

Kind of, yes. Map it directly:

• One agent, many skills → a monolith. One process, shared memory.
• Many agents, one orchestrator → microservices. Each with its own boundary.

Most tradeoffs carry straight over: a monolith is simple until it isn’t; microservices buy independent scaling at the cost of network calls and coordination.

One place the analogy breaks, though:

Microservices usually split because of deployment and team-ownership limits. Agents hit a different ceiling first — an LLM picking from a big pile of tools just gets worse at picking, no team problem required.

Same-shaped decision. Different root cause. Worth knowing which one’s actually pushing you.

So which do I pick?

Built the same app twice. Same spec, same API, same UI — architecture was the only variable.

The app: a task tracker. Add a task, mark it done, get flagged the moment something’s due soon and not done. Small on purpose, so the architecture question can’t hide behind feature complexity.

Wait — what’s the spec, exactly?

Before either option got built, there was just a plain-language ask: “we keep losing track of to-dos, flag what’s overdue, tell me what it costs to run.” That’s what a real stakeholder actually hands you.

Turning that into a written SPEC.md first is what makes the comparison fair — without it, “option B took longer” might just mean the prompt was vaguer that day.

The spec also carries something the stakeholder never asked for: guardrails. Five automated checks — API still matches, tests pass, no debug leftovers, no secrets — wired into a git pre-push hook. Not a reminder. An actual gate that blocks the push.

Option A — one agent, three skills

One process. Three plain functions, called directly. No message format, no network hop between them. A crash is just a crash — not a stuck handoff somewhere in the middle.

Option B — three agents, one orchestrator

Three separate modules, each owning one capability. The orchestrator is the only thing the UI talks to — it routes, then reconciles the reply.

Every arrow in that diagram is a round trip. Slow, drop, out of order — all possible. That round trip is the cost of this architecture. It’s also the entire reason to pick it, once the right conditions show up.

What actually happened

At this size, the single agent won — coordination, cost, latency, all three. The orchestrated version’s one real edge: change the reminder rule, only the reminder-agent changes. Barely matters when one person owns everything.

But “simple wins” isn’t the honest takeaway by itself. Here’s where it flips:

• Anthropic’s own multi-agent research system beat a single agent by 90.2% — using ~15x the tokens. Worth it only when the task’s value clears that cost.
• A Berkeley/NeurIPS 2025 paper traced most multi-agent failures to system design, not the model.
• A Google DeepMind/MIT paper (Dec 2025): coordination helps parallelizable tasks, hurts sequential ones. Task shape decides, not task size.
• Tool-selection accuracy measurably drops once one agent holds ~30-50 tools. That’s the real forcing function — not vibes.

That crossover is the whole decision in one picture.

The rule that survives both sides

Start with one agent and a well-curated set of skills. Split only when you can name the specific thing forcing it — not because the multi-agent version sounds more impressive in the design doc.

Decision matrix

The monolith/microservices lens from the top holds all the way through — same tradeoffs, same question: what’s actually forcing the split?

Decision checklist

Answer these before reaching for an orchestrator:

1. Can you name the forcing function? Team ownership, independent scaling, or a skill count already measurably hurting tool selection — not “feels more scalable.”
2. Is the task parallelizable or sequential? Coordination helps the former, actively hurts the latter.⁴
3. How many tools/skills does one agent actually hold? Under ~30, stay single. Past ~50, the accuracy cost is already showing up whether you’ve measured it or not.³
4. Can your task’s value clear a ~15x token cost? If the task is low-stakes or the win margin is thin, it won’t.¹
5. Is the failure mode you’re worried about actually a model problem — or a system-design problem? Most multi-agent failures trace to the latter.² A better prompt won’t fix a coordination bug.

If you answered “no” or “not sure” to most of these, start with Option A. You can split later — splitting a working monolith is far cheaper than un-tangling a premature microservice mesh.

What the recording actually shows

Each option’s build runs through the same eight steps — the sequence is the real point, not just the result:

1. Business requirement — plain language, no spec.
2. Project setup — clean skeleton first.
3. Spec-driven design — the ask becomes SPEC.md, guardrails included.
4. Build, one task at a time — checked against spec, summarized, before the next task starts.
5. Guardrails + the pre-push hook — proven live: broken push blocked, clean push goes through.
6. Docs — a real README.md and DEVELOPER-GUIDE.md.
7. A code-review skill, built from scratch — not pre-installed.
8. Tests, then a token-usage comparison between two optimization tools, side by side.

The token numbers land last — on purpose. The headline is steps 1 through 7.

Back to the analogy

Started this calling it monolith vs. microservices, and the matrix above is really just that debate wearing a different name. A monolith stays simple until a genuine pressure — team size, deploy cadence, scaling needs — forces the split. Agents hit their version of that pressure sooner, and from a different direction: not organizational friction, but a model’s own tool-selection accuracy degrading as the pile grows. Same shape of decision, different root cause, same answer either way — don’t split until something real is pushing you to.

Build it yourself

Shared spec, the full prompt sequence (steps 0–8, exactly as read on camera), and the Option A build with its commit history, including the push the hook blocked: single-vs-multi-agent-poc → option-a-single-agent. Option B lands in the same repo with Part 2.

Where has your own system hit the point where one agent holding too many tools became the actual bottleneck? Split it, or push through?

References