Everyone’s building agents. The teams that are actually shipping — the ones moving past demos into production — are hitting the same wall: one agent isn’t enough.

A single agent can answer questions, call tools, maybe kick off a workflow. But the moment you need an agent to research, plan, execute, and verify across different domains? You need multiple agents working together. And that’s where things get interesting — and messy.

I’ve spent the last few months watching multi-agent architectures evolve from academic curiosity to production necessity. Here’s what’s actually working, what’s failing, and why the orchestration layer might matter more than the model you pick.

The Single-Agent Ceiling

Let’s say you’re running a trading desk’s post-trade operations. You build an agent that handles trade exception resolution — it can look up trade details, match against counterparty confirms, and flag discrepancies. Works great.

Now you want it to also monitor settlement risk, reconcile portfolio positions, and coordinate with your compliance system. You could keep stuffing tools and context into that one agent, but you’ll hit problems fast:

  • Context window bloat. The agent needs different context for exception resolution vs. reconciliation vs. compliance. Loading everything means wasting tokens and degrading performance.
  • Tool explosion. Twenty tools is manageable. Sixty is a nightmare for tool selection accuracy.
  • Failure blast radius. One bad tool call in your reconciliation logic shouldn’t take down exception handling.

The answer isn’t a bigger model. It’s specialized agents that know their domain and a coordination layer that routes work between them.

Three Patterns That Work

After looking at production deployments across financial services, data-heavy enterprises, and SaaS platforms, three orchestration patterns keep showing up.

1. Supervisor Pattern

One orchestrator agent receives requests and delegates to specialized worker agents. The supervisor decides who does what, collects results, and synthesizes a response.

User Request
    ↓
[Supervisor Agent]
    ├── [Research Agent] → searches docs, APIs
    ├── [Analysis Agent] → runs calculations, comparisons  
    └── [Action Agent]   → executes writes, sends notifications

Where it works: Trade exception handling is a natural fit. The supervisor triages incoming breaks — routing pricing discrepancies to a valuation agent, settlement mismatches to a counterparty reconciliation agent, and regulatory flags to a compliance agent. Each specialist has its own tools and context — the supervisor just coordinates.

The trap: Don’t make your supervisor too smart. It should route and synthesize, not do deep work. The moment your supervisor starts making domain decisions, you’ve recreated the single-agent problem with extra steps.

2. Pipeline Pattern

Agents are chained sequentially — each one transforms, enriches, or validates before passing to the next. Think assembly line.

Raw Data → [Extraction Agent] → [Validation Agent] → [Enrichment Agent] → [Load Agent]

Where it works: Portfolio reconciliation is a natural fit. One agent extracts position data from custodian reports, another validates against internal book-of-record systems, a third reconciles NAV calculations and flags breaks, and a final agent routes exceptions to the appropriate ops team or auto-resolves within tolerance thresholds. Each agent is simple, testable, and replaceable.

The trap: Error handling. When agent three fails, do you retry? Skip? Roll back agents one and two? You need circuit breakers and dead-letter queues, just like microservices. Agents don’t magically solve distributed systems problems.

3. Collaborative Pattern

Multiple agents work on the same problem simultaneously, sharing a workspace or message bus. They negotiate, critique, and refine each other’s work.

[Planning Agent] ←→ [Review Agent]
       ↕                  ↕
   [Shared Workspace / Data Layer]

Where it works: Risk scenario analysis. A modeling agent proposes portfolio stress scenarios based on market conditions and exposure limits. A risk validation agent checks against VaR thresholds, concentration limits, and regulatory constraints. They iterate — the modeler adjusts assumptions, the validator re-checks — until they converge on a defensible risk assessment. Three rounds typically gets them there.

The trap: Infinite loops. Two agents can politely disagree forever. Always set iteration limits and have a fallback (usually: escalate to a human or go with the last “good enough” result).

The Real Problem: Data Handoffs

Here’s what nobody talks about in the multi-agent blog posts: how agents share data between steps.

When Agent A produces output that Agent B needs, how does that handoff work? Most frameworks punt on this — they serialize everything to strings and stuff it in the next prompt. That works for small payloads. It falls apart completely when you’re passing datasets, structured records, or anything beyond a few KB.

This is exactly why I built Datris Platform with agent-native data operations in mind. When agents need to pass structured data between stages — validated, transformed, profiled — you need infrastructure purpose-built for it, not prompt-stuffing.

The pattern I keep seeing work:

  1. Agent A writes results to a structured destination (database, file, API)
  2. A shared data layer handles schema validation, quality checks, and routing
  3. Agent B reads from that layer with full context about what it’s getting

The data layer becomes the coordination mechanism. Agents don’t need to know about each other — they just need to agree on the data contract.

What to Get Right First

If you’re building a multi-agent system, here’s the priority order:

  1. Define clear agent boundaries. Each agent should have a single responsibility and its own tool set. If you can’t describe what an agent does in one sentence, split it.

  2. Instrument everything. You need to trace a request across agents. Which agent touched it, what decisions were made, what data was produced. Without observability, debugging multi-agent failures is impossible.

  3. Design for partial failure. Agents will fail. Models will hallucinate. APIs will timeout. Every agent boundary is a failure boundary — handle it explicitly.

  4. Start with two agents, not ten. The supervisor + one specialist pattern teaches you 80% of what you need to know. Add agents only when you have a clear reason.

  5. Make your data layer agent-aware. Agents need to read schemas, validate outputs, and route data without human intervention. If your data infrastructure requires a human to configure every new pipeline, your multi-agent system will bottleneck there.

Where This Is Going

The next twelve months will separate the teams that built multi-agent systems on solid infrastructure from the ones that duct-taped prompts together. The patterns are stabilizing — supervisor, pipeline, collaborative — but the hard problems are all in the plumbing: data handoffs, error recovery, observability, and coordination protocols.

The model is the least interesting part of a multi-agent architecture. The orchestration and data layers are where the real engineering lives.

If you’re building agent systems that need reliable data operations underneath — pipelines that agents can create, execute, and monitor autonomously — take a look at Datris Platform. It’s open source, Docker-native, and built specifically for the world where agents are the operators.

Check out the docs at docs.datris.ai or star the repo on GitHub.

Todd Fearn is the founder of Datris.ai and has spent 25+ years building data infrastructure and AI solutions for financial services — from Goldman Sachs and Bridgewater Associates to Deutsche Bank, Freddie Mac, and beyond.