Integration Patterns: Wiring AI into the Enterprise

Why integration is where AI value is realized

A language model that answers cleanly in a sandbox has proven almost nothing about whether it can run a business process. The demo shows capability; production requires connection. Value appears only when the model reads from and writes to the systems that actually run the enterprise, the CRM that holds the customer, the ERP that holds the order, the case system that holds the claim. Until the model can act on those systems of record, it is a very articulate bystander.

This is why so many programs stall in the same place. The proof of concept clears in a fortnight because it touches nothing; the production build stretches across two quarters because it touches everything. The hard part was never the prompt. It was the last mile into the systems of record: the authentication, the data mapping, the transaction semantics, the error handling, and the ownership negotiations with the teams who run those systems and will not let an unproven component write to them casually.

The reframe that saves projects is to recognize what this work actually is. Wiring AI into the enterprise is enterprise integration, the same discipline that has connected systems for decades, with one new variable: a component in the middle that is non-deterministic and occasionally wrong. The patterns are not new. Synchronous and asynchronous calls, event streams, message queues, published contracts, all predate the current wave and all still apply. What changes is that one participant now returns different answers to the same input and fails in ways a database never did.

Synchronous vs asynchronous

The first design decision for any AI integration is also the oldest one in the book: does the caller wait for the answer, or not. Synchronous request-response suits interactive, low-latency work where a human is watching a cursor blink, a chat reply, an inline suggestion, a single classification behind a form submit. The caller holds the connection open and expects an answer inside a human attention span. Asynchronous, queued processing suits long-running or bulk work where no one is waiting in real time: processing ten thousand documents overnight, enriching a backlog, generating a batch of summaries. The request is accepted, a job is queued, and the result arrives later through a callback, a webhook, or a polled status endpoint.

What is different about AI is that the boundary moves. A conventional API call returns in tens of milliseconds and its latency is tight and predictable. A model call can take seconds, and a reasoning-class model working through a hard problem can take much longer, with a wide and heavy-tailed distribution: the median is tolerable, the ninety-ninth percentile is not. That variability, more than the raw latency, is what pushes AI integration toward asynchronous designs earlier than a classic API would. A synchronous path that is comfortable at the median quietly accumulates timeouts, held threads and exhausted connection pools at the tail.

The practical guidance is to reserve synchronous calls for genuinely interactive paths with a bounded, tested worst case, and to reach for asynchronous processing sooner than instinct suggests. Streaming responses is the useful middle ground for chat: the connection stays open but tokens arrive progressively, so the user sees motion while the full answer is still forming.

Event-driven and agentic integration

Beyond the request-response axis sits a more consequential shift in posture. In event-driven integration, the AI is not called by a user at all; it reacts to a business event. A ticket is created, a document lands in a queue, a payment is flagged, and that event triggers a model to classify, summarize, route or draft a response. The enterprise already runs on event streams and message buses for exactly this decoupling; AI becomes another subscriber, consuming events and emitting results without a human initiating each call.

Agentic integration goes one step further and inverts the usual relationship. Instead of the model being an endpoint that a system calls, the model becomes an actor that calls the systems, invoking enterprise capabilities as tools, increasingly through a standard protocol such as MCP. The agent decides, within its granted scope, which system to query and which action to take. Read this shift carefully, because it changes the risk profile entirely: AI-as-endpoint returns a value someone else decides to use, while AI-as-actor produces side effects directly, updating a record, opening a ticket, issuing a refund.

  AI-as-ENDPOINT                 AI-as-ACTOR (agentic)
  --------------                 ---------------------
  event ---> [ system ]          [ agent ] --> CRM (read)
                |                    |      --> ERP (write)
                v                    |      --> ticketing
            calls model              |      --> refund API
                |                     v
            gets answer          side effects on
            system decides       systems of record
            what to do next      (guardrails needed)

The engineering consequence is that an agent with write access to systems of record is a production integration with unusual failure modes, not a chatbot. Every tool it can call needs a scoped credential, and every side-effecting action deserves the scrutiny a human operator's would receive: least-privilege access, idempotency on writes, an approval gate for high-stakes actions, and an audit trail that records what the agent did and why. Multi-agent designs multiply this surface, not reduce it.

Coexisting with the iPaaS and ESB estate

