Receipts for Agent-Issued EDI
EDI standardized B2B transport. Autonomous agents change the trust model. When software starts issuing purchase orders, invoices, remittances, and adjustments on its own authority, the document is no longer enough. The counterparty needs a receipt.
The first wave of agent infrastructure talks about memory as if the only problem is retrieval. The next wave will discover the harder problem: a future agent, auditor, customer, vendor, or regulator has to know whether a past agent's claim is real.
That problem is old in business-to-business systems. Purchase orders, advance ship notices, invoices, remittance advice, and adjustment documents have been moving through EDI rails for decades. What changes now is the actor. The document may be authored, approved, reconciled, and disputed by autonomous agents across company boundaries. The receiving side cannot safely treat “it came through the normal channel” as proof of authority.
AS2 proved that a message came through a known pipe. Agent EDI has to prove which agent committed which bytes, under which key, against which prior receipts.
Walk the receipt chain
The demo from the research artifact becomes an article primitive: select a step, inspect the receipts, then map the EDI trust model to the Nukez trust model.
The handoff has no independent record
# EDI moves value, but the proof lives inside somebody's system
An 850, 856, 810, 820, and 812 pass between companies. Six months later, an auditor asks which autonomous actor authorized the disputed adjustment. The ERP has state. The VAN has logs. Neither gives the counterparty a receipt it can verify without trusting the operator.
Purchase orders, ship notices, invoices, remittances, and adjustments become proof-carrying agent transactions.
A coding or finance agent can record how it behaved, not merely what it output, before a reviewer trusts its work.
One agent can leave ciphertext for another while the gateway proves the encrypted bundle was not rewritten.
A root agent can verify child outputs before aggregation, so delegated research is not just pasted context.
Receipts become the chain of title for valuable machine-generated work products.
The Missing Layer
In the human-era trust model, the company was the actor and the EDI channel was the control surface. A trading-partner agreement said who could send what. A VAN or AS2 endpoint delivered the envelope. The ERP wrote state. Later, if something went wrong, the parties reconstructed intent from operational logs, archived documents, emails, and internal approvals.
That worked because the actual decision authority lived outside the message. A person approved the purchase order. A person released the payment. A person negotiated the dispute. The EDI document was evidence of a business process, not the whole proof of the process.
Agent-issued EDI collapses those layers. The runtime can generate the PO, select the supplier, interpret the ASN, match the invoice, release remittance, and propose an 812 adjustment. Once that happens, a trading partner needs to verify the action at the same level where the action occurred: the agent's keypair, its signed content hash, the prior receipts it relied on, and the independent attestation that the receipt existed before the dispute began.
| Question | Legacy answer | Agent-era answer |
|---|---|---|
| Who sent this? | Known endpoint or trading partner | Keypair-authenticated agent |
| What did it reference? | Document number and ERP state | Content hashes and receipt refs |
| Can the counterparty verify it? | Only through shared process or discovery | Yes, with recursive verification |
| Can the operator rewrite history? | Usually, yes | Not without breaking the proof |
Why EDI Is the Right Wedge
EDI is useful because the pain is legible. Money moves. Inventory moves. Late shipments, mismatched invoices, unauthorized discounts, and disputed adjustments already have budgets attached to them. Nobody has to invent a market for provenance here. The market exists anywhere two firms ask, after the fact, what happened.
This is also where the phrase “agents need memory” becomes too soft. The supplier does not need the buyer's agent to remember that it placed a PO. The supplier needs a counterparty- verifiable receipt for the exact PO that shaped the ASN, invoice, and disputed remittance. The auditor does not need a summary. The auditor needs to walk the chain.
A memory provider says: here is what I have. A receipt layer says: here is what was committed, by whom, when, under which key, with which source chain, and here is how you can verify it without trusting me.
What Nukez Adds
Every outbound EDI artifact can be wrapped in a signed envelope and returned with a receipt. The receiver checks the content hash, signature, policy, and attestation root without depending on the sender's database.
Invoice matching and payment exceptions become receipt chains instead of private state transitions. A finance agent can explain why it paid less. A reconciliation agent can issue an adjustment. Both claims are independently inspectable.
Cross-company agents can collaborate without collapsing into a single shared operator. Lockers define permissioned boundaries. Receipts define proof. Merkle roots provide public notice. The keypair is the durable identity.
The same primitive generalizes beyond EDI. Coding agents need behavioral attestation. Research agents need recursive context integrity. Strategy agents need sealed handoffs. Agent economies need property rights over outputs. But EDI is the clean wedge because it makes the verification problem impossible to hand-wave: either the adjustment is linked to the invoice and remittance, or it is not.
The agent economy does not need more screenshots of cognition. It needs enforceable provenance.
The Thesis
“AS2 from a known partner” was a sufficient trust model when the actor on the other end was a person working inside a business process. When the actor is an autonomous agent generating 850s, 820s, and 812s on its own authority, the receiving party needs to know which agent, which key, which policy, and which prior receipts authorized the document.
That is not a feature gap in EDI. It is the missing verification layer for agent-mediated commerce.