Execution Details

Deep dive into execution timelines, prompts, and AI-powered troubleshooting.

Overview

The Execution Details page provides a complete picture of what happened during a single agent execution. Use it to understand agent behavior, debug issues, and optimize performance.

Accessing Execution Details

1. Go to Governance > Activity History > Agent Executions
2. Click on any execution row
3. The details page opens

Execution Header

The header shows key metrics at a glance:

Status Badge

• Success (green) - Completed without errors
• Failed (red) - Encountered an error
• In Progress (yellow) - Still running
• Cancelled (gray) - Was stopped
• Resume Pending (purple timer) - Queued for automatic retry after a transient failure

Pre-Execution Classifier Card

The header includes a Pre-Execution Classifier summary card showing routing class, confidence, latency, cost, model, and work-type override. When the classifier did not finish within its time limit, a Timed out warning badge appears next to the Applied/Shadow badge. A timed-out classifier still applies a decision (the last partial result or a fallback), so the run proceeds - but you should review the full classifier decision card on the timeline to confirm the routing was correct.

Metrics Bar

Metric	Description
Duration	Total execution time
Input Tokens	Tokens in the prompt
Output Tokens	Tokens in the response
Total Tokens	Sum of input + output
Cost	Calculated cost

Email Input Section

Shows the original email that triggered the execution:

Email Headers

• From - Sender email and name
• To - Recipient (the monitored mailbox)
• Subject - Email subject line
• Date - When the email was received

Email Body

The full email content, including:

• Plain text or HTML rendering
• Thread history (if included)
• Attachments list (if any)

VIP Status

If the sender is a VIP:

• VIP badge displayed
• Privilege level shown
• Notes visible

Execution Timeline

The timeline shows the sequence of events:

1. Execution Started

When processing began.

2. Pre-Execution Classifier Decision

Before the agent begins reasoning, the pre-execution classifier evaluates the incoming request and determines routing, tool access, and prompt configuration. The timeline shows a full Classifier Decision card for this step.

Header row:

• Routing-class chip (e.g. standard, trivial, complex)
• Confidence percentage
• Applied or Shadow badge - Shadow means the decision was computed but not enforced
• Timed out warning badge when the classifier did not complete within its deadline

Decision reason: A natural-language explanation of why the classifier chose this routing class, citing the specific business rules that applied (e.g. "intent.kind=post_social triggers standard minimum").

Overrides row (shown when present):

• Work-type override: the default work type and what it was changed to
• Profile override: if a non-default agent profile was applied
• CCS variant: which prompt-compression variant was selected, with a coercion note if the value was adjusted by a feature flag

Tool groups: Chips listing the tool-group allow-list that was applied. Only tools belonging to these groups were available to the agent during dispatch.

Collapsed details - Prompt sections: A chip grid showing all 11 prompt sections with color coding: green chips were included in the prompt; gray chips were excluded. A count summary (e.g. "7 of 11 included") appears above the grid.

Collapsed details - Input envelope: The sanitized classifier input, displayed as labeled rows:

• Trigger: type, channel, and whether it is flagged high-stakes
• Sender: masked email address, classification, and whether the agent has prior contact with the sender
• Agent defaults: the configured work type and profile (provides the baseline for the override delta above)
• Tenant tier
• Intent: kind and confidence score
• Content excerpt (first 1,000 characters, in a quote block)

A View raw envelope toggle reveals the original text. Use this if the parsed fields look unexpected.

Collapsed details - Diagnostics:

• Input and output token counts for the classifier call
• Feature-flag snapshot: active percentage, circuit-breaker state, shadow mode, CCS-variants enabled
• Raw output: shown with warning styling when the classifier output failed to parse and a fallback decision was applied; omitted otherwise

Tip: If an execution used unexpected tools or a higher-than-expected model, check the classifier decision card first. The routing class and tool-group chips directly explain what was allowed and why.

3. Agent Reasoning

The agent's "thinking" process:

• How it interpreted the email
• What it decided to do
• Why it chose specific actions

What to look for:

• Is the interpretation correct?
• Are decisions logical?
• Does reasoning match instructions?

3. Tool Calls

Each tool invocation appears as a step:

For each tool call:

• Tool name
• Parameters passed
• Result returned
• Duration

