Integration Is the Hard Part, Not Intelligence

The most common disappointment with agents is described as a capability problem and is almost never one.

In the 2026 State of AI Agents report, 46% of respondents cite integration with existing systems as their primary challenge, and adoption is no longer limited by model capability.

For a vendor-side perspective on accountability and responsibility, see this guide from Monitask.

Why the model is not the bottleneck

Models became reliable enough at tool use — choosing which tool, with which arguments, and interpreting what came back. That threshold is what made agents viable at all, and it has been crossed for scoped tasks.

What has not been solved is reach. Most enterprises operate across ERP, CRM, service management, data platforms and custom systems, and fragmented data with brittle integrations quickly limits what an agent can usefully do.

An agent connected to nothing is a chat window. However good the model.

What the integration work actually is

Underestimated because it looks like plumbing and is not.

Access

Each system needs a way in — an API, a database connection, a service account. Many internal systems have none, or have one that was never meant for programmatic use.

Legacy systems are the recurring obstacle. The system holding the data you need is frequently the oldest one you have.

Identity and permissions

The agent needs its own credentials in each system, scoped to what it may do.

This is where projects stall at security review. Only 21.9% of teams treat agents as identity-bearing entities rather than extensions of human users or generic service accounts.

And it is per system. The permission model differs in each one. See agent identity.

Data shape

The agent needs to understand what it is looking at. Field names that mean something to a person who has worked there for years, codes with no legend, three tables that hold customer records for historical reasons.

Nobody documented this, and the documentation that exists is wrong in places nobody knows.

Data quality

An agent working with incomplete, incorrect or siloed data is restricted by exactly those limitations, and this pattern appears across enterprise, mid-market and small business alike, pointing to a need for centralisation before deployment rather than after.

Organisations discover their data problems by pointing an agent at them. Which is a useful and expensive way to find out.

Error handling

What happens when a system is down, slow, rate-limited, or returns something unexpected.

An agent that retries a failing call can generate substantial load and cost. See what agents cost to run.

Observability

Every action, logged, with attribution. Built alongside, not after — organisations that piloted without audit trail infrastructure are rebuilding permission and logging architecture before they can pass security review.

What the Model Context Protocol changed

One of the structural reasons agent adoption accelerated is that the Model Context Protocol standardised how agents connect to enterprise data.

What it solves: a common interface, so a tool exposed once works with any compliant agent, instead of bespoke work per pairing.

What it does not solve: whether your systems have interfaces at all, whether your data is clean, what the fields mean, or who is allowed to do what.

The connector standard removed one layer of work. The layers underneath it are the same as they were.

Estimating the work honestly

Assume integration is the project, and the agent is a component.

Count the systems. Each is separate work — access, credentials, permissions, data understanding, error handling.

Check which have usable interfaces. The ones that do not will dominate the timeline.

Ask who understands the data. If the answer is one person who has been there fifteen years, that is your dependency.

Assume the data is worse than described. Not cynicism; it is the consistent finding.

And budget for the security review, which is where projects meet the identity and logging requirements they postponed.

Reducing it

Start with one system. An agent doing something useful with one clean data source beats a stalled project spanning six.

Prefer systems that already have interfaces.

Read-only first. Removes most of the permission and risk work while you learn whether the thing is useful at all.

Fix data quality before scope. A narrow agent on clean data works; a broad one on messy data does not. For broader independent background, see NIST AI Risk Management Framework.

And treat the first deployment as finding out what the integration work actually is, rather than as the deliverable.

For small teams

The same problem at smaller scale, and frequently easier.

Modern tools have interfaces, so a small business running current software may have less integration work than an enterprise with decades of accumulated systems.

The constraint is usually credentials and permissions rather than technical access. Give the agent its own accounts, scoped narrowly, that you can revoke.

And the data quality problem is the same. A spreadsheet with inconsistent client names is exactly as limiting as an enterprise data warehouse with the same issue.

See agents for a one-person business.

Questions for a vendor

What does it connect to out of the box, and what needs building?

How does it authenticate to each system — its own identity, or borrowed credentials?

What happens when a connected system is unavailable?

What does it log about each action?

And what have your customers found took longest? The honest answer to this is integration; a vendor who says something else is selling.

The short version

46% cite integration as the primary obstacle — model capability is no longer the limit.

An agent connected to nothing is a chat window, however good the model.

The work is access, identity, data shape, data quality, error handling and logging — per system.

MCP removed the connector layer. The layers underneath are unchanged.

And organisations discover their data problems by pointing an agent at them, which is an expensive way to find out.