On May 7, 2026, OpenAI shipped GPT-Realtime-2 with GPT-5-class reasoning. A few days later, ElevenLabs quietly added a visited_agents field to its conversation response — an array that tracks, agent by agent, which AI agents took part in a single call.
Almost nobody covered it. Yet it's probably the most important design change in AI voice agents in the last eighteen months.
Why? Because it formalizes an idea that the better integrators have been whispering since the start of the year: your Quebec SMB may not need an AI voice agent. It may need several — that talk to each other, hand calls back and forth, and specialize.
Or it may not. That's exactly the question we tackle here.
What "multi-agent" really means
A monolithic voice agent does everything: it answers, qualifies, books, transfers, takes payments, speaks French and English, manages your Google Calendar. One brain. One prompt. One personality.
A multi-agent architecture splits that brain into specialized agents:
- Reception — qualifies the caller in 15 seconds and routes.
- Booking — knows your calendar, your services, your durations.
- Customer service / billing — accesses the CRM, invoices, customer records.
- Smart transfer — hands off to a human with the full context.
Each agent has its own prompt, its own voice (optional), its own tools. They pass the call like a baton, carrying the conversation history with them.
From the caller's perspective, it's one service. From inside, it's a team.
The numbers you need before you decide
The "one agent vs many" debate isn't philosophical. It's measurable. The benchmarks published earlier this year in Innervation AI's 2026 guide on multi-agent architectures paint a pretty clear picture:
- +23% accuracy on tasks that demand complex reasoning when you move to multi-agent.
- 15x more tokens consumed. Yes, you read that right. Multiply your LLM bill by fifteen for conversations of equivalent length.
- -39% to -70% performance on tasks that require strict sequential reasoning — exactly the kind of task a step-by-step booking represents.
- 200 ms of coordination overhead at 5 agents. At 50 agents, you cross 2 seconds. Knowing that on the phone you already have to obey the 800 ms latency rule before the caller hangs up, that detail isn't a detail.
- Anthropic, on their own internal tests, sees +90.2% improvement with a "lead-agent + helpers" design on distributed research tasks.
- Without a central orchestrator, errors propagate by a factor of 17.2x. With one, you drop to 4.4x. Reliability is an architecture decision, not luck.
Translated for a Quebec SMB: multi-agent is expensive, sometimes slower, and mostly helps when there are genuinely several "domains" to cover. It isn't magic. It's a tradeoff.
The three-domain rule
Here's the rule we use at TECHMA with our Quebec SMB clients, drawn from the recommendations of several research teams:
What's a "functional domain"? A block of knowledge that needs its own vocabulary, its own business rules, its own external tool. Examples:
- Booking (with calendar access)
- Product / service information
- First-line technical support
- Order or delivery tracking
- Claims / disputes
- Sales pre-qualification
A dental clinic with a single service (appointments) stays firmly in "one agent" territory. A car dealership that has to handle sales, after-sales, parts, financing and collision — five domains — tips into multi-agent.
Three concrete Quebec SMB scenarios
Scenario 1: The independent hair salon (1 location, 8 employees)
Volume: ~80 calls/week. Tasks: book appointments, quote prices, manage cancellations.
Verdict: single agent. One functional domain (booking), one external tool (the online calendar), no heavy bilingual load. Multi-agent would add cost and latency without a measurable benefit. This is exactly the case where, above 45% single-agent accuracy, adding more agents produces negative returns.
Scenario 2: The restaurant chain (4 locations, dine-in + delivery)
Volume: ~600 calls/week. Tasks: reservations, takeout orders, modifying orders, tracking the driver, complaints, allergen questions, mandatory bilingual.
Verdict: lightweight multi-agent architecture. Two or three agents — reception, order-taking, human transfer — with a central orchestrator. This is the gray zone where the ROI calculation decides: if the monthly recovered revenue exceeds the extra token and setup cost, multi-agent pays. Otherwise, an enhanced single agent stays more prudent.
Scenario 3: The car dealership (1 location, 5 departments)
Volume: ~400 calls/week. Tasks: new sales, used sales, after-sales, parts, body shop, financing, plus the autumn tire-rush calls.
Verdict: clear multi-agent. Five to six domains, each with its own data, its own hours, its own scripts. A monolithic agent becomes unmanageable: its prompt balloons, it routes to the wrong department, it loses context. Multi-agent here becomes the architecture that's easier to maintain, even if it costs more to run.
Why 2026 changes things (and not before)
Three things lined up in the last six months:
1. Reasoning has become fast enough. With OpenAI's GPT-Realtime-2, an agent can reason "like a GPT-5" without breaking the tempo of the conversation. Before, an agent deciding "should I hand off to my colleague agent?" burned 1.5 seconds of silence. Today it's instant.
2. The platforms caught up. In May, ElevenLabs added tracking of visited_agents in its conversations, which finally lets you debug who did what during a call. Small as a changelog item, huge if you operate several agents. The trace lives in the ElevenLabs changelog. OpenAI, for its part, is pushing its Agents SDK with native handoff support — visible in OpenAI's gpt-realtime announcement.
3. LLM costs have dropped enough to absorb the 15x of multi-agent for SMBs with serious volume. What would have cost $800 a month in 2024 costs $90 today for the same volume. The ROI calculation flips.
The traps we see most often
The "more is better" trap. Some integrators sell multi-agent to solo dentists because it impresses in demos. That's overkill. More complexity, more failure points, more debugging. If your traditional voice menu fit on three options, you probably don't need five AI agents.
The hidden latency trap. Every agent-to-agent handoff adds 150 to 400 ms if it's done well. Over three handoffs, you've eaten your 800 ms budget. At 1.2 seconds of silence between two sentences, the caller assumes the line dropped.
The observability trap. When a call fails in a multi-agent system, knowing which agent broke is non-trivial. Without a dashboard that traces handoffs (which is precisely what ElevenLabs' new visited_agents field provides), you're flying blind. Build the tooling before deployment, not after.
The governance trap. More agents = more prompts to maintain = more versions to manage. Should a price update propagate to every agent? How? Who validates? If you don't have a clear answer to those questions, stay on a single agent for another six months.
How we design this at TECHMA for Quebec SMBs
Our team handles the whole setup — there's no self-service configuration for you to wrestle with. Concretely, for an SMB considering multi-agent, here's how we work:
First, we map the real functional domains by listening to 30 to 50 actual calls. Not by imagining them. Three times out of four, what a client thinks of as "five different services" turns out to be three domains plus two variants of the same one.
Then we decide the architecture: enhanced single agent, or multi-agent with a central orchestrator. The default reflex is single agent. We only move to multi-agent when the data shows it pays.
If we go multi-agent, we hold to three principles:
- A central orchestrator that owns routing — no peer-to-peer anarchy between agents.
- A human-backup agent always available, ready to take over with the full transcript when an AI agent gets stuck.
- Logging of every handoff into a dashboard the client can consult — so you're never blind to what the agents are doing.
That's agent engineering, not prompt engineering.
Should you wait?
Honestly, for 70% of the Quebec SMBs we see, the answer is still "one agent, done well." Multi-agent answers a real problem, but a problem of volume and complexity that most SMBs don't have. Not yet.
For the 30% who genuinely have more than three functional domains with sustained volume, the 2026 environment is probably the first time the math holds up. Latency under control, mature platforms, reasonable LLM costs.
The only bad move is building a multi-agent system because it's fashionable, then paying 15x the cost for calls a single agent would have handled better.
If you're undecided, the right first step isn't picking an architecture. It's relistening to thirty of your incoming calls from the last two weeks and counting, by hand, how many distinct functional domains genuinely appear. That number will tell you almost everything.