What an Agent Payment Is
A payment initiated by software on someone's behalf, where no person approves that individual transaction. Automated payments have existed for decades, but those execute a schedule someone set. An agent decides that a payment is warranted, which is the property that changes what the system around it must provide.
What makes it different
Automated payments are old. A standing order pays rent monthly, a card on file renews a subscription, a payroll run executes on a date. In every case a person decided the arrangement and the system executes it faithfully.
An agent payment differs in one respect that changes everything downstream: the software determined that this payment should happen. Nobody chose this counterparty, this amount or this moment.
That single difference removes the control that consumer and business payments quietly depend on. In a conventional system a person sits somewhere in the loop and functions as a sanity check, catching the absurd amount, the unfamiliar recipient, the duplicate charge. Remove them and nothing catches those unless it was built to.
The secondary differences follow from the volume this enables. Payments become small and frequent rather than occasional and large, which inverts the assumptions of rails designed around a person deciding to buy something. A fee structure sensible for a monthly subscription is absurd for a per-request charge, and a settlement time acceptable to a shopper is unusable to a program waiting on a response.
What the system has to supply instead
Since the human check is gone, its function has to be reconstructed explicitly.
Bounded authority. The agent holds permission to spend up to a limit, within a period, to permitted destinations. Not an instruction saying so, an enforced ceiling, because an instruction is something the software can be argued past and arithmetic is not.
A policy evaluated before settlement. Counterparty, amount, rate, purpose and remaining budget, checked outside the model.
Idempotency. Agents retry, and a timeout does not distinguish a lost response from a failed payment. Every payment needs binding to the intent that caused it, or ordinary retries become duplicate spending.
A record with meaning. What was bought, why, under which task, against which budget. A ledger of transfers alone cannot answer the question anyone will actually ask afterwards.
A stop. A budget for the task, a rate limit, and an ability to revoke. The failure mode of an unattended system is not one large mistake, it is a thousand small ones executed faster than anyone notices.
Who is responsible
Software is not a legal person and cannot be a party to anything, so responsibility attaches to the operator. That is settled enough to plan around even where the detail is not: keep the record of what the credential permitted, when it was issued and what was actually done. Bounded authority is also the strongest position, because a cap that was set and enforced is a fact rather than an assertion. This is general information rather than legal advice.
Where it is genuinely useful
The honest scope is narrower than the enthusiasm suggests, and it is real.
Paying for machine-consumed resources. Data, compute, inference, API calls. The buyer is software, the seller is software, the amounts are small, and no human wanted to be involved on either side.
Metered access that was previously impractical. A charge too small to justify an invoice or a card transaction becomes viable when settlement is cheap and automatic, which opens pricing that could not previously exist.
Work that spans providers. An agent assembling a result from several paid sources, where pre-negotiating accounts with each is more work than the task is worth.
Where it fits badly is anything involving physical delivery, a dispute process, or a counterparty who expects a relationship. Those need a human somewhere, and the honest answer is to keep one there rather than to route around it.
CryptoCadet is built for the first category: a bounded USDC float on Base, delegated through session keys, so an agent can pay for what it consumes without holding unbounded authority over anything.
One boundary worth drawing early. An agent paying for what it consumes is a different system from an agent paying a person, and the second is much harder. Paying a supplier involves an invoice, a tax position, a relationship and a dispute path, none of which the first case has. Teams that build for the first and then extend into the second usually discover that they built a metering system rather than an accounts payable one, and those are not the same thing.
Frequently asked questions
- What is an agent payment?
- A payment initiated by software acting on someone's behalf, where no person approved that specific transaction. Automated payments execute an arrangement a person set up. An agent payment differs because the software determined that this payment, to this counterparty, at this moment, should happen.
- How is it different from a subscription or standing order?
- Those automate execution of a decision a person already made. An agent automates the decision itself, which removes the human who functioned as a sanity check on absurd amounts, unfamiliar recipients and duplicate charges. Nothing catches those now unless it was deliberately built to.
- What does an agent payment system need that a normal one does not?
- Bounded authority enforced rather than instructed, a policy evaluated before settlement, idempotency so retries do not spend twice, a record of what was bought and why, and a stop condition. The failure mode is a thousand small mistakes executed faster than anyone notices.
- Who is responsible for what an agent spends?
- The operator, since software is not a legal person and cannot be a party to anything. Keep the record of what the credential permitted, when it was issued and what was done, because bounded authority that was set and enforced is a fact rather than an assertion.