An AI observability platform is only as good as the data it collects. Every time an agent handles a request — calling a model, consuming tokens, returning a result, or hitting an error — that interaction either gets recorded with structure and context or it disappears. The event stream is what turns a fleet of agents into a system you can actually understand and operate. A per-interaction event model captures a structured record at the point each request completes, creating a queryable history of everything your agents have done without requiring you to instrument anything yourself.
Why the event model matters
Most teams discover they need AI observability data only after something goes wrong: costs spike, an agent starts returning errors, a stakeholder asks why usage doubled last month. At that point, if you haven't been collecting structured interaction records, your options are limited to guessing, log-grepping, or waiting for the next billing cycle to confirm your suspicion. The broader picture of what to collect and why is covered in Observability for AI Agents: Logs, Metrics, and Traces.
A purpose-built event model solves this by treating observability as a first-class concern from the start. Every interaction is recorded, indexed by organization, agent, event type, and time, and made queryable both through a dashboard and programmatically through the API. The difference between having this data and not having it is the difference between diagnosing a problem in minutes and spending hours reconstructing what happened from partial signals.
What gets recorded on each interaction
The event stream writes one record per completed agent interaction. Each record captures the organization and agent it belongs to, an event type that reflects the outcome, timestamp information, and outcome metadata — success or error, response latency, cost figures where applicable.
Recording at completion is a deliberate design choice. It means each event reflects what actually happened, not what was attempted. A failed request and a successful one both produce a record, but with different event types, which lets you distinguish your error rate from your throughput in every query. An event that is never written is an interaction that is permanently invisible to every dashboard, report, and alert you might build later.
The event type taxonomy is designed around the questions operators actually ask. Successful responses and errors are the primary signal. More specialized events — guardrail firings, token issuances, policy decisions — are captured through purpose-built governance and compliance systems rather than the analytics store. This keeps the analytics event stream focused on interaction-level data and ensures that compliance metrics draw from systems optimized for that purpose.
Organization and per-agent analytics
The analytics surface presents data at two levels of granularity, and both matter for routine operations.
Organization rollups give you the headline view: total requests, aggregate success rate, latency at common percentiles, and total cost across a selected period. These numbers answer the first question you ask when something looks off, or when a stakeholder wants to know how the AI program is performing. The rollup spans every agent in your organization, so you get a single representative summary without having to aggregate it yourself.
Per-agent analytics drill down to a single agent and apply the same metrics to it. Attribution at this level is what makes numbers actionable. When costs spike, per-agent data identifies which agent drove the increase. When error rates climb, you can isolate the responsible agent before the problem spreads. Queries are scoped by both organization and agent identifier, so data never crosses tenant or agent boundaries regardless of how many agents share the underlying infrastructure.
Both views support a configurable time window. You can compare today against last week, or examine a custom range that corresponds to a deployment or an incident, without switching to a different tool or waiting for a scheduled report.
The recent-events feed
Rollups show you what happened in aggregate. The recent-events feed shows you what happened, in sequence, with full context on each record. Praesidia provides a paginated event feed that operators can filter by agent, event type, and date range, and that returns a consistent pagination envelope across all queries.
This is the surface you reach for during incident investigation. When an agent starts behaving unexpectedly, you want to read the last hundred events for that agent in chronological order — not wait for a rollup to refresh or cross-reference multiple systems. The events feed delivers that directly. Filters compose naturally: you can narrow to a specific agent, request error events only, and constrain to a two-hour window. Large time ranges stay responsive because results are paginated with cursor metadata rather than fetched in a single unbounded query.
The same endpoint that powers the in-product Events tab is available through the API, so any tooling you build on top of it — a custom dashboard, a Slack alert bot, a scheduled report — draws from exactly the same data.
How the event model powers dashboards and reports
The analytics dashboard aggregates the event stream into the charts most useful for ongoing operations: request volume over time, error rate trend, latency distribution, cost per period, and per-agent success rate. These are computed from the same underlying data that the API exposes, so there is no divergence between what the dashboard shows and what you would get from a direct query.
Because the event store is structured for the query patterns that matter most, queries are efficient even as the history grows. Dashboard loads stay fast under concurrent use even as the event history accumulates.
Reports follow the same pattern. A weekly usage summary for a non-engineering audience draws from the same event data as the dashboard. There is no separate reporting pipeline to maintain, no reconciliation step, and no risk that the numbers in one place contradict the numbers in another.
Manual event ingest
The event stream also accepts events submitted directly via API, under the appropriate permission. This path is designed for business-level events you want to correlate with platform-generated records: a task completion, a downstream outcome, a workflow milestone that the agent triggered but that isn't itself an HTTP interaction.
When your custom events live in the same store as the platform events, they show up in the same queries and the same feeds. You can filter the recent-events view to show both API interaction records and your injected business events together, which makes it easier to trace what the agent did against what actually happened in the systems it touched.
What the event stream is not
It is worth being explicit about scope. The analytics event stream records completed interactions and any events you inject. It is not a distributed trace — spans, propagation context, and latency decomposition live in the OpenTelemetry layer. It is not a security audit trail — those records are written to the tamper-evident audit log with cryptographic chaining and independent verifiability. Each system is optimized for its purpose, and they complement rather than duplicate each other.
For teams that need to forward event data to existing tooling, the platform supports integration paths that let you send events to a SIEM or data warehouse — see Webhooks and SIEM Forwarding for how that pipeline works. The analytics API gives you programmatic access to pull data on your own schedule.
Common questions
Does writing an event record on every request add latency to my agents?
No. Event recording is handled outside the request path, so it adds no measurable overhead to the latency your agents or callers observe.
How far back can I query event data?
Events are retained according to your organization's configured data retention policy. Within that window, the API supports arbitrary time ranges. For analysis beyond the retention window, you can export event data or forward it to your own storage before the retention period expires.
Can I consume analytics data outside the dashboard?
Yes. All analytics endpoints are available via the platform API, scoped to your organization and subject to your permission model. Organization rollups, per-agent breakdowns, and the paginated events feed are all accessible programmatically, which makes it straightforward to build custom reports or pipe the data into an existing BI tool. For connecting cost data specifically, see Visualizing AI Usage and Cost.
The event stream is the layer that connects what your agents do to what you can understand and act on. Rollups surface trends across the organization. Per-agent data drives attribution. The events feed supports investigation. The append-only structure makes the record durable and consistent over time.
The choice is not whether you need this data — at any meaningful scale of agent operation, you do. The choice is whether to instrument it yourself or adopt a platform that treats observability as a default. Praesidia is designed so the event stream is operational from the moment you register your first agent, with no additional collection infrastructure required on your part.