Testing an Agent

The editor test uses the same agent and runtime as real conversations. It helps validate a configuration before you share it, but it is not an isolated simulation: messages consume credits, conversations are saved, and tools may perform real actions in connected services.

Before you start

Confirm three conditions:

1. The agent is Active. When it is inactive, Test Agent is disabled and tells you to activate it under Advanced Settings.
2. The changes you want to evaluate have been saved. The panel always runs the saved version. If changes are pending, it displays a warning and the Save and test action.
3. The data and services used in the test are safe. Prefer disposable records and no-impact requests. Do not test deletions, payments, sends, publishing, or other irreversible actions without a controlled environment in the destination system.

Review System Prompts, Models, Tools and Skills, and Advanced Settings before interpreting an unexpected result.

Open the test panel

In the agent editor, select Test Agent at the top. On larger screens, the test opens beside the form; on smaller screens, it opens as a panel over the page. The editor stays on the same agent.

The first send creates a persistent conversation. Closing the panel does not delete it.

In the agents list, the Chat action is a different flow: it opens a new session in the full Hub and depends on Hub access permission. Use the editor panel to iterate on configuration; use the Hub to verify the complete conversation and navigation experience.

Caution

An inactive agent does not accept messages. The list’s Chat action may currently remain available and open the Hub, however, and sending then fails. Treat Active status as a requirement in this flow as well.

Test conversations and history

The Test conversations button shows up to 20 recent conversations for that agent. Select one to resume its context.

New conversation clears the panel and starts a draft without deleting previous conversations. The new record is created only when you send the first message. The complete history remains available in the Hub.

Use a new conversation when you need to prove that a response does not depend on earlier context. Resume an existing conversation when testing memory, continuity, data correction, or a sequence of steps.

Minimum test matrix

Record the input, expected result, and actual result. Cover at least:

Scenario	What to verify
Simple request within scope	correct, direct response in the configured tone
Complex request within scope	problem decomposition and no invented facts
Request outside scope	clear boundary without pretending to have a capability
Insufficient information	clarification before assuming data
Linked knowledge	correct content retrieval and admission when the base has no answer
Tool required	tool choice, arguments, result, and failure handling
Tool not required	response without an external action
Allowed attachment	image, file, or audio processed according to multimodal settings
Guardrail	block or safe guidance for prohibited content
Transfer	destination and context preserved when the agent can transfer
Continuity	coherent behavior when resuming the same conversation

Also test ambiguous input, invalid data, an unavailable service, and a frustrated user. A convincing answer is not enough: confirm that the agent performed the correct action and did not hide an error.

Inspect tools and usage

When internal steps exist, the message displays a summary of the path taken. Open Show the path and then Show details to inspect each step. A completed tool includes its name, status, Input data, Result, and, when recorded, execution time. Guardrail and attachment-processing steps may appear too.

In the agent message’s actions menu, details may include the agent, requested and effective model, provider, tokens, cost, sent time, and tool names. Credits appear only when the organization allows that display and the user has the required access level.

The Executions page is not the detailed log for these messages: it retains legacy scheduling and follow-up flows. Audit the test through the steps and details on the message itself.

Danger

The test label does not create a sandbox, automatic confirmation, or simulation mode. A connected tool receives the real call. If an action can change data, validate it in a test service first or temporarily disable the tool and check only prompt behavior.

Correct and repeat

Change one variable at a time — prompt, model, knowledge, tool, or advanced setting —, save, and repeat the exact same case in a new conversation. This lets you attribute the result change to the correct configuration.

Before releasing the agent:

• repeat critical cases after the final save;
• confirm that no data from another organization, department, or conversation appeared;
• inspect failures and external effects, not only the final text;
• record passing and failing examples for regression testing;
• run at least one complete journey in the Hub with the real audience’s permissions.