Why it is different from application observability
Application observability assumes the thing you measure cooperates: you own the call site, so you put a probe there, emit a span, and read a dashboard. An agent gives you none of that. It is a vendor’s binary running a vendor’s model behind a vendor’s API, exposing only the surfaces the vendor chose. It will not carry your trace ID, and when it spawns a subagent that child is born and dies outside your instrumentation. So agent observability inverts the normal assumption: you instrument an uncooperative — sometimes actively hostile — subject from the outside, and you design every part of the system to survive the subject trying to bury it.
What it actually measures
The honest unit is not tokens, which are a vanity metric dominated by cache reads. It is cost per shipped unit of work — dollars per commit, dollars per verified task — attributed per developer, per project, and per vendor into one schema you own rather than scattered across each vendor’s billing console. Identity is computed, not assigned: a hash of stable observable facts, so even anonymous subagents get attributed without any cooperation from the thing being identified.
Why it matters
For a solo operator the payoff is seeing your own spend and pricing your own work. For an organization it is the artifact disclosure regimes and EU-AI-Act exposure will require: a per-developer, per-project, per-provider ledger a finance or compliance team can actually read — accountability without surveillance, because the schema stays pseudonymized the whole way down.
The full build — the fail-open capture layer, attribution by derivation, per-commit cost, and governing a multi-agent fleet — is in the pillar guide: AI agent observability and governance. The companion essay on the capture layer is you can’t ask an agent to log itself.