Hank Delimitski Has Seen This Before

Somewhere between the first EDI transaction in the 1960s and the first AI agent filling out a supplier portal form last year, a generation of integration engineers built the bilateral plumbing of B2B commerce. They negotiated standards, wrote mappings, managed exception queues, and watched informal workarounds spring up around every formal connection they built. Most of them are retired now, or close to it. The knowledge they carry about what formal integration actually cost, why it broke, and what the workarounds were compensating for is fading just as a new wave of automation arrives to cross the same boundaries.

Hank Delimitski retired in 2022 after thirty-one years building and maintaining EDI connections, middleware pipelines, and early API integrations for a regional food distributor in central Ohio. His LinkedIn profile, last updated three years ago, describes his expertise as "making computers agree with each other, or at least stop arguing." When we reached him, he'd been following the enterprise agent conversation with what he described as "déjà vu, but with better marketing."

We spoke over video. Behind him, a shelf held a row of three-ring binders: Implementation Guides from trading partners he'd connected to across the 1990s and 2000s. He reached for one of them twice during our conversation, holding it up to the camera like evidence in a trial nobody had convened.

Hank is a composite character. His experience is drawn from documented industry patterns and practitioner accounts, but Hank himself is, regrettably, fictional. His opinions are entirely his own, which is convenient since he doesn't exist.

People hear "integration engineer" and picture someone building things. What were you actually doing most days?

Hank: Building was maybe the first three months of any project. After that? You're a zookeeper. Feeding the animals, checking the fences, making sure nothing's escaped overnight.

Every morning I'd check the exception queue. That's the list of transactions that didn't make it through cleanly. A purchase order rejected because a field was formatted wrong. An invoice that bounced because the item code didn't match what the trading partner expected. The first thing I looked at was the 997, the functional acknowledgment in X12, which is basically a receipt that says "we got your document and it parsed."¹ No 997 back? Something's wrong. Wrong 997? Something's worse.

Then there was the maintenance cycle. A trading partner updates their Implementation Guide, which is their specific version of the EDI standard: the document that tells you exactly which fields they want, which ones they ignore, which ones they've decided mean something the standard never intended.² When that guide changed, I changed my mapping. Tested it. Tested it again against their test environment. Went live and watched the queue for two weeks to make sure nothing was silently wrong.

Multiply that by every trading partner we had. That was the job.

I once did the math. We had about forty active trading partners, which meant something like eight hundred distinct integration touchpoints to maintain. One organization documented that adding just four new data fields across their integration landscape required updates to nearly 1,500 touchpoints and cost roughly a million dollars.³ People outside my department would say, "I thought we already built that." Yeah. We did. Nobody budgets for the keeping-it-built part.

What did a typical failure look like?

Hank: The scary ones were quiet.

A mapping that's obviously broken, the transaction gets rejected, the 997 comes back with an error code, you fix it. That's Tuesday.

The expensive ones were the transactions that looked fine. Parsed, flowed, landed in the ERP. But the data meant something slightly different than what the other side intended. I had a situation where "unit of measure" in our system was "case" and in the partner's system it was "each." Both valid codes. The mapping didn't flag it. We shipped cases when they wanted individual units. For weeks.⁴

The chargeback was... educational.

If it was this painful, why did companies bother?

Hank: Walmart told you to.

That was the business case.

But workarounds existed alongside the formal systems anyway.

Hank: Always. Because the formal channel had a queue. You needed testing, certification, sometimes weeks of lead time before a new connection could handle live transactions. Meanwhile, the purchase order was already sitting there. The buyer needed product on shelves by Friday.

So someone picked up the phone. Someone sent a fax. Later, someone emailed a spreadsheet. And here's the thing. By the time the EDI connection was finally live and tested and certified, that spreadsheet had six months of institutional momentum. People trusted it. They'd built their morning routine around it. The formal pipe was technically superior in every measurable way, and it still had to compete with a workaround that a procurement clerk had been using since March.

You've been watching the conversation around AI agents in enterprise. What looks familiar?

Hank: [reaches behind him, holds up a binder]

This is a Walmart Implementation Guide from 2004. Sixty-some pages. It specifies every field in every transaction type we exchanged. What's required, what's conditional, what the qualifier codes mean, how to handle exceptions, who to call when something fails.⁵ This was the agreement. Both parties signed off on it before a single byte moved.

Now I watch a demo of an agent navigating a supplier portal, filling in forms, pulling invoice data. And it's impressive. Genuinely. But I keep waiting for someone to show me the equivalent of this binder. What's the agreement? When the agent submits a form and the portal accepts it, is that acceptance? Operationally? If the data's wrong, who owns the exception?

The mapping problem hasn't gone anywhere either. "Active customer" in one system and "account in good standing" in another. Those look equivalent until the day they aren't. A person copying data between two screens could catch that mismatch. They were doing semantic reconciliation, even if nobody called it that. An agent doing the same thing is doing it probabilistically, without a spec, without a test cycle. It'll work great until the moment it doesn't, and when it doesn't, there's no binder to open.

What do you think the agent conversation is most underestimating?

Hank: Exception ownership. I keep coming back to it.

Finding the technical cause of a failure answers one question. Knowing who owns that failure, who's responsible for resolving it, who eats the cost, who changes their system: that's the question that actually matters. We spent decades building infrastructure for that in EDI. The 997 acknowledgment. Chargeback processes. Dispute resolution procedures written into the trading partner agreement.

I don't see anyone building the equivalent for agents. Everyone's focused on what the agent can do. Nobody's building the infrastructure for what happens when it does the wrong thing.

And it will. Not because the technology is bad. Because the data is messier than anyone realizes, and the semantic gaps between systems haven't gone anywhere.⁶

Any last thoughts for the people building agent systems?

Hank: Do your data archaeology before you automate anything. Find out how many ways your organization describes the same product, the same customer, the same address. Because if you don't, you're just propagating your mess at machine speed.

And I mean this genuinely: find someone who's maintained an EDI connection for ten years. Buy them lunch. Ask them about their exception queue. You'll learn more in that conversation than in any demo I've seen.

He pauses, glances at the binder still in his hand.

Footnotes

1. The ANSI Accredited Standards Committee X12, chartered in 1979, defines the 997 Functional Acknowledgment as the standard transaction set confirming receipt and syntactical correctness of an EDI document. iWay Information Center ↩

2. Implementation Guides customize the base X12 standard for specific trading partnerships, specifying required segments, conditional fields, and partner-specific business rules that go well beyond what the standard itself defines. IntuitionLabs, "X12 EDI Standard Guide" ↩

3. A documented case: when one organization upgraded Oracle Financials, adding four new data fields across approximately fifty-five point-to-point integrations required updates to nearly 1,500 integration touchpoints, over a year of development, and roughly $1 million in cost. Chris Tiernan, "Why Point-to-Point Integrations Are Evil" ↩

4. "One of the most costly EDI issues is one nobody knows about" — silent mapping errors that produce technically valid but semantically incorrect transactions. Cleo, "Common EDI Issues" ↩

5. EDI Trading Partner Agreements specify data formats, transmission protocols, security measures, and — critically — guidelines for resolving disputes, managing errors, and handling exceptions. EDI Academy ↩

6. "For most companies, your data is messier than you realize" — with product codes varying, customer numbers overlapping, and pricing exceptions living in spreadsheets. ihateedi.com, "How Much Does EDI Cost?" ↩