Observability, safety, and governance are necessary for production AI agents — eventually. But the industry pushes them as universal requirements from day one, ignoring the very real costs, failure modes, and trade-offs involved.

This note collects the strongest counter-arguments from practitioners and authoritative sources. It does not argue that these pillars have no value. It argues that when, how much, and whether they’re needed are decisions the default discourse skips over.

                    ┌──────────────────────────────┐
                    │  Do you need AI agent infra?  │
                    └──────────────┬───────────────┘
           ┌───────────────────────┼───────────────────────┐
           ▼                       ▼                       ▼
   ┌───────────────┐      ┌───────────────┐      ┌───────────────┐
   │ OBSERVABILITY │      │    SAFETY     │      │  GOVERNANCE   │
   └───────┬───────┘      └───────┬───────┘      └───────┬───────┘
           │                       │                       │
   ┌───────┴────────┐      ┌───────┴────────┐      ┌───────┴────────┐
   │ Cost 20-30% of │      │ False positive │      │ Policy theater │
   │ infra bill     │      │ cascade:       │      │ (Grok, NYC     │
   │ 99% data wasted│      │ 0.9⁵ = 59%     │      │ MyCity)        │
   ├────────────────┤      ├────────────────┤      ├────────────────┤
   │ Over-engineered│      │ Legal exposure │      │ 70% have       │
   │ for early-stage│      │ from reliance  │      │ policies, but  │
   │ (PostHog)      │      │ alone (IAPP)   │      │ do they work?  │
   ├────────────────┤      ├────────────────┤      ├────────────────┤
   │ Root question: │      │ Over-blocking  │      │ Premature      │
   │ Does task need │      │ → shadow AI    │      │ regulation =   │
   │ an AI agent at │      │ (Airia)        │      │ paperwork      │
   │ all?           │      ├────────────────┤      │ (Law & AI Inst)│
   │                │      │ Prompt         │      │                │
   │                │      │ injection is   │      │                │
   │                │      │ unsolved       │      │                │
   └────────────────┘      └────────────────┘      └────────────────┘
           │                       │                       │
           └───────────────────────┼───────────────────────┘
                                   ▼
                    ┌──────────────────────────────┐
                    │  The Multiplicative Problem  │
                    │  Pillars compound, not add   │
                    │  More infra ≠ safer system   │
                    └──────────────────────────────┘

Observability

It costs 20–30% of your infrastructure bill

Observability spend typically ranges from 20–30% of total infrastructure cost, per Honeycomb’s Charity Majors. Agent-based collectors consume CPU and memory on the same nodes as your workloads — reducing resource efficiency to measure resource efficiency. Worse: approximately 1% of collected observability data is ever queried. You pay to store the other 99% just in case.

Sources: DevOps.com, Honeycomb, Charity Majors

It’s wildly over-engineered for early-stage AI products

PostHog’s guide on minimum viable AI observability (June 2026) explicitly argues that full LLM observability tooling is “wildly over-engineered if you just shipped your first AI feature on a Tuesday.” For small teams and solo builders, you need only three things on day one: trace every LLM call, track costs, and capture errors. Everything else — eval suites, prompt A/B testing, drift detection, governance dashboards, red-teaming pipelines — should be deferred until the product earns it.

Source: PostHog — Minimum viable AI observability

The deeper question: does the task need an AI agent at all?

If the input is structured and the outcome is binary (patching, provisioning, status checks), deterministic automation costs zero dollars and runs in milliseconds. Adding an LLM agent to such a task creates a cost chain: the agent itself, then observability to debug it, then safety to constrain it, then governance to audit it — all for a problem that 50 lines of Ansible already solved.

The “95% Problem”: an agent that’s 95% accurate still requires human babysitting for the remaining 5%. The “unreliability tax” — token costs, prompt engineering, API latency, monitoring overhead — can make the agent approach more expensive and less reliable than the deterministic alternative.

Source: Quinn Johns — Over-engineering with AI Agents: The Unreliability Tax

Safety

The false positive cascade destroys user experience

Five guardrails in sequence (toxicity → prompt injection → PII → hallucination → compliance), each independently well-tuned at 90% accuracy:

0.9⁵ = 0.59 — only 59% of legitimate requests pass through.

At 100,000 requests per day, 41,000 users submit a normal query and get blocked because one guardrail misfired. Every individual dashboard is green. No single detector looks broken. But the compound effect destroys adoption, and nobody monitoring component-level metrics can see it.

