Multi-Agent Orchestration Explained

Multi agent orchestration explained the way most teams actually learn it: after the fact, reading a pull request that touches the API contract, the database schema, and the model integration layer, all written by one general-purpose AI agent that had no signal it had wandered out of its lane. The symptoms are familiar. A ticket that should have taken a day drags into a week because nobody caught the schema change until the frontend broke. Two engineers ask the same AI tool the same question three days apart and get contradictory advice because neither session had memory of the other's decisions. When something breaks in staging, there is no record of which agent, or which reasoning pass, produced the line that failed. Multi agent orchestration is not a buzzword for running two chat windows side by side. It is a specific architectural pattern: one coordinating agent that scopes the work, dispatches the right domain specialists, reconciles their output when it conflicts, and leaves a legible record of who owns what. Most teams reach for it too late, after the single-agent chaos has already cost them a sprint.

Why a generalist chatbot and an autocomplete tool both fall short here

Ask ChatGPT or Claude.ai to "add real-time fraud scoring to checkout," and it will happily draft an endpoint, sketch a scoring function, and maybe stub a database column, all in the same response, all from the same undifferentiated reasoning pass. There is no internal mechanism that says "the API contract and the model inference path are two different disciplines with two different failure modes, and they need two different specialists who can push back on each other." A generalist chatbot has one voice. It cannot argue with itself. It cannot notice that the latency budget the API layer needs and the latency the fraud model actually produces are two different numbers, because it never modeled them as two separate concerns owned by two separate parties. It just picks one number and writes code around it, and the conflict surfaces three weeks later in a p99 latency alert nobody can trace back to a decision.

Cursor and GitHub Copilot solve an adjacent but different problem. They are excellent at completing the line you are typing, at expanding a function signature into a plausible body, at suggesting the next block in a file that is already open. But autocomplete has no concept of a ticket that spans domains. It does not know that the change you are typing into the checkout controller has implications for a model-serving endpoint in a different repo. It cannot dispatch anything, because dispatch requires a coordinating layer above the file you happen to have open, and autocomplete tools are, by design, scoped to the file. When a ticket needs two specialists and a reconciliation step, both the generalist chatbot and the autocomplete tool give you the illusion of one agent doing the whole job, and that illusion is exactly where the handoff failures and the invisible ownership gaps come from.

What real orchestration requires: a coordinator, not just more agents

Adding more agents does not fix the problem on its own. If you open two separate chat sessions, one for backend and one for ML, and paste context between them by hand, you have just relocated the coordination burden onto yourself, and you have no record of the reconciliation once it happens in your head instead of in the system. Real multi agent orchestration needs three things a pile of independent agents does not give you for free: a coordinator that decides which specialists a ticket actually needs, a shared understanding of what each specialist owns so their outputs do not silently overlap or silently gap, and a reconciliation step where conflicting specs get resolved by an agent whose whole job is to look across domain boundaries, not just within one.

This is the role Apex plays on the Tonone team for Claude Code. Apex does not compete with Spine on backend work or with Cortex on model integration, it sits above both. When a ticket comes in, Apex runs discovery first, decides whether the work is single-domain (send it straight to one specialist) or cross-domain (scope it, then dispatch more than one specialist in parallel), and stays in the loop after their work lands to check that the pieces actually fit together. The apex-plan skill is where this starts: instead of writing code from the ticket text, it produces a structured scope with S, M, and L depth options, each with a time and token estimate, so the team decides how much coordination the ticket actually warrants before any specialist starts working.

Tonone's Apex is the coordinating layer that decides which specialist agents a ticket needs, dispatches them, and reconciles their output before it ships.

Reaching the right specialist, even the one you didn't have installed

Orchestration also has to handle the case where the ticket needs a specialist that is not in the team's usual working set. The apex-route skill exists for exactly this: when a scoped roster is missing the right hat for the job, Apex reaches any Tonone specialist on demand, no restart, no reconfiguration. This matters for orchestration specifically because the whole point of dispatching agents instead of running one generalist is that the right domain owner shows up for the right domain problem. If the routing step were manual, a coordinator would only be as good as the human remembering which fifty agents exist. apex-route makes the dispatch decision structural instead of a matter of institutional memory.

Spine and Cortex: two specialists, two different failure modes

Spine is the backend specialist on the Tonone team, owning API design, system design, and backend performance. When a ticket needs an endpoint contract, request and response shapes, error codes, and an auth pattern, Spine's spine-api skill produces the spec, applying the kind of consistency principles a production API team would insist on rather than the first shape that happens to work in a demo. Cortex is the ML and AI integration specialist, owning model selection, LLM and model integration architecture, and the data flow around a model-serving path. When a ticket needs an AI or ML feature wired into a product, cortex-integrate designs the integration: which model, what architecture pattern, what the system prompt or feature pipeline looks like, what the error handling is when the model call fails, and a cost estimate for running it in production. These are genuinely different disciplines with different failure modes: an API contract fails by being inconsistent or insecure, a model integration fails by being slow, expensive, or wrong in ways that are hard to detect. Multi agent orchestration exists because a single agent asked to do both at once tends to under-invest in whichever discipline it reasons about second.

