Working thesis · Agent payments
A working thesis on the control gap in agent-driven payments — and the runtime authorization layer the agent economy will need before money moves, not after.
AI agents are beginning to move money on behalf of users and companies. They buy services, pay APIs, book travel, procure resources, and trigger workflows — without a human approving every transaction. That changes the control problem.
Most financial systems assume the actor behind a transaction is persistent — a person, company, account, cardholder, or merchant that can be investigated after the fact. An agent may be an ephemeral execution context: it can complete a task, initiate a transaction, and disappear.
Instructions inside the model are useful, but they can't be the final control layer for money movement. A probabilistic system can misinterpret, overreach, or act outside its intended scope. For high-consequence actions, financial policy has to be enforced outside the agent itself.
Most financial control is retrospective: money moves, then systems reconcile, audit, dispute, or remediate afterward. That works when mistakes are recoverable and there's a persistent actor to hold accountable.
Agentic payments put pressure on both assumptions. On instant rails, settlement is fast and often irreversible; by the time a problem surfaces, the funds may be gone and the agent that initiated the transaction may no longer exist.
Control has to happen before money moves, not after.
Issuers and agent-payment networks can approve a single transaction against a spending limit. But a per-transaction limit is a static gate. It doesn't track cumulative authorization — the running answer to how much of an agent's mandate has already been consumed.
What no single participant clearly owns is the state across transactions:
That live authorization state is the missing primitive.
A runtime financial-control layer between agent decision-making and payment execution. Before money moves, that layer resolves five questions:
Transactions that fail those checks are blocked before execution. Transactions that pass commit the authorization consumed, budget state, and audit record as one atomic event. Policy is enforced by construction rather than reconstructed later through logs and reconciliation.
At machine scale, control, accounting, and audit stop being separate systems and become one operation.
This state has to stay coherent across agents, issuers, wallets, networks, merchants, and tools — which makes it hard for any single participant to hold alone. Each sees only its own slice:
Sees its own authorizations.
Sees activity on its own rails.
Governs what flows through its own product.
Enforces policy inside its own runtime.
None of them necessarily sees the full authorization state once an agent operates across multiple tools, rails, issuers, and payment methods. So the control point likely needs to sit below individual rails — or be implemented as infrastructure that platforms embed when they orchestrate agentic transactions on behalf of users and enterprises.
The first pressure points are likely platforms that let agents initiate transactions or high-consequence actions for end users or companies:
Each will need to prove not just that a transaction settled, but that the agent was authorized to initiate it in the first place.
I'm trying to understand where this problem is already real, where it's still premature, and how teams building agentic products are handling it today.
I'm a venture-backed startup CFO who spent about a decade building the controls, governance, and audit systems this thesis is about — from seed through exit. I have an engineering team ready to start work on it. Right now I'm pressure-testing the thesis with people close to the ecosystem: where the gap is real, where it's already being solved, and what agent builders actually need from a control layer.
If you're building agentic products — or financing the teams that are — I'd like to compare notes on where the control gap is real today.