Build a workspace library
In workspace Tests, choose Create a test, select its type and save it. The All tests tab shows folders and test definitions, with each test’s type, creator and last update. Filter by Created by me, a specific creator, or Shared with me. Older tests may have no creator.
The workspace test library groups reusable tests into folders and offers search, creator and type filters, sorting and personal pins.
Add tests to an agent

An agent's Tests page lists its attached tests and shows monthly test credits in the header.
Choose a test type
Click a saved test’s name to open its full-page editor. The three test-type tabs sit above the settings on the left. The conversation preview stays on the right and changes with the selected type. On a narrow screen, the conversation follows the settings. A new test on an agent opens with the agent’s greeting in the preview. Use the preview’s + button to add a user or agent message. Each message has a role menu, an insert-below button and a delete button. Edit message text in place. For next-reply and tool-invocation tests, end the history with a user message. Choose Save to update a saved definition, or Save as new to create an independent copy of your edited setup. Past runs opens that test’s results and saved run configurations. Settings the three types share sit below the form, under Advanced settings: expected and forbidden tools, tool response overrides, the agent version, environments, and the starting workflow node.
Create a test: choose its type, configure the test and provide conversation history.
Simulation test
Fill in Describe simulated user scenario and Describe success criteria, then set Maximum conversation turns from 1 to 50. New tests start at five turns. Choose Add criterion when you need several conditions checked. Every criterion must pass, and the results show which ones did. The simulated customer sees its scenario and the conversation. It cannot see your agent’s instructions or the success criteria. A separate evaluator grades the completed dialogue and action evidence. Type@ in a success criterion, an additional criterion or an expected next
message to reference one of the agent’s procedures. The evaluator receives the procedure’s steps, so a criterion
can say the agent followed it without repeating them.
Conversation history is optional. If you provide it, the simulation continues
from that point. Otherwise it starts with the agent’s greeting.
Next reply test
Add user and agent messages to Conversation history, ending with the user message you want answered. Use Describe expected next message to state what the next reply must achieve.
A next-reply test pairs the expected behavior and example replies with editable conversation context.
Tool invocation test
Provide conversation history ending with a user message, then choose Add tool and pick what to check. The test looks at one new agent reply. It does not grade the wording of that reply against a success criterion.
Choose a tool, say whether it should be called, and set how each parameter is checked.

Type and Creator narrow the tool list.
Check a transition to another agent
A test in the workspace library has no agent of its own, so Select agent with workflow comes first and Target workflow node lists that agent’s nodes. When the test runs on that agent, this is an ordinary move. When it runs on a different agent, the conversation can only get there by a handoff: the test checks that an Agent transfer step handed over to that node. A transfer that names no node starts the other agent at its beginning. The run ends at the handoff, so a test can’t follow the conversation further into the other agent.Check actions and parameters
In a tool-invocation test, Expected extracted parameters has a row for each parameter the tool takes. Choose Anything, Exact, LLM, or Regex for a row and enter what you expect. Anything on a required parameter checks that the agent sent it. On an optional one it checks nothing. For simulation and next-reply tests, the checks are under Advanced settings. Leaving Expected tools empty skips action assertions. Selecting tools requires exactly that set, with no missing or extra actions. Order does not matter and repeated calls count once. Calls that return errors still count as invocations. Procedure control steps do not count as actions. Turn on Check arguments beside an expected action to validate its inputs. Choose a validation method and enter a JSON object:{"order_id":"123"} require that order ID,
while allowing other inputs. A Regex check of {"order_id":"^[0-9]+$"} accepts
a numeric order ID. An LLM check of {"reason":"The customer requests a refund because the item arrived damaged."} checks the meaning of the supplied reason.
All checked parameters must match in the same call of the expected action.
Turn on Validate each parameter separately to combine exact, regex, and
semantic checks within one tool call. Each parameter has its own name, method,
and expected value. Exact values can be text or JSON.
Earlier conversation history does not count as an action invocation. Regex
checks that exceed their execution limit fail. If the evaluator cannot grade
an LLM check, the run receives No verdict.
Set action responses
In a simulation test, turn on Mock all tools, or turn it off and use the + beside Choose tools to mock to pick some. For the other test types these controls are under Advanced settings. Tools that aren’t mocked use your connected accounts and can change data. System tools are never mocked: they only change the test’s own conversation, and keypad and voicemail tools refuse to run outside a real call. Under When no mock response matches, choose whether a mocked tool returns an error or runs the real tool. Configure lists every tool with the mocks saved on it, which answer that tool’s calls in every test. Choose Edit beside a tool to change its saved mocks without leaving the test. Under Advanced settings, use Set response beside an expected tool or Add tool response under Tool response overrides to define JSON responses for this test only. Return as error tests failure handling. Add several responses for the same action and set Match call arguments or Parameter conditions to choose between them. Conditions support exact, regex, and semantic checks. The first matching response wins. Reorder definitions through Edit as JSON when you need to change their priority. Older tests retain their original per-tool mock settings until you choose a global strategy.Variables and models
Under Dynamic variables to use in the test run (optional), choose Add new, enter a name and select Text, Number, Boolean, or JSON. Enter a value or toggle a boolean. Invalid numbers or JSON must be corrected before saving. These values replace placeholders such as{{customer_name}}. They apply to
the agent’s instructions, guardrails and greeting, the test scenario and history,
and criteria and examples. They also
supply values for tools that use dynamic variables. The test does not change
your saved agent settings.
Use unique variable names containing letters, numbers and underscores, starting
with a letter or underscore. Undefined placeholders stay unchanged. Variable
substitution does not rewrite JSON mock responses or expected argument JSON.
In Model configuration, choose the Simulated user model for simulations
and the Evaluator model for graded replies, LLM parameter checks, or semantic
mock conditions. The picker includes the current model catalog and the legacy
OpenAI models. The default is gpt-4.1-mini; the chosen provider must be
configured on the deployment.
Your agent still answers with the model selected in
Instructions. LLM parameter checks use the
evaluator model saved in the test configuration.
Use Edit as JSON to edit the complete test configuration. Changes are
validated when you save or return to the visual editor.
Target a channel, environment, or workflow
Choose Simulated channel below the variables, and the agent version under Advanced settings → Execution settings. The test uses that channel’s instructions, model, and available tools. The conversation remains a text simulation, including when the channel is Phone. Named environments supplies variable maps for staging or other environments. Select an environment, then override individual values in Dynamic variables. Variables also apply to shared HTTP and MCP endpoints and headers. Named environments can includeconnections mappings from a tool’s toolId to a
saved connection’s resourceId. The available saved connections appear below
the environment editor. Mappings use the saved endpoint and credentials, and
variables cannot change that connection’s origin.
Agent configuration overrides changes instructions, guardrails, greeting,
model, temperature, or language for this test without saving changes to the agent.
Under Workflow, choose a starting node or use the default entry point. Add
transition assertions to require the agent to move between specific nodes in
order. A source of Any node accepts a transition from any preceding node.
Start from a conversation
When the agent gets something wrong, turn that moment into a test so it can’t happen again unnoticed. Open a transcript in Conversations, hover over a message and choose Create test. Create test in the transcript’s menu does the same for the whole conversation.
A test made from a conversation starts from the customer's message, with the tools the agent ran in their place.
- its variables, with sensitive ones still masked
- its channel
- the workflow node the customer was on, as the starting node
- the tools the agent ran, each in its place in the history
Test a workflow node
Open Workflow, select a Subagent or Say node, and open its Tests tab. Add test lists the agent’s tests and the workspace library, with Create new test and Create folder at the bottom.
Tests attached to a node start from that node.
Run tests and read results
In an agent’s editor, click Save, or Save & run to start one run. New tests use Create and Create & run. The adjacent menu runs a test 3, 5, 15 or 50 times, and Custom repeat count takes any count from 1 to 50. Search by name or filter by Completed, In-progress and Never run. Select tests and choose Run selected to run each the same number of times. Already-running tests are skipped. Use Run all tests to start the agent’s whole suite. Attached tests lists the suite, while Past test runs analyzes its latest 500 saved batches.Read a run

