The three planes of running agents

In 2026 the infrastructure vendors arrived at agents from both ends. Okta built agent identity — Agent SSO, short-lived credentials brokered at connection time. Honeycomb built agent observability — Agent Timeline, OpenTelemetry GenAI traces, reconstruction of multi-agent workflows. Both launches are good news, and both draw the same border from opposite sides.

Put them on a timeline and the map draws itself:

   BEFORE the session          AT the moment of action         AFTER the fact
──────────────────────────  ───────────────────────────  ──────────────────────────
     identity plane                control plane              observability plane
──────────────────────────  ───────────────────────────  ──────────────────────────
 who is this agent?          should THIS call run?        what did the agent do?
 who is the user behind it?  allow / ask / deny —         which tools, what path,
 what scopes does it get?    on tool + arguments +        what broke, what did
 can we revoke it?           session history, with        it cost?
                             the decision recorded
──────────────────────────  ───────────────────────────  ──────────────────────────
 Okta Agent SSO / Gateway,   agentic control plane        Honeycomb, OTel GenAI
 Auth0, Entra                                             traces, Datadog

Three planes, three questions, three tenses. The identity plane’s question is settled before anyone knows what the agent will attempt. The observability plane’s question is answered after the attempt is history. The middle plane owns the only question whose answer can still change the outcome.

Why the middle plane is not the sum of the other two

It’s tempting to think identity plus observability covers it: verified agents in, full traces out. The gap between them is exactly where agent incidents live.

Identity can’t see the action. A scoped, short-lived, perfectly-brokered credential permits every call inside its scope — the routine update and the prompt-injected destructive write carry the same valid token, because scope was decided at grant time. The failure mode that makes agents different from other workloads is that the entity holding the credential is steerable by its own input; the credential stays legitimate while the behavior goes wrong.

Observability can’t refuse anything. A trace is written down unconditionally, after the fact. Honeycomb’s Agent Timeline reconstructs “the full decision path” — the agent’s decisions: which tool it chose, what it did next. It contains no policy decisions, because the observability plane makes none. When the timeline shows the alarm being silenced, the alarm is already silent.

And observability’s record has a structural dependency identity shares: it trusts the agent. OpenTelemetry instrumentation runs inside the process it measures — the agent self-reports its spans. An injected, buggy, or crashing agent misreports or drops its own telemetry at precisely the moment the record matters. The control plane’s record is different in kind, not just in content: it’s metered at a chokepoint outside the thing being measured. Double-entry bookkeeping, applied to agent behavior — the agent’s account of itself, reconciled against an independent ledger. When we ran a full benchmark through the live gateway, the harness silently re-ran ~145 episodes and booked them at $0; the benchmark’s own accounting, and the results files, missed all of them. The decision log on the call path was the only witness.

So the middle plane contributes two things neither neighbor can: the verdict (each call examined against policy while it can still be held — allow, ask a human, or deny) and the independent record of it (why each action was allowed, attributed to the identity that initiated it — the answer an incident review and an auditor actually ask for).

How the planes compose

The seams are standards, which is why this is a map and not a war.

Identity → control. The identity plane hands the control plane its principal: an IdP-issued JWT — Okta, Auth0, Entra, any OIDC provider — arrives at the call path as the verified who, and every per-call decision and audit row is attributed to it. User → agent → action → verdict, one chain.

Control → observability. The control plane hands the observability plane its verdicts: decision records flowing as OpenTelemetry spans — gen_ai.* conventions plus the decision attributes — into whatever backend already holds your traces. Your Honeycomb timeline gains the one span type self-instrumentation can’t produce: what the policy said, and why. And the independent meter gives the query engine something to reconcile against, not just more of the agent’s own account.

Each plane does a job the others structurally can’t. An agent that matters runs behind all three: credentials issued by the identity plane, actions decided and recorded on the control plane, behavior explored in the observability plane.

The one-question test for each plane

Evaluating a vendor in this space? One question per plane sorts everything faster than a feature grid:

“Can you revoke this agent’s access right now?” — if yes, you’re looking at the identity plane.
“Can you hold this specific call — this tool, these arguments — before it runs, and show me why it was allowed after?” — if yes, the control plane.
“Can you show me every span of what the agent did last Tuesday, and query it by any attribute?” — if yes, the observability plane.

A vendor that answers one question well is infrastructure. A vendor that claims all three deserves the follow-up: at which moment, from which vantage point? The honest answer is always one plane with exports to the others — which is the architecture you wanted anyway.

What are the three planes of agent infrastructure?

The identity plane decides, before a session, whether an agent should hold a credential — who it is, who’s behind it, what scopes it gets (Okta Agent SSO and Agent Gateway, Auth0, Entra). The control plane decides, at the moment of action, whether a specific tool call should run — allow, ask a human, or deny, on the tool and its arguments, with the decision recorded. The observability plane reconstructs, after the fact, what the agent did (Honeycomb Agent Observability, OpenTelemetry GenAI traces). Same agent, three different questions, three different moments in time.

If I have Okta for agents and Honeycomb for traces, what's missing?

The decision at the moment of action. Identity granted the credential before anyone knew what the agent would attempt; observability writes down what happened after it did. Neither examines the call in flight — so a prompt-injected destructive write with a valid, in-scope token passes the first plane unseen and appears in the third plane only as history. The middle plane is the only one positioned to hold or refuse it, and the only one that can record why each action was allowed.

Does a control plane replace observability tooling?

No. An agentic control plane’s trace is a record of judgments — every tool call with its verdict, rule, reason, and identity — captured at a chokepoint the agent can’t misreport. An observability platform is a query engine over behavior at high cardinality. They meet cleanly: decision records can flow as OpenTelemetry spans into whatever backend you already run, adding the one span type self-instrumentation cannot produce — the verdict.

Why does it matter that the control plane's record is independent of the agent?

Because observability instrumentation runs inside the process it measures: the agent self-reports its spans. A compromised, buggy, or crashing agent misreports or drops its own telemetry precisely when the record matters most. A meter at the call-path chokepoint is outside the thing being measured — double-entry bookkeeping for agent behavior. In one benchmark run we published, a harness silently re-ran ~145 full episodes and booked them at zero cost; the gateway’s decision log was the only witness.