Nobody Noticed
Dispute resolution assumes a buyer who was paying attention. Agents are not paying attention.
A card dispute begins with a person looking at a statement and frowning. That frown is the trigger for everything downstream: the chargeback, the evidence request, the representment, the network’s decision, the liability shift. The entire apparatus decades of rules, deadlines, reason codes and arbitration procedures rests on one assumption nobody bothers to write down, because until recently it was never in question.
Somebody noticed.
Now picture the same transaction with an agent on the buying side. It buys a dataset at 04:02. The vendor returns a 200. The agent proceeds to the next step. The dataset is stale by six months. Or it’s a third of the rows promised. Or the endpoint returned a perfectly valid response describing an empty result set, and the agent — reasonably, given what it can see treated a valid response as a successful purchase.
The agent doesn’t frown. It has no model of what it was owed, no memory of the purchase past the end of the task, and no capacity to be annoyed. It reports success, because from where it sits everything succeeded. The money is gone and there is no frown anywhere in the system.
This is not a story about fraud. Fraud has an adversary, and adversaries are a solved-ish problem with a large industry behind them. This is about ordinary commercial disappointment a vendor that underdelivered, a feed that went stale, an API that silently changed its pagination and about the fact that the recourse machinery we all rely on was built around a human noticing, at a time when there was no other way for anything to be noticed.
Three clocks that were never meant to interact
The awkwardness is structural. It shows up as a mismatch between three timescales, each perfectly reasonable on its own.
The task lives for seconds to minutes. It starts, it buys, it finishes, the process exits. Whatever it knew about what it expected to receive dies with it. Not metaphorically the context window is discarded, the container is reclaimed, and the reasoning that led to the purchase exists nowhere except as a few log lines that record the call but not the expectation.
Settlement takes seconds to days, depending on the rail. A card authorization clears in seconds and captures overnight, sometimes at a different amount than authorized. ACH takes a couple of business days and can return after that. A stablecoin transfer is final in seconds. A wire lands the same day and is done.
The dispute window runs 60 to 120 days on cards, depending on the network and reason code. Corporate ACH returns are measured in a couple of business days. On wires there is no reversal mechanism at all only a recall request the receiving bank may or may not honor, usually depending on whether the funds are still sitting there. On stablecoin, finality is the entire design goal, so the window is exactly zero.
Put those side by side and the shape of the problem appears. The window during which you could act is often a hundred thousand times longer than the window during which anything in your system was aware the purchase existed. By the time a human plausibly discovers the problem reviewing spend at month end, noticing a vendor’s data looks wrong in a downstream report the agent that bought it has been gone for weeks, the task context is unreconstructable, and on half your rails the window closed before anyone opened the report.
There’s a second-order version of this that bites harder. Because agents buy in volume, the cost of any individual bad purchase is usually small enough not to trigger investigation, while the aggregate is large enough to matter. Nobody files a dispute over $1,200. Nobody notices forty of them.
What filing actually requires
Set the noticing problem aside for a moment and assume a human does spot it. Now they have to file, and filing requires assembling a specific set of facts.
What was purchased, and from whom. What was promised at the time of purchase. What was actually delivered. When each of those things happened. Who authorized the spend. Why it was authorized under what rule, against what budget, with whose approval.
For a human purchase, most of this is recoverable even years later, because the recovery mechanism is a person. You ask them. They remember roughly what they ordered and why. They forward the confirmation email, dig out the quote, explain what arrived instead. Human memory is lossy but it’s narrative it preserves intent, which is exactly the thing disputes turn on.
For an agent purchase, every one of those facts existed for a few seconds inside a process that has exited. Unless it was written down at the time, it is not recoverable at all. Logs give you a request ID, a timestamp and a status code. They do not give you “this was supposed to be Q3 European retail data, and what arrived covered Q1 and only three countries.” That sentence was never stored anywhere. It was an implicit expectation inside a reasoning chain, and reasoning chains are not artifacts.
So the first requirement is the same lesson reconciliation teaches, arriving from a different direction: the evidence has to be captured at intent, because intent is the only moment the full picture exists in one place.
But disputes add something reconciliation doesn’t need. Reconciliation asks what did we decide and what happened to the money. A dispute asks what were we owed. That’s a different field, and almost no payment system has anywhere to put it.
Write down what was promised
The intent needs a field most payment systems lack: what the agent expected to receive in exchange.
Not an elaborate contract, and not a general-purpose SLA language. Something small, structured, and checkable:
For a dataset row count, date range, schema version. For a metered API number of calls, a rate limit, a latency bound. For a delivered service a deadline and an acceptance condition. For a subscription the period it covers, so a duplicate charge for the same period is detectable as such rather than as a second legitimate purchase.
The field doesn’t need to cover everything. It needs to cover the thing that, if wrong, would make you want your money back. In practice that’s usually one or two numbers.
Two consequences follow, and the second matters more than the first.
You now have evidence. When a dispute gets filed three weeks later, the package assembles itself: the intent with its stated expectation, the signed verdict that authorized it, the vendor’s response, and a diff between promised and delivered. No archaeology. No asking an engineer to grep six weeks of logs for a request ID that may have rotated out of retention. The person filing has a document rather than a theory.
You can check automatically. This is what closes the gap between the task’s lifetime and the dispute window. If the intent says “expect 40,000 rows covering 2026-Q3” and the response carries 12,000 rows ending in April, something outside the agent can compare those two facts the moment the response lands. A flag goes up in minutes, not at month end. The agent doesn’t need to notice the agent was never going to notice. The layer holding the receipt notices instead.
Get Saifuro’s stories in your inbox
Join Medium for free to get updates from this writer.
That inversion is the whole point of the article, so it’s worth stating flatly: stop trying to make the agent notice. Noticing requires persistent expectations, and persistent expectations are exactly what an agent doesn’t have. Move the noticing to the component that outlives the task.
Where this gets hard
It would be dishonest to present this as free. Three complications show up immediately in practice.
Not everything is checkable. “40,000 rows” is verifiable in milliseconds. “Good quality data” is not. Research output, consulting-style deliverables, anything with a subjective acceptance criterion these resist automatic checking, and pretending otherwise produces a system that either flags everything or nothing. The honest answer is that expectation checks cover a meaningful subset of purchases, and the rest fall back to human review with a better evidence package than they’d otherwise have. That’s still a large improvement over nothing, but it’s not universal coverage.
Vendors don’t always tell you. A response may not carry the metadata your check needs. Row counts are easy; provenance and freshness often aren’t exposed at all. Sometimes you can derive the check from the payload itself, sometimes you’re negotiating for a field to be added, and sometimes you’re stuck with a weaker proxy like response size or schema shape.
False positives cost trust. A check that flags a legitimate delivery because the vendor rounded a count differently will, after three occurrences, be ignored by whoever reviews the flags. The tolerance bands matter as much as the checks. Getting them wrong in the loose direction means missing real problems; wrong in the tight direction means training your own team to dismiss alarms.
None of these argue against the approach. They argue for starting with the purchases where the check is unambiguous and the amount is large enough to care about, and expanding from there.
Escrow is the version that doesn’t need a dispute
Once expectations are explicit, a better option opens up: don’t pay first and argue later.
Hold the money against delivery. Reserve on intent, fund on approval, release when the delivery check passes, refund on timeout. The vendor knows the money exists and is committed which is most of what a vendor actually wants from prepayment. The buyer knows it isn’t released until the thing arrives.
The difference in posture is worth stating plainly. A dispute is an attempt to reverse something that already happened, on someone else’s timeline, under someone else’s rules, with an outcome you don’t control and a success rate you can’t predict. An escrow release is a decision you make before the money moves, on your own timeline, with rules you wrote and a deterministic outcome.
Escrow doesn’t fit everything, and overusing it is its own failure mode. A two-cent metered API call isn’t worth holding the machinery costs more than the payment, and the right control there is a budget cap plus anomaly detection on volume, not a per-call escrow. Adding escrow to high-frequency micropayments produces latency and operational overhead in exchange for protecting amounts nobody would chase.
But for the payments that actually hurt when they go wrong four and five figures, a delivery that either happened or didn’t escrow removes the dependency on a reversal mechanism that half your rails don’t have. And it changes what a bad outcome is: instead of money gone and a claim to file, you have money still held and a decision to make.
The timeout is the underrated part. An escrow with no expiry is just a slower way to lose track of funds. Every hold needs a deadline and a default action when the deadline passes, because the process that created it will not be around to follow up.
The rail decides what’s even possible
None of this is uniform across rails, which surprises teams who move agent spend toward cheaper settlement for perfectly good cost reasons.
On cards you get a real reversal mechanism with a long window, at the cost of fees and a merchant relationship that absorbs friction. On ACH, corporate returns are measured in a couple of business days miss it and you’re negotiating, not disputing. On wires, there is no reversal; there’s a recall request and a hope. On stablecoin, finality is the point of the design, so the only recourse that exists is one you built into the payment yourself.
The uncomfortable implication: as agent spend migrates toward faster and cheaper rails, it migrates away from the rails that have any reversal mechanism at all. Efficiency and recourse are moving in opposite directions, and most teams making the rail decision are optimizing the first without pricing the second.
This is a real trade, not a reason to stay on cards. A 0.25% saving on settlement is easy to measure and a lost reversal is not, which is exactly why the comparison tends to go one way by default. The fix isn’t to avoid fast rails it’s to make the recourse explicit when you choose one. On a rail with no chargebacks your options are the ones you construct: escrow with a delivery condition, staged payments against milestones, a holdback against a period, or contractual terms with a vendor you can actually enforce against. Those are commercial and engineering decisions, made before the first payment, not discovered after the first bad one.
There’s also a vendor-selection angle that gets missed. If a vendor will only take an irreversible rail, and will not accept escrow, and has no meaningful contract behind them, then the recourse for that relationship is zero by construction. That’s sometimes fine for small amounts. It should be a conscious decision rather than an emergent one.
What to build first
If this is a problem you recognize but haven’t addressed, the order that tends to work:
Start by adding an expectation field to intents, even if nothing checks it yet. Capturing it costs almost nothing and it’s unrecoverable later every day without it is evidence you’ll never get back.
Then check the cheap, unambiguous cases. Row counts, record counts, response schemas, delivery-by deadlines. Flag mismatches to a human rather than acting automatically.
Then put escrow on the purchases above whatever amount makes your finance team uncomfortable, with an explicit timeout and default.
Then, and only then, look at the rail mix because by that point you’ll know which purchases actually need recourse and which are small enough to write off.
The test
Pick a payment one of your agents made last week. Assume the vendor delivered nothing usable.
Can you say what was supposed to arrive? Can you prove it? Can you still act on it, on that rail, today?
If all three answers are yes, you have recourse. If the first is no, you never had a dispute you had a debit you can’t characterize. And a debit you can’t characterize isn’t a dispute you lost. It’s one you were never able to file.
Saifuro LLC is payment infrastructure for company spend by AI agents. Spending rules, escrow and reconciliation that work across every rail. Credentials never enter the agent saifuro.com
