I watched the same integration failure repeat for years.

Every integration project I worked on started the same way. A customer needed SAP Business One connected to their eCommerce platform, or their CRM, or their warehouse system. And every time, the implementation team started from zero with mapping fields, translating data models, writing custom logic to handle the differences between what SAP calls a “Business Partner” and what Shopify calls a “Customer.”

The work was never reusable. The mappings we built for one customer couldn’t transfer to the next, even if they were running the same systems. Every project was a fresh start. And every project carried the same risk: one mapping error in production, and orders go missing, inventory drifts, invoices don’t reconcile.

After enough deployments, you stop seeing it as a technical problem. It’s a language problem. These systems don’t fail to connect because the APIs are broken. They fail because there’s no shared vocabulary. No agreement on what a “Customer” or an “Order” actually means across system boundaries.

The platforms that dominate integration today, the big iPaaS vendors, the automation tools, the connector marketplaces, are genuinely good at one thing: moving data from point A to point B without dropping it. That part is solved. What none of them solve is the part that actually eats the time. They hand the customer the hard question and walk away: what does this data mean at each end, and how do you translate between the two?

It’s why so much of what gets sold as “integration” isn’t really integration at all. Roughly 40% of it is automation, the when-this-happens-do-that workflows that AI agents will soon handle on their own. The real work is the other 60%: keeping records in sync both ways, reshaping data into a common form, handling compliance rules, and managing state as things change. And that needs something the industry never actually built: a shared business language.

OneEnterprise started with a question that felt almost too simple: what if we defined, once, what a Customer looks like across every system? Not in SAP’s schema. Not in Shopify’s schema. In a canonical business language that both systems could translate to and from.

We called it the OneEnterprise Specification: OES. It defines canonical business objects like Customer, Order, Product, and Invoice in a vocabulary modeled from years of real-world deployments. Not academic theory. Not a committee’s best guess. Patterns extracted from hundreds of actual integrations, across dozens of industries, in markets from Latin America to DACH.

Then we built the Business Connectors, the components that translate between each system’s native language and OES. Map once to the canonical model, and every system that speaks OES becomes interoperable. Add a new system, and it inherits the entire vocabulary immediately.

And when the Model Context Protocol (MCP) emerged as the standard for AI-to-system access, we saw the third piece of the architecture fall into place. OES gives AI agents something no other platform offers: the ability to reason about business data across system boundaries, in business terms, safely.

MCP is now the de facto standard for AI-agent-to-tool communication. Every major platform (Anthropic, OpenAI, Microsoft, Google, AWS) has adopted it. The Agentic AI Foundation under the Linux Foundation governs its evolution. The protocol question is settled.

But protocol is just the transport layer. MCP tells AI agents how to talk to systems. It doesn’t tell them what to say. That’s the semantic layer, and it’s wide open. Right now, every platform is building its own proprietary interpretation of what business data means. SAP defines it one way for Joule. Microsoft defines it differently for Copilot. Salesforce has yet another model for Agentforce.

If this fragmentation takes hold, the AI era will repeat the same mistakes the integration era made. Proprietary data models. Vendor lock-in. Custom translation at every boundary. The technology changes; the problem stays the same.