Anatomy of an Agent Stack
An Agent Stack is not a single prompt with a giant system message. It’s a layered system, and the layers do different jobs. Once you’ve seen them, the rest of the configuration UI starts to make sense.
The two runtime layers
Customer message
│
▼
┌──────────────┐
│ ORCHESTRATOR │ Decides which specialist takes this turn
└──────┬───────┘
│
▼
┌────────────────┐
│ SPECIALIST │ Replies to the customer
└────────────────┘
There is no separate router stage: the orchestrator is what routes. (A stack can still carry a legacy router member from an older version; the pipeline drops it before it builds the specialist surface, and nothing you create today produces one.)
For text conversations, every turn goes orchestrator → specialist. Voice calls use the same stack configuration differently: the call brain loads the tenant baseline, stack playbooks, and the knowledge and tools of every specialist on the stack — the catch-all included — into a single flattened runtime, because a call does not pick one specialist per turn.
Orchestrator
The orchestrator is the front door and the manager in one. When a customer message arrives it decides which specialist should handle the topic, using LLM topic matching against each specialist’s scope (responsibility text) and any explicit routing topics defined for that specialist. The decision is made fresh each turn, so a conversation that changes subject moves to a different specialist without the customer noticing.
It is also where risk escalation lives: sentiment and risk signals — frustration, a legal threat, churn risk, an explicit ask for a human — reach the handover tool from here.
The Orchestrator tab has exactly one control: a free-form text box for extra routing rules, such as “for refund questions, prefer the Billing specialist over the Tech specialist.” Anything you type there is appended to the default prompt — the built-in actions and core rules always stay in effect. Save, Discard changes and Clear saved rules sit beneath it. See The orchestrator.
Specialist agents
Specialists are the experts. Each one is a separate config with its own:
- Scope (responsibility) — the kind of questions it handles. Used by the router.
- Instructions — specialist-specific behavior, required steps, escalation triggers.
- Knowledge access — which Knowledge Base categories, Handbook procedures, Library packs, Documents and code bases it can use.
- Capabilities — the actions it can take in your other systems.
- Playbooks — multi-step procedures the specialist follows for specific tasks.
In text conversations, the orchestrator selects the specialist for each turn. In voice calls, the call brain unions the knowledge and tool scope of every specialist on the stack — not a relevant subset — instead of selecting one per turn, and that union includes their code-base assignments. Where those specialists carry different code-base disclosure modes, voice uses the strictest of them.
A specialist’s reply temperature is forced to 0 at runtime — specialists are precise, not creative. Stack-wide tone and voice live on the Personality tab; specialist-specific behavior lives in Instructions. See What is a specialist agent?.
Personality is stack-wide
Voice and tone — formality, directness, warmth, confidence, humor and emoji policy — all live on the stack’s Personality tab — they’re shared by every specialist in the stack. You pick a preset — Friendly help desk, Expert advisor, Concierge, Efficient, Brand-playful, or None — and tune the dimensions from there. See the personality presets reference.
This split exists for a reason: customers should not feel like they’ve been transferred to a different person every time the orchestrator hands off. Tone stays consistent across the stack; expertise changes between specialists.
Background — infrastructure agents
Behind the two runtime layers sits a set of infrastructure agents handling cross-cutting concerns. Thirteen types exist; these are the four you are most likely to configure:
- Conversation summary — Generates a running summary of the conversation, used at handoff and shown in Sidekick
- Sentiment & risk — Tracks customer sentiment and flags conversations as risky for auto-escalation
- Handoff pack — Prepares a briefing — summary, sentiment, suggestions — for the human picking up
- Missing info — Identifies what information is still needed to resolve the issue, and how to ask for it
Each can be toggled on or off and has its own configuration. See Infrastructure agents reference.
Tabs in the configuration UI
When you open a stack from Settings → Agent Stacks, you see these tabs:
- General — Name, avatar, enabled toggle, and Automatically mark as Done after inactivity (the timer resets on every new message). Voice-type stacks show voices per language and the welcome greeting here instead of an avatar
- Personality — Persona presets and tone dimensions for the whole stack
- Orchestrator — The stack diagram. Click the orchestrator to customize routing rules; click any specialist to drill in
- Agents — Flat list of specialists with the same drilldown (legacy view; the Orchestrator canvas folds this in)
- Handover — Triggers, Prerequisites and Delivery — when, what, and to whom. A voice-type stack shows the voice handover card and Prerequisites instead of those three: nothing on the call path reads the delivery settings, so they would silently do nothing
- Testing — Test sandbox for the stack and individual specialists, the browser voice test card for voice-type stacks, plus the tuning flow
- Change History — Audit log of changes to the stack
- Danger Zone — Delete the stack
Text-type stacks do not show voice settings.
Inside any specialist drilldown you’ll find four sub-tabs: Setup (name, scope, instructions), Capabilities (which tools it can call), Knowledge (five sections — Knowledge Base, Handbook, Library, Documents and Code bases), Playbooks (multi-step procedures).