Multi-agent systems

The pattern that turns AI from a clever assistant into a working team.

A general-purpose model is a generalist. A multi-agent system is a specialist team - each agent has a narrow job, a coordinator routes work between them, and the result behaves less like a chat interface and more like a teammate that already knows your standards, work routine, projects and clients.

Last updated:

What changes

What changes when you stop using one model for everything.

Most "AI agent" demos break the moment you ask for something they were not pre-prompted for. Multi-agent systems give you the appearance of capability; the underneath is the actual work - defined roles, tool-access controls, shared memory, retry logic, observability, cost ceilings. Three things change in practice once you take that work seriously.

Three things change in practice

Accuracy. Speed. Resilience.

  • Accuracy

    A reviewer agent catches what a drafter agent missed. Error rates on the systems we run sit in the single digits because we never ask one model to do the whole job.

  • Speed

    Agents work in parallel on independent subtasks and join the results. Requests that touch four systems return in seconds - not the half-hour it used to take a person to assemble the same answer by hand.

  • Resilience

    If one agent times out or fails, the orchestrator retries or routes around it. The whole task does not fall over because one tool was slow.

Patterns we use

Four shapes of multi-agent system.

  • Orchestrator-worker

    A coordinator receives the request, decomposes it, delegates each piece to a specialist, and assembles the final output. This is the pattern behind our deep-dive orchestrators - six sub-agents covering database queries, API calls, code search, web research, drafting, and validation, governed by a single coordinator that decides who needs to do what.

  • Sequential handoffs

    A pipeline. A researcher gathers context, hands it to a planner, who hands it to a writer, who hands it to an editor. Each step adds something specific. We use this on long-form content workflows where review fidelity matters more than throughput.

  • Parallel fan-out / fan-in

    The same input goes to multiple agents at once, and a join step combines their outputs. We use this on monitoring stacks - independent monitor agents (trend, process, hardware, log) run on their own schedules, surface anomalies into a shared queue, and an orchestrator decides which deserve a person’s attention.

  • Iterative refinement

    A coder agent generates, a reviewer scores, the coder revises against the score. Loop until the score clears the threshold or a budget runs out. Slower, but produces work that does not need a human pass. We use it on our own engineering work daily.

Single-agent vs multi-agent

Why one model rarely does the whole job well.

Asking a general-purpose model to handle the whole pipeline - intake, retrieval, reasoning, drafting, review, action - is the most common reason an AI feature underperforms in production. The fix is architectural, not a better model.

Single-agent (one model, the whole job)
common pattern · ships fast · breaks at scale
  • One general model handles intake, retrieval, drafting, review - it is mediocre at all of them
  • Errors compound silently; nothing inside the loop is checking the loop
  • No parallelism - the model waits on each tool serially
  • A single tool failure takes down the whole task
  • Cost grows linearly with prompt length, no matter how trivial the step
Multi-agent (specialist team, coordinator)
each agent does one job · reviewer catches drafter · parallel where possible
  • Each role is a specialist, prompted and tooled for its narrow job
  • A reviewer agent catches what the drafter missed before output ships
  • Independent subtasks run in parallel and join - wall-clock latency drops
  • Orchestrator retries or routes around a failing agent - task survives
  • Cheaper models for routine subtasks; frontier models only where they earn it
Use cases we ship

Multi-agent systems running in production.

  • Customer support triage

    Intake agent classifies, routing agent fetches the relevant context (knowledge base, ticket history, account state), answer agent drafts the response, reviewer scores tone and accuracy, escalation rules send anything below threshold to a human.

  • Marketing campaign planning

    Researcher gathers competitor and market signals, strategist drafts a plan, writer produces variants, planner schedules across channels.

  • Software engineering

    Coder generates, reviewer flags, manager handles approvals and deployment. We use this on our own work daily.

  • Financial analysis

    Pull-and-aggregate agents query multiple data sources in parallel, a reasoning agent synthesises, a validator cross-checks against source documents.

  • Operational monitoring

    Independent monitor agents watch separate signals; an orchestrator surfaces only the anomalies a human should see.

  • Document processing

    Extraction, classification, validation, and routing across high-volume document workflows - the kind that used to live in a back-office bullpen.

Frameworks we use

The framework is a means. The architecture is the product.

  • LangGraph

    Orchestrators with branching state machines - the right pick when the workflow itself has logic that needs to be inspected and replayed.

  • CrewAI

    Hub-and-spoke patterns where reliability matters more than flexibility. Faster to ship, simpler to operate, fewer moving parts.

  • AutoGen

    Iterative refinement loops - generator + reviewer + revisor cycles where each pass measurably improves the output.

  • Anthropic MCP

    Tool standardisation across providers. Agents swap models without rewriting their tool layer; long-term protection against vendor lock-in.

  • Custom Node + BullMQ

    Long-running cron and queue patterns where the framework adds more weight than it carries. The cleanest path when the work is mostly scheduling and retries.

Architecture over framework

The framework choice is tactical. The architecture is the product.

Roles, tools, memory, retries, observability, cost ceilings - those decisions determine whether the system survives in production. The framework on top is a tactical question we answer per engagement, often switching mid-project. The 19-skill ERP agent we run for SBS uses a different stack than the orchestrator behind the SBS-side intelligence pack - same architecture, different framework underneath. Architecture survives. Frameworks come and go.

FAQ

Three things people ask.

How is this different from "agentic AI" buzzword?
It is the same idea, with the engineering done. "Agentic" demos work in a slide; multi-agent systems work on Friday night when one of your APIs is degraded and a model returns malformed JSON.
Do we need a different model for each agent?
Often, yes - and the routing of "which model for which step" is part of what we tune. A frontier model for reasoning; a smaller, cheaper model for classification or formatting. Often a fine-tune for a narrow drafter role.
How do you keep cost bounded?
Per-agent cost ceilings, per-task wall-clock budgets, and routing rules that send 80% of traffic to cheaper models. The orchestrator enforces ceilings before a runaway loop turns into a runaway invoice.
AI that already runs

Bring us a problem that is eating your team's week.

Book a 30-minute diagnostic call. We tell you whether multi-agent is the right fit, and what an MVP would look like. Free; written summary either way.

Live · powered by Gemma-4 · running on our hardware in Sofia