AI & Machine Learning

Agent Governance: Why Nobody Owns Agent Behavior

94% of teams have agent observability in place, yet only 12% say they can actually govern their agents — the gap isn't a tooling problem, it's an unassigned architectural responsibility.

Share this article
Comments
Share:
94% of teams have agent observability in place, yet only 12% say they can actually govern their agents — the gap isn't a tooling problem, it's an unassigned architectural responsibility.
Table of Contents

You rolled out agent observability months ago. Traces flow through Langfuse or Braintrust, your security team has a runtime policy layer watching for shadow agents, and the dashboards are green. Then an agent approves a refund it would have denied ninety seconds earlier for an identical request, or executes three steps of a five-step workflow, writes a partial state downstream, and exits with a clean success code. No error. No latency spike. No stack trace. Just a wrong outcome that nobody was watching for, because nobody on either team owned that question.

This is the architectural blind spot that a lot of production agent deployments are running into right now, and it’s not a tooling gap. A LangChain survey of 1,300+ practitioners found 94% of teams running agents in production have implemented some form of observability — yet 32% still name quality as the thing blocking them from shipping further. An OutSystems survey of 1,900 IT leaders found the gap in sharper relief: 96% of enterprises have agents in production, and only 12% say they can actually govern them. An 84-point spread between “we deployed it” and “we can govern it” is not something a better dashboard fixes. It’s evidence that the responsibility for judging whether an agent’s decision was correct was never assigned to anyone, on either the engineering or the security side of the org chart.

Observability Records What Happened, Not Whether It Was Right

Traditional application monitoring assumes a binary: the request succeeded or it threw an error. Agents break that assumption completely. An agent can call the right tool with the wrong argument, resolve a support ticket by taking an action it shouldn’t have been authorized to take, or make an inconsistent decision on functionally identical inputs — and every one of those failures produces a clean trace, a 200 status, and zero alerts. The system did exactly what it was told to do at the API level. Whether it did the right thing is a separate question that most observability stacks were never built to answer.

This matters more than it sounds, because the industry has spent two years optimizing for the wrong failure mode. An analysis of 10,000+ enterprise AI failure events across ten-plus industries found hallucination accounts for under 10% of production incidents. The largest categories are resolution and escalation failures, decision failures, and execution and workflow failures — the ones that don’t produce an error signal. Enterprises built extensive tooling for the minority case (the model said something false) and shipped the majority case (the agent did something inconsistent, unauthorized, or incomplete) into production essentially unmonitored.

Four Markets, One Search Term, No Shared Owner

Part of why this gap persists is that “AI observability” isn’t one market — it’s four, each selling to a different buyer, each solving a different failure mode, and none of them overlapping enough to close the gap between them.

Infrastructure telemetry (Datadog, Chronosphere, Dynatrace) answers “where in the stack did this break” and sells to engineering and platform teams — this segment posted the strongest revenue growth of the four, with Datadog alone reporting $1.12B in Q2 2026 revenue, up 36% year over year. The developer inner loop (Langfuse, LangSmith, Braintrust, Opik) traces agent runs, scores outputs, and gates CI releases for AI/ML engineering teams — Opik alone processes 40M+ traces daily across 150,000+ developers. Runtime behavioral assurance (Zenity, Noma, WitnessAI, Cisco AI Defense, Palo Alto’s Prisma AIRS) sells to security and the CISO’s office, discovering shadow agents and producing audit evidence. Autonomous remediation (Resolve.ai, Traversal, Cleric) treats observability data as input to an agent that fixes production itself, and it’s attracting serious capital — Resolve.ai raised $125M at a $1B valuation months out of stealth.

Fourteen months of acquisitions confirm the split rather than closing it. Weights & Biases went to CoreWeave for roughly $1.7B. Statsig went to OpenAI for $1.1B. Langfuse went to ClickHouse. Palo Alto Networks alone has committed north of $3.35B across Chronosphere, Portkey, and Protect AI, and now reports its observability business has crossed $300M ARR. Three distinct theses are being funded with real money: foundation labs buying the evaluation layer, infrastructure vendors buying the application layer, and security platforms buying everything that touches agent traffic. None of the three is buying the layer that sits between engineering’s trace data and security’s policy enforcement — the layer that would actually answer “was this outcome correct and consistent given the input and the policy.”

The Ownership Vacuum Is the Architecture Problem

If your engineering team owns Langfuse or Braintrust and your security team owns Zenity or Prisma AIRS, you likely already have both halves of visibility and neither half of accountability. The engineering platform sees trajectories — the full sequence of tool calls, intermediate states, and outputs — but has no mechanism to enforce a decision it deems wrong. The security platform sees traffic and policy violations, but can’t reason about whether a permitted action was the correct action given the business context. Between those two systems sits the actual production risk, and right now it belongs to whichever team happens to notice the incident first, which in practice means it belongs to no one until something breaks visibly enough to force a postmortem.

