Babel
AI doesn't break in operations because the model can't read. It breaks because the documents stopped speaking the same language.
By Kelly Breakstone Roth, Co-Founder & CEO of Prysmic · April 2026 · 6 min read
Babel teaches what holds a project together by taking it away. Bricks, plans, materials — all in place. What goes is invisible and load-bearing: the shared language between every part of the work. The most ambitious project in human history dissolves on its own — intact, abandoned to seventy tongues that can no longer reach each other.
This is what is happening inside most AI projects in operations today.
The model is capable. The integrations are built. The data exists. The systems are connected. The team is willing. The project still doesn't click — because the data is full of inconsistencies. The same supplier appears under three names across three systems. The same SKU lives in two formats across two documents. The same shipment is carved into pieces across files that never reference each other. Hundreds of small mismatches, accumulated over years, invisible until something tried to read them all at once.
These are five of the most common. None are exotic. All are familiar. All quietly determine whether AI in operations compounds value or stalls.
How we got here
Operations documents grew up the way operations did: in pieces, by hand. The packing list comes from a supplier whose template hasn't changed in fifteen years. The freight invoice comes from a forwarder still doing it the way they did when fax was the medium. The vendor master in your ERP was set up when procurement onboarded a supplier — and procurement, finance, and merch all spelled the supplier's name slightly differently, and no one ever merged the records.
This isn't only a legacy problem. A new supplier signs on through a modern portal with its own SKU conventions. A merch team launches in a new geography. A brand acquires a smaller company and inherits its naming system whole. Every layer of growth — old or new — adds another quiet variant. Multiply across forty, sixty, two hundred suppliers, and you get the result: a working system, populated by competent people, that quietly accumulated inconsistency every year. The data is there. The connections were never built.
1. The reference problem
The address without the apartment number
A shipment arrives with fifty units of one SKU. Two different purchase orders include that SKU. Without a line-level reference on the invoice or packing list, there's no way to know which units belong to which PO. It's like sending forty packages to an apartment building with no apartment numbers on the boxes — the delivery arrives, but nobody can sort it.
Now make it harder. Suppliers rarely ship a full PO at once. The same SKU might appear on three POs, with partial quantities arriving across multiple shipments over weeks. Without line-level references, every reconciliation becomes a guess. AI can't reconcile guesses.
The fix: every cross-reference between documents needs to reach the line. Talk to your suppliers. Ask them to print the PO number alongside every line item on commercial invoices and packing lists, not just at the document header. Most templates can be updated within a week. The hard part is keeping every supplier consistent over time, and knowing in advance which ones haven't done it yet.
2. The naming problem
Same product, two names
Like calling someone Bob in one room and Robert in another. Same person, different name, no way to merge the records without help. The supplier prints their internal SKU on the invoice. The master catalog uses a different SKU. Same product, different strings.
AI reads both perfectly. Without a translation between them, it has no way to know they refer to the same item. A reconciliation that should take seconds becomes half an hour of manual lookup, multiplied across hundreds of shipments, growing as the catalog grows. Conceptually simple. Infinite at scale.
The fix: build a cross-reference table that maps each supplier's SKU codes to your master SKU. For a stable vendor base, this is achievable in a quarter. The hard part is keeping it current. SKUs get retired, repurposed, and repackaged. New vendors arrive every month with their own conventions. The table has to drift with them.
3. The identity problem
One supplier, four names
The same supplier shows up four ways. The legal entity in full on the invoice. A four-letter internal code in the ERP. The supplier portal's own handle. An email signature with a typo that's been there for years. Same company. Four strings.
AI sees four suppliers where there's one. Performance metrics get split. Spend rollups underreport. The system can't reason about a supplier's behavior across shipments because it doesn't know they're all the same supplier. Every analysis runs on a fractured view.
The fix: maintain a supplier alias table. One canonical name per vendor. Map every variant — legal entity name, supplier portal handle, internal code, common typos — to it. Designing the table is straightforward. The hard part is maintenance. New suppliers arrive every quarter. Existing ones rebrand or get acquired. Email signatures change without notice.
4. The context problem
A list of IDs without names
A class roster of student IDs with no names attached — just numbers. You know how many students are in the class. You can't tell who is who without another document, somewhere, that maps the IDs to identities.
This is what most product catalogs look like. A list of SKUs and quantities, with no descriptive layer behind them — no description, no category, no weight, no dimension. AI looks at a packing list, sees a SKU, and has nothing to anchor it to. A typo, a column shift, a different unit of measure, and the match breaks silently — which is exactly when AI fails confidently.
The fix: enrich your product catalog. SKU + description + category + dimension + weight + supplier + country of origin. The data usually exists somewhere — a merch spreadsheet, a forgotten PIM, a supplier portal — but no single record connects it. The work is making those connections, and keeping them current as new products launch and existing ones change suppliers.
5. The format problem
Same number, different units
A kitchen where one cook measures in cups, the next in grams, the third by handful. All correct. None compatible without conversion. Operations documents have the same problem — and at scale, the conversion never ends.
The packing list shows "40,000 cartons." The PO was written in "each." The invoice prices "per unit," but the unit is sometimes a SKU and sometimes a kit — a jar, a lid, and a cap, sold together. One supplier sends amounts in USD with the FX rate noted; another sends invoices in local currency without it. A third varies its schema quarter to quarter — country-of-origin appears on one invoice and disappears from the next. Same product, same amount, different format. Every shipment turns into a translation exercise.
The fix: standardize what you can, translate what you can't. With suppliers you have leverage with, push for consistent units, currencies, and schemas. For everyone else, build a conversion layer that maps 40,000 cartons of supplier A's packaging to 960,000 each in your master, and converts local currencies to USD at the right historical rates. The hard part is the translation never finishes — every new supplier, every new geography, every new product introduces a new conversion rule.
All five problems share one root: your systems use different names, codes, and formats for the same things. Fixing them is the work of getting your data to agree with itself again.
That work isn't preparation for AI. It is the AI work.
And it has no end state. Suppliers change templates. SKUs get retired and reissued. Acquisitions bring entire foreign vocabularies overnight. Whatever shared language you build today may drift by next quarter.
What ends the cycle is a different shape of system. A layer that lives between your existing tools and runs continuously — reading every new invoice, every new packing list, every new supplier email, updating the maps in real time. Reconciliation as a function instead of a project. Always on. Cross-system. Cross-document. Learning as the operation changes.
Build that, and AI compounds. The same translator that resolves this week's mismatch catches next week's. The shared language gets richer, not staler. Every shipment teaches the system. Every new supplier strengthens it instead of breaking it.
Babel ended in silence because the language fractured. Every operation at scale arrives at the same edge. The best operators we work with stopped thinking of this as a data problem a long time ago. They think of it as infrastructure — the kind that runs in the background and makes everything else possible.