Debug Logs

The Debug Logs feature provides comprehensive visibility into AI Employee workflow execution. It addresses the critical need for debuggability and explainability by offering deep, structured insights into every workflow run -- including agent configurations, input/output values with their sources, detailed work logs with LLM prompts and responses, and clear error/warning indicators.

Debug Logs are accessible directly from the workflow canvas. This feature allows builders to independently debug failures, test improvements iteratively, and inspect any user's workflow execution without contaminating production metrics or requiring reproduction steps.

Accessing Debug Logs

Chat AI Employees

1. Save the persona and start using the AI Employee.
2. In the conversations window, each message has a Show Work button.
3. Click Show Work to open a modal with an action execution summary for each action in the workflow (in the order it was run). Under every action, you can see the summary of each step during that action's lifecycle.

Dashboard AI Employees

1. In the Dashboard view, a separate column displays the Show Work button for every row, regardless of workflow run status.
2. Click the button to view the detailed graph view, same as in chat.

Deep Logs Viewer

Admins see an additional button to view detailed logs (deep logs). This opens the canvas showing a graph view of the workflow in read-only mode. Non-admins do not see this button.

Node Status Colors

The outline color of each node indicates the run state for that action:

Node Status Icons

The icon on the right side of each node (next to the expand button) follows this mapping:

Inspecting Action Details

Clicking on any node in the canvas opens a drawer on the right side with four tabs: Configuration, Inputs, Work Log, and Outputs.

Inputs

Displays all inputs the agent received at runtime. For each input, you can see:

• Input name -- The identifier.
• Input type -- The data type.
• Input value -- The actual value. JSON data is automatically formatted with expand/collapse and copy options.
• Input source -- Where the input came from.

Each input dropdown includes an expand option to view the full JSON payload in a modal.

Configurations

The configuration section mirrors the right-hand-side drawer in builder mode. It shows the exact configurations the agent was wired up with, in read-only mode. All widgets used in the configuration are displayed.

Configurations are snapshotted at runtime when the workflow engine receives the workflow definition and the persona config.

Work Logs

Work logs contain messages generated by the action implementation at runtime. Key details:

• Step-wise logging: All messages are logged under a specific step, even if a step has only a single message.
• Regular messages: Logged directly by the action implementation. JSON data is automatically formatted.
• LLM calls: Populated at the LLM caller level each time the action makes an LLM call. Each LLM call has three parts:
  • System prompt -- Viewable by Ema internal users only.
  • User prompt -- Viewable by all admins. For some LLM calls, these are the instructions provided in the agent configuration tab.
  • Response -- Viewable by all admins.

Step Status Indicators

Each step tile in the work logs section shows a status icon:

• Green check circle -- Step succeeded.
• Red cross circle -- Step failed.
• Yellow warning circle -- Step had a warning.

Errors and warnings are also displayed at the top as clickable tiles that scroll to the relevant step when clicked.

Outputs

Displays all data produced by the agent during execution. For each output:

• Output name -- The identifier.
• Output type -- The data type (e.g., Text, Text with Sources, List).
• Output value -- The actual data produced, formatted based on type.
• Published status -- Whether this output was published as the final chat response. Published outputs display a green "Published as primary category" badge.

Complex Output Values

For outputs containing complex data structures or JSON, the built-in JSON viewer automatically formats the data. Each output dropdown includes a "View Full Data" option that opens an expanded modal.

Array Outputs

• Named array items -- If the array contains objects with name properties, each item is expanded into its own output entry.
• Regular arrays -- Displayed as "Array with X items" in the summary, with individual items accessible via the expandable view.
• Complex object arrays -- Each item can be expanded to view the full JSON structure.

Empty State

If an agent did not produce any outputs (e.g., it failed early or was configured without outputs), the Outputs tab displays: "No output data available for this execution."

Per-Agent Latency Metrics

The debug view surfaces per-agent latency data to help builders identify performance bottlenecks. Each action node in the Show Work and Deep Logs views displays the total LLM latency accumulated during that action's execution.

Where Latency Appears

Latency is displayed in two locations within the debug interface:

• Action summary cards -- Each action card in the Show Work modal includes a latency badge showing the total time spent on LLM calls, formatted in seconds (for example, "1.24 seconds").
• Work Logs detail view -- Within the Work Logs tab for a specific action, each individual LLM call entry includes its own latency measurement alongside cost and success/failure indicators.

How Latency Is Calculated

The latency value represents the total wall-clock time spent waiting for LLM responses within a single action. The per-call latency is read directly from LLM response metrics (already in seconds). The llm_latency_ms field is displayed separately in milliseconds in the Work Log tab

Using Latency Data

• Identify slow actions -- Compare latency across actions in a workflow run to find which agents contribute the most to overall response time.
• Evaluate model choices -- If EmaFusion™ is enabled, compare latency between runs to assess the performance impact of different model selections.
• Optimize workflows -- Actions with consistently high latency may benefit from prompt simplification, reduced context sizes, or model downgrades where quality permits.
• Set baselines -- Track latency across workflow versions to detect regressions after configuration changes.