For years, we measured AI adoption by counting people.

How many employees had a license? How many opened the tool each week? How many prompts did they send? How many seats could we roll out next quarter?

Then I saw a chart that made those questions feel dated.

According to A16Z’s visualization of OpenRouter data, agentic systems consumed roughly 7.3 trillion tokens on a seven-day average by August 7, 2026. Direct human usage sat closer to 1.4 to 1.5 trillion. Agentic usage had grown about 14 times since February and crossed human usage around February 6.

That does not mean agents have replaced people. It does not mean five times as much useful work happened. And it definitely does not mean OpenRouter represents the entire AI market.

But it does reveal a change in the shape of demand.

The biggest customer of AI is becoming AI itself.

That sounds circular until you look at what an agent actually does on a Tuesday morning.

A person asks for an outcome. The agent loads context, makes a plan, searches files, calls tools, reads the results, notices a gap, tries again, hands one part to another agent, checks the work, revises it, and packages the answer. The human may type two sentences. The system may process millions of tokens before it returns something useful.

Tokens are no longer just words exchanged with a chatbot. They are fuel consumed by machine labor.

And that changes the economics of software.

A prompt is not the unit of work anymore

The chatbot era trained us to think in turns.

You ask a question. The model answers. You ask another. The model answers again.

That interaction makes token usage feel like a communication cost. Longer prompt, longer answer, bigger bill.

Agents break that mental model because most of their work happens between the request and the result.

I have seen this directly while building agent and knowledge systems. The visible interaction is often the smallest part. The expensive part sits underneath it: retrieving the right context, deciding which capability to use, coordinating work, validating the output, and preserving what matters for the next run.

One human request can trigger an entire chain of machine activity.

Think of the difference between calling a contractor and hiring a crew. A chatbot hands you advice from the front porch. An agent walks into the job site, checks the plans, gathers materials, coordinates specialists, inspects the work, and comes back when it has something ready for approval.

The crew consumes more resources than the conversation. Of course it does.

The mistake is treating that consumption as the result.

More tokens do not mean more value

The chart is powerful, but it is easy to overread.

OpenRouter measures activity routed through its own platform. It does not cover every model provider, enterprise deployment, or private inference environment. Its classifications also describe traffic patterns on that platform, not a clean census of every human and agent using AI.

And token volume alone cannot tell us:

How many people initiated the work
How many requests the systems handled
How much the work cost
Whether a human accepted the output
Whether the output created any value

An agent that burns 10 million tokens and completes the task may be useful. An agent that burns 10 million tokens while looping through the same failed browser action is an expensive screensaver.

This is where a lot of AI reporting gets sloppy. We take a measure of activity and quietly turn it into a measure of progress.

They are not the same.

Companies made this mistake with software adoption, too. A seat looked like usage. Usage looked like value. Then renewal season arrived and everyone discovered that 2,000 provisioned accounts did not mean 2,000 people had changed how they worked.

Agents make that mistake more expensive because they can generate activity without waiting for another human prompt.

The metric has to move up the stack.

Measure cost per accepted outcome

I think the right operating metric is not cost per token. It is cost per accepted outcome.

An accepted outcome is work that clears the standard required for the job. A report a manager uses. A support case resolved correctly. A contract review approved by counsel. A campaign brief that reaches production. A research package that survives fact-checking.

The word “accepted” matters because completion is easy to fake.

An agent can mark a task complete because it created a file. That does not mean the file was accurate, useful, or safe. The system needs a clear definition of done and a way to test against it.

For any meaningful agent workflow, I would track five things:

1. Completion rate: Did the agent reach the defined end state?

2. Acceptance rate: Did the human or downstream system approve the work?

3. Total cost: What did models, tools, infrastructure, and review consume?

4. Cycle time: How long did the outcome take from request to acceptance?

5. Intervention rate: How often did a human have to rescue the process?

Now token usage has context.

If one workflow uses twice the tokens but produces four times as many accepted outcomes, the higher token count may be a bargain. If another model cuts token cost by 40 percent but doubles human review time, the savings may disappear.

