ブログに戻るAI Implementation

The Benchmark Illusion: Why Top-Scoring AI Agents Only Succeed 30–40% of the Time on Real Enterprise Work

公開日 2026年9月22日9 分で読了

On public leaderboards, the top AI agents post ever-more-impressive scores. Plug one into your own private systems, though, and the success rate often collapses to somewhere between 30% and 40%. This piece uses three primary benchmarks from this week — a 38.8% pass@1 on real private enterprise code, a consistency gap that drops success from 77.4% to 53.0%, and a 73.4% failure rate on long tasks — to break down the three layers of the "dazzling demo, broken deployment" gap, and to explain why supplying private context, not chasing a higher leaderboard score, is the real lever for getting agents into production.

TL;DR: The strongest frontier AI agents resolve only about 38.8% of tasks (pass@1) on real, private enterprise codebases. Put differently: an agent that tops the public leaderboards will, once it meets your own systems, data, and business rules, get roughly six out of ten jobs wrong. The gap comes from three layers — missing private context (it doesn't know your internal systems or your conventions), inconsistency (running the same task twice doesn't guarantee the same result), and long-horizon failure (the more steps in the chain, the more likely it breaks). Public benchmark scores measure general capability; they are not your business score. What actually determines production success is whether the private context has been supplied. Below, we quantify all three gaps with three primary benchmarks from this week — and lay out what enterprises should do about them.

This is the data companion to Why Enterprise AI Agents Fail in Production: that piece explains why agents break; this one uses benchmark numbers to answer how badly, where exactly the gap lives, and how to close it.

Do public benchmark scores reflect your real success rate?

No — and the gap is wider than most teams assume.

The crux is where the benchmark tasks come from. Most of the headline scores you've seen are drawn from public, open-source repositories. The Real-SWE Benchmark from Specific Labs deliberately changes that framing: every task is sourced from private production codebases licensed from real companies — changes to billing, tax filing, customer migrations, the kind of work where getting a step wrong has business consequences. Under that far more realistic bar, the top performer, Claude Code, lands at just 38.8% pass@1 (averaged over 8 independent runs per task), followed by GPT-6 Astra at 33.8%, Gemini CLI at 31.2%, GLM 5.3 + Claude Code at 28.8%, and Kimi K3 at 18.8%.

In other words, even today's most capable frontier agents solve fewer than four in ten tasks on real private enterprise code. The "nearly production-ready" story you read on a leaderboard and the success rate you'll actually observe after deployment are simply not the same number.

Dimension What the public leaderboard implies Your real private enterprise reality
Task source Public open-source issues (self-contained, clean boundaries) Licensed private production code (billing, tax, migrations — real consequences)
Best-agent success rate A high-score "almost usable" narrative ~38.8% pass@1 (Real-SWE top performer)
Where it fails Short, snappy demo-style tasks Long tasks (cross-system, multi-step, long chains)
Evaluation basis Single-shot / first-pass counts as success 8 runs averaged per task — and consistency matters too

This table is the spine of the article: the next three questions map onto the "evaluation basis" and "where it fails" columns and the mechanisms behind them.

Why does it dazzle in a demo but only work half the time in practice?

Because "can do it once" and "does it every time" are two different things — separated by a consistency gap.

IBM Research quantifies this precisely in a Hugging Face write-up, Your Agent Aced the Task. Will It Do It Again?. A ReAct agent built on GPT-4.1 posts an average success rate of 77.4% on the AppWorld benchmark — respectable on paper. But require that same task to succeed five times in a row, and the pass rate collapses to 53.0% — a 24.4-percentage-point consistency gap, widening to 30 points on the harder tasks. And because "most benchmarks only report the first number," the demo shows you the 77.4% face while production hands you the 53.0% one.

That is exactly the "great demo, disappointing rollout" experience: a demo is one carefully chosen success, while production is the same action repeated over and over. IBM puts it bluntly — "reconciling a financial transaction or checking a contract for an obligation… that can be a showstopper." In work with real consequences, one failure in five isn't a rounding error; it's a production incident.

Are long-horizon tasks where agents actually break down?

Yes. The longer the task, the more likely the agent loses the thread partway through.

The same Real-SWE data gives a blunt signal along the duration axis: short rollouts that finish within ten minutes fail comparatively rarely, while longer rollouts fail at a rate of 73.4%. Long tasks are where failure concentrates.

