Your Agent Is Only as Good as the APIs It Can't See

The reason most enterprise AI agents never reach production is not the model. It is the integration layer. A December 2025 survey of 3,400 developers found 70% reporting integration problems with their agents. A Tray.ai survey of 1,000+ enterprise technology professionals found 90% saying integration with organisational data is critical, but 86% saying they will need to upgrade their existing tech stack to deploy agents. The bottleneck is not reasoning. It is wiring an agent into the ERPs, CRMs, and legacy systems that actually run the business. Those systems were designed for human operators with patience, context, and judgment, not for autonomous callers operating at machine speed. Read access takes days. Write access takes quarters. Most pilots prove reads. Production requires writes. That gap is where the project dies.

Every agent demo runs against a clean REST API. The data is structured. The authentication is OAuth. The response comes back in milliseconds. The agent reasons, calls the right tool, and produces the answer.

Then the team tries to connect that same agent to the system of record.

The ERP has a SOAP endpoint with 340 operations and a WSDL that nobody has fully documented. The CRM requires session-based authentication that times out after eight minutes. The finance module accepts a fixed-width file at 2 AM and produces output four hours later. The warehouse system has no public API at all. Just a screen someone built in 2011 that nobody is willing to touch.

The model is fine. The integration is not.

This is not an edge case. It is where the enterprise value lives. The systems that hold the customer master, the order book, the general ledger, and the inventory position are rarely the systems with a modern API. And an agent that cannot reach them is an agent that can summarise documents and little else.

A December 2025 survey of 3,400 developers building AI agents, conducted by Langbase, found that 70% reported problems integrating their agents with existing systems. A separate Tray.ai survey of more than 1,000 enterprise technology professionals found that 90% said integration with organisational data is critical to success, but 86% said they will need to upgrade their existing tech stack before they can deploy agents. A CrewAI survey of 500 C-level and senior leaders at organisations above $100 million in revenue found that data readiness and integration ranked as the number-one barrier to scaling agentic AI at 35%, ahead of talent at 33% and budget at 25%.

The industry talks about these numbers as if they are a model problem. They are not. The model is on a commoditization curve that integration simply cannot follow. Inference for GPT-4-class performance has fallen more than 90% in two years. Integration is where a company's own processes, exceptions, quirks, and operational history all end up getting wired together in ways that nobody outside the organisation can replicate. That work does not get cheaper when the model gets cheaper. It does not get easier when the model gets smarter.

The integration layer is the only part of agentic AI that is not going to be abstracted away by the next framework. And it is the part most AI strategies have not bothered to look at.

The Read/Write Gap

Here is the distinction that most integration discussions miss.

Reading is cheap. An agent that can query a system of record, pull a status, retrieve a record, or summarise a document needs one credential and a query. That is a read integration. It takes days to build. It demos well. It is what most pilots prove.

Writing is expensive. The moment an agent has to create a purchase order, adjust a ledger entry, or cancel a shipment, four new requirements appear at once. The call must be idempotent, so a retry after a timeout does not duplicate the record. The action must be reversible, so a wrong decision has a compensating path. The actor must be identifiable, so an auditor can answer months later which agent, acting for which person, under which policy, made the change. And the whole sequence must be visible in a form that your compliance team will accept.

Most systems of record older than fifteen years expose none of these four things. They were built for human operators who could see that a retry had already been submitted, who knew which voice to call to reverse a wrong entry, who could explain themselves when asked. The interface assumed a person in the loop. The person is now gone from most steps. The interface has not changed.

This is why read integrations take days and write integrations take quarters. The model is irrelevant to that difference. The gap is engineering work. It is a normal integration project with a normal integration timeline. It is measured in quarters.

The CrewAI survey data is the clearest signal I have seen on this. When asked what blocks scaling, respondents ranked data readiness and integration first. When asked what matters most in choosing an agent platform, "ease of integration with existing systems" ranked second at 30%, well ahead of "time to value" at 2%. The people who have tried to ship this are telling you where the work actually lives. The people who have not tried are still asking which model to use.

What the Integration Layer Actually Has to Do

The agent-era teams are not discovering anything new here. They are rediscovering, from first principles, what thirty years of enterprise integration already figured out. The difference is that the old integration patterns assumed a human in the loop. The new ones cannot.

The integration layer now has to do four things on its own. None of them are optional. None of them show up in the RFPs I see getting written today.

Semantic stability. If an agent relies on a field called customer_id, that field has to still mean what it meant six months ago when someone wrote the prompt. Most enterprise systems cannot guarantee that. Definitions drift. Schemas get extended in silence. The rough edges end up buried under glue code nobody wants to touch. Agents find the drift and act on it anyway, because they do not know any better. Contract testing and versioned schemas are not a nice-to-have in this environment. They are the floor.

