EU Agentic AI Adoption: What OpenAI's Metrics Show

EU agentic AI adoption is expanding: OpenAI’s October 14 report says Codex and ChatGPT Work now produce over half the output tokens in its EU sample.

For business owners comparing their own teams, our practical reading distinguishes how much output agents generate, how many people use them, and what work actually gets completed.

EU agentic AI adoption: token share is not user reach

The official EU report reports more than eightfold growth in SMB weekly active users since May. Its SMB definition is at most 200 associated users, not employees. The firm-intensity comparison includes ChatGPT Enterprise and Business accounts.

Our first example is hypothetical, not a reconstruction of the report’s data. Imagine a team with 50 active users. Five use agents extensively and each generates 100,000 output tokens. The other 45 each generate 1,000 tokens through chat. Agentic output is 500,000 tokens out of 545,000: about 92 percent. The five heavy agent users are only 10 percent of the active users.

These two percentages answer different questions. The first describes where the output volume comes from. The second describes how widely that particular behavior has spread through the team. A manager who reads the larger percentage as broad employee adoption might overlook 45 people whose usage remains light. Conversely, a small group can be responsible for substantial delegated work without making agent use universal.

For an internal comparison, our recommendation is to display the token numerator and denominator beside the active-user count. In the example, changing one heavy user’s task to produce longer responses could raise token share even if nobody new adopted an agent. Adding 10 occasional users could increase reach while reducing tokens per active user. Neither change is inherently contradictory; the two measures describe different movement.

The text token counter can help estimate the size of a particular text sample. It does not identify unique users, classify a company’s adoption, or prove that generated output was useful. Those questions require the team’s own usage and task records.

Weekly active users need a stable counting rule

Our second hypothetical example concerns a recurring weekly summary. Suppose the first recorded week has eight active users and a later week has 65. That is a little over eight times the original count. Without the original count, a growth multiple cannot tell a reader whether the team expanded from a small base or reached most of the organization.

For this example, define active as having at least one qualifying agent request during the reporting week. This is our illustrative counting rule, not OpenAI’s disclosed definition. Apply it consistently across both weeks. If the later count starts including ordinary chat requests while the earlier count includes only agent requests, the comparison changes its meaning even though the arithmetic is correct.

Count a person once when that person uses both products in the same week. Otherwise, a switch from one product to two could be mistaken for an additional user. Keep the calendar boundary consistent as well: a request just before midnight and one just after it can belong to different reporting periods without representing two different people.

A useful internal note would therefore record the week, the included products, the qualifying activity, and the distinct-user rule. It would also name any change to those fields. If a reporting-system migration prevents applying the same rule to an earlier week, present a break in the series rather than a seamless growth line.

For a practical illustration of the difference between participation and work, consider an operations team generating meeting follow-ups. A person can count as active after one request; the organization may still need to review whether the resulting actions have owners and usable deadlines. Activity counts answer who engaged. A separate acceptance record answers what the team could act on.

Firm intensity needs an outcome beside it

The EU report defines frontier firms as the top tenth by output tokens per active user. In September, EU frontier intensity exceeded typical EU firms by more than fourfold.

Our third hypothetical comparison holds the user count constant. Two teams each have 10 active users and handle 100 similar requests. One generates 1 million output tokens; the other generates 4 million. Output per active user differs fourfold. That arithmetic alone cannot establish which team delivered better results or spent less time on review.

The higher total could reflect a more demanding task: inspecting a longer record and comparing several proposed answers. It could also reflect repeated work after unusable drafts. These are different explanations for the same intensity ratio. Inspecting accepted results and retry reasons helps distinguish them without assuming that every additional token is either progress or waste.

For the comparison, our suggested task record links each request to its final accepted artifact. Mark rejected or superseded attempts separately so a repeated draft does not become another completed request. If both teams finish 90 acceptable results, a fourfold token difference does not become a fourfold completion difference. If their task difficulty differs, review comparable request types rather than averaging unlike work together.

OpenAI’s earlier Enterprise Signals explanation, updated August 12, calls tokens an imperfect measure of business value. That older global report is supporting context, not the current EU sample or a source for extending this release’s time series.

Keep the benchmark’s population attached to the number

An internal team comparison needs a population boundary as much as a calculation. Our proposed benchmark note identifies the accounts included, the products counted, the observation period, and the excluded work. Put those fields beside the result instead of leaving them in a separate presentation that the next reader may never see.

For example, compare an agent-heavy engineering group with an account covering many occasional users. A difference in average tokens per active user may come partly from who is included. Before deciding the second group is behind, separate the teams or compare similar task categories. The organization can then distinguish a change in its user mix from a change in how a particular workflow uses agents.

The site’s source-backed research brief offers a reusable way to retain a claim, its supporting evidence, and unresolved questions. For this report, a useful brief would keep the published usage metric separate from a team’s own outcome measurement. It would not fill a missing sample size with a number from an earlier study.

This news also differs from the SBDC small-business training pilot: that earlier event concerned a training initiative, while this release presents usage research. For a team reading the new figures, the immediate task is to choose the comparison it actually needs—reach, output intensity, or accepted work—and collect the corresponding denominator.