This is basic operational thinking. But the industry still talks about tokens the way early cloud buyers talked about server prices. The input cost is easy to compare, so we pretend it is the business result.

It isn’t.

Architecture becomes financial control

Once agents become the largest consumers, technical architecture stops being an engineering detail.

It becomes a margin decision.

Take context. An agent needs enough information to act well, but loading every document into every run creates an enormous tax. The system has to retrieve the right context at the right moment, then discard what it no longer needs.

The same logic applies to models. Not every step needs the smartest and most expensive model. Classification, extraction, planning, research, synthesis, and review have different requirements. Routing each job to the right model can change the cost of the whole system without changing the experience the user sees.

Then add caching, compact skills, structured tool outputs, retry limits, and stop conditions. None of these features will make a great keynote slide. All of them matter when an agent runs the same workflow 50,000 times.

This is the part of agent design that deserves more executive attention. The demo shows whether the agent can perform the task once. The architecture determines whether the company can afford to let it perform the task every day.

The questions that become practical:

Are we sending the entire history back through the model on every step?
Which tasks require premium reasoning, and which do not?
When does the agent retry, escalate, or stop?
Can we trace cost to a workflow and an accepted result?
Who owns the budget when one agent calls three more?

Those are not token questions. They are system questions.

Pricing will have to follow the work

Agent consumption also puts pressure on seat-based software pricing.

A seat assumes a person is the active user. The vendor estimates how often that person will log in, spreads the cost across the customer base, and charges for access.

But what is a seat worth when one person supervises 20 agents? What happens when those agents work through the night, use five models, call ten tools, and generate more activity than an entire department?

Vendors have a few options. They can charge for consumption, charge for completed work, bundle usage into tiers, or combine a platform fee with outcome-based pricing. Each approach carries risk.

Pure consumption pricing punishes efficient use and makes budgets unpredictable. Pure outcome pricing creates arguments over what counts as an outcome. Flat subscriptions work until a small number of heavy agent users destroy the economics.

The market will probably settle on hybrids.

But buyers should insist on one thing now: the pricing unit needs a clear relationship to value. Paying for an agent to think is not the same as paying for it to finish.

The hidden risk is autonomous waste

Humans have natural brakes. We get tired. We go to lunch. We decide a task is not worth another hour.

Agents need those brakes designed into the system.

Without limits, an agent can retry a broken action, reload bloated context, call another agent that repeats the same research, or continue polishing work that already meets the standard. Every loop consumes tokens. Some loops can also send messages, alter records, make purchases, or create other consequences.

So governance cannot begin after deployment.

Every production agent needs a budget, a stopping rule, an escalation path, an audit trail, and a clear owner. Higher-risk actions need approval gates. Repeated failure needs to trigger a halt, not more optimism.

This is not bureaucracy for its own sake. It is how you give a machine room to work without giving it room to wander.

Build for machine demand, manage for human value

The A16Z chart will keep moving. Token prices will fall. Models will get faster. Agents will run longer workflows and coordinate with more agents. Machine-generated demand will grow even if the number of human users grows slowly.

That is the important signal.

We are moving from a world where people consume intelligence one answer at a time to one where systems consume intelligence continuously in pursuit of work.

The winners will not be the companies that buy the most tokens. They will be the ones that build the clearest connection between machine activity and a result someone values.

So open one agent workflow this week. Pick something already running in your business. Measure the tokens, model cost, tool cost, review time, retries, and final acceptance.

Then divide the total by the number of outcomes people actually kept.

That number will tell you more about your AI strategy than any seat count ever will.

Source note

The chart shown above was produced by A16Z using OpenRouter rankings data. It reports seven-day average token usage by type and identifies agentic, human, and mixed traffic. OpenRouter reflects activity on its platform, not the entire AI market. Token volume does not directly measure users, requests, revenue, productivity, or successful outcomes. Review OpenRouter’s current methodology and rankings at openrouter.ai/rankings: https://openrouter.ai/rankings?benchmark=intelligence.

GTM AI Podcast & Newsletter

AI’s Biggest Customer Is Becoming AI