The Next Trillion Agents

Eleven months ago, we founded Sapiom. Six months ago, we announced our $15 million seed. Today, we are announcing Sapiom’s $35 million Series A, led by Dragonfly, bringing total funding to $50 million.

Alongside it, we are revealing what we have spent those eleven months building. Before I show you exactly what it is, I want to explain why it has to exist.

The operator

Every tool humans have ever built assumed a human would use it. Until now, there was only ever one kind of operator: someone to find the tool, create the account, manage the credentials, configure it, approve the payment, and review the bill.

That assumption sits underneath almost every piece of software and financial system we use today. For the first time, the operator is not human.

Today is August 5, 2026. Our operator is an agent, and it decides which tool to use, which service to call, and what to do next. It searches, runs code, sends messages, buys access, and recovers from failures without a person directing any of it. Continuously. When the operator changes, the infrastructure underneath has to change with it.

A city would look very different if it had been designed for autonomous vehicles instead of human drivers. The phone network was built for voices, so the first internet connections had to dial in like a person and sing static down a line meant for hello. A generation later, the roles have reversed, and this time the old infrastructure fights back. The internet has spent twenty years defending against the next newcomer: software that acts on its own. Every layer assumes a human is in control. Accounts require identity verification, credentials need a trusted holder, and payments must be authorized by hand. Fraud systems exist specifically to catch software pretending to be a person and stop it.

We built those systems deliberately, and we were right to. But the result is that the most capable operator we have ever created arrives into a world engineered to treat it as an intruder.

This is not the first time I have watched a problem like this play out. At Earny, we built software that automatically found price drops and secured refunds for millions of people. When the infrastructure did not support autonomous action, we built around it ourselves. Later, at Shopify, I helped scale Shop Pay past $100 billion in GMV on infrastructure that still assumed a person was ultimately in the loop.

Both times the ceiling was the same: what software is allowed to do on its own is determined by systems nobody thinks about until they break, but almost none of those systems were designed for software making its own decisions.

The operator has changed, but the operating system has not.

Demo vs. production

Almost anyone can build a capable agent demo in a weekend. Getting that agent to run reliably, at scale, in the real world is extremely difficult.

A production agent has to run continuously, preserve its progress, connect to outside systems, recover when something fails, stay inside the boundaries you set, explain what it did, and do all of it at a cost the business can sustain. Most agents never clear that bar. Gartner forecasts that more than 40% of agentic AI projects will be canceled by the end of 2027, with escalating costs among the leading reasons.

When we started Sapiom, the first place we saw the break was money, and it was not just the size of the bills. It was something more basic: an agent has no way to pay for anything on its own at all.

Consider a support agent that has just resolved a customer’s issue and needs to text them a confirmation. The message costs one cent. There is no card on file for a one-cent purchase, no checkout flow worth building for one cent, and no person waiting to approve it. So the team does what every team does: provision a shared credential with a spending limit behind it, hand it to the agent, and hope nothing goes wrong.

Card systems were built for occasional human purchases, not software transacting continuously. So we started there: giving agents permission to spend, and a safe way to interact with the real economy.

We did not invent new rails to do it. We built on the open standards emerging for exactly this, Coinbase’s x402 among them, so an agent can reach the real economy over infrastructure the ecosystem is developing in the open, rather than a walled garden of our own.

Then we began supporting a customer running 34,000 agents every day, and payments turned out to be one piece of a much larger problem. Their team also had to keep agents running through failures, control what each one could access and do, and track every action and dollar spent. They were effectively rebuilding the entire infrastructure required to operate thousands of agents themselves.

Payments and governance were not the whole problem. They were the first visible cracks in a much larger gap.

The $12,000 question

We have somehow turned enormous token bills into a status symbol, which is funny, because a large bill only proves that activity happened. Not whether any of it was worth doing.

Before moving to Sapiom, one customer running thousands of agents asked what should have been a reasonable question: How many agents ran yesterday, and what did they cost?

The only answer the team could produce was $12,000. Nobody knew which agents had generated that cost or what the $12,000 had paid for.

They could not see which agents ran, which tasks succeeded, where agents got stuck, or how many times they retried the same failed step. It was a company-wide credit card statement with no cardholders and no receipts attached.

That is the strange state of agent infrastructure today. Teams can watch an agent reason in real time, but often cannot answer basic questions about what happened after it was deployed.

The moment an agent acts

Sapiom is production infrastructure for AI agents. It sits between an agent and the models, compute, tools, and services it uses, enforcing what the agent is allowed to do at the moment it tries to act.

Imagine a research agent that finds the exact source it needs behind a paywall. It has the right article, knows the next step, and needs to spend $8.

Today, one of two things usually happens.

