Your Systems Don't Talk to Each Other. A Person Is the Integration.
Every company has one: the human middleware who reads one system and types into another. Here's how to work out whether AI is the fix or an expensive detour.
Ask a mid-market operations lead what slows them down and you'll get the same sentence often enough to set your watch by it: our systems don't talk to each other.
What they mean is specific. There's an ERP holding the record, a CRM holding the relationship, a warehouse system holding the physical truth, two vendor portals, and a spreadsheet that reconciles the parts none of them agree on. Between each pair sits a person, moving information across by hand. That person is the integration layer, and they're the most expensive middleware in the building.
The instinct now is to point AI at it. Sometimes that's right. Often it's a costly way to avoid a simpler decision, and knowing which case you're in takes about an hour.
Three questions that settle it
1. Do both systems have a usable API?
If they do, and the data model is reasonably clean, build the integration. A normal integration is cheaper, faster, more reliable and vastly easier to debug than anything with a model in it. It also doesn't drift when a vendor updates something. This is the answer more often than people expect, and it's unglamorous enough that nobody proposes it.
"Usable" is doing work in that sentence. An API that requires a $40,000 professional-services engagement to enable, or that returns data twelve hours stale, is not usable for a workflow that runs hourly.
2. Is the input structured?
If information arrives as a defined record with consistent fields, that's a mapping problem. If it arrives as a PDF, an email in prose, a screen a human reads, or a spreadsheet whose columns move around by customer, that's where a model earns its place. Language models exist precisely to handle input that resists a schema, and that's the entire technical case for using one here.
3. Does moving the data require interpretation?
Does someone have to decide what a line item corresponds to, whether two records are the same customer, or which of three plausible SKUs a customer's part number maps to? That's judgment, and it's the second thing that justifies a model. Pure transformation with no judgment is a script.
Two yeses out of three and AI is probably the right tool. One yes and you're likely looking at an integration project wearing a fashionable hat.
The fourth question nobody asks
Why do these systems exist separately at all?
Sometimes the answer is good: they're best-of-breed, they serve genuinely different functions, and integration is the correct architecture. Sometimes the answer is that two of them overlap by seventy percent because a department bought one without telling anyone, and the person in the middle exists to maintain the fiction that both are systems of record.
In the second case, no amount of AI will fix it. You have a governance problem presented as a technical one, and automating the reconciliation makes the duplication permanent by making it bearable. Companies spend six figures building an elegant sync between two systems that should have been one, and the sync becomes the thing nobody can ever remove.
What the middle layer looks like when it works
Where AI is the right answer, the shape is consistent. A layer sits between the systems and does four things:
- Reads whatever arrives, in whatever format, and extracts a structured record
- Validates that record against the system of record and flags what doesn't reconcile
- Writes the clean cases through the proper interface, with a full audit trail
- Escalates the rest to a person, with the discrepancy already identified
Notice what it doesn't do. It doesn't become a system of record itself. It doesn't hold state anyone depends on. If you switch it off, work slows down and nothing is lost, which is the property that makes it safe to run. A middle layer that quietly becomes authoritative is a new system nobody decided to buy.
The spreadsheet problem
There's always a spreadsheet. It isn't in any system, one person maintains it, and every integration proposal for six years has worked around it.
Before you automate anything, open it. What's in there is usually business logic that never made it into software: which customers get which terms, which SKUs can substitute for which, which suppliers are on informal hold. That logic is the actual integration, and the systems can't talk to each other partly because this knowledge lives in a file on someone's desktop.
Getting that into a form a system can use is often more valuable than the automation you were planning. It's also the single largest risk in the operation, because it has a retirement date attached to it.
What I'd do first
Take one flow, end to end. Pick the highest-volume one. Then map it as it actually runs, not as documented: every system touched, every manual step, every decision and who makes it, and how long each takes.
That map answers the three questions above by itself, and it usually surfaces something better than the project you were considering. About a third of the time the fastest win turns out to be a configuration change in a system you already own, which costs nothing and nobody had noticed because no one had ever drawn the whole flow on one page.
If the map says you need the middle layer, that's the automation work, and it starts by counting rather than by building. Tell me which two systems your team spends the most time between and I'll tell you which of the three cases you're in.