Glossary
AFPM: AI Flow Performance Monitoring
AFPM (AI Flow & Performance Monitoring) is the practice of reconstructing AI executions as traceable flows — across agents, models, policies, tools and infrastructure — wherever they are instrumented, so they can be observed, explained and controlled.
Application performance monitoring (APM) and distributed tracing already follow requests across services, including dynamic paths, retries, fan-out and service dependencies. AFPM builds on that telemetry and adds the context an autonomous system needs: the mission the work belongs to, the identity of the agent and who it acts for, the delegation between agents, the model and tool decisions, the policy evaluations, the attributable cost and the business outcome.
APM vs. AFPM
| APM and distributed tracing | AFPM adds |
|---|---|
| Follows a request across services, including retries and dynamic paths | Groups that execution under the mission it serves |
| Identifies services and endpoints | Identifies the agent, who it acts for and how that identity was established |
| Records spans and their parent-child relations | Records delegation: which agent handed which work to whom, with which permissions |
| Measures latency, errors and throughput | Records which model and tool were chosen, and which policies were evaluated with what decision |
| Shows resource usage per service | Attributes tokens and cost to the mission, agent and step |
| Request outcome: completed or failed | Mission completion: was the goal achieved |
| Error rates and SLOs | Policy compliance: what was allowed, denied and actually enforced |
| Resource and latency budgets | Cost efficiency: what the result cost against the route it needed |
| Service health and incidents | Operational risk: retries, exposure and boundary crossings along the way |
AFPM reports these four dimensions separately: a completed mission can still be non-compliant, inefficient or risky.
AFPM does not replace APM. The applications, infrastructure and services an agent touches still need application and infrastructure monitoring; AFPM connects that telemetry to the AI execution that caused it.
Success is not the whole answer
A mission that completed successfully has not thereby shown that it was efficient, that its cost was acceptable or that it stayed free of security risk. An agent can reach the right result after avoidable retries, with an oversized context, or after a policy decision that was recorded but not enforced. AFPM is designed to keep those questions separate: whether the mission was achieved, what it cost and why, and what was allowed, denied and enforced along the way.
Example
An agent is asked to deliver a file securely and confirm it was processed. Its SFTP attempt fails; it switches to an approved API, refreshes expired credentials, delivers the file and verifies the checksum. Where those steps are instrumented, the flow shows which agent acted and who delegated to it, which model and tools were used, which policies were evaluated, what each attempt cost, and whether the mission was achieved. Steps that ran outside the instrumented path appear as gaps, not as assumptions.
Why it matters
Because the path changes from run to run, a passing outcome can hide a wasteful or risky route. If a MissionFlow changes route five times before succeeding, AFPM should reconstruct that journey. If two agents complete the same mission through very different paths, AFPM should compare them. If missions succeed only because agents keep compensating for a failing service, AFPM should surface that hidden operational debt.
In Tracston today
- Available in Imperium: for each AI request routed through it, Imperium records the initiating user and how that identity was established (as reported, not independently verified), the agent and how it was identified, the parent agent for Claude Code and Codex sessions, the model or tool requested, the policy decision and whether Imperium enforced it, and token usage and cost per request and per agent.
- Available in Observatory: a coverage report of what was and was not observed from each source, the slowest recorded work, and recorded failure classes, shown as candidates for investigation rather than as causes.
- Depends on configuration: which of those Imperium fields reach Observatory (cost, policy decisions, parent agents) depends on the export permissions granted in each deployment. Activity that does not pass through Imperium or reach Observatory as telemetry is not observed.
- In development, not yet available: correlating requests into missions and steps, verifying whether a mission's business outcome was achieved, confirmation of enforcement from the destination system, and recovery for AI workflows.