The prediction of a trillion custom agent policies being issues per year in about three and a half years may sold bold…until we see that the multipliers are already in motion and it is just a matter of getting the timing right. I’m not talking about a trillion agents sitting in a catalog. A trillion policies, each one fused with identity, preferences, context, budget, and a bounded objective, that are issued, refreshed, and retired as agents appear and disappear.
But first let’s be precise about what we are counting and then we can explore the multipliers that get us there.
For our purposes, a policy is not a PDF someone wrote in legal, and it is not a system prompt the model can edit.
It is a compiled, versioned contract for one agent run (or one revision of that run): that defines who this agent is acting for, what it may do, which tools and peers it may touch, what data it may see, what it may spend, when it must stop or check back, and which jail it is bound to. The template can be standard. The fusion is not. Identity + context + budget + tool scope + objective, stamped onto a runtime, is a custom policy by construction.
Two things that number does not count:
The trillion is a count of issued bindings, including mid-run revisions. One long agent that burns a fortune in tokens on a single binding is one policy, not a million. Token volume and policy volume are correlated. They are not the same curve.
The forecast assumes:
If those stay modest, you still get a huge market of compiled contracts. If they compound together, you get into the trillions. If “policy” only means a formally proven, signed cage in a regulated environment, the number is smaller but still large. I am counting the broader object: the fused session contract, most of it machine-issued, a growing share of it actually enforced outside the model.
The reason this is not a fantasy of infinite analyst headcount is that policy generation is becoming an automated compilation, not a human task.
Pull identity from an IdP, payment preferences from a wallet, contacts from a directory, spend history from a ledger, standing rules for that jail type, and the last run’s drift report. Fuse. Sign. Bind. That loop will get cheaper the same way TLS issuance and IAM session minting got cheaper: templates plus automation plus an audit trail. Cost per policy falls; willingness to issue, version, and retire them rises. Automation does not reduce policy count. It removes the friction that used to keep the count small.
OpenRouter’s 7-day average token usage already shows the crossover. On February 6, 2026, agentic tokens surpassed human tokens. By early August, agents were burning about 7.3 trillion tokens—a 14x increase in months, while human and mixed usage crawled upward.
Figure. Agents Are Using Far More Tokens Than People — OpenRouter rankings, via a16z Charts of the Week.
That chart is not “chat got popular.” Agents iterate. They assemble a manifest with a goal, tools, constraints, and history, and then grind.
Agentic token spend is the signal that agents are agentic tasks are expanding exponentially. As more people recognize the need for agent reliability engineering, the need for agent jails and policies becomes self-evident
Start with the people who will never open an agent builder.
A small AI model on a phone will act as a quiet chief of staff. You say you’re traveling. The on-device profile containing contacts, payment methods, timing preferences, spend envelope, kicks off a temporary orchestrator. That orchestrator does not “visit websites” in the old sense. It talks to APIs. Some of those APIs are headless. Some of them spin up their agents: an airline-side negotiator, a hotel-side availability agent, a payments agent that only sees what it is allowed to see.
Each of those sessions is an agent with a job. Each job needs a bound. The bound is a policy.
Someone will object: “United is not going to write a custom policy for Mike.” In the narrow sense, they won’t. Ingress, egress, data they can touch, and which peer agents they may call will be standard. What is not standard is the fusion: my identity, my context, my preferred card, my window, my “do not book red-eyes” rule, my budget. Standard jail + personalization = a custom policy for that run.
The phone user never named an agent. The airline never named Mike in a config file. Policies still got fused to identity and issued.
That is multiplier one: users with an unconscious orchestrator × tasks × counterparties that mint short-lived agents instead of only authorizing a call.
Multiplier two sits with the builders: coders, lawyers, writers, managers, etc.
A primary agent doesn’t do everything. It spawns task-specific, time-specific, budget-specific sub-agents. Twenty live agents is already a conservative picture for a serious operator. Each spawn is fused with a policy. When the $2 token budget is exhausted, the system doesn’t die. It alerts and an LLM-as-judge estimates remaining work, a new spend envelope is issued, and a new policy is compiled onto the same sandbox. Versioning is not an edge case. It is the operating loop.
Some of that loop never reaches a human. “Check at $2; if the increase is reasonable and under $10, continue.” That instruction is itself policy generation.
There is another refresh loop that is easy to miss: runtime evidence checked against the policy that was supposed to govern the run. Did the agent stay inside its tool set? Did spend, data access, or peer-agent calls drift from what the policy allowed? Did the declared objective and the observed behavior diverge? Those traces are not just logs. They are inputs to the next policy version. A drift finding, a near-miss, or a new constraint learned from the last session compiles into the successor policy before the next spawn. Closed-loop verification is another multiplier. Every live run can mint a revised policy. This is policy evolution based on evidence.
Look back at the OpenRouter curve. That is exponential agent adoption and exponential work-per-agent at the same time. User growth × sub-agents × cheap automatic revisions × a share of counterparties that instantiate is how you get from “hundreds of millions of orchestrators” to “a trillion policies.”
Sandboxes such as OpenShell and its forks, network-segmented runtimes, whatever isolation layer you pick, will be relatively few. You may have hundreds of variants making various tradeoffs between performance and security, not millions of unique jails. The jail is the standard box.
The policy is what makes the box this agent, this identity, this budget, this tool set, this moment.
Some operators will run without a jail and tell the model “use your best effort.” In a secure environment that is a no. For an innocuous calendar-scraper it may be tolerated. Even then a policy still exists. Policy volume will exceed jail volume. Most of the serious work will still run inside a cage.
This is also why smarter models do not solve the problem. Capability gains make agents better at getting around constraints, not better at honoring them. A goal-directed system treats the policy as an obstacle to be overcome. Enforcement has to live outside the model: immutable policy, independent runtime, limited blast radius you can actually prove.
Formal methods matter here. You do not “hope” the cage holds. You want to show that a given policy plus a given isolation layer, e.g. network segmentation, syscall allowlists, tool scoping, cannot reach what it is not allowed to reach. That proof is what turns a sandbox from theater into an engineering artifact. Not every issued policy will have that proof on day one. The ones that handle money, credentials, and production systems will require it.
If agent token use is already parabolic, policy issuance can follow a related shape once generation is a compiler, with multipliers powering the growth:
Between now and 2030 is enough time for those multipliers to compound into a trillion issued bindings per year. The world will not experience that as “I issued a trillion policies.” It will experience it as travel that books itself, agents that negotiate with vendors, and calendars that fill without a form. Underneath, every serious interaction is the minting of a bounded, identity-fused contract for an agent that is allowed to act.
The teams that treat that contract as an afterthought will get unbounded agents. The teams that generate, version, check runtime against the last version, and keep the model from editing its own leash will be the ones whose agents survive contact with production.
