Debug Logs

Debug logs give you a complete, structured record of what an AI Employee (AIE) did on a single run — every node that executed, in order, with its status, inputs, outputs, the LLM prompts and responses behind it, the Tools it called, and any errors. When a response is wrong or a run fails, the debug logs tell you exactly where and why, without re-running or guessing.

Every run records this trace automatically. You reach it from the run detail page, and the same data is available over the API.

Opening a run's debug logs

Each run has a detail page that opens from the AI Employee's run history, or from the chat or dashboard surface.

The run detail page is a single page holding the run summary, input, Tool calls, output, and the full step trace — this is the debug log. (Audit events for the AI Employee live on the AIE's Activity tab, not on the run page; see Auditing.)

At the top, a summary shows the run's duration, total tokens, workflow version, and started / completed timestamps. The run's status (pending, running, paused, completed, failed, or cancelled — plus skipped for scheduled fires the scheduler skipped) is shown next to the title. An admin (system_admin, env_admin, or builder_admin) can abort a pending, running, or paused run from here.

What the page shows

Input and output

• Input — the parameters the run was started with, rendered as expandable JSON with a copy button. Empty when the run took no input parameters.
• Output — the result the run published when it completed (its publish-node outputs), also expandable JSON with copy. Empty until the run finishes.

Tool calls

Durable, asynchronous Tool calls attached to the run are listed in their own card, and stream live while the run is still in progress.

Step trace

The heart of the debug log is the step trace — the ordered list of every node the run executed. Each step is a collapsible row showing, at a glance:

• The step number and the node's status.
• The node label (and its underlying node ID).
• Duration (see the note below for waiting steps).

Beyond what the row shows, each step's API payload also records the agent configuration and the pinned agent-type version (base_type_version) it executed with — so you can reconstruct exactly which configuration ran, even months later.

Step status uses these values:

Expanding a step

Open any step to see its full detail:

• Error — a structured error display when the step failed.
• Input — what the agent received at runtime, as readable text when there's a clear summary field (like a query or message) or as expandable JSON otherwise.
• Output — what the agent produced. Rule-validation outputs render as a structured validation report; other outputs render as text or expandable JSON.
• LLM trace — for steps that called an LLM, the per-iteration trace: the model used, the input messages, the output content, and any tool calls and their results, with a prompt / completion / total token breakdown per iteration. Tool-call IDs are resolved to human-readable Tool names. (The step's total is also available as tokens_used on the API.)
• Code-agent execution trace — for code-executing agents, the execution trace.
• Integration call trace — the list of integration (Tool) executions the step made.
• Routing decisions — the per-edge condition evaluation that determined which branch the run took out of this node.

This is how you answer concrete debugging questions: Which branch did the run take? (the routing decisions and which steps are Skipped). Why did the agent answer this way? (the LLM trace — the exact prompt and response). Did the Tool get the right arguments? (the integration call trace). Where did it break? (the failed step's structured error).

Reading the trace over the API

The same data backs the UI and is available programmatically; the workflow service's routes are exposed under the /api/v1/workflow prefix.

GET /runs/{run_id}/steps returns the steps in execution order. Each step carries its node_id, node_label, status, started_at / completed_at, tokens_used, input, output, error, the llm_trace, action_executions (the Tool calls), and edge_evaluations (the routing decisions), plus the pinned base_type_version for agent steps. See the API reference for the full schema.

What's next

• Testing AI Employees — produce runs to inspect.
• Launching and monitoring — when a production metric moves, the debug log is where you find out why.