A recurring temptation, usually from a vendor with a new platform to sell, is to treat AI as a reason to replace the integration estate. Resist it. The iPaaS and ESB middleware already connecting your systems represents years of accumulated connectors, credentials, data mappings and hard-won governance. AI does not obsolete that fabric; it becomes another participant on it. The pragmatic architecture routes AI through the integration layer you already run, reusing the tested connector to a CRM or ERP that a team already built rather than granting a new component its own direct, ungoverned path to a system of record.

Routing AI calls through the iPaaS or ESB buys you the governance that is already wired in: the audit logging, the credential management, the rate limiting, the data transformations and the connector library that would otherwise be rebuilt. The integration platform mediates between the model and the enterprise system, which is exactly where you want a policy point for traffic that touches sensitive records.

There are cases where a direct path is the better call, and the discipline is to make that a deliberate exception rather than a default.

• Route through the iPaaS/ESB when the call touches a system of record, reuses an existing connector, or needs the platform's governance and audit. This is the default.
• Keep a direct path when latency is critical and the middleware hop is a measured cost, when the target is the model gateway itself, or when the platform cannot handle streaming or long-lived connections gracefully.
• Never let an AI component hold its own copy of a production credential to a system of record when a governed connector already exists.

API-first and the contract discipline

The fastest-moving thing in your architecture is the model. Providers deprecate versions, change pricing, adjust behavior and ship new families on a cadence measured in months. If your consuming applications call a specific model directly, every one of those changes becomes a code change rippling across the estate. API-first discipline is the antidote: wrap each AI capability behind a stable internal API whose contract is defined in terms of the business function, summarize this claim, classify this ticket, not in terms of the model that happens to serve it today.

On the model side, the model gateway is where this insulation is enforced against provider churn: one interface in front of every provider, so a model swap is a routing change rather than an application change. The capability API is the same idea one layer up, facing your own consumers. Together they mean a business application depends on a contract you control and a model portfolio it never sees, which is also how a reference architecture keeps its layers independent.

The contract discipline that makes this hold is unglamorous and non-negotiable. Version the interface so a breaking change ships as a new version while the old one keeps serving. Define the schema of what goes in and what comes back, and validate both, because a non-deterministic component makes loose output contracts genuinely dangerous. And design for graceful degradation: when the model is slow, unavailable, or returns something that fails validation, the API should have a defined fallback, a cached answer, a simpler model, a queued retry, or an honest error, rather than propagating the failure raw to a caller that has no idea how to handle it.

The non-functional concerns that decide production

Whether an AI integration survives contact with production is decided almost entirely by its non-functional design, the concerns that never appear in a demo and always appear at 2 a.m. AI raises the stakes on every one of them because the component in the middle is both slower and less predictable than the services enterprise integration usually connects. The classic patterns still apply; they just have to be tightened.

Two of these deserve emphasis because they are where AI departs most from ordinary integration. Idempotency stops being good hygiene and becomes essential the moment an agent has write access, since a retried refund or a duplicated ticket is a real-world error, not a log line. And output handling is a category that barely exists for deterministic services: a conventional API returns a well-formed response or an error, whereas a model can return a confident, well-formed and wrong answer that passes every structural check. Validating structure is necessary and not sufficient; the human fallback is what covers the residue.

The unifying principle is to design for the model being wrong, not as an edge case but as an expected event with a defined path. An integration that assumes the model is always right and always fast is not a production system; it is a demo that has not met its worst day yet.

The architect view

Step back and the whole subject resolves into a single sentence: AI integration is enterprise integration with added non-determinism. Almost everything you need has existed for years, request-response and asynchronous processing, event streams and message buses, published contracts and versioned APIs, the iPaaS and ESB fabric already running in production. The instinct to invent a wholly new discipline for AI is the expensive mistake. The correct move is to reuse the patterns and the platforms, then add the specific guardrails the new variable demands.

Those guardrails are the short list this article has been building toward. Lean toward asynchronous designs because of tail latency. Put agents behind scoped credentials and approval gates because they cause side effects. Wrap capabilities behind versioned internal APIs and a model gateway because the model churns. Make writes idempotent, retries bounded, timeouts explicit and outputs validated, and always leave a human path because the model is sometimes wrong. None of these is exotic. Each is a known pattern applied with the knowledge that one participant is non-deterministic. You can sketch how the pieces fit with the Architecture Designer in the Lab.