An agent payment rail cannot also be the accountability layer
The selling point is autonomous checkout without human friction. That is a genuine capability with genuine demand, and it is structurally the opposite of what proving human authority needs.
Why can't an agent payment rail own the human accountability layer?
Because its design goal is transacting without human involvement, which is exactly what removes the record accountability needs. Platforms such as Skyfire and Catena Labs solve agent identity, settlement and machine-readable pricing well. A delegation record is most useful when the party relying on it did not issue it.
- Agent payment platforms optimise for removing human involvement per transaction, which is what makes them useful.
- Human accountability requires a record of what a human authorised, which the autonomy objective actively removes.
- These are layers rather than competitors: the rail moves value, the accountability layer establishes who stood behind it.
Part of Category comparisons
What the rail is for
Agent payment infrastructure solves problems that existing rails handle badly: identifying agents, settling small amounts, machine-readable pricing, programmatic access to services.
Each of those is real. Existing payment infrastructure assumes a person at a checkout, and an agent buying API access a thousand times a day does not fit.
The objective that creates the gap
| Design goal | Consequence |
|---|---|
| Transactions without human intervention | No human authorisation record per transaction |
| Low friction at scale | Approval steps are removed deliberately |
| Agent-native identity | Identity is the agent's, not a person's |
| Programmatic spending limits | Bounds set in configuration, not signed by a person |
Read the right column as a description rather than an accusation. These are the correct consequences of the stated goals, and a platform that added a human approval per transaction would have failed at its own purpose.
The question that arrives later
When an agent transaction is disputed, the questions are ones the rail cannot answer.
- Which human authorised this agent to spend on this organisation's behalf?
- What scope did they authorise — amount, counterparties, duration?
- Can that authorisation be verified by the counterparty, the bank, or a court?
- Was it still in force at the time of the transaction?
A configuration record showing a spending limit is an internal setting. It is not a record of a human commitment, and in a dispute it is an assertion by the party relying on it.
Why the rail should not build it
Three structural reasons, and the third is the strongest.
- Objective conflict. Adding human authorisation friction works against the product's core claim.
- Scope. The accountability layer spans every consequential agent action, not only payments. A payment rail has no view of the permission grant or the data export.
- Neutrality. A record of what a human authorised is most useful when the party relying on it is not the party that issued it. Evidence produced by one side of a transaction is worth less than evidence either side can verify independently.
How the layers compose
# Accountability layer — neutral, verifiable by anyone
human signs a delegation:
agent X may spend up to N, with counterparties C,
until date D, revocable immediately
# Rail — moves value, handles settlement
agent transacts under that delegation
each transaction references the delegation
# Counterparty, bank, auditor
verify the delegation chain offline
a transaction outside the scope produces no valid chainNeither layer needs to know much about the other. The rail carries a reference; the accountability layer does not care which rail was used.
Why this is a partnership rather than a competition
| Need | Rail | Accountability layer |
|---|---|---|
| Agent identity | Yes | Uses it |
| Settlement | Yes | No |
| Machine-readable pricing | Yes | No |
| Human delegation record | No | Yes |
| Offline verification by third parties | No | Yes |
| Coverage of non-payment actions | No | Yes |
There is no row where both are required and neither has it. That is the definition of complementary rather than competing.
The commercial argument for the rail
A rail whose transactions carry verifiable human delegation is a rail that merchants and banks will accept. One whose transactions arrive as unattributable automation is one they will price as fraud risk.
That is the practical reason for a payment platform to want this layer to exist without building it: acceptance is the constraint on agent commerce, and acceptance follows evidence.
Why the rail should not build it
Three structural reasons, and the third is the strongest.
| Reason | Detail |
|---|---|
| Objective conflict | Adding human authorisation friction works against the product's core claim |
| Scope | Accountability spans every consequential agent action; a payment rail has no view of a permission grant or a data export |
| Neutrality | Evidence produced by one side of a transaction is worth less than evidence either side can verify independently |
There is a commercial argument for the rail wanting this to exist without building it. Acceptance is the constraint on agent commerce: a rail whose transactions carry verifiable human delegation is one that merchants and banks will accept, and one whose transactions arrive as unattributable automation gets priced as fraud risk.
Objections and honest limits
“A configured spending limit is the same thing.” It is an internal setting. In a dispute it is an assertion by the party relying on it, not a record of a human commitment a third party can check.
“This is a competitive pitch.” There is no row in the comparison where both parties are required and neither has it. That is the definition of complementary rather than competing.
What the delegation record must contain
- The principal. A named human, authenticated with user verification, not an account.
- The scope. Action class, counterparties, per-transaction and aggregate ceilings.
- The expiry. So a stale delegation does not persist indefinitely.
- Revocation that is enforced. At the point of effect, not at a gateway.
- Offline verifiability. So the counterparty, the bank and a court can all check it without calling anyone.
Terms used here
- Agent payment rail
- Infrastructure for identifying agents, settling small amounts and exposing machine-readable pricing — problems existing card rails handle badly.
- Delegation chain
- A record connecting an agent's action to the human who authorised that class of action, with scope and expiry, verifiable by a third party.
- Acceptance
- Whether merchants and banks will take a transaction. The real constraint on agent commerce, and it follows evidence.
Frequently asked questions
Are agent payment platforms doing something wrong? No. They solve real problems that existing rails handle badly. Removing human involvement per transaction is their purpose, not an oversight.
Why can't the rail add human authorisation? It conflicts with their core claim, it covers only payments rather than all consequential actions, and evidence is worth more when the issuer is not a party to the transaction.
Isn't a configured spending limit enough? It is an internal setting. In a dispute it is an assertion by the party relying on it, not a record of a human commitment a third party can verify.
Why would a rail want this to exist? Acceptance. Merchants and banks will accept transactions carrying verifiable human delegation and price unattributable automation as fraud risk.
Why does neutrality matter? A record is most useful to the party who did not issue it. Evidence produced by one side of a transaction carries less weight than evidence either side can verify.
Why would a rail want this? Acceptance. Merchants and banks will take transactions carrying verifiable human delegation and will price unattributable automation as fraud risk.
Where this fits in Manav
Manav issues the delegation and the receipt; the rail moves the value. The chain verifies offline against a published key, so a merchant, a bank or a court can check it without an account with either party.