50% of Enterprises Shipped an AI Agent That Passed Evals — Then Watched It Fail a Customer

Here's something I can't stop thinking about: half of enterprises that deploy AI agents have shipped one that passed every internal evaluation and then failed, publicly, in front of a real customer. Not in a staging environment. Not in a demo. In production, with a customer watching.

That number comes from VentureBeat's June 2026 Pulse survey of 157 enterprises with 100 or more employees. 50% confirmed they'd deployed an agent or LLM feature that cleared their eval suite and then caused a customer-facing failure. A quarter said it happened more than once.

The stat is jarring. But the reaction from those same enterprises is what should really worry you: 66% are pushing toward fully automated, zero-human-in-the-loop deployment for their agents. Only 5% say they fully trust the automated evaluations that are supposed to gate those deployments.

They know the tests don't work. They're shipping anyway.

What are these evals actually testing?

The short answer: the wrong thing.

Most evaluation pipelines check whether an agent produced the correct output for a given input. Did the refund get processed? Did the response contain the right information? Did the workflow complete?

That sounds reasonable until you think about what it misses. An agent can process a refund correctly but skip identity verification, ignore policy limits, bypass an approval step, and produce a clean output at the end. The result is right. The process is a liability. And your eval gave it a pass.

Brian Neville-O'Neill at Confident AI wrote about this exact pattern back in April. A support agent that handles refunds correctly but never checks who's asking, never verifies the refund amount against policy, never routes large sums for approval. From an output-only eval perspective, that agent is perfect. From a governance perspective, it's a disaster waiting to happen. Nobody's test asked "did this agent follow the rules?" because the test was designed to ask "did this agent produce the right answer?"

The VentureBeat data backs this up. The single most-cited limitation of automated evaluations, reported by 29% of respondents, was poor alignment with real-world outcomes. Not speed. Not cost. Not tooling maturity. The tests don't predict what happens when a customer, employee, or downstream system encounters the agent in the wild.

Why do agents break in production but not in testing?

There's a deeper problem here, and it's about sequences.

A single interaction might look fine. Over multiple steps, small decisions compound. A skipped check here. An unchecked assumption there. Suddenly the agent is doing things nobody explicitly authorised. Your eval suite never caught it because your eval suite ran the agent through clean, curated scenarios, one at a time, in controlled conditions.

Production doesn't look like that. Real users ask the wrong question. They use the wrong format. They say things the prompt wasn't designed for. They discover edge cases your test cases never anticipated. And agents, unlike traditional software, don't fail with a stack trace. They fail by doing something plausible but wrong, confidently, often without anyone noticing until the damage is done.

The VentureBeat survey found that only about a quarter of enterprises run real-time quality checks on live production traffic. The most common primary eval tools are either the model provider's native evals or, and this is the really telling bit, nothing at all. Tied at 17% each. Nearly one in five enterprises has no dedicated evaluation tooling. They are shipping agents into customer-facing roles and hoping.

What does the eval gap mean for vibe coding?

This is where the no-code and vibe-coding audience needs to pay attention.

If you build an AI agent by generating raw code, whether that's with Bolt, Lovable, Cursor, or Replit, you own every failure mode the eval gap creates. There is no platform layer between your agent and your customer. There is no runtime guardrail that says "stop, you don't have permission to access that data." There is no audit trail that shows which decision the agent made and why. There is no rollback when the agent does something catastrophic.

A vibe-coded agent that passes your tests is still a vibe-coded agent. And half the enterprise data says it'll fail a customer anyway. The New Relic State of AI Coding report for 2026 found that 82% of organisations have suffered at least one major production failure caused by AI-generated code in the past six months. That's not coincidence. It's the same gap, the same cause: code that passes tests but breaks reality.

What do governed platforms do differently?

Governed no-code platforms, the ones built with role-based permissions, data access controls, and audit logging, don't solve the eval gap. They don't make your agent smarter. They make the blast radius smaller.

Here's what that looks like in practice. On a governed platform like Stacker, an agent operates within a permission boundary. It can only access data the user who triggered it is authorised to see. It can only take actions its role permits. If it tries to do something outside its scope, the platform blocks it. Not at the agent's discretion. At the infrastructure level. Every action is logged. Every decision is traceable. You can roll back.

That changes the failure calculus. When a governed agent produces the wrong answer, you have a quality problem. When an ungoverned agent produces the wrong answer and also accessed data it shouldn't have, you have a compliance problem, a security incident, and a customer trust crisis. Same agent capability. Different infrastructure. Radically different outcome.

The eval gap means your tests will miss things. That's not a temporary problem you fix with better prompting. The VentureBeat survey makes it clear: enterprises have been trying to close this gap and it's widening, not narrowing, because the autonomy ceiling is rising faster than the assurance beneath it. 66% are engineering toward zero-human-in-the-loop deployment while only 5% trust their tests. That's not a testing problem. That's a governance problem.

The takeaway

Build your agents however you want. But put them on rails.

The eval gap is structural. It exists because agents are non-deterministic, because users are unpredictable, and because the space of possible failures is larger than any test suite can cover. Better evals will help. Better monitoring will help. But the real defence, the one that determines whether a failure is a bad review or a legal liability, is the platform your agent runs on.

A vibe-coded agent with no governance layer is a bet that your tests are better than everyone else's. The data says that bet loses half the time.