Improving each guardrail from 90% to 95% sounds modest, but the last 5% of accuracy per guardrail — the hard, ambiguous edge cases — can consume more annotation budget than the entire initial deployment. And even then: 0.95⁵ = 0.77, still blocking 23% of legitimate traffic.

Source: The multiplication math is from Pratik Bhavsar’s analysis of guardrail compounding (LinkedIn)

The IAPP’s April 2026 analysis warns that organizations relying solely on guardrails are “exposing themselves to significant liability.” Guardrails catch known patterns. They miss context-dependent violations, novel attacks, and adversarial inputs designed to bypass them. Deploying guardrails signals awareness of risk without necessarily reducing it — a legally worse position than not deploying them at all if you haven’t also built the organizational processes to handle what guardrails miss.

Source: IAPP — AI guardrails are not enough

Over-blocking drives shadow AI

Guardrails that block without explanation erode user trust. Users learn to rephrase until they bypass — worse, they route around the guardrailed system entirely and use ungoverned external AI tools. The net effect can be reduced safety: the guardrailed system has fewer users but the organization’s AI risk hasn’t decreased, it has just moved to unmonitored channels.

Source: Airia — What Guardrails Can and Cannot Do

Prompt injection has no perfect defense

OWASP ranks prompt injection as LLM01. Every major vendor — Anthropic, OpenAI, Microsoft — acknowledges no deterministic solution exists. If the foundational threat vector cannot be closed, the entire runtime safety layer operates on probabilistic best-effort. Safety becomes a cost center that reduces but never eliminates risk.

Governance

Policy theater: frameworks that don’t govern

Many organizations build AI governance frameworks that are comprehensive on paper and ineffective in practice. Jones Walker’s analysis cites two case studies:

  • Grok (xAI): Had AI safety policies and review processes. Engineers removed one prompt instruction instructing the system to “deeply research and form your own conclusions.” The result: Holocaust denial and detailed instructions on violence. Governance existed, but didn’t govern.
  • NYC MyCity chatbot: An official government AI advised users to break New York labor law (illegal tip deductions) and housing law (discrimination based on income source). Despite mandated oversight for a government service.

The gap between governance intent and operational reality is “one of the most pressing challenges facing organizations deploying AI today.”

Source: Jones Walker — Building Governance That Actually Works

70% have policies, but do they reduce risk?

A 2026 Cyber Security Tribe report found 70% of organizations have AI policies in place. The harder question is whether these policies materially reduce risk or merely signal acknowledgment. Experts distinguish governance that shapes behavior — embedded in workflows, access controls, approved tools, data handling — from governance that remains “static, symbolic, and difficult to enforce.”

Source: Cyber Security Tribe — What Separates Real AI Governance From Policy Theater

Premature regulation creates paperwork without improving outcomes

The Institute for Law & AI proposes “automatability triggers” — regulations that become effective only when tooling exists to automate compliance. Without this, governance becomes a manual paperwork exercise that consumes resources without necessarily making AI systems safer. The argument is not against regulation itself, but against regulation that outpaces the tooling needed to comply with it efficiently.

Source: Institute for Law & AI — Automated Compliance and the Regulation of AI

EU AI Act: abstract tiers, moving target

The four-tier risk classification is conceptually clean but operationally vague. Specific technical standards for high-risk systems remain in draft. The “AI Omnibus” political agreement (May 2026) pushed high-risk enforcement to December 2027 / August 2028. Organizations building governance frameworks today are targeting standards that do not yet exist in final form.

The Multiplicative Problem

These pillars interact multiplicatively, not additively. Each guardrail added to the safety layer compounds the false positive cascade. Each governance requirement adds process overhead to every observability-driven investigation. A system with all three pillars can be worse — more expensive, less usable, and no safer — than a system with none, if each pillar is implemented as theater rather than operational control.

The argument is not against observability, safety, and governance. It is against deploying them as universal defaults without asking:

  1. Does this task need an AI agent at all? If deterministic automation suffices, the entire infrastructure stack is unnecessary.
  2. Is this system interacting with real users and real data, at scale? If it’s an internal prototype with controlled inputs, full production infrastructure is premature.
  3. Is each pillar solving a measured problem, or being deployed because “best practice” says so? Infrastructure that doesn’t address a specific, observed failure mode is overhead.

When these questions have clear answers — yes, the system warrants AI; yes, it touches real users; yes, specific failures have occurred — then observability, safety, and governance stop being overhead and start being the engineering foundation the companion overview describes.