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 any list of runs — the AI Employee's run history, the chat or dashboard surface, or a result row in an evaluation (each eval result links back to the workflow run that produced it via its workflow_run_id).

The run detail page has two tabs:

• Details — the run summary, input, output, and the full step trace. This is the debug log.
• Activity — the audit activity for the run.

At the top, a summary shows the run's duration, total tokens, trigger (how the run was started), workflow version, and started / completed timestamps. The run's status (pending, running, paused, completed, failed, or cancelled) is shown next to the title. An 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 returned when the run completed, 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).
• The node type (for example agent).
• For agent nodes, the agent-type version that was pinned and executed — so you can reconstruct exactly which configuration ran, even months later.
• Duration and, when the step used an LLM, the token count.

Step status uses these values:

Expanding a step

Open any step to see its full detail:

• Token breakdown — prompt, completion, and total tokens for the step.
• 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 and provider used, the input messages, the output content, and any tool calls and their results. Tool-call IDs are resolved to human-readable Tool names.
• 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:

GET /runs/{run_id}/steps returns the steps in execution order. Each step carries its node_id, node_label, node_type, status, started_at / completed_at, token counts, input, output, error, the llm_trace, and action_executions (the Tool calls). See the API reference for the full schema.

What's next

• Testing AI Employees — produce runs to inspect.
• Evaluating AI Employees — each eval result links to the run that produced it.
• Launching and monitoring — when a production metric moves, the debug log is where you find out why.