1. Ema v2 Docs
  2. Testing Operations
  3. Testing AI Employees

Testing AI Employees

Testing an AI Employee (AIE) means running its workflow with real or representative inputs and checking what it produced. You do this throughout the build, not just at the end — run a partial workflow to confirm one branch works, run the whole thing to confirm an end-to-end response, and run it in test mode when you don't want to touch live integrations or production metrics.

An AI Employee is a workflow: a directed graph of typed agent nodes. Running the AIE triggers a workflow run, which executes the nodes in order and records a full trace you can inspect afterward in debug logs. This page covers single, interactive runs. To measure quality across many inputs at once, use evaluation.

Ways to run an AI Employee

How you run an AIE depends on its interaction type:

  • Chat AI Employees run as a conversation. You open a chat session and send messages; each message triggers a workflow run scoped to that session.
  • Non-chat AI Employees (for example document- or form-triggered) run from an input form. You fill in the workflow's input parameters and submit; that triggers a single run.

Both are available from the AI Employee builder — open the AIE, then choose to run it. You stay inside the builder, so you can edit a node and re-run without leaving the page.

Run a chat AI Employee

  1. Open the AI Employee and start a run. If the workflow declares required inputs, an inputs gate appears first — fill those in to start the session; otherwise a session opens directly.
  2. Type a message and send it. The response streams back in real time.
  3. Use the session list to switch between conversations, start a new chat, or rename and delete sessions. Each session keeps its own history, so you can test follow-up handling (does the AIE retain context across turns?) and context isolation (does an unrelated follow-up leak the previous topic?).

Run a non-chat AI Employee

  1. Open the AI Employee and start a run.
  2. The run form shows the workflow's input parameters, derived from the workflow's input schema. Fill them in.
  3. Submit to trigger one run. When it completes, the result and full step trace are available.

Test mode (dry run)

Test mode lets you exercise a workflow end to end without making real external calls. When test mode is on, Tools that would call an external system instead return mocked responses generated from each Tool's output schema. The UI shows a banner on the conversation while test mode is active:

Test Mode — no real API calls were made. Integration responses are mocked from output schemas.

Use test mode to:

  • Validate workflow logic, branching, and agent wiring before any integration is connected or before you want to spend real API quota.
  • Avoid creating real records in downstream systems (no real tickets, emails, or writes).
  • Keep these runs out of production analytics — a test-mode run is recorded as a dry run and is not counted in the production chat metrics described in Chat metrics.

Toggle Test Mode on the chat composer (or open the run with test mode pre-enabled from the builder). For chat AI Employees, test mode is sent as a per-message flag, so you can switch it on or off between turns in the same session.

When mocks aren't enough. Test mode mocks Tool responses from their output schemas, so it confirms shape, not real data. To validate against real systems safely, point your Tools at sandbox or non-production instances of the connected app and run with test mode off. Switch to production instances only at launch — see Launching and monitoring.

Under the hood: runs and the API

Interactive runs go through the workflow service. The same endpoints are available in the API reference if you want to drive runs programmatically.

ActionEndpointNotes
Start a runPOST /workflows/{id}/runBody is StartRunRequest (input_params, optional session_id). Returns the run asynchronously.
Start a dry runPOST /workflows/{id}/dry-runSame request shape; the run is marked as a dry run (is_dry_run: true).
List runs for a workflowGET /workflows/{id}/runsFilter by trigger_type (ui, api, schedule, webhook, feedback, document), status, and since.
Get a runGET /runs/{run_id}Full detail including token usage and is_dry_run.
Get a run's step traceGET /runs/{run_id}/stepsThe ordered list of steps — what debug logs renders.
Cancel a runPOST /runs/{id}/cancelAborts a pending, running, or paused run and cancels its pending HITL requests. Admin only. Returns 409 if the run is already terminal.

A run moves through these statuses: pending, running, paused (waiting on a human-in-the-loop request), completed, failed, or cancelled.

POST /workflows/8f3c.../run
{
  "input_params": {
    "query": "What's our PTO carryover policy in California?"
  }
}

Canceling a stuck run

If a run is taking too long or is paused on a human-in-the-loop step you no longer want to answer, an admin can cancel it. Cancellation transitions every pending HITL request on the run to cancelled in one step and marks the run cancelled. Runs that have already finished (completed, failed, cancelled) cannot be canceled and return a conflict.

What to test

A practical checklist before you consider an AIE ready to evaluate or launch:

  • Happy path. The most common inputs produce correct, complete responses.
  • Branching. Each branch of the workflow is reachable and selects correctly. Use the step trace to confirm which branch ran.
  • Follow-ups (chat). The AIE retains relevant context and does not leak unrelated context across turns.
  • Out-of-scope inputs. The AIE handles inputs it should decline or redirect, rather than hallucinating an answer.
  • Human-in-the-loop. Steps that pause for approval, a form, or a question behave correctly and resume after a response. To test these at scale automatically, use the LLM simulator in evaluation.
  • Tools. With test mode off and sandbox integrations connected, Tools call the right systems with the right arguments.

What's next

Last updated: Jul 3, 2026