Multi-Agent Systems

Built only when you actually need one

Multi-agent systems are the most over-sold pattern in AI right now. Most teams asking for one need a capable assistant with the right skills and a couple of tight workflows — not a swarm of agents to coordinate. I help you find the rung you actually need, and build a real multi-agent system only when the situation genuinely demands it.

Start with the simplest thing that works

Anthropic's own engineering guidance is blunt: "find the simplest solution possible, and only increase complexity when needed. This might mean not building agentic systems at all." (Building Effective Agents)

There's a cost reason, not just a taste reason. Agentic systems spend roughly 4× the tokens of a normal chat, and multi-agent systems around 15× — so they only pay off when the value of the task is high enough to justify it. (How we built our multi-agent research system)

For most business work, a general assistant with a well-built library of skills — the approach behind ThirdBrain BOB — plus a few small, deterministic workflows covers the ground, with far less to build, break, and maintain.

The ladder — four rungs, in order

Pick the lowest rung that meets the need, not the most sophisticated

1. A capable assistant + skills — one agent, a curated toolkit, picks what it needs at runtime. Handles the large majority of business tasks.

2. A small deterministic workflow — fixed steps that tie into the same skills, for when a process must run the same way every time. Anthropic calls this a workflow: "LLMs and tools orchestrated through predefined code paths."

3. A dynamic agent — when the task is open-ended and the model should decide how to break it down at runtime. Anthropic calls this an agent: "LLMs dynamically direct their own processes and tool usage."

4. A true multi-agent system — multiple coordinated agents, and only when the structure buys you a guarantee a single agent can't (below).

Modern models and harnesses can already spawn subagents dynamically at runtime — so you rarely need to hard-code an orchestration the model can derive itself. The rule I work by: pre-define the rails (the constraints that must hold), not the route (the reasoning).

When a pre-defined multi-agent system IS the right call

Build the real thing when the value comes from structure, not raw intelligence — specifically when you need a guarantee a single dynamic agent can't give you:

  • Determinism & auditability — the same process every time, with a provable trail. Workflows offer "predictability and consistency for well-defined tasks."
  • A bounded cost & latency envelope — a fixed topology has a known cost; dynamic fan-out varies from run to run.
  • The right model for each step — route bulk, easy work to a small, cheap model and the hard step to a frontier model. (This is Anthropic's own routing example: Haiku for the easy questions, Sonnet for the hard ones.)
  • Durable, resumable, human-in-the-loop processes — long-running work with defined approval gates that survives restarts, rather than one ephemeral run.
  • High-volume repetition — if the same process runs thousands of times, compile it once instead of paying the model to re-reason the decomposition on every run.

None of these are "the task is hard." They're all "I need a guarantee, at a scale that justifies building and maintaining the structure."

When NOT to split into agents at all

Knowing when not to build one matters just as much. Splitting work across agents backfires when:

  • The work shares one context. Anthropic: domains that "require all agents to share the same context, or involve many dependencies between agents, are not a good fit for multi-agent systems today."
  • It's write-heavy, not read-heavy. Research and reading parallelize well; multiple agents writing toward the same output create coordination conflicts. Cognition's "Don't Build Multi-Agents" makes this case hard for coding work — see Philipp Schmid's synthesis of the debate.
  • It isn't genuinely parallel. Multi-agent only earns its ~15× cost on breadth-first tasks with independent branches. If the work is one connected chain, a single agent — or a simple workflow — wins.

How I work with you

  • Diagnose first — I work out which rung you actually need before proposing anything. Often the honest answer is "you don't need a multi-agent system," and I'll tell you so.
  • Build to the guarantee, not the hype — if a workflow suffices, that's what you get. If you genuinely need multi-agent (audit trail, cost ceiling, per-step model routing, resumable human gates, or parallel breadth), I build it observable, testable, and bounded.
  • Framework-agnostic — I work with current tooling (LangGraph, CrewAI, the OpenAI Agents SDK, or custom orchestration) and choose by fit, not fashion.
  • You own it — complete documentation and knowledge transfer so your team can maintain and extend the system independently.

The thinking behind this

This position is grounded in current published guidance, not vendor hype

Not sure which rung you need?

That's the right question to start with. Book a call and we'll figure out the simplest thing that actually solves your problem.