Example tool call:

search_knowledge_base
Parameters: { query: "return policy", limit: 3 }
Result: [3 documents found]
Duration: 1.2s

4. Response Generated

The final output:

• For replies: email content generated
• For escalations: escalation details
• For failures: error message

5. Execution Completed

Final status and total duration.

Steps Tab

The Steps tab shows all timeline events as a compact table, one row per step. For the classifier decision step, the detail column shows an enriched one-liner instead of the raw log message: routing class, confidence percentage, applied/shadow status, a timed-out flag when applicable, and the work-type delta (e.g. chat → composition). This gives a quick-scan summary without opening the full timeline card.

Request Details

Full Prompt

View the complete prompt sent to the LLM:

Includes:

• System prompt (agent instructions)
• Email content
• Thread history
• VIP status
• Tool descriptions

Why review this:

• Verify all context is included
• Check prompt size (affects cost)
• Debug unexpected behavior

Available Tools Panel

The LLM Request preview includes an Available Tools section showing all tools provided to the agent for that request.

Viewing tool details:

• Click on any tool name (green badge) to open the Tool Schema modal
• The modal displays:
  • Tool name - The function name the LLM can call
  • Description - What the tool does
  • Parameters - A table showing all parameters with:
    • Name (in green monospace font)
    • Type (string, number, boolean, etc.)
    • Required/Optional indicator
    • Description of the parameter

Why review tools:

• Verify the right tools are available
• Check parameter definitions
• Understand what capabilities the agent has
• Debug tool usage issues

Messages Array

The message sequence:

• System message (instructions)
• User message (email + context)
• Assistant messages (responses)
• Tool messages (results)

Response Details

Raw Response

The exact output from the LLM:

• Complete text generated
• Tool call requests
• Any errors or issues

Parsed Output

Structured view of what the agent did:

• Tool calls made
• Parameters used
• Final response text

AI Troubleshooting

Using Troubleshoot with AI

For problematic executions:

1. Click Troubleshoot with AI
2. Wait for analysis
3. Review findings:
   • Root cause identification
   • Suggested fixes
   • Related issues

What AI Analysis Provides

For Failed Executions:

• Why the failure occurred
• What could have prevented it
• Recommendations for fixing

For Poor Quality Responses:

• What went wrong
• Instruction improvements
• Tool usage suggestions

For High-Cost Executions:

• What drove up costs
• Optimization opportunities
• Model alternatives

Understanding Tool Results

Successful Tool Calls

Shows:

• Parameters sent
• Result returned
• How agent used the result

Failed Tool Calls

Shows:

• Error message
• What went wrong
• Impact on execution

Tool Call Patterns

Efficient pattern:

1. Search knowledge base → Found answer
2. Reply with answer

Inefficient pattern:

1. Search knowledge base → No results
2. Search again with different query → No results
3. Search third time → Found something
4. Reply with answer

The inefficient pattern uses more tokens and time.

Agent-to-Agent Message Executions

When an execution represents an agent-to-agent (A2A) envelope - one agent dispatching a message to another - the detail page adapts to show the routing context instead of the standard email/LLM stat view.

A2A Header Banner

When the execution is an A2A message, the header shows an Agent-to-Agent Message banner in place of the usual LLM cost and duration tiles:

• From / To - Friendly agent names (e.g. "AI Chief of Staff → Personal Assistant")
• Hop - Which hop in the chain this message represents (e.g. hop 3 of 6)
• Delivered at - Timestamp when the message was enqueued

The LLM calls, cost, and duration tiles are hidden because an envelope execution does not run an LLM directly.

Steps Table - Route Row

In the Steps tab, the A2A step row shows:

AI Chief of Staff (CAIOO) → Personal Assistant (PA) · hop 3 of 6 · conv 64b4af5a…
[Message preview: first ~200 characters of the redacted message body]

Hop-limit and daily-limit refusals are styled as warnings with a "send refused" note when the agent hit its hop cap or daily message cap before the send could complete.

Cross-tenant messages show a partner-tenant badge next to the route when the message crossed a tenant boundary.

Step Detail Panel

Clicking the A2A step row opens the detail panel with:

