Daniel sent us this one — and it's the kind of question that sounds narrow at first but opens up into something huge. He's asking about AI agents doing B2B purchasing, specifically the infrastructure layer. The last time we talked about this, we focused on payment rails and where humans stay in the loop. But he's pointing at something deeper: the fact that enterprise procurement already runs on invisible, standardized electronic systems that handle trillions in transactions every year. Purchase orders, invoices, credit extensions, payment reconciliation — all of it happens programmatically right now. So the real question is whether these new agentic commerce frameworks get layered on top of that existing plumbing, or whether we're looking at a full rip-and-replace of the entire electronic purchasing stack.
This is exactly the right moment to ask it. You've got Google's Agent-to-Agent protocol — A2A — announced back in April of last year, designed to let agents discover each other's capabilities and negotiate in real time. You've got the LLM-native purchasing tools emerging from OpenAI and Anthropic. And they all face the same fork in the road. Do they learn to speak EDI, which is the forty-year-old protocol that still runs most of B2B commerce, or do they try to replace it with something built for agents from scratch?
I think what makes this interesting is that neither path is obviously correct. The answer depends on what kind of procurement we're talking about — high-volume standardized stuff versus complex strategic sourcing — and the most interesting action is probably in the middle, where hybrid architectures start showing up.
Let's start by understanding what EDI actually is under the hood — because if you've never worked with it, you might be surprised by how much of the global economy runs on these forty-year-old message formats.
Most people hear "EDI" and their eyes glaze over. But we're talking about the circulatory system of global trade here.
EDI — Electronic Data Interchange — emerged in the nineteen eighties as a way for companies to exchange business documents without paper. Before EDI, if a manufacturer needed to order steel, someone typed up a purchase order, mailed or faxed it, someone on the other end re-keyed it into their system, and errors were constant. EDI replaced all of that with structured electronic messages that computers could process directly.
The key thing is, it's not just one format. There are standards bodies behind this. ANSI X12 is dominant in North America. EDIFACT, the UN-backed standard, is more common internationally. These standards define very specific transaction sets — numbered messages for every step of the procurement lifecycle.
So the big ones: eight fifty is the purchase order. Eight ten is the invoice. Eight twenty is the payment order. Eight fifty-six is the advance ship notice. Nine ninety-seven is the functional acknowledgment. Every one of these has a rigid structure — specific segments, specific data elements, specific allowed values. There's no ambiguity.
Which is exactly the point. These systems were designed for deterministic machine-to-machine communication. You and your trading partner agree on prices, terms, delivery schedules in advance — that's called a trading partner agreement, or TPA — and then the EDI messages just execute against that pre-negotiated framework. There's no haggling in the message stream. That conversation happened weeks ago, offline.
The scale here is staggering. EDI handles trillions of dollars in transactions annually. Walmart basically forced its entire supply chain onto EDI in the nineties. Automotive, aerospace, pharmaceuticals — these industries run on EDI. If you're a tier-two supplier to Ford and your EDI system goes down, you're not shipping parts, and assembly lines stop.
That's the existing world. Now let's talk about what's emerging on the agentic side.
Google announced the Agent-to-Agent protocol — A2A — in April twenty twenty-five. It's designed for a fundamentally different paradigm. Instead of pre-negotiated, fixed transactions, A2A assumes agents will discover each other dynamically, exchange "agent cards" that describe capabilities, and then negotiate terms in real time. The messages are JSON-based, flexible, and the whole model is built around conversation and adaptation rather than rigid document exchange.
This is distinct from what OpenAI and Anthropic have been doing with function calling and tool use. Those are single-agent paradigms — one agent deciding to call an API. A2A is multi-agent. It's agents negotiating with other agents. That's a different problem space entirely.
Here's where the architectural mismatch gets really stark. EDI assumes you already know who you're trading with. You've signed a TPA. You've tested the connection. The prices are fixed. The message formats are validated against schemas that haven't changed in years. An agentic system assumes none of that. It assumes the agent will discover suppliers it didn't know about five minutes ago, evaluate their offers, negotiate terms, and commit to a transaction — all dynamically.
The data models don't align. EDI has rigid segments — N1 for name, PO1 for line item, CTT for totals — and every field has a specific position and length. Agentic systems work with flexible JSON payloads where the structure can vary from one interaction to the next. Mapping between those two worlds is not trivial.
Let me make this concrete. Imagine a procurement agent for a manufacturer that needs to reorder steel coils. In the EDI world, the agent would need to generate an eight fifty purchase order — and that message has to be perfect. Exact part numbers from the pre-negotiated contract. Exact delivery windows. The agent can't say "give me your best price on steel coils." It has to say "I am ordering SKU four seven two dash B, quantity five hundred, at the contracted price of one thousand two hundred dollars per unit, delivery to dock seven by July fifteenth." If any of those fields are wrong, the order bounces.
Or worse, it goes through and you've just ordered five hundred of the wrong thing.
Now in an agentic world, that same agent might discover three steel suppliers it didn't previously have relationships with. It might negotiate volume discounts in real time. It might adjust delivery schedules based on what's happening on the production line. That's genuinely useful — but it produces a transaction that doesn't fit neatly into an eight fifty message.
Can an AI agent speak EDI today? But it's awkward. The agent would need middleware that translates its internal state — "I want to buy steel coils from the cheapest qualified supplier" — into the specific, rigid fields of an EDI message. Then it needs to authenticate through a Value Added Network, or VAN, or via AS2, the internet-based transport protocol for EDI. Then it needs to handle the acknowledgments — the nine ninety-seven and nine ninety-nine messages — which are batch-oriented, not real-time. The whole thing is architecturally possible, but it's like putting a jet engine on a horse cart.
The VANs themselves are worth understanding. Companies like SPS Commerce, TrueCommerce, Cleo, OpenText — these are the intermediaries that route EDI traffic between trading partners. They provide the mailboxes, the translation services, the compliance checking. If you want to send an eight fifty to Walmart, it goes through a VAN. And these VAN relationships are deeply embedded in enterprise procurement operations. They're not going anywhere.
We've got this legacy infrastructure that's deeply entrenched, and these new agentic protocols designed for a fundamentally different paradigm. The question is: which one wins, or do they find a way to coexist?
This is where institutional inertia gets really powerful. Large enterprises have decades of investment in EDI. We're talking about thousands of trading partner agreements, each one negotiated, tested, and audited. VAN contracts renewed annually. Deep ERP integrations — SAP S/4HANA, Oracle Fusion — where EDI messages flow directly into the general ledger, inventory management, and accounts payable. The compliance departments that audit these transactions for SOX and other regulatory requirements are built around EDI's structured, auditable nature.
The switching costs are enormous. If you're a Fortune 500 manufacturer with ten thousand EDI trading partners, migrating each of those partners to a new protocol isn't just expensive — it's organizationally impossible in any reasonable timeframe. Each partner has their own systems, their own timelines, their own compliance requirements. You can't just flip a switch.
For high-volume standardized procurement — MRO supplies, raw materials, office goods, the stuff companies buy by the truckload — the most likely path is an agentic wrapper around existing EDI. You deploy an AI agent that makes smart decisions about what to order, when to order, from whom to order — but when it comes time to actually execute the transaction, the agent translates its decisions into EDI messages via middleware. The EDI layer becomes invisible, but it's still there.
This is basically the hybrid architecture thesis. The agent does the thinking and the negotiating, but the transaction execution still runs through the proven, auditable EDI rails. I think this is where the action is going to be for the next five to ten years.
Now, the rip-and-replace case gets stronger when you look at complex, strategic procurement. Custom engineered parts. These transactions involve negotiation, scope definition, dynamic pricing — exactly the things that EDI is terrible at and agentic systems are designed for. Companies like Zip, Coupa, and Ivalua are already building AI-native procurement platforms that bypass EDI entirely for these use cases.
This is where the two-tier system starts to make sense. Tier one: EDI-compatible agentic middleware for high-volume, low-complexity transactions. Tier two: native agentic protocols for strategic procurement where the flexibility actually adds value. The question is whether those tier-two platforms eventually scale down and eat into tier one, or whether they remain specialized tools for complex buying.
There's a historical parallel here. In the twenty-tens, when REST APIs started becoming ubiquitous, a lot of people predicted the death of EDI. And EDI didn't die. It survived because APIs didn't offer enough incremental value for high-volume, standardized transactions. If you're ordering ten thousand widgets every Tuesday at the same price from the same supplier, the flexibility of an API doesn't buy you much. The transaction is already deterministic.
The agentic transition may follow a similar pattern. For high-volume standardized stuff, the agent's value is in the decision-making layer — optimizing quantities, timing, supplier selection — not in the transaction execution layer. So you let the agent do the smart part, and you let EDI do the boring part it's been doing reliably for forty years.
The wildcard here is the ERP vendors. SAP and Oracle sit at the center of enterprise procurement. If SAP announces native agentic procurement capabilities embedded in S/4HANA — not just an API that agents can call, but actual agent-to-agent negotiation protocols built into the core ERP — that changes the calculus. Suddenly, thousands of enterprises get agentic capabilities through an upgrade, not a rip-and-replace.
The same goes for the procurement platform vendors. If Coupa or Ariba embeds A2A or a similar protocol natively, their existing networks of buyers and suppliers get agentic capabilities overnight. The network effects could flip quickly.
The other wildcard is whether a standards body steps in. GS1, which manages barcode standards and some supply chain data standards, could attempt to bridge EDI and agentic worlds. If someone produces a standardized way to represent EDI transaction sets in an agent-friendly format — essentially an "EDI for agents" — that could accelerate the hybrid approach dramatically.
That's the thing I keep coming back to. The most likely outcome isn't a clean victory for either side. It's a mess. A productive mess, but a mess. Some transactions will run through agentic-native protocols. Some will run through EDI with an agentic wrapper. Some will run through middleware that translates between the two. And the whole thing will be held together by adapters, translators, and the quiet heroism of integration engineers.
Which brings us to the practical question. If you're building or buying procurement systems right now, what should you actually do?
Given all that, let's get practical. If you're building an agentic procurement system, the first thing to understand is: don't try to replace EDI for high-volume transactions. It's not going to work, and the market won't reward you for ideological purity. Build an EDI adapter layer first. Look at what middleware platforms like Cleo or TrueCommerce already do — they bridge EDI and API worlds — and extend that pattern to agentic protocols. The market will reward you for reducing friction, not for being architecturally pure.
If you're an enterprise buyer, start auditing your procurement stack now. Go category by category. Which spend is high-volume and standardized? That's your EDI-plus-agentic-wrapper tier. Which spend is strategic and complex, with lots of negotiation and scope definition? That's where you should be evaluating agentic-native platforms like Zip or Coupa's newer AI modules. The split will define your procurement architecture for the next decade, and getting it wrong means either overpaying for flexibility you don't need or underinvesting in flexibility you desperately need.
For investors and strategists, here's the signal to track: watch what SAP and Oracle do. If they announce native agentic procurement capabilities embedded in their core ERP platforms, the rip-and-replace scenario becomes more plausible because the distribution problem is solved. If they announce EDI-compatible agentic middleware — essentially, agents that speak EDI through adapters — the hybrid path wins. Either way, the ERP vendors are the kingmakers here.
I think the biggest open question is whether agentic protocols will develop their own "EDI moment" — a standardized, widely adopted schema for commercial transactions that everyone agrees to use. Without it, we'll get fragmentation. Every platform will have its own agentic format, and the middleware layer that translates between them becomes permanent rather than transitional.
Which might actually be fine. The agentic procurement layer may ultimately make EDI obsolete not by replacing it, but by making it invisible. Agents handle the translation, humans never see the eight fifty messages again, and the underlying infrastructure becomes a legacy compatibility layer that nobody thinks about — like the way TCP/IP still runs underneath everything we do on the internet. The question is whether that counts as evolution or extinction.
On that note — we should probably acknowledge that this entire conversation assumes the agents work reliably. We're talking about trillions of dollars in transactions. If an agent hallucinates a purchase order for five hundred steel coils when the factory needed five, that's not a customer service ticket. That's a material financial event.
Which is why the hybrid approach has another advantage people don't talk about enough. EDI's rigidity is a feature, not a bug, when it comes to compliance and auditability. Every transaction is structured, logged, and verifiable. If you rip that out and replace it with flexible agentic negotiation, you also need to rebuild the audit trail from scratch. That's not impossible, but it's a much bigger lift than most of the agentic commerce demos acknowledge.
Daniel's question — build on top or rip and replace — turns out to have a surprisingly clear answer, at least for the medium term. Build on top for the high-volume stuff. Replace selectively for the complex stuff. And in both cases, don't underestimate the institutional gravity of systems that have been working reliably since before most of the people building AI agents were born.
The boring plumbing wins again. At least for now.
Yet — here's what I keep chewing on. The invisible plumbing has a philosophical assumption baked into it that the agentic world directly challenges. EDI assumes the transaction is the atomic unit. You agree on terms, you issue the eight fifty, you get the nine ninety-seven back, and that's a completed event. Agentic systems assume the relationship is the atomic unit — continuous negotiation, continuous adaptation, the transaction is just a snapshot of a moving conversation.
That's a really clean way to frame it. And it explains why the mismatch isn't just technical — it's conceptual. EDI was built for a world where procurement meant executing against contracts. Agentic procurement is about forming contracts on the fly. Those are different activities, and they produce different data shapes.
When Daniel asks whether we're building on top or ripping and replacing, part of the answer is that we're probably doing both, but for different parts of the procurement lifecycle. The execution layer stays EDI-compatible because it's solved. The formation layer — discovery, negotiation, terms — is where the agentic stuff actually adds value.
That's the thesis I think we should carry through the rest of this. The build-on-top versus rip-and-replace question resolves into a tiered answer. High-volume standardized procurement keeps EDI with an agentic decision layer on top. Complex strategic sourcing goes agentic-native. And the interesting engineering is in the middleware that lets those two tiers talk to each other when they need to.
Which they will. Because even the most strategic procurement eventually terminates in something that looks like a purchase order, and someone's ERP system is going to want that in a format it understands.
Let's get under the hood of EDI at the message level, because the specifics matter. An EDI transaction set — say, an eight fifty purchase order — is not a document in the way most people think of documents. It's a flat file composed of segments, and each segment is a string of data elements separated by delimiters. You've got an ISA segment that identifies the sender and receiver, a GS segment that groups related transactions, then ST to mark the start of the eight fifty itself. Inside that, BEG for the beginning of the order, N1 segments for party identification, and then PO1 segments for each line item — quantity, unit of measure, price, product identifier. Then CTT for totals, SE to close the transaction set, GE and IEA to close the envelopes. Every single field has a fixed position, a fixed length, and a fixed set of allowed values.
If the product identifier in PO1 doesn't match what's in the supplier's system, the whole thing rejects. There's no "close enough." The rigidity is the point.
And that's just the North American X12 flavor. EDIFACT, which dominates in Europe and Asia, uses a different syntax — UNB and UNH segments instead of ISA and GS — but the philosophy is identical. Now, there have been attempts to modernize this. cXML, which came out of Ariba, wraps purchase orders in XML with HTTP transport instead of VANs. OAGIS does something similar for manufacturing. These are more readable, more flexible in their schema, but they still assume a world of pre-negotiated terms and fixed catalogs. You don't use cXML to haggle. You use it to punch out to a supplier's catalog, select items from a pre-approved list, and return a completed order. The negotiation happened months earlier.
Even the "modern" EDI variants still treat the transaction as the execution of a prior agreement, not as the formation of one.
Now contrast that with what A2A actually does at the protocol level. When two A2A-compatible agents meet, they don't exchange a pre-formatted purchase order. They exchange agent cards — JSON documents that describe what each agent can do. One agent says "I can source industrial materials, here are my supplier relationships, here are the categories I cover." The other says "I need steel coils, here's my required specs, here's my budget range, here's my delivery constraints." Then they enter a task — a structured conversation where they negotiate terms, exchange proposals, and converge on an agreement. The data model is fundamentally conversational, not transactional.
This is where the mismatch gets concrete. In EDI, the data model is built around completed decisions. The eight fifty says "this is the order, these are the terms, execute it." In A2A, the data model is built around the process of reaching a decision. The messages are proposals, counter-proposals, acceptances, modifications. The final agreement might eventually look like a purchase order, but the protocol doesn't force it into that shape until the very end — if at all.
The integration challenge isn't just about format translation. It's about state management. An agentic system maintains a negotiation state — who offered what, which terms are still open, what's been accepted. EDI has no concept of negotiation state. It has transaction state — was the message received, was it acknowledged, was it processed. Those are different state machines, and bridging them means the middleware has to track the negotiation on one side and then, at the moment of commitment, freeze it into a deterministic transaction on the other.
Let me make that painfully concrete. Suppose an agent negotiates with three suppliers and gets three different proposals. Supplier A offers five hundred coils at one thousand one hundred dollars each, delivery in ten days. Supplier B offers four hundred coils at one thousand fifty dollars, delivery in seven days, but can't do the full five hundred. Supplier C offers the full order at one thousand two hundred dollars but can deliver in four days. The agent decides to split the order — three hundred from B and two hundred from C, because production can't wait ten days. That's a smart, dynamic decision. But now the agent has to produce two separate eight fifty messages, each referencing a different supplier, each with exact prices pulled from the negotiation. And if either supplier's EDI system rejects the message because the price in the PO1 segment doesn't match their internal contract price — which was never negotiated through the traditional TPA process — the whole thing unravels.
That's the authentication and compliance nightmare. In traditional EDI, before you ever send an eight fifty, you've executed a trading partner agreement. Legal has reviewed it. The supplier is set up in your ERP with approved payment terms, tax IDs, bank details. The VAN connection has been tested. An agentic system that dynamically selects suppliers and negotiates terms on the fly is essentially asking the EDI infrastructure to accept transactions from trading partners that may not have gone through any of that onboarding process.
The middleware layer has to solve not just the format translation, but the identity, authentication, and compliance problems. It has to say "this agent-negotiated transaction is authorized, even though there's no traditional TPA, because the agent operated within approved parameters." That's a governance problem as much as a technical one.
Then you add the VAN layer. The agent doesn't just generate an eight fifty and email it. It has to connect to the VAN — probably through AS2, which requires digital certificates for authentication — drop the file in the right mailbox, and then wait for the nine ninety-seven functional acknowledgment. That acknowledgment is batch-oriented. It might come back in minutes or hours. The agent, which is designed for real-time interaction, now has to sit and wait for a batch acknowledgment before it knows whether the order was even accepted. That's a speed mismatch that frustrates the whole real-time promise of agentic commerce.
Yet — this is all technically solvable. You can build adapters. You can cache VAN connections. You can pre-register potential suppliers and pre-authorize negotiation ranges so that when the agent commits, the EDI transaction clears compliance. The question isn't whether it's possible. It's whether the resulting architecture is elegant or a Rube Goldberg machine held together by middleware and prayer.
I think it's the latter for now, but I also think that's fine. Most of the internet's infrastructure is held together by things that are architecturally ugly but operationally reliable. BGP, DNS, email — none of these are elegant protocols. They're survivors. EDI is a survivor. And survivors tend to get wrapped, not replaced.
Let's talk about what tips the scales. Because the technical mismatch is real, but technology rarely decides these things on its own. Network effects and institutional power do. And EDI's network effects are almost comically strong. Every major retailer, every automotive manufacturer, every pharmaceutical distributor — they all speak EDI. If you want to sell to Walmart, you speak EDI. That's not a technical preference, it's a market requirement.
The thing about network effects this deep is that they're self-reinforcing. New suppliers adopt EDI because buyers require it. Buyers keep requiring it because all their suppliers already speak it. Breaking that loop requires something more than a better protocol — it requires a coordination event. Someone big has to move first and bring everyone else along.
Which brings us to the kingmakers. SAP and Oracle. If SAP embeds native agentic procurement — actual A2A-style negotiation, not just an API wrapper — into S/4HANA, that's not a feature release. That's an infrastructure event. Tens of thousands of enterprises get agentic capabilities through an upgrade cycle, not a migration project. The network effects flip because the installed base moves together.
The same logic applies to the procurement platforms. Coupa has something like seven million suppliers on its network. If Coupa flips on agentic negotiation natively, that's instant critical mass for a new protocol. The suppliers don't have to choose to adopt it — it just appears in the platform they already use.
The counterweight is that these vendors are deeply conservative about their core transaction infrastructure. SAP spent decades building EDI integration into S/4HANA. They're not going to rip it out on a bet. What's more likely — and this is where the hybrid thesis gets its institutional backing — is that they'll ship agentic capabilities as a parallel track. EDI for execution, agentic for discovery and negotiation, with the ERP handling the handoff between them.
That's the scenario where the middleware layer becomes permanent infrastructure rather than a transitional hack. If SAP and Oracle decide the hybrid path is the product strategy, then the adapter pattern gets blessed by the platforms that run the global economy. At that point, it's not a workaround — it's the architecture.
There's one more player worth watching: the standards bodies. GS1 already manages the barcode standards that underpin global supply chains. If GS1 or OASIS produces a standardized way to represent agentic negotiations in a format that maps cleanly to EDI transaction sets — essentially, an agentic envelope around EDI payloads — that accelerates everything. It gives the ERP vendors and procurement platforms a standards-based path instead of having to invent their own.
Without that, we get fragmentation. Every platform builds its own agentic format. The middleware layer has to translate not just between agentic and EDI, but between Coupa's agentic format and SAP's agentic format and Ariba's agentic format. That's a combinatorics problem, and it's exactly the kind of mess that eventually forces standardization — but only after years of pain.
Which is why I keep coming back to the EDI-to-API transition as the template. In twenty twelve, everyone said REST APIs would kill EDI. They didn't. What happened instead is that APIs grew up alongside EDI, and middleware platforms emerged to bridge them. Today, a company like Cleo or TrueCommerce handles both — they'll accept an API call from your e-commerce platform and translate it into an eight fifty for your supplier's EDI system. The agentic transition will almost certainly follow the same pattern. Coexistence through translation.
That's the practical answer to Daniel's question. The build-on-top path wins for the bulk of procurement volume because the switching costs are too high and the incremental value of replacing EDI at the execution layer is too low. The rip-and-replace path wins for complex strategic sourcing where EDI was never a good fit to begin with. And the whole thing gets stitched together by middleware that treats EDI as a legacy compatibility layer — invisible to the agents, invisible to the humans, but still doing the boring work of moving purchase orders through the global economy.
The boring plumbing wins again. At least for now.
If you're building one of these systems — and I know a lot of our listeners are either in the weeds on this or thinking about entering the space — the first rule is: don't be ideologically pure about EDI. The market doesn't reward purity, it rewards reduced friction. Build the EDI adapter layer first. Make your agent speak eight fifty and eight ten, even if it's through middleware that translates JSON intent into X12 segments. Platforms like Cleo and TrueCommerce already do this for APIs. Extend that pattern to agentic protocols and you've got a product enterprises can actually adopt without a multi-year migration.
For enterprise buyers, the move right now is to audit your procurement categories and split them. High-volume standardized stuff — raw materials, MRO, office supplies — that's your EDI-plus-wrapper tier. Don't overthink it. The value of agentic there is in the decision layer, not the transaction layer. But for strategic procurement — custom engineering, services, software — start evaluating agentic-native platforms now. The flexibility actually matters there, and the switching costs are lower because EDI was never a great fit for those categories anyway.
That split is going to define procurement architecture for the next decade. Get it wrong and you're either paying for negotiation flexibility you'll never use on commodity purchases, or you're trying to cram complex sourcing into rigid message formats that were designed for executing pre-negotiated catalogs.
For anyone watching this space from an investment or strategy perspective, the signal is simple. Watch SAP and Oracle. If they embed native agentic procurement into S/4HANA or Fusion — not just API access, but actual multi-agent negotiation — the rip-and-replace scenario gets real distribution. If they announce EDI-compatible agentic middleware instead, the hybrid path locks in. Either way, the ERP vendors are the kingmakers. Everything else is noise.
That's the practical side sorted. But there's one thing I can't stop turning over. The biggest unknown in all of this is whether agentic protocols will ever have their own EDI moment — a standardized, widely adopted schema for commercial transactions that everyone agrees to use. Without it, we get fragmentation. Every platform builds its own agentic format, the middleware layer has to translate between all of them, and the hybrid approach stops being transitional and becomes permanent.
That might actually be the most realistic outcome. A translation layer that sits between agentic intent and EDI execution, and just... Like the way SOAP and REST have coexisted for two decades now. Nobody loves the middleware, but it works, and the cost of replacing it is higher than the cost of maintaining it.
Which leads to the provocative version of this. The agentic procurement layer may ultimately make EDI obsolete not by replacing it, but by making it invisible. Agents handle all the translation. Humans never see the eight fifty messages again. The purchase order still exists, the invoice still flows, but they're generated and consumed by machines that don't care about the format. The question is whether that counts as evolution or extinction.
I think it's evolution. EDI doesn't need to die for the agentic layer to win. It just needs to become irrelevant to the humans. And honestly, it mostly already is. The people placing purchase orders at large enterprises aren't looking at EDI segments. They're clicking buttons in Coupa or SAP, and the EDI happens somewhere underneath. Extending that one layer further — so the agent clicks the button instead of the human — doesn't fundamentally change the architecture.
EDI becomes the TCP/IP of commerce. Nobody thinks about it, nobody configures it directly, but it's still carrying the packets. And the agentic layer becomes the application layer — where the decisions happen, where the value lives.
Which is a fitting place to land. Daniel asked whether we're building on top or ripping and replacing. The answer for the foreseeable future is: we're building on top, selectively replacing at the edges, and the whole thing will be held together by translators that nobody will ever praise but everyone will depend on.
The invisible plumbing wins.
Now: Hilbert's daily fun fact.
Hilbert: The word "natron" — a naturally occurring salt mixture used for preservation in ancient Egypt — shares a root with the modern chemical term "natrium," which is why sodium's symbol on the periodic table is Na. The natron trade routes through the Sahel, particularly through Chad during the interwar period, were so economically significant that local salt cakes were used as currency well into the nineteen thirties.
...salt cakes as currency.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you want to send us your own weird prompt, email the show at show at my weird prompts dot com.
We'll be back next week.