Observability at the decision layer. A log that says "HTTP 200" is not observability. When something goes wrong, you need to be able to reconstruct why the agent chose that tool, what context it had in front of it, and what else it could have done. Without that, you cannot trace a bad outcome back to a root cause, and you have no basis for trusting the system with anything more consequential later. Most incidents in agent systems are reconciliation problems, not reasoning problems. You need to be able to answer, months later, what the agent proposed, what the integration layer accepted, what the legacy system recorded, and where those three disagree.

Bounded authority. An agent that can find and call any API on your network is a standing risk. The integration layer has to actually enforce what an agent is allowed to do. Not just describe it in a policy document. People tend to file this under governance. It is not governance. It is an integration problem that governance sits on top of. The distinction matters because the enforcement has to live at the boundary, where the integration layer controls the call, not in a prompt that the agent can reason past. This is the same architectural principle I have written about elsewhere: the LLM reasons, and something deterministic enforces what actually runs. The integration layer is the enforcement plane for the agent's reach.

Graceful degradation. Upstream systems return partial results, stale values, and malformed payloads all the time. When they do, the integration layer needs to decide what the agent gets back: a safe default, an explicit error, or a handoff to a human. Leaving that decision to the agent's own judgment is the single most common failure I see in production right now.

These are not features. They are the cost of removing the human from the loop. The human was the integration layer. The human caught the malformed response. The human knew not to retry the duplicate. The human explained the change when the auditor asked. You cannot remove that person and expect the same system to keep working.

What Actually Works

The pattern that works is not a model selection. It is not a framework. It is not a protocol. It is an integration discipline that most teams are still treating as an afterthought.

The first thing is to stop treating the legacy system's interface as the agent's interface. A SOAP endpoint with 340 operations designed for a system-to-system caller who already knows which operation it needs is not a tool surface for an agent that has to choose. Exposing all 340 operations as tools is a recipe for context explosion, operation-selection degradation, and a security boundary that is the union of everything those operations can do. For an ERP, that is close to unlimited.

What works is an intermediate capability layer that exposes business capabilities rather than technical operations. Not a new idea. This is what API management has been arguing for since the beginning. Agents make the argument decisive rather than aesthetic. If your agent's tasks need eleven distinct pieces of information, you need roughly eleven capabilities. Not 340 operations. Not one god-tool with a mode parameter. Task-shaped granularity, designed from the agent's task decomposition, not from the legacy system's structure.

The second thing is idempotency where the legacy system cannot offer it. An agent will retry. Networks time out. Orchestrators restart. A retried create request against a legacy endpoint produces a second purchase order, a duplicate journal entry, an over-issued shipment. The fix is a caller-supplied idempotency key that the capability layer stores and honours. Legacy systems almost never provide this. The capability layer has to own the deduplication table itself. This is unglamorous. It is also what stops an agent retry from double-posting a journal entry at 3 AM.

The third thing is a compensating action for every verb you expose. Most legacy transactions cannot be rolled back after commit. The practical answer is a compensating action: a credit note against an invoice, a cancellation against an order, a reversal entry against a ledger. Write down the compensating action for every verb you expose. If a verb has no compensating action, it does not get agent access this quarter. This is not caution. This is how you accumulate the evidence needed to justify raising autonomy later.

The fourth thing is to read broadly first and write narrowly second. Read capabilities are lower-risk, easier to govern, and deliver a surprising share of the value. An agent that can answer "what is the status of this order across our four systems" is genuinely useful and cannot damage anything. Build the read surface across as many systems as you can reach. Then add writes one verb at a time, through the existing validated path the business already uses — the same service the current application calls, with the same validation and the same audit. Do not build a new write path for the agent. A new write path means new validation logic, new audit gaps, and a second place where business rules live.

The Organisation Problem Behind the Integration Problem

The hardest part of integration is not technical. It is organisational.

Granting an autonomous agent write access to a system of record requires a security review cycle, a liability decision, and system-owner buy-in. Those things do not compress for AI projects. They run on governance timelines, not engineering timelines. Each system in scope adds its own review queue. Those queues are not under the control of the engineer building the agent.

The moment a blocker is rooted in system-owner incentives or governance accountability rather than technical configuration, escalation is not a failure. It is the correct project management response. Engineering can fix a missing API endpoint. It cannot motivate a system owner who has every reason to protect their ERP and none to open it.

This is why the integration surface audit needs to happen in week one, before any date is agreed. Enumerate every system the agent must read from and write to. Assign each one a readiness tier. Flag every Tier 3 and Tier 4 system as a timeline risk immediately. Audit the auth and permission requirements for each. For each system, answer: does a service account exist, is OAuth delegation supported, and who owns security sign-off. Unanswered questions are risk flags, not to-dos. The integration surface is also the governance surface. The boundary between what an agent can reach and what it can decide alone is not a binary switch, and the integration layer is where that distinction gets built or ignored.

If your next scoping call surfaces more than one Tier 3 system or a missing system owner, you have found the real delivery risk. That is the moment to reset the timeline conversation, not after the SOW is signed and the demo is in production.

Why This Changes the AI Strategy Conversation

The strategic implication is uncomfortable for anyone who has been betting on model selection as the differentiator.

