Test your AI agent
Nexus gives you two complementary places to test:
- Playground - interactive, single-conversation testing on every agent's profile. Best while you build. Documented on this page.
- AI Trust Centre - saved tests you run again after every change, so you know an agent still works. Best once an agent has taken shape.
Use both - they answer different questions.
Playground - try the bot as a user would
Inside any agent's profile, click the play (▶) icon in the title bar to open the Playground - a side panel on the left where you chat with the bot exactly as a customer would. This is your fastest feedback loop while building.
The Playground gives you:
- The bot's actual welcome message and quick-reply chips.
- A live chat input - type a message, hit Enter, watch the agent respond in real time.
- Per-message action icons (copy, voice playback, 👍 / 👎) for quick feedback.
- A voice/mic toggle for testing voice flows without leaving the page.
Don't confuse the Playground with the Nexus AI. The right-hand "How can I help you today?" panel on an agent's profile is the Nexus AI - an AI assistant for you, the builder. Use it to ask questions about the bot's configuration, generate suggestions, or scaffold logic. The Playground is for acting as the end-user and seeing how your bot actually replies.
Step-by-step: try the bot
- Open any agent from AI Agent → Agents.
- Click the play (▶) icon in the title bar - the Playground opens on the left.
- Use one of the welcome quick-reply chips, or type a message and press Enter.
- Watch the agent respond. If voice is enabled for the bot, tap the speaker icon on a bot message to hear the TTS playback.
- Use 👍 / 👎 on individual messages to flag responses that looked good or bad - useful when you come back later to figure out what to fix.
Step-by-step: verify a routing rule fires
- Open the agent whose routing you want to test.
- Send a message that should match the rule (e.g. "I need a refund").
- Confirm the expected agent or tool takes over - the persona / response pattern should match.
- If the wrong thing fires, go back to Routing Logic and tighten the rule, or sharpen the agent's Trigger.
Step-by-step: verify a widget renders
- Make sure your bot has Nexus agents enabled - widgets only render in Nexus conversations.
- In the Playground, send a message that triggers a workflow node hosting your widget.
- The widget renders inline in the Playground chat. Interact with it (fill the form, click the button); the output flows back into the conversation as the next user input.
Mock APIs
Mock APIs let you rehearse a conversation in the Playground without calling your live backends. When mock mode is on, matching API calls return a saved response you defined instead of hitting the real service - so you can test happy paths, edge cases, and error handling deterministically, before anything is wired to production.
Turn on mock mode
Mock mode is a toggle you flip while testing:
- Playground - the Use Mock APIs control in the playground toolbar. When it's on, a banner reads "Mock mode ON — API calls return saved mock responses."
- Testing Lab - save mock responses under Mocks, then turn on Enable Mocks when you start a run. Do this when a system the agent calls is down, so the run tests the agent rather than that system.
With the toggle off, every API call runs live as normal.
Author a mock
Mocks are created and managed in the Mocks view. A mock has two parts - the match rules that decide when it applies, and the response it returns.
Match rules
| Field | What it does |
|---|---|
| Name | A label for the mock, so you can find it in the list. |
| Entity type | What the mock targets - a tool, a flow, or an api. |
| Priority | When more than one enabled mock matches, the highest-priority one wins. |
| Match conditions | One or more field/operator/value tests. All must pass (AND). Operators: equals, not-equals, in, not-in, exists, regex, and the numeric >, <, >=, <=. |
Response
- A canned response body (JSON) returned to the caller in the same shape a live call would produce, so the agent's transforms and branching behave exactly as in production.
- An optional latency to simulate a slow call.
What gets mocked
Mock mode covers APIs wherever they run in a turn:
- Direct API tools the agent calls, and
- APIs called inside a flow or skill - for example an API node in a guided flow, or an API a workflow invokes.
So a mock you author is honoured whether the API is called straight by the agent or several steps deep inside a workflow - you can rehearse an end-to-end journey, including the business logic behind it, without touching live systems.
When no mock matches
With mock mode on, only the entities you've actually mocked are intercepted - everything else passes through, so an un-mocked call never breaks the run:
- A mock exists for this entity and its conditions match → that mock's response is returned. When several could match, the highest-priority one wins.
- A mock exists for this entity but nothing matches its conditions → the call falls back to the mock you marked as default, or - if none is marked - the first (highest-priority) mock for that entity. A mocked entity is always served from a mock, never a live call.
- No mock is defined for this entity at all → the call runs live against the real API. Only the entities you explicitly mocked are intercepted, so an un-mocked call passes through instead of failing the run.
- Mock mode off → every call runs live.
AI Trust Centre - durable evaluation
The AI Trust Centre is where you keep the tests that prove an agent works, and run them again after every change. The Playground tells you a conversation worked once; a saved test tells you it still works after your next edit. You start each run yourself.
Start with Get started: what to test, how to read a run, and how to keep your tests worth trusting. Then open the page for what you're doing:
| Page | Open it when |
|---|---|
| Get started | You're building a test suite for an agent. |
| Testing Lab | You want to create tests, group them into datasets, and run them. |
| Evaluators & Rules | You want to change how replies are scored. |
| Test Case | You want to see one test's conversation and what the agent did at each turn. |
| Reports | You want to know what happened in a run. |
| Execution traces | You want to see what the agent did on a turn - the tools it called, the values it saved, who it handed over to. |
| Debugging | A test is failing and you want to find out why. |
| Test signals on the agent page | You're editing an agent and want to know whether its tests still pass. |
Common testing pitfalls
- Testing only the golden path. The hard cases are where bugs hide. Schedule time for adversarial testing - jailbreaks, off-topic, hostile users.
- Forgetting to test after rules change. Even a small wording tweak in identity, conversation rules, or routing logic can shift behaviour.
- Trusting "it worked once." LLMs are stochastic. Run the same test twice - if a behaviour is fragile, it'll fail intermittently. In the Testing Lab, Iterations runs a test several times in one go.
- Not saving test cases. A test you ran manually once is one you'll have to re-run manually next time. Save it as a test in the Testing Lab.
Best practices
- Test in the Playground first, then save the conversations that matter as tests in the Testing Lab.
- Set your evaluators up once and let them score every run - but still read a few passing conversations now and then. A pass means the test was satisfied, not that the agent did everything right.
- Keep your tests up to date. Fix tests that no longer match what the agent should do, and remove ones that check nothing. See Keep your tests trustworthy.
- Test voice and chat separately - they don't behave identically, even with the same agent config.
Go to Widget Builder if you need custom UI in your conversations.