1. The agent stops and waits for a human.
2. Someone gives it a credential broad enough to turn an $8 decision into a very expensive mistake.

The first option limits the agent’s autonomy. The second creates unnecessary risk.

Sapiom gives the agent a third option. Before the task begins, the team defines its mandate: what the agent can use, what it can spend, and where it needs approval. When the agent reaches the paywall, Sapiom checks who is acting, what it is trying to buy, and whether the purchase falls within those limits. If it does, the agent gets access and keeps moving. The authorization is attached to the receipt. If it does not, the purchase never happens.

The same control applies when an agent calls a model, starts compute, invokes a tool, or pays for a service.

Once an action is permitted, Sapiom can select among eligible execution paths according to the team’s requirements for cost, quality, latency, reliability, availability, and company policy.

For open-weight models served through Sapiom-hosted inference, requests run on dedicated GPUs in a California data center. This gives teams a US-based processing path they can enforce through policy while avoiding frontier-model prices for work that does not require a frontier model.

Every execution receives an ID. Open its execution record and the details are there: each step’s cost, duration, outcome, and retry count. When something breaks, the team can see where the agent failed, what it attempted, and what it did next.

This is more than observability. Observability tells you what happened after the agent acted, while Sapiom determines what it is allowed to do before it acts.

The goal is not to make agents incapable of failure. It is to make their behavior bounded, visible, and recoverable.

Router, Agent Studio, and Runtime

Sapiom delivers this infrastructure through three products: Sapiom Router to optimize existing workloads, Sapiom Agent Studio to build agents, and Sapiom Runtime to operate them in production.

Sapiom Router is the layer everything runs through

It matches each call to the most efficient model instead of defaulting to the most expensive one, and it is the fastest way to find out what your current agents actually cost. You do not have to migrate anything. If your agents already use an OpenAI- or Anthropic-compatible client, getting started takes two changes (the base URL and API key):

# before-base_url = "https://api.anthropic.com"  # or your current provider-api_key  = PROVIDER_API_KEY# after+base_url = "https://llm.services.sapiom.ai/v2/openai/v1"+api_key  = SAPIOM_API_KEY

That is where most teams start.

Sapiom Agent Studio takes you from idea to working agent

Bring an agent you already have, start from an agent template, or describe what you want. Build, test, and inspect agents locally using the context of your existing codebase, then deploy to production with one command. Agent Studio is free to use.

Sapiom Runtime is managed infrastructure for production agents

Runtime lets you operate agents reliably from the first deployment to massive scale without building or managing the infrastructure yourself. It provides sandboxes, memory, secrets, tool access, scheduled triggers, and automatic recovery when steps fail.

Through one Sapiom integration, an agent can search the web, use a browser, generate media, send SMS and email, call models, and access other tools and services. Your team does not need to create a new provider account or manage another API key each time the agent needs a new capability.

Every model call, tool call, and retry is recorded as it happens, with its cost and outcome attached.

Pricing is simple: you are billed per run. The first 50 runs each day are free, with infrastructure, models, and tools included.

Sapiom Router lowers the cost of inference. Sapiom Agent Studio takes you from idea to working agent. Sapiom Runtime lets you depend on that agent in production.

The starting line

The customer who could not account for that $12,000 now runs on Sapiom. They can see every agent, every step, and every dollar. Sapiom recently helped them reduce their monthly inference bill from approximately $1.2 million to approximately $100,000.

In the six months since launch, Sapiom has processed more than 270 million transactions and now powers more than 100,000 agent runs per day.

We started with cost because that is where teams feel the problem first. But our ambition is much larger: to remove all the barriers that stand between builders and the next trillion agents.

Our Series A is led by Dragonfly, with participation from Accel, Gradient, Coinbase Ventures, Operator Collective, Formus Capital, and VanEck Ventures, alongside continued support from existing investors, including Okta Ventures, Menlo Ventures, Anthropic, and Array Ventures. Dragonfly understands the intersection of programmable money, infrastructure, and autonomous software. Haseeb Qureshi, Managing Partner at Dragonfly, joins our board.

Autonomous software has moved from possibility to production. Agents are already making decisions, using services, and moving money at scale. I am grateful to the team building the infrastructure this new kind of operator demands, to the customers trusting Sapiom in production, and to the investors backing our conviction that autonomous software requires an entirely new infrastructure layer.

This round gives us the resources to move faster, raise the bar for what agents can do in the real world, and establish Sapiom as the standard for how the next trillion agents are built, run, governed, and trusted.

If you already have agents running, change two lines and see what they cost on Sapiom. If you are starting from scratch, your first agent can be running in under 10 minutes. Start building, or read the developer documentation.

We are live.