A run's results group each test's repeats by cause. The selected conversation sits on the right, with the evaluator's reason above it.
Track issues

Issues lists what your team flagged on test results, grouped by where each one stands.
Analyze past test runs

Past test runs charts pass rates and lists each run, with its tests, repeats, result and credits.
Tests and evaluations
Tests check behavior before a release. Evaluations, in the agent sidebar, grade real customer conversations after they end. Use tests to catch a regression before you publish and evaluations to measure what happened with customers.Credits and limits
Every model request your agent makes consumes credits, including tool-loop requests. The simulated customer and evaluator do not use message credits. Test credits are shared across the workspace and reset at midnight UTC on the first of each month.Questions
Do test conversations reach my customers?
Test transcripts do not appear in Conversations or receive production traffic. New tests mock every tool. Choosing Use real tools, leaving tools outside a mock selection, or enabling real-tool fallback can run actions against connected accounts and change data.Which version of my agent does a test run against?
Choose the current draft, published version, a branch or a saved version in Execution settings. Each run keeps the selected configuration and tools while it runs.Why did a test fail when the evaluator passed it?
An action, parameter or workflow assertion can fail independently of the evaluated outcome. Open the run to inspect its reason, Never called, Not expected, and workflow evidence.What does No verdict mean?
An error prevented grading, such as a timeout or an unavailable AI provider. A conversation that stops during grading gets one automatic retry first. No-verdict repeats do not count toward the pass rate, so run the test again.What happens when my test credits run out?
You see the remaining credits and an estimate before the run. Run anyway allows message-credit fallback. Without that permission, a repeat stops when its test credits run out. With it, a repeat stops when both balances run out.Can I close the page while tests run?
Yes. Up to five repeats run at a time across the workspace, and the rest queue and continue after you close the page.Can Mastermind write tests for me?
Yes. Mastermind can propose test edits and runs. Each run still needs your approval. See Mastermind.Run tests from CI or code
Workspace API keys can create and update tests, attach them to agents, start runs, read grouped results, and cancel work through/api/v2/tests and
/api/v2/agents/{agentId}/test-runs. A run returns a suiteId; read every test
in it from /api/v2/agents/{agentId}/test-suites/{suiteId}, or cancel them
together. Use a write-enabled key for mutations. Run creation supports
Idempotency-Key, and message-credit fallback requires explicit opt-in.
The repository includes scripts/agent-testing-client.mjs for JavaScript and
scripts/agent-testing-cli.mjs for CI. The CLI waits for results, saves a JSON
report, and exits unsuccessfully when a run fails or has no verdict.