An AI agent answering every turn with one prompt and one model eventually becomes a generalist nobody has on their support team. Devotel Orbit's agent squads take a different shape: a classifier agent sits behind the inbound conversation, reads the customer's message, and hands the turn to whichever specialist agent owns that intent — while the whole exchange stays in a single conversation record.
Why multi-agent orchestration matters
The single-agent pattern breaks in one of four ways:
- Prompt bloat. An agent that handles sales, support, and billing in one prompt carries the instructions for all three on every turn. Every instruction competes for the model's attention, and the prompt degrades as your business grows.
- Wrong-model cost and latency. Routing a simple FAQ to a heavyweight reasoning model, or a billing dispute question to a cheap small model, both hurt: the former burns budget, the latter burns trust. Specialization means you can pick the right model per role.
- Guardrail mismatch. Billing needs different guardrails than onboarding support. One shared prompt can't safely mix "issue a refund" and "query the product catalog" with equal weight.
- Fragmented observability. When one agent does everything, you can't see which intents fail, which specialist caused a drop-off, or which role needs retraining. Splitting responsibilities gives you usable per-role analytics instead of a mushy "agent handled it" metric.
Squads are the orchestration answer: one classifier, several specialists, one conversation. The customer asks; the classifier decides which specialist continues; the exchange has a stable identity. The orchestration problem (which specialist, which prompt, which model) is solved by a structure you set up explicitly.
What a Squad is on Orbit
In Orbit, a Squad is a named orchestration structure with four parts:
- Classifier agent — one agent that receives every inbound turn for the squad, returns an intent label, and the router resolves it to a member.
- Specialist members — the agents the classifier can route to. Each member lists the intent labels it owns (for example
billing,refunds,invoice-issues) and a description the classifier reads to pick a label. - Optional fallback agent — where unmatched intents go, so a classifier that emits nothing the squad recognizes doesn't drop the turn on the floor.
- Optional daily cost cap — a cap on the LLM spend the classifier burns routing squad traffic, so a runaway classifier can't drain tenant budget silently.
The squad exists as a canvas in the dashboard: you drag the classifier, each specialist, and the fallback onto a graph, and define which specialist owns which intent label. The runtime also guards against the structural footguns — the classifier must not appear as a member, and the fallback must not equal the classifier, because both of those create routing loops. The same loop-free validation runs on create, on update, and again when the runtime routes a turn, so a broken squad can't be saved by accident or assembled into a loop later.
For inbound voice the same routing logic applies: a team's assigned inbound agent can be the squad classifier, and the first utterance of the call is classified just enough to decide whether the call continues with that agent or is rerouted to a billing, support, or sales specialist — without opening any extra outbound leg.
How squads differ from knowledge bases, memory, and model presets
Squads solve which agent handles this turn. That's not the only thing an Orbit agent needs, and squads aren't meant to overlap with the other knobs:
- [Knowledge bases](/agents/knowledge-base) supply the factual content a specialist grounding on. A squad says which specialist answers; the knowledge base says what the specialist may claim. Pair them: a billing member grounded on your billing docs, a support member grounded on your help content.
- [Memory](/agents/memory) keeps what a specialist has learned about this contact — identity facts, prior resolutions, preferences a per-contact window should not re-derive. Squads route the turn; memory scopes what the specialist remembers learning from that contact.
- [Model presets](/agents/model-presets) save which model, temperature, and provider settings each agent runs. Specialization without model presets still pays full price on every specialist; presets let you pin a cheap classifier model and a stronger specialist model per role.
Squads are the routing layer. The other three are orthogonal and composable with squads — and the squad is exactly where you compose them.
A worked example: Sales, Support, and Billing in one squad
Suppose a tenant wanted a general inbound agent and three specialists, one for each function. They define a squad with:
- Classifier: a general "Front door" agent whose sole job is to answer with an intent label
- Specialist members: Sales (
pricing,plans,upgrade), Support (how-to,troubleshoot,setup), Billing (invoice,refund,payment-failed) - Fallback: a general "Catch-all questions" agent so no recognized intent gets left unhandled
- Daily LLM cost cap: set so classifier routing spend can't exceed what the tenant budgeted
A customer on WhatsApp says "My card was charged twice." The classifier returns billing; the router hands the turn to Billing; Billing (grounded on the tenant's billing knowledge base, with memory of the contact's account) resolves the double-charge; the same conversation record now shows the classifier and the Billing specialist. Later the same contact says "is there a discount for annual?" — the classifier this turn returns pricing, the router hands to Sales, and the Sales specialist answers where Billing got before.
Every handoff shows up in the squad's analytics: which members carry the volume, whether intents land on the right specialist, and whether the fallback agent is doing too much work — a clear signal that the classifier's intent labels need adjusting.
Where squads differ from agent-comparison
Squads and agent-comparison are about different shapes of "which agent is better." Squads decide which agent handles this conversation at runtime — a routing choice, recorded per turn. Agent-comparison scores which agent performs better over time — side-by-side analytics of separate agents, useful once you've separated squad and non-squad designs. Use agent-comparison to decide which specialist deserves the most traffic; use squads to route the traffic to it.
Frequently asked questions
What is an agent squad on Orbit?
A named composition of a classifier agent, specialist members, and an optional fallback agent that the routing layer resolves to for each turn.
Does a squad replace the knowledge base, memory, or model presets?
No. A squad decides which specialist handles a turn; knowledge bases, memory, and model presets define what the specialist relies on and runs with. They are meant to be composed together.
What does the classifier actually do?
It reads the inbound message, returns an intent label, and the router resolves that label to the owning specialist. Four guardrails keep it honest: the classifier can't be a member, the fallback can't be the classifier, every member needs at least one intent label, and the same structural validation runs at create, update, and runtime route resolution.
Can squads route inbound voice calls too?
Yes. The assigned inbound agent for a voice phone number can be a squad's classifier agent, and the first utterance of the call is classified to decide which specialist continues — with no new outbound leg opened.
What does the fallback agent do?
When the classifier returns a label no member owns, or when it returns nothing sensible, the router hands off to the fallback agent instead of leaving the turn unresolved. Without a fallback, an unmatched turn just stops being routed at the classifier.
How do I see whether my squad is routing well?
The squad's analytics surface (Editor / Analytics tabs on the squad page) shows per-member utilization, handoff success and drop-off rates over 7/30/90-day windows, so mis-routed intents and over-used fallbacks are visible rather than guessing from raw volume.
The takeaway
Once a team's agents have grown past "one prompt, one model, one knowledge base," the routing question becomes the same problem inbound telephony has always had: an IVR or a front door deciding where the customer goes next. Squads put that orchestration structure in the agent layer itself, so the classifier, the specialists, and the fallback are designed to hold one conversation. The whole exchange still lives in a single conversation record, the runtime enforces the loop-free rules at the route-resolution layer, and the customer never has to know how many agents it took to answer.