A worked example: fraud scoring on the checkout flow

A payments team, call them the Fenwick checkout squad, files ticket FEN-482: "Add real-time fraud scoring to checkout before we submit the charge." This is a textbook cross-domain ticket. It needs a new endpoint in the checkout API and it needs a fraud-scoring model wired into the request path. A generalist AI agent handed this ticket in one shot would write a scoring function inline, probably assume a hardcoded threshold, and never surface the latency tradeoff buried inside the decision. Apex handles it differently.

Apex runs apex-plan first. Discovery surfaces that the checkout API currently has a synchronous request path with a 220ms p99 budget end-to-end, and that no fraud model exists yet, only a rules-based blocklist. Apex scopes three options: an S option that adds a rules-only pre-check with no model call (roughly 3 hours, ~9k tokens), an M option that adds a hosted fraud-scoring model behind a synchronous call with a fallback (roughly 1.5 days, ~48k tokens), and an L option that builds an async scoring pipeline with a pre-authorization hold pattern (roughly 4 days, ~120k tokens). The team approves M. Apex dispatches Spine and Cortex in parallel on the same ticket.

FEN-482, Fraud Scoring at Checkout, Option M dispatched

Spine (spine-api): checkout scoring endpoint
  POST /v1/checkout/score
  Request:  { cart_id, user_id, payment_method_token }
  Response: { risk_score: 0-100, decision: allow|review|block }
  Contract assumption: caller expects a response within
  the existing 220ms p99 checkout budget.

Cortex (cortex-integrate): fraud model integration
  Model: hosted gradient-boosted classifier (fraud-v2)
  Avg inference latency measured in staging: 380ms
  Cost estimate: ~$0.0009 per scoring call at current volume
  Flags: inference latency exceeds the API contract Spine
  assumed. Cannot hit 220ms p99 synchronously.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Apex reconciliation (apex-review):
  Conflict: 220ms contract vs 380ms measured inference.
  Resolution: checkout submits synchronously against the
  rules-based pre-check only (Spine's contract holds at
  220ms). Model score runs async and attaches a review flag
  to the order within 1s if risk_score > 70, routing to
  manual review instead of blocking the charge inline.
  Owner of record: Spine owns the endpoint contract post-fix.
  Cortex owns the model serving path and retrain cadence.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Next: both specs updated, single merged decision doc, ready
for implementation.

This is what orchestration actually buys the team: the conflict between a 220ms contract and a 380ms model surfaced before a single line of implementation code existed, not after a latency alert three weeks post-launch. The apex-review skill is what performs this reconciliation. It is not reviewing Spine's spec or Cortex's spec in isolation, each of those specialists already did a competent job inside their own domain. It is reviewing the boundary between them, the place neither specialist is individually responsible for, and it is the reason the team has a written owner of record for the endpoint contract versus the model serving path instead of a shrug when something breaks.

The reconciliation step, not the dispatch, is what separates real multi agent orchestration from two AI agents working the same ticket without talking to each other.

Notice what did not happen here. Nobody had to manually copy Spine's endpoint spec into a second chat window and ask Cortex to "check if this works with the model." Nobody had to remember, a month later, whether the 220ms number came from a real measurement or a guess. The merged decision doc names both specialists and the specific responsibility each one owns going forward, which is exactly the visibility gap that shows up when an incident hits production six months after a cross-domain ticket shipped and nobody can say who wrote which part.

Multi-agent orchestration vs the alternatives

The comparison below is specific to the orchestration question: not "which tool writes better code" but "which tool can take a cross-domain ticket, dispatch the right specialists, and reconcile their output before it ships."

The pattern generalizes past fraud scoring. Any ticket that touches an API contract and a model serving path, a database schema and a frontend data shape, or an infrastructure change and a security boundary, has the same structure: two disciplines, two sets of assumptions, one point where they have to agree. Multi agent orchestration explained simply is this: stop asking one agent to hold both sets of assumptions in its head at once, dispatch the two owners, and put a coordinator in charge of catching the place where their assumptions diverge before a user does.

Install and try

Tonone is free and MIT-licensed. Installing it once gives you Apex as the coordinating layer alongside Spine, Cortex, and the rest of the specialist roster, all available in the same Claude Code session. You pay only for the Claude Code token usage the work itself consumes, and Apex's scoping step shows you that estimate before any specialist is dispatched.