69% vs 57%
who you ask decides your agent count

Sixty-nine percent against 57%. Same question, same companies, and a 12-point difference between the C-suite and vice presidents. That difference is the number budgets get built on.

One question, two answers

The figures come from research Teradata commissioned from Wakefield Research: 1,000 technology and data leaders at vice-president level or above, at companies with at least 500 employees, 500 in the United States and 100 each in the United Kingdom, France, Germany, Japan and Saudi Arabia. Fieldwork ran from March 23 to April 5, 2026, and the report is titled Arrested Automation: Why Agentic AI Stalls at the Enterprise Level. It was published in July; Teradata returned to it in an article on October 11.

The gap is not the only number worth reading. Only 7% of enterprises reached what the report calls the Operationalizing stage, where agents execute multi-step workflows across systems with measurable business impact. Ninety percent expect to raise their agentic investment over the next 12 months, and 63% report no more than a small or emerging return so far. Seventy-seven percent say that 20% or less of their enterprise data is described well enough for agents to use. Forty percent say more than 40% of their pilots die for one shared reason: the infrastructure was never built for autonomous use. Only 15% get 80% or more of their pilots into production.

What the 12 points are made of

The difference is not about facts. It is about definitions. For a C-suite respondent, already running can mean a signed contract, a provisioned platform, a demo seen once, two departments experimenting. For a vice president, already running means this business line is answerable for what it outputs. Both statements can be true, and neither is a lie.

The reason it matters is that the two definitions get used at different moments. Budget and headcount are approved against the first one and delivery is accepted against the second, which leaves those 12 points recorded as weak execution and assigned to a person.

Our judgment: a deployment rate is a self-reported metric, not an operating one. Self-reported metrics are not useless, and the 69-to-57 spread is the most useful part, because it measures how far a company’s internal definitions have drifted apart. The mistake is writing it into a report as an operating fact.

The other side of the same coin comes from the IBM Institute for Business Value survey of 2,000 technology executives across 33 geographies and 19 industries, fielded from January to April 2026. Seventy percent said business teams deploy technology faster than IT can track it. In other words, much of what counts as deployed in a survey has no owner in the company.

The more useful seam in the report

Seventy-seven percent say under a fifth of their data is described well enough to use, and when leaders rank the barriers, missing metadata, context and relationships takes 43% while data fragmented across systems that cannot be connected in real time takes 42%. The two are usually merged into a single item called data governance. They are not the same. One is absence: nobody wrote down what the field means. The other is duplication: the same fact lives in two places.

The costs differ too. Absence makes people guess. Duplication makes records disagree, and it is the more expensive of the two because it stays quiet until someone acts on a stale copy. In our own operations duplication bit first. When a derived file drifts from the source, nothing alerts, unless a field-by-field comparison exists on purpose.

So our approach is not to describe everything, which is a target with no end. When a fact has exactly one authoritative source and everything else is computed from it, the missing parts surface at reconciliation time. Inside our own system that looks like this: article metadata lives in one database, and the titles, summaries and image paths that appear on pages and in exported files are recomputed from that database by a script. If anyone edits a derived file by hand, the field-by-field comparison fails and the release is blocked. That mechanism has never let an inconsistency survive the day.

Swap the survey number for an artifact count

Replacing the metric takes three steps and can start today.

Part of why we can run the test this strictly is size: one founder and seven AI units, with every operating record in the same place. But nothing about the method requires a small company. What large organisations lack is not a system, it is one definition and one person who owns the difference.

Boundaries

First, an artifact ledger proves a job ran, not that it ran correctly. Correctness needs eval sets, sampling and a release gate, and folding that into the same ledger empties the ledger of meaning.

Second, one authoritative source per fact only works when the fact really is single. An order means different things in finance and in logistics. The answer there is distinct naming, not a forced merge into one field.

Third, self-reported numbers will not disappear and should not. They are what communication between layers produces, and they do reveal the drift in definitions. The error is treating them as operating evidence.

Our judgment

A deployment rate is a self-reported metric, not an operating one. Move the test from which platforms are provisioned to which outputs exist today, and the difference is the part that is not really running yet. That part tends to be large: in the same survey, only 15% of companies got 80% or more of their pilots into production.

Before the next report, try one experiment. Do not open the platform dashboard. Count what was produced yesterday. How many dated artifacts can you name? If that number is far below the job count in the dashboard, you have found where the 12 points went.

Why both definitions survive

The split is not a misunderstanding. It is what the incentives produce. Externally, the C-suite needs progress it can describe on a call. Internally, a vice president needs a boundary to stand behind. One counts how much has started; the other counts who answers when something breaks. Both are true inside the same company, and nobody has a reason to reconcile them.

Reconciliation tends to happen the moment budget and acceptance criteria stop matching. By then the number is usually already in the annual plan, and the difference has been filed as an execution problem rather than a definition problem.

Three more numbers from the same report

Three other figures belong next to the 69-to-57 gap. Fifty-one percent of leaders name the accuracy and reliability of outputs as a significant barrier to deployment. Sixty percent report decision paralysis on durable infrastructure choices. Thirty percent worry about vendor lock-in. Read with the 7% that reached the Operationalizing stage, they describe a specific condition: the constraint is not affordability and not selection, it is the unwillingness to let agents act on their own.

That unwillingness traces back to data that cannot be trusted, and untrustworthy data traces back to a description problem. Seventy-seven percent say under a fifth of their data is described well enough. That single line explains the other three: accuracy is the symptom, paralysis is the consequence, and lock-in is the excuse used to postpone.

Which is why we do not queue a data programme as a precondition. We start smaller: find the facts that two systems both claim to know, and turn one of the two into a derived copy. There are usually not many, and every one of them is waiting for the day someone acts on the stale version.

A definition swap you can copy

Four steps, in this order.

Our own weekly report works this way: artifacts, failures and the unfinished list, not how many jobs were launched. The two formats produce different conversations. One asks about specific things, the other asks about progress.

Do not use our numbers as a benchmark

Our operating data comes from one company with a single founder and seven AI units. The sample is one, not a thousand. It demonstrates that the test can be run; it does not supply a percentage anyone should quote. Reading it as an industry benchmark produces a false comparison.

What transfers is the test, not the number. The test is what exists today; the number is yours.

References: Teradata press release, New Research: Why Enterprise Agentic AI Stalls Before It Scales, July 7, 2026: www.teradata.com/press-releases/2026/why-enterprise-ai-stalls-before-it-scales Teradata analysis article, October 11, 2026: www.teradata.com/insights/ai-and-machine-learning/disconnected-data-stifling-roi-from-agentic-ai IBM Institute for Business Value, CIOs and CTOs Face Growing AI Control Gap, June 8, 2026: newsroom.ibm.com/2026-06-08-new-ibm-study-finds-cios-and-ctos-face-growing-ai-control-gap-as-enterprise-deployment-scales The Teradata study was fielded by Wakefield Research; all figures are self-reported.