AI observability for agents, workflows and models

A conventional monitoring stack tells you that a request took four hundred milliseconds and returned a success code. For an AI system that is the least interesting part. The questions that matter to an operator, a security lead or a reviewer are different. Which model answered? What did it read? What tools did it call? What did the call cost? Did a policy allow, warn, filter or deny any step? Did a person approve? What was the outcome?

Those are the same facts the platform defines as traceability: the chain from data to model to agent to decision to action to outcome. Observability is the day-to-day view onto that chain. It is also the cheapest source of early warning, because most AI incidents are visible in the record well before anyone complains.

Observability is also where honesty is tested. A trace that records only the happy path, or that cannot join a step to its cost, is a trace you will not trust when it matters. We say below which of those gaps exist today.

Anomaly detection in the products today is deliberately simple. The analytics service compares the current period with the previous one and flags a rise or fall in usage, a rise in latency, a rise in error rate and a cost shift. Because it compares an organisation with its own history, it needs no model of what normal means in general.

Two limits are worth stating. Detected anomalies are computed on demand and are not stored as a history, and acknowledgement of an anomaly is not available. We do not claim either. A dashboard banner that says something moved is a prompt to look, and not yet a case-management system.

A separate pipeline exists for web experience: errors, signs of struggle and churn risk in the sessions of Swfte’s own web applications are aggregated into issues and classified by a language model. That is product analytics for web applications, and it does not trace AI agent runs. We mention it only so that nobody mistakes one for the other.

The products above each hold part of the picture, and each is scoped to its own surface. The Intelligence Platform is designed to put them on one graph with one set of identities, so that a trace can name the agent’s owner, the approver, the policy set and the evidence status of the facts it relied on. Today the graph can resolve people, groups and reporting lines from your directories. Service and system ownership depend on collectors that are on the roadmap.

It is also designed to carry an observation forward. A spike in policy denials is not an end point: it is the starting point for a SecOps response agent, which gathers the events, pulls each agent’s Trust Profile and notifies the owner. No automatic path from an observed issue to a built agent or workflow exists today. A worker template for triaging an issue exists, but nothing connects a detected issue to it, and the link is design intent.

Natural-language questions over your own data exist for datasets in the products today. Asking questions of usage, cost and trace telemetry in plain language is not available, and is designed for. <query language - founder to fill>