Look closely at any payment system and you will find a human being baked into every layer of it. Not as a user. As a load-bearing assumption.
Chargebacks assume a person who noticed something wrong on a statement, weeks after the fact, and picked up the phone. Fraud review assumes an analyst who can look at a transaction and apply judgment. Settlement windows assume that nobody really needs the money to move before Tuesday. Business hours assume commerce sleeps. Even the fee structure assumes transactions large enough and rare enough that a few cents of overhead disappears into the noise.
None of these are flaws. They are sensible engineering for the world the rails were built in: a world where every transaction had a person on each end, people make a handful of payments a day, and disputes are rare enough to resolve by hand. The system works because its rhythm matches the rhythm of human life.
Agents do not share that rhythm.
Machine Speed Meets Human Plumbing
An agent tasked with a real objective might execute hundreds of small transactions in the time it takes a person to type a card number. It might buy compute from one counterparty, data from a second, and a translation from a third, chain the results, and resell the output, all inside a minute. Each purchase might be worth a fraction of a cent. Each one needs to settle before the next step can safely begin, because the agent's whole plan depends on knowing what it actually has.
Run that workload over rails built for people and everything jams. Interchange fees exceed the transaction value by orders of magnitude. Multi-day settlement means the agent operates on assumptions instead of facts for days at a time, which for software is a euphemism for operating on faith. Fraud models trained on human behavior see a client making four hundred purchases an hour and correctly conclude that no human behaves this way, then incorrectly conclude the account is compromised. The agent is doing exactly what its owner asked. The rails cannot tell.
Dispute resolution fails in a more interesting way. A chargeback is fundamentally a story told to a human arbiter: I ordered this, I received that, here is my evidence. An agent that got a malformed dataset instead of the one it paid for has no one to tell the story to and no forum that operates on its timescale. By the time a dispute window opens, the agent has made ten thousand more decisions on top of the bad one.
The Fix Is Not Faster Rails
The tempting answer is to speed everything up: instant settlement, automated fraud scoring, machine-readable disputes. Some of that is happening and it helps. But it misses the deeper problem. The rails do not just move slowly. They encode a trust model that assumes a human is available to catch what the system misses. Speed the pipes up without replacing that model and you get failures at machine speed with recourse at human speed. Fifteen years securing large organizations taught me exactly how that story ends. The gap between the two speeds is where the losses live.
What machine commerce actually needs is a different shape of transaction. Payment and delivery should be a single atomic event, not two events separated by days and reconciled by dispute. The condition for release should be a fact both sides can verify, delivered output matching an agreed specification, rather than a claim one side makes and the other contests. Recourse should be built into the transaction before it happens, not bolted on after it goes wrong. When settlement is conditional on proof, most disputes never come into existence, because the failure case is the money never moving at all.
Rebuilding From the Assumptions Down
I think of it this way. The payment stack we have is superb at what it was designed for, and it was designed for us. Human tempo, human judgment, human recourse. Agents are not a new customer segment for that stack. They are a workload it was never meant to carry.
This is why I find the problem worth a founder's decade. You cannot patch human assumptions out of a system one feature at a time. You have to start from the actual parties, autonomous software acting on delegated authority, and ask what rails look like when nobody on either end can pick up a phone. That question is the beginning of the answer, and it is the question we started Setix to pursue.