Analytics

The Analytics dashboard shows how agents, capabilities, handoffs, actions, knowledge, and generated content are performing over a selected time range.

Analytics are derived from live platform data. The dashboard uses conversations, conversation turns, conversation audit logs, and generated artifacts. It does not use demo data.

Filters

Use the filters at the top of the page to choose:

• Agent: view all agents or one specific agent.
• Range: view a recent or custom time period.

The dashboard automatically chooses the chart grouping for the selected range. For example, a 24-hour range is grouped hourly, while longer ranges are grouped daily or weekly.

KPI Summary

KPI	What it means	How it is derived
Capability completions	Number of capabilities that reached a successful terminal outcome.	Counts audit logs with capabilityCompletion where the outcome is categorized as completed.
Completion rate	How often terminal capability runs completed successfully.	completed terminal capability outcomes / all terminal capability outcomes. Open or still-running conversations are excluded.
Automation rate	How often completed capabilities were handled without human participation.	automated completed outcomes / completed outcomes. A completed outcome is automated only when there is no human-agent turn, no active human handoff state, and no handoff reason for that conversation.
Handoff rate	How often terminal capability runs needed a human handoff.	handoff or escalated terminal outcomes / all terminal capability outcomes.
Active conversations	Conversations that are still open with AI or human participation.	Counts conversations whose status is ai_active or human_active in the selected range.
P95 latency	The 95th percentile response/orchestration duration.	Uses performance.totalDurationMs from conversation audit logs.
Estimated cost	Estimated LLM cost for the selected range.	Sums llmCalls[].cost from audit logs, with fallback to llm.cost when only the summary is available.
Generated artifacts	Files or artifacts generated during conversations.	Counts rows in conversation_artifacts for the selected range.

Important Semantics

Capability success is not conversation closure

Conversations can remain open after one capability completes. A user may complete one capability, ask a follow-up question, start another capability, or simply leave the conversation idle.

Because of that, analytics treat capability completion as the success unit. Conversation closure is shown only as explicit closure state; it is not used as the success rate.

Open conversations are not failures

In-progress conversations are normal. They are counted as active conversations, but they are not counted as failed, unresolved, or incomplete capability runs.

Terminal outcomes only

Completion rate, automation rate, and handoff rate are based on terminal capability outcomes from audit logs. Running conversations without a terminal capability audit event are excluded from those rate denominators.

Charts And Breakdowns

Section	What it shows	Source
Conversation activity	Conversation openings and transcript turns over time.	conversations.created_at and conversation_turns.created_at.
Capability outcomes	Completed, handed-off, and failed terminal capability outcomes over time.	conversation_audit_logs.audit_data.capabilityCompletion.
Cost and latency	Estimated LLM cost with P95 latency over time.	llmCalls, llm, and performance in audit logs.
Top capabilities	Capability activation, completion, and handoff volume.	capabilityActivation and capabilityCompletion audit events.
Conversation state	Current conversation status and execution-state distribution.	conversations.status and conversations.execution_state.
Handoff reasons	Why work was handed to a human.	conversations.handoff_reason, with audit handoff data used when conversation state does not already provide a reason.
Action reliability	Action success, failure, and average duration by action.	conversation_audit_logs.audit_data.actions[].
Knowledge usage	Whether agent, capability, merged, or no knowledge was used.	conversation_audit_logs.audit_data.knowledgeSource.
Generated content	Generated-content mode and action counts.	conversation_audit_logs.audit_data.generatedContent.

Data Sources

Analytics V1 reads from existing platform tables:

• conversations
• conversation_turns
• conversation_audit_logs
• conversation_artifacts

No analytics rollup tables are required for V1. Queries are bounded by the selected date range and use the existing audit-log JSON data.

Audit Log Fields Used

The analytics API expects these audit-log fields when they are available:

Audit field	Used for
capabilityActivation	Capability activation counts and top-capability usage.
capabilityCompletion	Completion, handoff, failed outcomes, completion rate, automation rate, and handoff rate.
performance.totalDurationMs	P50/P95 latency.
llmCalls[].tokenUsage.totalTokens	Total token usage.
llmCalls[].cost	Estimated LLM cost.
llm.tokenUsage.totalTokens	Fallback token usage when individual calls are not present.
llm.cost	Fallback cost when individual calls are not present.
actions[]	Action success, failure, and average duration.
knowledgeSource	Knowledge usage breakdown.
generatedContent	Generated content breakdown.
handoffBrief	Handoff reason fallback when conversation state does not provide one.

Regression Expectations

Analytics KPI behavior is covered by component tests that persist conversation and audit-log scenarios, then call the public analytics API. These tests are intended to catch regressions when audit-log structure or lifecycle behavior changes.

The test scenarios cover:

• empty tenants
• automated completion
• human-assisted completion
• handoff/escalation
• failed or unresolved terminal outcomes
• still-open conversations
• explicit conversation closure
• agent filtering
• cost, token, latency, action, knowledge, and generated-content derivation
• Studio permission enforcement