Hassan and I have integrated enterprise systems with AI services across a dozen engagements. The pattern library is smaller than you'd expect. Not because the problems are simple, but because the same integration patterns keep solving different problems. The boring ones work. The clever ones cause production incidents.
What You Need to Know
- Enterprise AI integration is 80% standard integration work and 20% AI-specific. The AI call itself is the easy part. Everything around it is where the complexity lives.
- Three patterns handle 90% of enterprise AI integrations: synchronous request-response, async queue processing, and webhook-triggered pipelines
- The most common integration failure is not the AI model failing. It is the data pipeline feeding the model with stale, malformed, or incomplete data.
- Always build the fallback path first. The AI service will go down. Your integration needs to handle it gracefully.
The Three Patterns
Pattern 1: Synchronous Request-Response
The simplest pattern. User action triggers an API call to the AI service. The response comes back. The application displays it.
Works for: Real-time suggestions, document classification, chat interfaces, inline content generation.
Watch out for: Latency. AI model responses typically take 2-15 seconds. If the user experience requires sub-second response, this pattern needs a caching layer or a lighter model.
User action → Application server → AI service → Response → Display
Hassan and I both default to this pattern when the use case permits it, because it has the fewest moving parts. Fewer moving parts means fewer failure modes.
The synchronous ones are the easiest to debug, the easiest to monitor, and the easiest to explain to the rest of the team. Start here unless you have a specific reason not to.
Hassan Nawaz
Senior Developer
Pattern 2: Async Queue Processing
User action (or scheduled trigger) places a job on a queue. A worker picks up the job, calls the AI service, processes the response, and stores the result. The user is notified or retrieves the result later.
Works for: Batch document processing, report generation, data analysis, anything where the user doesn't need the result immediately.
Watch out for: Queue depth. If jobs arrive faster than the AI service can process them, the queue grows. Set alerts on queue depth and implement backpressure or rate limiting.
Trigger → Queue → Worker → AI service → Store result → Notify
This pattern handles AI service outages more gracefully than synchronous, because jobs wait in the queue rather than timing out in the user's browser.
Pattern 3: Webhook-Triggered Pipeline
An external event (new document uploaded, form submitted, email received) triggers a webhook. The webhook initiates a multi-step AI pipeline: extract data, classify, enrich, route.
Works for: Document intake workflows, email processing, automated triage, integration with third-party systems that push events.
Watch out for: Idempotency. Webhooks can fire multiple times for the same event. The pipeline must handle duplicate triggers without creating duplicate outputs.
External event → Webhook → Pipeline (extract → classify → enrich → route) → Store/Notify
The Data Pipeline Problem
Stale Data
The AI model is only as good as the data it receives. If the retrieval pipeline serves data that was indexed two weeks ago, the model's responses are two weeks behind reality. For enterprise use cases where accuracy matters (claims processing, compliance checking, customer support), stale data produces wrong answers that look right.
Build monitoring for data freshness. Know when your last index update ran. Alert if it's behind schedule.
Malformed Data
Enterprise data is messy. PDFs with broken formatting. Spreadsheets with merged cells. Documents with headers in the body and footers in the header. The AI model receives whatever the extraction pipeline produces, and extraction pipelines are only as good as their error handling.
Build validation between extraction and AI processing. If the extracted data doesn't meet minimum quality thresholds, flag it for human review rather than feeding garbage to the model.
Incomplete Data
The most insidious problem. The model receives a partial context and produces a plausible answer based on incomplete information. The answer looks correct. It may even be correct for the data it received. But it's wrong for the full context.
Build completeness checks. If a document analysis expects five sections and receives three, that's a signal. If a customer query references an account but the account data retrieval failed silently, the AI's response will be confidently uninformed.
Production Essentials
Build the Fallback First
Before writing the AI integration, write the fallback. What happens when the AI service is unavailable? Options:
- Queue the request for later processing
- Route to human processing
- Serve a cached response
- Degrade gracefully with partial functionality
The fallback should be tested independently and regularly.
Timeouts and Retries
AI services have variable latency. Set timeouts per use case (2 seconds for real-time, 30 seconds for batch processing). Implement retries with exponential backoff for transient failures. Set a maximum retry count. Log every timeout and retry for monitoring.
Cost Tracking
Every AI API call has a cost. Track token usage, cost per call, and cost per business outcome (cost per document processed, cost per query answered). Without cost tracking, a high-traffic integration can generate surprising bills.
Enterprise AI integration is integration work, with AI characteristics layered on top. The patterns that work are the patterns that have always worked in enterprise integration: simplicity, reliability, monitoring, and graceful degradation. The AI part is new. The engineering discipline is not.