This article classifies the four integration patterns the AITE-SAT architect uses, maps five legacy system classes to their best-fit patterns, and walks the failure-mode coverage each pattern must specify before it ships.
The four integration patterns
Every AI-to-legacy integration fits one of four patterns. The patterns are not novel — they come from enterprise integration texts long predating AI — but their application to AI systems has new constraints.1
1. Synchronous request/response
The caller (legacy or AI) makes a direct call and waits for the response. Simple, fast for small payloads, tolerable when the total round-trip is well within the user’s latency budget. Model-side synchronous calls work when the model returns quickly and when the caller has a sensible timeout. An AI-powered lead scoring service called from a Salesforce flow when a record is created is a canonical synchronous integration.
The limits are real. A GPT-4 class model answering a two-paragraph question may take four to ten seconds under load. A synchronous call from a CRM flow with a thirty-second timeout survives that; a synchronous call from a SAP BAPI with a two-second default does not. The architect reads the caller’s timeout budget first and only then picks the pattern.
2. Asynchronous queue-based
The caller submits a request to a queue, the AI service processes it when capacity allows, and the response is returned by callback, poll, or a separate read channel. Durable, load-absorbing, tolerant of variable processing times. Works whenever the user experience can tolerate seconds or more of delay and the caller system has somewhere to put a reference identifier until the response arrives. Document-processing AI features almost always belong here.
Queue depth becomes a new signal worth monitoring. A queue growing faster than it drains is an early warning of capacity or cost problems. The architect puts a queue-depth SLO (Article 20) into the platform’s observability layer.
3. Event-driven
The AI service subscribes to events emitted by the legacy system and acts on them — summarising, classifying, enriching, or kicking off a downstream action. The legacy system is not aware the AI exists; it just emits an event. Clean separation, highly scalable, and resilient to AI-side failures because the legacy side never blocks on AI. Epic’s EHR event streams feeding a clinical-note summarisation service is a documented pattern in modern healthcare AI integration.2
Event-driven integration is not passive. The architect still specifies idempotency (a replayed event must not produce a second side effect), ordering expectations (some workflows require strict per-patient order), and dead-letter handling.
4. Batch
The AI processes records in scheduled batches against an extract from the legacy system. Classical ML territory that persists into generative AI for large-scale enrichment tasks — content classification across an entire catalogue, bulk translation of documents, retrospective summarisation of closed tickets. Inexpensive, simple to operate, well understood. The tradeoff is freshness: batch results are always at least one cycle old.
Pattern-to-system fit
Different legacy systems have different tolerance for each pattern. The architect classifies before choosing.
| Legacy system class | Natural patterns | Avoid | Why |
|---|---|---|---|
| CRM (Salesforce, Microsoft Dynamics) | Synchronous (small), async, event | Batch-only (too slow for sales workflows) | CRM workflows are interactive; users expect responses in seconds. |
| ERP (SAP, Oracle, Workday) | Event, batch, async | Synchronous for deep transactions | ERP processes are rigid; injecting AI into core financial postings is risky. Side-car patterns are safer. |
| EHR (Epic, Cerner/Oracle Health) | Event (primary), async | Synchronous in critical paths | Patient safety means the EHR must never block on an AI service. Event-driven with asynchronous AI-side processing is the norm. |
| Mainframe / COBOL / CICS | Batch, async, event | Synchronous | Latency, throughput constraints, licence costs of per-request interop make synchronous calls from or to mainframe expensive and brittle. |
| Data warehouse (Snowflake, BigQuery, Redshift) | Batch (primary) | Synchronous at user latencies | Warehouses are optimised for analytical throughput; AI enrichment typically runs as scheduled jobs. |
The CRM-synchronous pattern is by far the most common first AI integration in enterprises because CRMs are interactive and users forgive one to three seconds of latency for a clearly labelled AI response. The EHR-event pattern is the most common AI integration in healthcare because the safety case forbids critical-path AI blocking.
Failure-mode coverage
Every integration specification must answer the following questions before it ships. The answers change by pattern; the question list does not.
Timeouts. What is the caller-side timeout, and what does the AI service do when it approaches that boundary. Graceful early return with a partial result is often better than a silent timeout.
Retries. Are retries safe, and if so with what back-off. Non-idempotent actions (sending an email, writing to a journal) must not be retried without explicit idempotency keys. The AI service declares its idempotency contract and the integration honours it.
Circuit breakers. When does the caller stop calling the AI service and fall back. Hystrix-style circuit breakers are the standard reference; modern implementations use resilience libraries or service-mesh configuration.3
Backpressure. When the AI service is slow, does the caller slow down or queue up. Unbounded queuing is the failure mode that brings whole systems down.
Idempotency. Can the same request be processed twice without producing the same side effect twice. Every write integration must have a clear answer.
Dead-letter handling. Where do requests go when all retries fail. A visible dead-letter queue with a triage owner is mandatory.
Observability. What trace context crosses the boundary. OpenTelemetry propagation is the baseline; the AI-side tracing (Article 13) should include the legacy-side correlation identifier so that end-to-end investigation is possible.
Cost and quota. Does the caller have a budget, and does the AI service know how to enforce it. A spike in legacy-side traffic must not silently exhaust the AI budget for the quarter.
Worked example — Salesforce Einstein and the AI-augmented CRM boundary
Salesforce Einstein, now integrated through the Einstein Copilot and the broader Agentforce platform, exposes AI features inside Salesforce flows through declarative actions and via programmatic Apex invocations. The integration patterns Salesforce publicly documents are primarily synchronous-with-timeout for user-interactive use cases and event-driven for platform event subscriptions.4
For a lead-enrichment use case — a new lead arrives; the AI reads web sources, returns a summary and a score — the practical integration choices are:
- Synchronous: fast, one call, low complexity; constrained by the Salesforce timeout budget and risky if the AI provider is slow.
- Async via Platform Events: the flow emits an event; an external AI worker processes and updates the record; user sees the enriched record on next refresh.
- Event-driven: Change Data Capture on the lead object triggers an external subscription; the AI side processes and updates with no flow involvement.
Each pattern has different error-handling and user-experience consequences. The choice depends on sales ops tolerance for eventual consistency. The architect writes an ADR (Article 23) that names the choice and the tradeoffs.
Worked example — SAP Joule and the AI-augmented ERP boundary
SAP’s Joule assistant is designed to sit alongside SAP applications rather than inside the core transactional flows.5 The public architecture pattern is side-car: Joule is an orchestrator that calls SAP APIs, BTP services, and external model providers, but the ERP transactional flows continue to run under their existing rules.
This is not accidental. ERP systems encode decades of financial-close, audit-trail, and segregation-of-duties rules. Letting an AI model influence a journal-entry posting is a compliance problem before it is a technical problem. The side-car pattern — AI assists users who then approve or edit before the transaction commits — is safer. The AITE-SAT learner takes this pattern as the default for any integration with a system of record.
Worked example — Epic EHR and the clinical event pipeline
Epic’s AI integration programme has multiple visible threads: clinical-note summarisation, inbox triage, patient-message drafting.2 The dominant pattern is event-driven with asynchronous AI processing. The EHR emits an event (message received, note completed), the AI subscriber processes, and the result returns to the clinician through a defined workflow step — typically with explicit human acceptance. No AI writes to the patient record without a clinician signing.
The pattern is reinforced by regulation. HIPAA, FDA guidance on clinical decision support, and the evolving patient-safety expectations mean that AI-to-EHR integrations must be designed to fail safely. Event-driven with human-in-the-loop satisfies that requirement by default.
Mainframe integration
Mainframe integration deserves its own note. Most large banks, insurers, and government agencies still run transactional workloads on z/OS COBOL. Integration patterns that work: asynchronous messaging through IBM MQ, scheduled batch files, API gateways fronting CICS transactions through REST adaptors (IBM’s z/OS Connect or comparable). The AI side must assume slow, expensive, and latency-variable responses.
The two failure modes that catch first-time mainframe integrators: per-transaction MIPS costs (every synchronous call against the mainframe consumes licensed compute) and schema rigidity (copybooks change through controlled releases, not agile sprints). Async patterns with thoughtful batching both reduce cost and insulate the AI side from mainframe release cycles.
Governance integration
Legacy integration is where EU AI Act Articles 10 (data governance) and 15 (cybersecurity) meet real deployments. Data flows across trust boundaries; the architect specifies authentication (mTLS, OAuth2 client credentials), encryption (TLS 1.3 minimum), data residency (Article 18), and audit logging for every cross-system call.
Article 12 (record-keeping) applies to the integration surface specifically. Logs that capture which legacy record was acted on, what AI decision was produced, and what downstream action occurred are exactly the evidence trail the Act requires. Article 14 (human oversight) is often operationalised at the integration boundary: a human reviews and approves before the AI-side action propagates to the legacy record.
Anti-patterns
- Model logic inside the ERP customisation. Writing prompt handling, retrieval logic, or response parsing as SAP ABAP or Salesforce Apex creates maintenance debt that will outlive the architect. Keep AI logic in the AI service; call it cleanly.
- Synchronous calls against a mainframe. Unless the use case absolutely requires it and the MIPS budget is reserved, use async.
- No circuit breaker. Calling an external AI service without a circuit breaker couples legacy availability to AI availability. When the AI provider has an outage, the CRM flow stops working and users complain. A circuit breaker with a defined fallback is mandatory.
- Unbounded queues. Queues without back-pressure or depth limits absorb traffic until memory runs out. Bounded queues with visible metrics are the baseline.
- Opaque cross-system errors. An error that surfaces to the user as “AI service failed” teaches them nothing. The error path must include a correlation identifier and a recovery action the user can take.
- Event-driven without idempotency. Events get replayed; integrations that produce side effects without idempotency will eventually double-send messages or double-post journal entries.
Summary
Most enterprise AI features live at the boundary of systems that pre-date the AI era. The architect picks the right pattern — synchronous, async, event-driven, batch — for each boundary and specifies the full failure-mode contract before the integration ships. CRM, ERP, EHR, mainframe, and warehouse integrations each have natural pattern fits; deviating from them is a decision worth an ADR. Salesforce, SAP, and Epic’s public architectures are the industry-standard references to study.
Key terms
Legacy integration pattern Synchronous versus async AI integration Circuit breaker Idempotency key Side-car integration
Learning outcomes
After this article the learner can: explain the four integration patterns for legacy and AI systems; classify five legacy system classes by best-fit pattern; evaluate an integration for failure-mode coverage; design an integration specification for a given legacy system.
Further reading
Footnotes
-
Hohpe and Woolf, Enterprise Integration Patterns (2003). ↩
-
Epic Systems AI integration programme disclosures; HIMSS and JAMIA coverage of EHR AI deployment patterns (2023–2024). ↩ ↩2
-
Netflix Hystrix original documentation; Resilience4j and service mesh resilience configurations. ↩
-
Salesforce Einstein and Agentforce architecture documentation. ↩
-
SAP Joule public architecture materials and SAP TechEd disclosures (2023–2024). ↩