Browse documentation

Investigate

Investigate agent runs

Triage AI executions by customer, status, cost, tools, and quality evidence.

Open Explore → Agent Runs to investigate an AI workflow as one execution rather than a collection of unrelated model spans.

Find the run that matters

Filter by agent, customer or distinct ID, terminal status, any provider used by the run, and quality state. Sort by duration, steps, tool calls, or cost to find outliers. The summary cards cover every run matching the current filters, not only the visible page; use the page controls below the table to move through the full result set. A run without a customer link usually means identity was not active before its first span.

The run identity prefers the recorded agent name. For a direct model call without an agent name, Anectico shows the model instead; if neither is present, it falls back to the root operation. The root operation remains visible separately so an HTTP or job span is not mistaken for an agent name.

Every run has one terminal state: Completed, Failed, Timed out, Cancelled, or Max steps. The detail and customer timeline also explain the safe terminal reason code. An explicit outcome on the earliest invoke_agent span is authoritative, so a failed child tool does not turn an explicitly cancelled or max-steps run into a failure. Older telemetry without an explicit outcome uses a visible, deterministic inferred result: any error child means Failed; otherwise it means Completed. A run can use multiple model providers, so Anectico displays the complete sorted provider set and the provider filter matches when any step used that provider.

Open a run and review:

  • the execution sequence and slow or failed steps;
  • repeated model or tool calls;
  • token use and calculated cost;
  • errors and status transitions;
  • human scores and automatic evaluation results; and
  • connected customer, trace, replay, or Issue evidence.

Interpret quality scores carefully

Human scores capture reviewer judgment. Automatic scores apply the organization’s configured sample and criteria. Neither score explains a failure by itself; compare the cited run steps, tool outputs, and application evidence.

Agent-run reads are project-scoped. The CLI sends the active project selected by --project, ANECTICO_PROJECT, or the current profile; an organization-level credential must select one, while a project-scoped API key can rely on its signed project binding. With MCP, an organization-level credential must provide project_id; a project-scoped credential can omit it because Anectico pins the call to the project signed into the key. Passing a sibling project cannot widen that key. Missing, foreign-project, and random run IDs return the same not-found response, while list calls for foreign or random projects both return an empty result.

Scores belong to the same project as their run. Anectico verifies that the run—and an optional scored span—exists in that project before accepting feedback. A missing run, a sibling-project run, and a span outside the run all return the same not-found result so identifiers cannot be used to probe another project.

Each reviewer has one score per project, run, optional span, source, and metric name. Safe retries return that same score instead of creating duplicates. Submitting changed feedback for the same identity edits it in place: the score ID and creation time stay stable while the update time advances. Different reviewers, metrics, spans, and automated evaluators remain separate judgments. This also keeps an automatic evaluation retry from duplicating a verdict if its bookkeeping step temporarily fails after the score is stored.

The feedback controls are shown only with scores:write; a refreshed viewer permission removes them immediately, and the server independently enforces the same permission.

If a run was not sampled, that is not a passing score. If an evaluation lacks the inputs needed for a criterion, change the recorded evidence or criterion before increasing the sample rate.

Move from run to impact

Open the customer to see what preceded and followed the run. Compare similar runs for other customers before treating one expensive or failed execution as systemic. Use Customer Detective when a grounded cross-signal explanation is more useful than manually reading every span.