This matters disproportionately for enterprises, because in real operations almost all the valuable work is long-horizon: a customer data migration, a reconciliation path spanning several internal systems, a compliance change threaded through multiple approval steps — all multi-step, cross-system, long chains. The "one sentence, one step, done" tasks that shine in demos are precisely the ones agents handle best and that look least like real work. The more you push an agent onto the long chains of your actual business, the further it drifts from its leaderboard score.

After launch, how do you keep confirming the agent hasn't regressed — without burning budget?

You don't have to re-run the full benchmark on every change — adaptive, sampled evaluation holds the line at a fraction of the cost.

Going live isn't the finish line: models get swapped, prompts get edited, dependencies get upgraded, and every change can quietly erode performance. But re-running a full benchmark each time is so expensive that nobody actually does it. An arXiv study, Efficient Benchmarking in Production: A Study of an Evolving LLM Agent (2609.21267), offers a cheaper path. The subject is a production analytics agent with tens of thousands of monthly active users, studied over 574 historical runs split chronologically. The finding: a multidimensional 2PL adaptive test (IRT — item response theory, which selects questions dynamically by difficulty) delivers the best fidelity, holding evaluation error to 1.03 percentage points (MAE) while running only 200 questions — 38.5% of the full set. For deployment, the authors chose an even simpler engineering option, a difficulty-stratified fixed subset, which transfers to five other agent families with zero recalibration and stays stable even with a calibration window as short as a single day.

Beyond measuring regression, locating it has a cheaper path too. The same IBM Research method ships a Consistency Analyzer that needs only one recorded execution trace and no ground-truth labels to pinpoint the fragile decision points — the ones that are a single sampling step away from going the other way — and then generates guidelines that cut the consistency gap from 24.4pp to 12.0pp (a 16.0pp lift in same-task Pass⁵) with no drop in average accuracy.

Put the two together and the principle is simple: continuous re-evaluation doesn't have to be expensive, but it does have to be continuous. Low-cost sampled evaluation holds the line against regression; trace analysis tells you where the regression lives. That loop is the infrastructure that keeps an agent trustworthy in production over time.

So how do enterprises actually close the 60% gap?

The answer isn't "switch to a model with a higher leaderboard score" — it's "supply the private context it's missing."

Look back at the three sets of numbers. Real-SWE drives the success rate down to 38.8% precisely because the tasks come from private production codebases the agent has never seen. IBM stresses financial reconciliation and contract review as showstoppers precisely because those scenarios hinge on business rules that are uniquely yours. Both point to the same conclusion: leaderboard scores measure general capability; your business score depends on private context — how your internal systems are called, what your data contracts look like, where the boundaries of your business rules sit, which edge cases are simply off-limits. None of that is in any public benchmark, and no public benchmark can supply it for you.

Supplying that private context is the core value of a Forward Deployed Engineer (FDE). An FDE doesn't hand you a generic agent and walk away; they embed in your real environment and inject private context into the model's capability, layer by layer:

  1. Contextualize the requirement — translate a fuzzy business goal into a task the agent can execute, with its boundary conditions made explicit.
  2. Build a private eval set — establish a baseline from your own real tasks (not public problems), so the "business score" becomes measurable.
  3. Close the re-evaluation loop — use the low-cost sampled evaluation and trace analysis from the previous section to keep performance from decaying as things change.

This is why at 6AM TECH we treat production outcome, not leaderboard rank, as the delivery standard: the public score is the starting line, but private context is the moat. If you want to know how far your own scenario sits from "usable," start with a free AI implementation diagnosis — we'll help you locate whether your gap lives in private context, consistency, or long-horizon tasks. And for the deeper why behind production failures, read the companion piece, Why Enterprise AI Agents Fail in Production.


Sources: Real-SWE Benchmark / Specific Labs, IBM Research @ Hugging Face, arXiv 2609.21267.

関連記事

6AM TECH6AM TECH

エンタープライズAI導入サービス。FDEが常駐し、AIを貴社の業務に根づかせ、コストを抑え競争に勝つ。

sales@sixamtech.ai

オフィス

  • 海南
  • 上海
  • 香港
  • シアトル
  • パロアルト
  • 東京

© 2026 6AM TECH · AI-Native Precision · 無断転載を禁じます