> ## Documentation Index
> Fetch the complete documentation index at: https://www.truefoundry.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Agent Observability
> Metrics, traces, and the audit trail for every registered agent — what exists today, and the complete observability blueprint governance requires.
Observability is the [audit-and-respond pillar](/docs/agent-platform/agent-governance/governance-blueprint#5-audit-and-respond-close-the-loop) of the blueprint, and it answers the last of the [five questions](/docs/agent-platform/agent-governance/overview#the-five-questions-governance-must-answer) governance must answer: **what did the agent actually do?** Because every governed hop passes through a gateway, the answer is recorded as a side effect of enforcement — not reconstructed afterward from scattered application logs.
This page covers what you get today for every registered agent, and the complete picture we are building toward — items marked **coming soon** describe planned behavior and may change as they ship.
## What you get today
### Unified metrics
Every registered agent — wherever it actually runs — reports into one dashboard: request counts, latency percentiles, error rates, and usage over time. This is the "which agents are active, and what should we invest in?" view, and it works identically for an agent on Bedrock, LangGraph, or a custom HTTP service.
### Request traces with per-hop attribution
Navigate to **AI Monitoring → Request Traces** to inspect individual requests. Each trace records **which agent** made the call and **which user it acted for** — the per-hop attribution the blueprint is built on — along with the full payload (including the JSONRPC request/response for A2A agents).
### Guardrail execution in traces
Every [guardrail](/docs/agent-platform/agent-governance/agent-guardrails) that ran on a hop appears as its own span: what it checked, whether it passed, what it found or redacted, and how long it took. Traces are logged for blocked requests too — a denied hop is audit evidence, not a gap.
### Activity logs per agent
Each agent's row in the [Agent Registry](/docs/agent-platform/agent-governance/agent-registry) has an **Activity Logs** entry in its **⋮** menu — administrative history for that specific agent, alongside its access control and token management.
## The complete picture
Full agent observability has to answer more than "how many requests?" — it has to connect **what the agent was allowed to do** (its registry entry and grants) with **what it actually did** (the trace record). That connection is what turns logs into governance:
| Capability | What it answers | Status |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | --------------- |
| Per-hop attribution (agent + user acted for) | Who did what, for whom, on every call | **Available** |
| Guardrail spans in traces | What was inspected, found, blocked, redacted | **Available** |
| Unified metrics across all agents | Which agents are active; traffic, latency, errors | **Available** |
| Full actor-chain view | The complete delegation path (user → agent → sub-agent → tool) rendered as one trace, across hops | **Coming soon** |
| Authority vs. usage (drift detection) | Which granted permissions the agent actually exercises — and which grants are unused and should be revoked | **Coming soon** |
| Anomaly alerts | An agent suddenly calling new tools, spiking volume, or acting outside its historical pattern | **Coming soon** |
| Access certification evidence | Exportable, per-agent reports of grants + usage for periodic owner review (SOC 2 / ISO-style attestation) | **Coming soon** |
| One-click suspend (kill switch) | Freeze a misbehaving agent's identity everywhere at once, from its registry entry | **Coming soon** |
Two of these deserve emphasis, because they are what auditors and security teams actually ask for:
* **Drift detection** operationalizes least privilege. Grants tend to accumulate; usage data is the only honest input for trimming them. "This agent has access to 40 tools and has called 6 in 90 days" is an actionable finding.
* **The actor chain** is what makes multi-agent systems auditable. Without it, a sub-agent's tool call is attributed to the sub-agent alone; with it, you can trace the action back through every delegation step to the human who started it.
## How the pieces fit
The reason this works without instrumenting your agents: enforcement and observation happen at the same place. The gateway that authenticates a hop and runs its guardrails is also the component that records it — so the audit trail is complete by construction for every governed hop, and an agent cannot opt out of being observed any more than it can opt out of being authorized.
```mermaid theme={"dark"}
flowchart LR
subgraph Registry["Agent Registry"]
Entry["Agent entry
identity · owner · grants"]
end
subgraph Gateway["Gateways (Agent / MCP / LLM)"]
Enforce["Authenticate · authorize · guard"]
end
subgraph Observe["Observability"]
Traces["Traces + metrics
per-hop attribution"]
Review["Drift · certification · alerts
(coming soon)"]
end
Entry -->|"defined authority"| Enforce
Enforce -->|"records every hop"| Traces
Traces -->|"actual usage"| Review
Review -.->|"trim grants, suspend"| Entry
```
The loop closes on the left: usage data feeds back into the registry entry, where grants get trimmed and — when something is wrong — the identity gets suspended. That feedback loop is the difference between *logging* and *governance*.
## Next
* [Agent Registry](/docs/agent-platform/agent-governance/agent-registry) — the registry entry that observability data is attributed to.
* [Guardrails for Agents](/docs/agent-platform/agent-governance/agent-guardrails) — the checks whose results appear as trace spans.
* [Implementation Overview](/docs/agent-platform/agent-governance/truefoundry-implementation) — how observability fits the full TrueFoundry governance setup.