ANALYTICS & OBSERVABILITY. ONE TRACE ID, ONE AUDIT QUERY.

An auditor asks what an agent did for one user last Tuesday. In a stock Claude deployment that question becomes a grep across application logs, an LLM provider dashboard, and an MCP server's stdout, and a week later the answer is still a guess. systemprompt.io collapses it into a single trace_id lookup, so the CISO answering "can I prove this in an audit?" has the query in one line and the row in one table.

A structured log row reaches the database only after identity is bound to it. Every event carries user_id, session_id, trace_id, and where applicable task_id, context_id, and client_id as typed columns. Builder methods attach those ids at construction, so a row that reaches the database without a trace_id is a programming error, not a configuration choice. The struct that enforces this is named in the reference below.

One trace_id resolves the full request lineage in a single call. The trace query service runs parallel lookups across log events, AI request events, MCP execution events, execution step events, and the linked summaries and task id, returning an ordered timeline. Nothing is sampled. Every row for the trace is fetched. An auditor runs one SQL lookup and gets the chain from login to model output, which is the artefact finance, legal, or an external auditor actually asks for.

An agent issues a tool call nobody anticipated. By the time it lands in a log, it has already executed against a customer database. The fix is a programmable checkpoint in front of the tool call, not behind it, so the block happens before the model runtime ever sees a result. The staff engineer answering "where do I plug my policy in?" gets one enum with named lifecycle moments, not a post-hoc alerting rule.

Lifecycle moments are covered across the agent runtime: before a tool runs, after it succeeds, on tool failure, at session start and end, on user prompt submit, on notification, on stop, and when a subagent starts or stops. Each moment routes to a list of matchers (glob default "*") and each matcher runs one of three handlers, a shell command, an LLM evaluation, or a delegation to another agent. A pre-tool-use matcher that exits non-zero aborts the tool call before dispatch, so a destructive call written into an agent prompt does not reach the backend.

Delegation closes the loop. When one agent spawns a child, the parent-child relationship is recorded against the same trace_id, and the trace lookup from the previous section walks the full chain back to the originating user prompt. A CISO asking "which child did what for which user" reads the same single table, not a join across a parent log and a subagent log.

The SIEM team runs one test before accepting a new audit source. Does the event schema import into Splunk, ELK, Datadog, or Sumo Logic without a custom parser? systemprompt.io emits structured JSON for every event domain, with stable field names like trace_id, user_id, session_id, context_id, client_id, and task_id that a SIEM indexes without a regex extraction pass. A search by user or session is one query, not an ILIKE over free-form messages.

Distribution runs over server-sent events, with one channel per user per connection. The broadcaster holds the connection state in memory, and an automatic cleanup deregisters the subscriber when the client disconnects, so there is no background reaper for stale connections. A short keep-alive keeps idle dashboards open and detects a dropped link on the next tick rather than waiting for a TCP timeout.

Anomaly checks sit on the same audit stream. Default metrics trend against a rolling average, request rate per user, unique sessions per device fingerprint, and error rate. A value above baseline raises a warning signal, a larger multiple raises a critical one. Warning catches the "something changed" moment, critical is the "page someone now" moment, and both trigger off the same audit rows the CISO already reads. An unauthorised account hammering the inference API at 3am shows up as a row in the anomaly table, not a ticket filed next Tuesday.

Finance asks why this month's Claude spend doubled. Without typed attribution, the answer is a ticket and a week of CSV merging. The CTO answering "can I show the board spend broken by team, tool, and model without a spreadsheet?" should run one SQL query against one table. systemprompt.io's cost repository reads exactly that table.

Methods share one source. A summary method returns total request count, total cost, and total tokens for a window. Per-model and per-provider breakdowns group by the dimension an exec actually asks about. A per-agent breakdown joins the request log to the task log on task_id, so every dollar resolves to a named agent, not a category bucket. A time-series method returns the raw points a chart renders. Costs are stored as integer microdollars to avoid floating-point drift across aggregation and presentation boundaries.

The wider dashboard reads the same numbers. One query returns platform metrics for the overview ribbon (users, sessions, contexts, tasks, and request counts), and rolling windows across 24h, 7d, and 30d sit beside total cost and average cost per request. A tool ranking is a second read against the tool executions table, ordered by execution count, success rate, latency, or last-used. The reliability question and the spend question hit the same rows, so an engineer and a CFO stop arguing about definitions.

An operator opening the dashboard at the start of a shift wants three answers. Who is using AI, how the system is behaving, and what changed since yesterday. In most AI stacks those answers live in three tools owned by three teams. systemprompt.io collapses them into one query set against one database, so the 9am conversation stops being a reconciliation meeting.

The overview ribbon reads one method that returns total users, active users in the last 24 hours and 7 days, total and active sessions, total contexts, total tasks, and total AI requests. An activity-trend method returns a daily time series across sessions, contexts, tasks, AI requests, and tool executions over a configurable window. The operator answering "what changed since yesterday?" reads one chart backed by one query, and the number on the chart is the same number the CISO queries in the audit table.

User-side behaviour sits on the same schema. Named event categories cover page view, page exit, link click, scroll, engagement, and conversion, plus an escape hatch for in-house events, mapped into navigation, interaction, engagement, and conversion buckets. An engagement row persists identity and timestamps alongside behavioural fields a product team actually uses: time on page, scroll depth, scroll velocity, focus time, rage-click and dead-click flags, and a coarse reading-pattern label. The dashboard updates over SSE with the same heartbeat described in the SIEM section, and leaderboards rank top users, agents, and tools so "who is most active today" is one read, not a stitched report.

The 3am incident question is rarely "what does the dashboard show." It is "give me the raw rows for trace abc123 right now, and pipe it through jq." A platform engineer wants a CLI that hits the same database the dashboard uses, not a second query path that could disagree. The CLI here runs the same SQL methods the dashboard does, so an incident responder and an operator never read different numbers.

Analytics subcommands cover the daily surface: overview, conversations, agents, tools, requests, sessions, content, traffic, and costs. Each subcommand offers both a remote HTTP mode and a local database-context mode, so the same binary runs against staging, production, or a local Postgres dump on a laptop. The underlying trace service exposes list and search helpers with typed filters for agent, status, tool, server, level, and since, so a pattern search or a time-bounded scan is one flag, not a recompile.

Audit work uses the same lookups. One call resolves a request from a request id, task id, or trace prefix. Another returns the full conversation. A third returns every tool invocation. A fourth joins tool invocations to the MCP executions they ran against. A retention runner handles cleanup with tiered policies so hot logs age out faster than error logs, with debug, info, warn, and error windows configurable per deployment, and a scheduled vacuum keeps the index small enough that the 3am query still returns in seconds.