This has a direct precedent in customer identity architecture. Product teams built login flows because they needed signup. Security teams bought workforce IAM because they needed to control employee access. Both were funded, both were correct in isolation, and for years nobody owned the customer-facing identity surface — which is exactly where the breaches happened. That vacuum didn’t close because someone shipped a better login box. It closed when CIAM (customer identity and access management) got named as a distinct problem with a distinct budget line, separate from workforce IAM and separate from application code. Agent behavior ownership is at the same pre-naming stage today: the tooling exists on both sides of the gap, but the job title, the budget line, and the accountability structure don’t exist yet. Gartner’s “guardian agents” framing and vendor attempts to brand this “runtime control” are early signs the category is being named — but a category with an analyst term and no organizational consensus is still a gap on your org chart.

Architecture Impact

What changes in system design? Agent architectures need an explicit decision-correctness layer that sits between the trace/eval pipeline and the policy-enforcement gateway — neither can be assumed to cover it. This typically means adding a review or scoring stage that evaluates agent decisions against business context and historical consistency, not just tool-call validity or policy compliance, and routing ambiguous or high-stakes decisions through this layer before they execute irreversibly.

What new failure mode appears? “Silent inconsistency” — an agent that produces different outcomes for functionally identical inputs, with every individual outcome passing its own observability and policy checks. This is invisible to error-rate monitoring, latency SLOs, and trace-based evals because no single trace looks wrong in isolation; the failure only shows up in aggregate, across sessions, which most teams aren’t set up to compare.

What enterprise teams should evaluate:

  • Platform/ML engineering: whether your eval suite tests decision consistency across repeated or near-identical inputs, not just single-run output quality against a rubric.
  • Security/GRC: whether your runtime policy layer can flag a policy-compliant-but-inconsistent decision, or whether it only catches outright policy violations.
  • Engineering leadership: who is named as accountable when an agent makes an incorrect-but-untraceable-as-an-error decision — if the answer is a tool name instead of a person, that’s the gap.

Cost / latency / governance / reliability implications: Adding a decision-correctness review layer typically costs one additional LLM-as-judge call or a lightweight consistency-check pass per high-stakes decision, adding roughly 200–800ms of latency depending on model choice — acceptable for approval-chain and financial-action workflows, less so for high-throughput low-stakes interactions. On governance, the 84-point gap between deployment (96%) and governability (12%) found in the OutSystems survey suggests most enterprises are currently carrying unquantified regulatory and reputational exposure on every agent decision that isn’t logged as policy-relevant but turns out to matter.

Implementation Guide

Start by instrumenting to the OpenTelemetry GenAI semantic conventions even though every gen_ai.* attribute in the official registry still carries “Development” stability status as of mid-2026. It’s not stable, but it’s the only convergence path across LangGraph, CrewAI, and the OpenAI Agents SDK, and building your trace schema against it now avoids a rewrite later when it stabilizes. Don’t wait for a single vendor to promise you unified coverage across infrastructure telemetry, developer eval, runtime security, and remediation — that vendor doesn’t exist yet, and anyone selling a single pane of glass across all four segments is selling you a roadmap slide, not a shipped product. Plan on running two tools deliberately: a neutral eval platform for the engineering loop, plus either an APM tool for stack correlation or a governance layer for audit evidence, chosen based on which failure mode is costing you more right now.

The mistake most teams make first is treating this as a procurement problem — buying a fifth tool to sit in the gap — before treating it as an organizational one. Assign a named owner for agent behavior correctness before you evaluate another vendor. If the honest answer to “who is accountable when an agent makes an inconsistent decision” is a product name rather than a person or a team, no purchase closes that gap; it just adds a fifth dashboard nobody is required to check. Pull your own incident history and classify failures using the decision/interaction/workflow taxonomy referenced above instead of your default hallucination-rate metric — if your real failures cluster in decision and workflow categories the way the broader dataset shows, your current eval suite is very likely testing the wrong thing, and that mismatch is measurable in an afternoon.

You’ll know the approach is working when your postmortems start naming a specific role, not a tool, as the party that should have caught an inconsistent decision before it shipped, and when your eval suite has a passing or failing check for decision consistency across repeated inputs, not just output quality against a static rubric. A secondary signal: if a security incident review and an ML eval review of the same agent incident produce two disconnected reports that never reference each other, the ownership gap is still open regardless of how much observability tooling is installed.

Over a 6–12 month horizon, teams that get this right converge on a lightweight but explicit RACI for agent decisions: engineering owns trace quality and eval coverage, security owns policy enforcement and audit evidence, and a named product, risk, or “agent governance” owner sits over both, holding the actual decision-correctness metric and the authority to gate releases on it. That role doesn’t need a new department — it needs to exist as a real accountability line before the agent count grows past the point where any one person can eyeball the incidents. Given how much acquisition capital is currently flowing into exactly this seam between engineering observability and security telemetry, expect the vendor landscape here to consolidate fast; the organizational fix — naming an owner — is available to you now and doesn’t require waiting for that market to settle.

Sources

Enterprise AI Architecture

Want more enterprise AI architecture breakdowns?

Subscribe to SuperML.

Comments

Sign in to leave a comment

Back to Blog

Related Posts

View All Posts »