Integration and data contracts: the layer that decides whether AI agents work

This spring, the enterprise-AI industry shipped the wiring. Anthropic’s Model Context Protocol (MCP) gives an agent a governed connection into your systems of record. Google’s Agent2Agent protocol (A2A) is now in production across Microsoft, AWS, Salesforce, SAP, and ServiceNow, letting agents hand work to each other across platforms. MCP itself has crossed from experiment to enterprise infrastructure, with servers quietly wired behind firewalls to Salesforce CRM, Jira, Snowflake warehouses, and HR systems.

Connection was never the thing stopping agents.

TL;DR: When you ask the people actually deploying AI agents what’s in their way, the answer is integration with existing systems (46%) and data access and quality (42%) — not the model. The 2026 protocol wave (MCP, A2A) standardizes how agents connect to systems and to each other. It does nothing about whether those systems agree on what a record means or who owns it. That agreement — the data contract — is the unglamorous layer that decides whether enterprise AI works, and it’s still mostly manual.

The barrier is integration, and the people deploying agents say so

This isn’t a hunch. In Anthropic’s 2026 State of AI Agents report, a survey of more than 500 technical leaders, the most frequently cited obstacle to scaling agents was integration with existing systems, named by 46%. Data access and quality came second at 42%. Security and compliance, 40%. Model capability — the thing the entire market spends its attention on — didn’t make the list of top barriers.

Put that next to Gartner’s projection that over 40% of agentic AI projects will be canceled by the end of 2027, and the shape of the problem is clear. These projects aren’t dying because the model wasn’t smart enough. They’re dying at the seams between systems — the same place MIT researchers found most enterprise AI pilots stall before they ever reach production.

The protocols address the cheap version of the problem. The expensive version is still sitting there.

A protocol standardizes the envelope, not the contents

Here’s the distinction that gets lost in the launch announcements. MCP handles vertical integration — the connection between an agent and a tool or data source. A2A handles horizontal integration — one agent delegating to another. Both are genuine engineering achievements. Both are standards worth adopting.

But a standard for how two systems exchange a message says nothing about what the message means.

Wire an agent into seven systems of record this week. When System A reports an order as complete and System B reports the same order as open, the protocol has no opinion about which one is right. When the CRM’s “customer” is a billing account and the ERP’s “customer” is a legal entity, MCP will faithfully hand the agent both, and the agent will faithfully treat them as the same thing. A timestamp that means created in one system and last-modified in another passes cleanly through every layer of the stack and lands as a quiet, confident error.

This is the part no protocol fixes: meaning and ownership. Which system is the source of truth for this field? What does this value actually represent? Who reconciles the two when they drift? Humans answer these questions a hundred times a day without noticing — they infer the missing field, they know “complete” means invoiced not shipped, they ping the one person who knows. An agent inherits none of that tacit knowledge. It inherits only the data, and every disagreement baked into it.

What the 2026 wave solves — and what it leaves on your desk

Layer	What 2026 shipped	What it still doesn’t fix
Agent ↔ tools & data	MCP: a governed connection to a system of record	Whether the data behind the door is clean, current, and owned
Agent ↔ agent	A2A: a standard way for agents to delegate work	Whether two systems mean the same thing by “complete”
Discovery & security	Vetted MCP registries (e.g. Amazon’s central registry as both a discovery and a security tool)	Whether an approved server exposes a coherent contract, not just an endpoint

A vetted registry tells you which doors are approved. It says nothing about whether the rooms behind them are in order. That’s the gap between the announcement and the production incident.

The working version: legibility, then contracts, then the agent

None of this is an argument against MCP, A2A, or agents. It’s an argument about order of operations. The connection layer is now solved and commoditized — which means the differentiator has moved one layer down, to the part that was always the actual work.

Make the process legible first. Document what actually happens across systems — every field, its owner, and every exception — not the idealized flowchart. Most teams discover the real process is nothing like the documented one. This is the work that comes before any agent, and it’s the work I do first on every engagement.

Write the data contracts. For each piece of data passing between systems, define the shape and the meaning: the fields, the types, required-vs-optional, the source of truth, and what each value represents. A contract turns an agent handoff from a hope into an interface. This is the same lesson that shows up the moment any system exposes its stack as an API — the failure mode moves to your data quality, whether or not you were ready for it.

Reconcile before you connect. Where two systems disagree, decide which one wins and make it explicit. An agent connected to unreconciled systems doesn’t surface the conflict — it launders it into a decision.

Then add the agent. On a legible process with real contracts, MCP and A2A do exactly what they promise. The connection is reliable because the thing being connected is sound. You often find you need far less orchestration than the architecture diagram suggested — a pattern that holds whenever the process underneath is the real bottleneck.

I’ve built this layer the hard way — an internal MCP server giving AI agents governed access to enterprise data, on top of integrations across Salesforce, NetSuite, and ServiceTitan. The throughline of that work is the same every time: the model was never the bottleneck. The contract between systems was.

The operator read

The protocol war is real, and adopting the standards is correct. But it’s solving the connection problem — the cheap, now-commoditized layer. The 46% problem — getting your systems to agree on what a record means and who owns it — is still manual, still unglamorous, and still the whole job.

Standardizing the handshake doesn’t clean the data behind it. A data contract does. Build that, and the agents you connect on top of it finally do what the demo promised.