What is a Specialist Agent?
A specialist is one focused AI agent inside an Agent Stack. It handles a specific kind of question — orders, cancellations, returns, billing, technical support, onboarding — and only that. For chat, the router picks which specialist takes each message; the specialist replies.
Voice stacks route the same way: a spoken turn goes through the same orchestrator routing decision as a chat message, so a scope or routing rule written for chat applies to a call without being re-done. What differs is latency — a call short-circuits the routing round trip on single-specialist stacks, keypad input and short continuations, and if the decision takes longer than four seconds the catch-all specialist answers instead. A turn where no decision was reached is recorded against the catch-all with a routing confidence of 0.
The single biggest lever you have over how well an Agent Stack performs is how you slice the work into specialists. A stack with one generalist will always be weaker than a stack with five focused specialists, because each specialist can have its own scope, its own instructions, and only the knowledge and capabilities it actually needs.
What a specialist is made of
When you open a specialist from the orchestrator canvas, the slide-over header shows four derived counters — Capabilities, Knowledge, Playbooks, Routing topics — above the sub-tabs, and the Setup tab below holds three fields.
- Agent Name — Internal identifier. Customers never see it — replies go out under the stack’s name — “Billing Support”
- Responsibility — What this specialist handles. Used by the router to pick who answers. (The Add dialog labels the same field Scope.) — “Billing, invoices, refunds, subscription changes”
- Instructions — Specialist-specific behavior — required steps, things to always do, things to never reveal, escalation triggers, reply format — “Confirm account email before issuing refunds. Hand off charges older than 90 days.”
That split — Responsibility vs. Instructions — is important. Responsibility is what topics come here. Instructions is how to behave once a topic is here. Don’t put tone in either; tone lives on the stack’s Personality tab.
Scope is what the router reads
The router uses LLM-based topic matching to decide which specialist takes a message. It looks at three signals:
- The Responsibility field on each specialist.
- Any Routing topics attached to a specialist.
- Any Routing rules appended to the orchestrator’s prompt.
Most stacks only need a clear Responsibility per specialist. When you add a specialist to a stack, a routing topic is generated from its Responsibility text automatically and goes into the router’s prompt — but it is filed against the stack’s router, so the specialist’s own topic counters (the slide-over header, the canvas card’s hover card) still read 0 / “inferred from responsibility”. The app has no editor for topics at all; adding or editing them is only possible through the public API. The orchestrator-level routing rules are for global preferences (“prefer Billing over Tech for refund questions”). See Define routing topics.
A specialist with empty Responsibility and no routing topics shows a warning triangle on its canvas card (“No routing signals — orchestrator may struggle to route messages here”) — fill in the Responsibility at minimum.
Knowledge access — per specialist
Each specialist’s Knowledge tab controls how much of the stack’s knowledge it can read. Note that the Knowledge Base and Handbook dropdowns on that tab set which knowledge base and handbook the whole stack is bound to — only the category restriction underneath is per specialist.
- Knowledge Base — pick Full access (every category, including ones added later) or Restrict to specific categories. Customer-facing articles. Quoted and linked in replies.
- Handbook — off by default; once a handbook is selected you can tick Restrict to specific categories. Internal procedures. Used to guide behavior, never quoted directly to customers.
- Library (knowledge packs) — add packs from the specialist’s Knowledge tab with the Add knowledge pack button and its slideout. Only packs enabled for your tenant are available. Packs supplement the specialist’s Knowledge Base and Handbook access; they don’t replace either one.
- Code bases — assign connected repositories from the specialist’s Knowledge tab. Repositories are still connected tenant-wide in Settings → Code bases; this card only chooses which connected code bases this specialist can use. Specialists default to no code-base access. One What it may say setting covers the whole card — either Answer in product terms or May cite file and line — not one setting per repository.
A technical-support specialist might have access to the troubleshooting KB category, the technical-procedures Handbook category, and the product repository with May cite file and line enabled. A billing specialist might have a different scope — refund policies in the Handbook, billing FAQs in the KB, and no code bases at all. Tighter scope = faster, more accurate retrieval.
See Give a specialist knowledge access.
Capabilities — per specialist
Capabilities are the actions a specialist can take in external systems. Each specialist gets only the capabilities it needs:
- The order tracker gets the order-lookup capability.
- The billing agent gets the refund and invoice-lookup capabilities.
- The product expert gets nothing acting — just KB access.
Each capability assignment can override the default security level. Three levels are offered: No proof (level 0, open to anyone), Verified customer (level 2 — a code sent to a channel already on their account), and Signed-in customer (level 3 — signed in on the connected system). Level 1 is retired: nothing at runtime grants it, so it isn’t offered. An order-status lookup might sit at No proof (anyone can ask “where’s my order”), but a refund action needs a signed-in customer.
Playbooks — multi-step procedures
A playbook is a deterministic procedure the specialist follows for a specific task — “process a return,” “verify identity,” “escalate a complaint.” Playbooks live under each specialist’s Playbooks tab and can be edited as a visual canvas.
Playbooks are useful when the LLM is reliable for one-off answers but inconsistent for multi-step flows where order matters. If your specialist sometimes skips the “did you turn it off and on again” step, a playbook makes sure it doesn’t.
The catch-all specialist
Every stack that has specialists has exactly one catch-all — it is required, not optional, and the first specialist you add to a stack becomes it automatically. Look for the star icon and the “Catch-all” badge on the canvas. There is no control in the app for moving the designation to a different specialist; that only happens through the public API (PATCH /api/v1/agent-stacks/{id} with catchAllSpecialistId).
The catch-all is a voice fallback. On a call, it answers the turns the router didn’t decide — a routing call that timed out or returned nothing. In chat there is no fallback to it: when the orchestrator matches no specialist it answers the turn itself, asking a clarifying question or deflecting an out-of-scope request.
Specialists are precise, not creative
Specialist temperature is forced to 0 at runtime. The temperature column exists in the schema because Self-Learning writes adjustment proposals there, but in practice every specialist replies deterministically. If you want personality, that’s the Personality tab — voice and tone are stack-wide.