Do You Still Need an Integration Platform When Agents Can Call APIs?

An agent triggers a refund. The payment API times out. The agent, reasoning that the refund probably failed, retries the call with slightly different wording. The customer receives two refunds and a support ticket. No idempotency key was passed because the agent does not naturally generate them.

This is the demo versus production asymmetry. Every agent integration demo runs on the happy path. The API responds in 200 milliseconds, the schema matches, the auth token is fresh. Production is the unhappy path with a time limit.

The question comes up in steering committees now: if agents can call APIs and string together tool calls, what are we paying the integration platform for? It is a fair question. The uncomfortable answer is that you are paying for the flows where the agent’s creativity is a liability.

The agent can call the API. That was never the hard part. Writing a prompt to pull a record from a CRM, transform the JSON, and push it into an ERP takes ten minutes in a sandbox. The enterprise deployment takes six months, mostly because the sandbox has no concept of a dead-letter queue. Integration platforms were built for the unhappy path. Agents are built for the demo.

When a vendor updates an API and breaks a field mapping, an integration platform fails deterministically. The pipeline stops. The error is logged. When an agent encounters an unmapped field, it infers the meaning from context and maps it anyway. Silent data corruption is always more expensive than a hard failure.

Consider the retry semantics. An integration platform retries with the exact same payload and an idempotency key. An agent retries with plausible variation because the prompt instructs it to accomplish a goal. In a transactional context, an agent retry is just a new request with a creative excuse. If a flow cannot tolerate being run twice, do not let an agent own it. Idempotency is the mechanical fault line.

Then there is the audit trail. When an auditor asks why a customer record changed, or how a transaction moved from the trading system to the ledger, the integration platform provides a flow instance, a payload, a timestamp, and a responsible party. The agent platform provides a chat transcript. The transcript shows what the agent intended to do. The auditor wants a ledger of what actually happened. A chat transcript is evidence of an interaction, not a record of system state. If the routing logic is probabilistic and depends on the model’s interpretation of the system prompt on a specific Tuesday, the compliance review goes poorly.

The dividing line is not the technology. It is the shape of the flow and the consequence of failure.

Most enterprises have hundreds of small, occasional, low-stakes tasks that never justified a formal integration build. Pulling a list of active campaigns for a marketing dashboard. Assembling a status report across three systems. Triaging exceptions where the agent surfaces data and a human decides. This is the long tail. Agents handle it well. It is cheap at low volume and highly flexible.

But flexibility is what you want in a prototype and what you dread in a payment flow. The trunk routes move purchase orders, employee terminations, and ledger entries. They require auditability, guaranteed delivery, and compensating transactions when a multi-hop flow fails halfway through.

The cost curves also diverge. Integration platforms are expensive but predictable. Agents are cheap at low volume and terrifying at scale. A nightly batch that reconciles two hundred thousand records costs near nothing on an integration platform. Running that same reconciliation through an agent platform costs a mortgage payment in token fees. An agent deployed to help sales query customer history might not understand caching or rate limits, making twenty concurrent calls to the CRM every time a rep asks a question until the vendor issues a throttling warning.

Both sides of the market see this and are racing to converge. Integration platform vendors are adding agent orchestration. Agent platform vendors are adding connectors and tool registries. Procurement gets caught in the middle, facing consolidation pressure and the promise of a single pane of glass.

Connectors are not flows. Having four hundred pre-built connectors does not mean you have retry semantics, transaction boundaries, or a dead-letter queue. The safe architecture is to let the platforms converge in the vendor roadmaps while keeping your own architecture split. The integration platform becomes the governed substrate. Agents consume idempotent, monitored, audited endpoints instead of raw APIs. The platform’s job shifts from being the only way to connect systems to being the only safe way for certain operations to be executed.

You do not need an integration platform for the flows agents handle today. You need it for the flows agents will be asked to handle next quarter, when the ad hoc task acquires a schedule, a service expectation, and downstream dependencies. Most enterprises do not know which of their integrations move money until the business asks an agent to do it.