Settingsbeginner

My Agent Stack isn't replying — where do I look?

When an Agent Stack stops replying or never replies in the first place, work through these checks in order — channel wiring, stack enabled, specialist enabled, capability errors.

Updated September 2, 20264 min read

My Agent Stack isn’t replying — where do I look?

A stack that’s not replying is usually one of five problems. Walk through them in order — most teams find the cause by step three.

1. Is the stack wired to the channel?

A stack only handles conversations on channels you’ve connected to it. The most common cause of “the stack isn’t replying” is “the channel doesn’t know about the stack.”

Open your channel’s settings and find its routing control:
Settings → Web Chat → Routing — the Route Conversations To dropdown.
Settings → Email — the Route To dropdown on the inbox (it lists teams and Agent Stacks together).
Settings → Voice — the default Agent Stack picker for the number, saved with Save default Agent Stack. If the number also has an IVR flow, the IVR wins.
Confirm it points at this stack. If it’s empty or points at the wrong stack, set it correctly and save.

2. Is the stack enabled?

Open Settings → Agent Stacks → [stack] → General.
In the Stack settings card, confirm the first switch reads Enabled rather than Disabled.
If it’s off, toggle it on. It saves immediately. New conversations on the stack’s channels will start being handled; conversations already open stay where they are.

3. Is the relevant specialist enabled?

The stack might be on, but the specialist that should answer might be off.

Open the Orchestrator tab.
A disabled specialist is dimmed on the canvas and its card carries an off badge; the card’s hover tooltip and the slide-over header spell it out as Disabled.
There is no toggle in the app for re-enabling one — the Setup sub-tab holds only Agent Name, Responsibility and Instructions. Re-enable it with PATCH /api/v1/specialists/{id} and enabled: true.

4. Did a capability fail?

When a specialist is configured to call a capability and the capability errors, nothing customer-facing says so — the failure shows up in the turn’s debug trace, which names each tool the specialist ran and whether it succeeded. The fix path:

Open the conversation in Conversations (or in Monitor for in-progress). A Super Admin with debug on (command palette → “Debug: On”) gets a debug panel under each AI reply listing the tools that ran and whether each succeeded.
Open the offending capability in Settings → Capabilities and re-run it against the live endpoint from the editor’s test panel — there is no stored execution log to read, so reproducing the call is the check.
Common causes: API key expired, target endpoint changed, response format changed.

5. Is handover blocking the AI?

A completed handover switches the AI off for that one conversation: it stamps ai_disabled_at on the conversation row, and once set the AI does not reply there again. Confirm:

The conversation should appear in your team queue, not in the Alia tab (which lists AI-managed conversations).
If you expected the AI to keep replying, that’s a bug in the handover trigger configuration. Review Handover → Triggers and Delivery.

Less common causes

Routing rules in the orchestrator config point at a specialist that doesn’t exist. A rule saying “always route to Old Specialist” can’t actually break routing — the router is only offered the specialists currently in the stack, and removing one also deletes its routing rules — but a stale rule still wastes the model’s attention. Open the Orchestrator slide-out and audit your rules.
No specialist at all. A stack with zero specialists has nothing to route to. The Orchestrator canvas then shows the orchestrator node on its own, with no specialist cards hanging off it.
Channel disabled at the tenant level. Even if the stack is wired correctly, the channel may be disabled. Check the channel’s settings page.
The AI service failed on the turn. There is no health badge in the product for this. It usually shows up as a generic platform reply rather than silence — a message like “Sorry — I ran into a problem responding just now.” — so persistent, total silence points at one of the checks above instead.

When in doubt — use the Testing tab

If you can reproduce the silence in the Testing tab, the problem is in the stack (specialists, knowledge, capabilities). If the Testing tab works fine but production is silent, the problem is in the channel wiring or routing.