The companies pulling ahead are not the ones with the best model strategy. They are the ones that started treating integration as an engineering discipline three or four years ago, back when most of their peers were still running AI as a slide-deck line item. OpenAI and AWS launched their Stateful Runtime Environment in April 2026. A direct commercial bet on this layer. Two of the biggest AI infrastructure players in the industry are willing to stake product roadmaps on the thesis that what blocks enterprise agentic AI is integration, not model reasoning.

Mount Sinai's April 2026 OpenEvidence rollout across seven hospitals is another useful data point. It worked because the AI sat inside the Epic workflow the clinicians were already using. Nobody had to open a new tab. The AI that scales is the AI that arrives where people already are.

The organisations that are going to end up in Gartner's 40% cancellation figure are not the ones with the wrong model. They are the ones spending on model selection while integration debt quietly compounds underneath them — the undocumented SOAP endpoints, the session-auth systems that time out, the batch jobs that do not do request-response, the screen drivers from 2011 that break when the screen changes. That debt does not show up in a model benchmark. It shows up in the calendar, in the security review queue, and in the quarter when the pilot is still in staging and the team is being asked about ROI. This is the same gap I have written about before from the other side: the pilot proves the model works. It tells you nothing about whether the enterprise does. Integration is the part of that question the pilot was never designed to answer.

Frequently Asked Questions

Why do AI agents fail at integration more than at reasoning?

Because reasoning is what the model was built for. Integration is what the enterprise was not built for. Most enterprise systems were designed for human operators with patience, context, and judgment — a person who could see a malformed response, know not to retry, and explain a change to an auditor. Agents remove that person from most steps. The integration layer has to do those things itself, and most enterprises have not built it yet. The Langbase survey of 3,400 developers found 70% reporting integration problems. The model was not the thing breaking.

What is the difference between a read integration and a write integration for an AI agent?

A read integration gives an agent permission to query a system and retrieve data. It takes days to build and demos well. A write integration gives an agent permission to create, amend, or reverse a record in a system of record. It requires an idempotency mechanism, a compensating action for every verb, a non-human identity that survives audit, and a visibility layer that satisfies compliance. Most systems of record older than fifteen years expose none of these. That is why read integrations take days and write integrations take quarters. Most pilots prove reads. Production requires writes.

Does MCP solve the legacy integration problem?

No. MCP standardises how an agent discovers and calls a tool server. It says nothing about what that tool server integrates with. If your ERP has no transactional API, MCP gives you a consistent way to call an interface that does not exist yet. The protocol removes bespoke glue between the model and the connector, which is a real saving. The connector itself remains the expensive part. MCP does not create the tool. It only standardises reaching for it.

What is a capability layer and why does an agent need one?

A capability layer is an intermediate service that exposes business capabilities — the things the agent actually needs to do — rather than the raw technical operations the legacy system exposes. A SOAP endpoint with 340 operations designed for a caller who already knows which one it needs is a bad tool surface for an agent that has to choose. A capability layer exposes roughly the number of capabilities the agent's tasks require, with semantics resolved in code rather than forwarded to the model, with idempotency where the legacy system cannot offer it, and with compensating actions for every write verb. It is unglamorous. It is also what makes agent access to legacy systems safe enough to productionise.

Why do write integrations take so much longer than read integrations?

Because writes require a safety envelope that most legacy systems were never designed to provide. A read just queries. A write has to be idempotent so a retry does not duplicate the record, reversible so a wrong decision can be compensated, attributable so an auditor knows which agent made the change for which person under which policy, and visible in a form that the compliance team will accept. Those four things are properties of the interface between the agent and the system of record. In a legacy estate, that interface usually does not exist yet. Building it is a normal integration project with a normal integration timeline. It is measured in quarters.

How should we sequence agent integration work to avoid the pilot-to-production trap?

Start with one workflow that has measurable money attached. Build the capability layer for that workflow alone — two or three verbs and their compensating actions. Run it behind human approval for a quarter while you record the agent's error rate by verb. Then relax approval only on the verbs whose failures are cheaply reversible. Do not attempt a full modernisation before any agent work — that delays value by years. Do not attempt agent work before any integration — that produces a demo that cannot be promoted. The narrow vertical slice tests the integration design and the business case at the same time.

What is the right question to ask about AI agent integration instead of "which model should we use"?

The better question is: who owns our integration layer, what is their budget, and can they show you in writing what every agent in our environment did yesterday? If any of those answers is unclear or missing, the model you pick is not what is going to decide how this plays out. The integration layer is where the compounding value and the compounding risk both live. It is the one part of agentic AI that cannot be commoditised by model progress, because it is made of your own processes, exceptions, quirks, and operational history wired together in ways that nobody outside your organisation can replicate.

Your agent's reasoning is only as useful as the system it can safely act on — and most enterprise systems were never built to be acted on by anything except a person with a login, a phone, and the patience to work through a screen someone built in 2011.

The model is a commodity. The integration layer is where the work actually lives.

Filed under: Agent-Native Architecture / Enterprise AI Transformation