Field	Description
From agent	Sending agent name and ID
To agent	Receiving agent name and ID
Conversation	Short conversation ID
Hop	Hop count and cap (e.g. 3 of 6)
Message body	Full redacted message text
View sender run	Link to the execution that called send_to_agent (available on new messages; absent on historical entries)
View recipient run	Link to the execution that processed the inbound message (resolved retroactively via correlation ID)

Note: The message body is passed through the platform redaction service before display. Patterns such as email addresses that match redaction rules appear masked.

Investigating A2A Issues

Tracing a full chain:

1. Open any A2A execution and note the From/To agents and conversation ID.
2. Use View sender run to step back to the execution that initiated the send.
3. Use View recipient run to follow the message forward to how the receiving agent processed it.
4. Repeat from the recipient run to follow subsequent hops.

Hop-limit refusals:

• The step row will be styled as a warning and show "send refused."
• The hop cap is set per-agent in agent configuration. Contact your Outermind administrator to adjust the cap if legitimate workflows are being blocked.

Missing sender link:

• The View sender run link is only populated for messages sent after this feature was deployed. Historical envelope executions show the route, hop count, and conversation ID but do not include the back-link.

Auto-Resume Details

When an execution has been checkpointed for automatic retry, the execution details page shows additional resume state information.

Resume State Fields

Field	Description
Status	Current resume state: pending, resumed, completed, or abandoned
Attempt Number	Which retry attempt this is (e.g., 2 of 5)
Max Attempts	Total retry attempts allowed before giving up
Error Class	Category of the transient error (e.g., balance_exhausted, rate_limit, network)
Original Error	The full error message from the failed attempt
Next Retry At	When the next retry attempt is scheduled
Progress Summary	A checkpoint summary of what the agent completed before the failure

Using Resume State for Troubleshooting

The resume state helps you understand:

• Why the execution paused - Check the error class and original error
• What work was completed - Review the progress summary
• When it will retry - Check the next retry time
• Whether to intervene - If the error class suggests a persistent issue (e.g., balance_exhausted), you may need to top up your LLM provider credits before the next retry

For more about how auto-resume works, see Agent Executions - Auto-Resume.

Debugging with Execution Details

Step-by-Step Debugging

1. Review the input - Is the email what you expected?
2. Check agent reasoning - Did it understand correctly?
3. Examine tool calls - Were the right tools called?
4. Look at results - Did tools return expected data?
5. Review response - Is the output correct?

Common Issues to Spot

Misunderstanding the email:

• Agent reasoning doesn't match email content
• Wrong entities extracted
• Context missed

Wrong tool usage:

• Tool called when not needed
• Wrong parameters
• Tool not called when it should be

Response problems:

• Missing information
• Wrong tone
• Incorrect facts

Making Fixes

Based on what you find:

Problem	Fix
Misunderstands email type	Add examples to instructions
Wrong tool choice	Clarify when to use each tool
Missing information	Ensure tool result is used
Wrong response format	Add format guidelines

Comparing Executions

Finding Similar Executions

1. Note the agent and email type
2. Go back to execution list
3. Filter by same agent
4. Look for similar emails
5. Compare how they were handled

What to Compare

• Did agent make same decisions?
• Were tool calls similar?
• Is response quality consistent?
• Are there outliers?

Exporting Execution Data

Copying Details

• Copy execution ID for reference
• Copy specific sections (prompt, response)
• Screenshot for documentation

Using for Training

Executions can inform improvements:

• Good examples → Template for instructions
• Bad examples → What to avoid
• Edge cases → Add specific handling

Performance Optimization

Identifying Slow Steps

Look at timing in timeline:

• Which tool calls took longest?
• Was LLM response slow?
• Any unnecessary waits?

Reducing Token Usage

Check prompt and response:

• Can instructions be shorter?
• Is thread history too long?
• Are responses verbose?

Improving Success Rate

For failed executions:

• Identify common failure modes
• Add error handling to instructions
• Consider fallback behaviors

Best Practices

Regular Review

• Review sample executions weekly
• Focus on failures and outliers
• Track patterns over time

Documentation

• Save good examples as templates
• Document common issues
• Share findings with team

Continuous Improvement

• Use insights to improve instructions
• Adjust tool assignments based on usage
• Optimize based on cost analysis

Related Topics

• Agent Executions
• Debugging Techniques
• Agents
• Common Issues