Teams comparing agent tooling usually end up comparing a tracing product with an enforcement product and asking which to buy. It is the wrong question, in the same way that comparing your logging stack with your firewall is the wrong question. One explains what happened. The other decides what may happen. You will eventually want both, and the order you adopt them in matters less than knowing which problem each one leaves untouched.
Traces, spans, token counts, latencies, prompt and response capture, evaluation reports. It reconstructs what an agent did, in what order, with what inputs, and how much of the context window it burned doing it. When an agent behaves strangely, this is the only thing that will tell you why.
Budgets, policy verdicts, identity, approval ceremonies, hard ceilings. It sits in the request path and answers before the call happens: allowed, refused, or held for a human. Its output is not a chart, it is an action that did or did not occur, and a record that it was decided on purpose.
Take one concrete case: an agent enters a retry loop against a production API at two in the morning and spends four figures before anyone wakes up.
| Observability alone | Governance alone | Both | |
|---|---|---|---|
| At 02:00 | Records every call faithfully | Refuses the call that crosses the cap | Refuses it, and records why |
| At 09:00 | You can reconstruct exactly what happened | You know it was stopped, not why it started | Root cause and a bounded loss |
| The bill | Already spent | Capped at the budget | Capped, and attributable per run |
| The fix | A ticket for next sprint | A cap, without knowing the trigger | A cap now, the trigger fixed properly |
| The auditor | Logs, if retention was right | A signed decision record | Both, joined on one id |
The middle column is deliberately uncomfortable. Governance without observability is a fleet that is safe and opaque: you know an action was refused, and you cannot say what made the agent try. That is a worse place to debug from than most teams expect, which is why the answer is not to replace one with the other.
The join is the only integration decision that really matters. If the trace, the spend line, the policy verdict and the outcome tag all carry the same run identifier, then the two halves compose: a refusal in the governance record links to the exact chain of calls that led to it, and a spike in the trace links to the budget that stopped it. If they do not, you have two dashboards and an argument.
In this stack the run id is the unit everything keys on, and the governance planes deliberately emit rather than hoard: policy decisions and quality runs export over OTLP into whatever tracing backend you already run, the gateway writes its own traces as Parquet, and every plane emits the same agent-event envelope. Governance data belongs in your observability stack; the enforcement decision does not belong in a dashboard.
If you have tracing and no enforcement, which is the common case, the shortest path to the other half is not a migration. Route model calls through one gateway, watch in shadow mode for a week, then turn on caps where the outliers are. Your traces keep working; they gain a spend line and a verdict per run.
The governance side is laid out in the agent governance guide, the money in FinOps for AI, and the defensive half in AI agent security. All of the tools are Apache-2.0, run on infrastructure you own, and export into the observability stack you already have.
Observability reconstructs what an agent did: traces, token counts, latencies, evaluations. Governance decides what it may do next, in the request path, with a binding answer. One is a record you can question, the other is an action that did or did not happen.
Tracing alone leaves every insight arriving after the action and often after the invoice. Governance alone leaves you safe and opaque: you know an action was refused and cannot say what made the agent try. Most teams already have the first half, and the shortest path to the second is a gateway in shadow mode.
On one run identifier. If the trace, the spend line, the policy verdict and the outcome tag all carry the same id, a refusal links to the exact chain of calls that led to it. If they do not, you own two dashboards and an argument.
No. The governance planes here export over OTLP into whatever backend you already run, and the gateway writes its own traces, so governance data lands in your observability stack rather than competing with it. What does not belong in a dashboard is the enforcement decision itself.
Four questions. Does it act in the path or after it? Is the answer binding, or can the agent proceed past a warning? What happens when it is unreachable, and is that choice documented? Can somebody who does not trust you verify its record?