Test an Agent Stack

The Testing tab is a sandbox that lets you chat with your Agent Stack exactly as a customer would, without affecting any real conversations. Use it before going live, after every meaningful change, and any time a customer reports a confusing reply.

Before you start

• The stack must exist with at least one specialist.
• (Optional) If your stack uses identity-gated capabilities (the Verified customer or Signed-in customer proof levels — level 1 is retired and no longer offered), decide whether you want to simulate a test user for scoped full-access gated tools or test a real customer sign-in connection. Real live conversations and OTP/OAuth sign-in flows are unchanged.

Steps

Test the whole stack

1. Open Settings → Agent Stacks → [stack] → Testing.
2. The default mode is Full Stack — meaning the router decides which specialist replies, just like in production.
3. Type a customer-style message in the input at the bottom. Hit Enter or click Send.
4. The reply appears with the routing decision — which specialist took it, plus model, tokens, and latency (if you’re a Super Admin).
5. Continue the conversation as the customer would.
6. Click New Test to clear the transcript and start over. That also resets the simulated login, so any gated capability goes back to needing proof.

Test a single specialist in isolation

1. Switch the mode control from Full Stack to Individual Agent.
2. A specialist picker appears (Select an agent…). Pick the one you want to test.
3. Type a message. The router is bypassed — every message goes directly to the chosen specialist.

This is the right way to verify a specialist’s instructions, capabilities, and knowledge without the router interfering.

Test identity verification

If your stack has capabilities that require the Verified customer or Signed-in customer proof level, the Testing tab supports two testing paths.

Simulate a login

Use simulation as a shortcut when you want to test gated capabilities in the Testing tab without completing a real sign-in flow.

1. In the banner that reads Testing as anonymous visitor, type an id into the User ID field.
2. Click Simulate login. The button stays disabled until the field has a value — a level alone elevates nothing.
3. The tab writes a synthetic Identity verified (simulated) line into the transcript. That line is a notice from the tab and is never sent to the model as history.
4. Continue the conversation. The simulated login elevates the test session to Signed-in customer, and the id you typed is the user_id claim used for claim-variable scoping.
5. Capabilities that need more proof than the session has, or a scope the test user does not satisfy, are still denied.

Sign in with a real connection

Use real connection sign-in when you want to test the same customer sign-in flow that production conversations use.

1. Ask for something that requires identity verification through a configured customer-sign-in connection.
2. When the reply asks for identity, the Testing tab shows a sign-in card.
3. Click Sign in.
4. Complete the hosted login.
5. Return to the Testing tab and click I have signed in.
6. Retry the request.

Persistence across visits

Your test session — mode, messages, selected specialist, proof level — persists in the browser and is restored when you reopen the tab, and it follows you into the full-screen view. Click New Test to clear it; that resets the simulated login and the conversation id as well as the transcript.

Verify it worked

• The conversation flows naturally and the router picks the specialist you’d expect.
• Replies match the personality you configured.
• Capabilities that should be available execute. Ones that shouldn’t (not enough proof, missing scope) are denied with a clear message. Testing a voice stack is different — its Testing tab has no chat, no simulated login and no full-screen view, and only level-0 capabilities exist on a call at all.
• Knowledge citations point to real KB articles in the categories you granted.

Flag bad replies

When a reply isn’t right — wrong specialist, missed information, awkward tone — click the flag icon on that message. The flagged message moves into the Tuning panel on the right, where you can give feedback and review proposed fixes. See Flag and tune bad responses.

Troubleshooting

• Symptom: The router routes to the wrong specialist on test messages. Fix: see Define routing topics. The Testing tab uses the same router as production, so a mis-route here is a real mis-route.
• Symptom: Replies in test feel fine but production replies feel off. Fix: the test sandbox can use simulated identity or a real customer sign-in connection. Real conversations may still have different identity-gated capabilities available, plus real KB content the AI is retrieving in real time. Run a few production conversations through the Monitor module to compare.
• Symptom: A capability that works in test fails in production. Fix: confirm the capability’s security level and scope aren’t blocking it in production for unauthenticated callers. The test sandbox lets you simulate a login with a test user ID, which writes a real elevated session against a synthetic test_-prefixed conversation; production won’t elevate without a real verification flow.

See also

• Flag and tune bad responses
• What are Agent Stacks?
• Define routing topics