Event-driven integration
The plumbing that lets AI work alongside your core systems without slowing them down, losing messages or doing anything twice.
What it is
Event-driven integration is how AI connects to the systems that run the business: the ERP, the warehouse system, the CRM, the claims or case system. Instead of the AI calling those systems directly and waiting, each system publishes events, such as 'order created' or 'claim received', and the AI subscribes to the ones it needs. Its results go back as events or through a controlled API.
The parts are familiar to anyone who has run integration at scale. An event bus routes events to subscribers. Queues hold work safely when a consumer is slow or down. An API layer is the only way into the core systems. Every message carries an ID, so a retry never creates a duplicate order or payment. The outbox pattern makes sure an event is published only when the database change behind it has actually happened. Messages that keep failing go to a dead-letter queue with an owner, not into a void.
In an enterprise, this is what lets the AI be switched off without stopping the business. If the AI is paused, events still reach people and existing processes. If a core system is down, work waits in the queue. Most organisations already have an integration platform, and the right answer is usually to reuse it, not to build a second one for AI.
Use it when, and think twice when
Use it when
- The AI needs to react to things happening in core systems
- Core systems are old, slow or can't take extra load
- Work must not be lost or processed twice
- Several consumers need the same event: AI, reporting and audit
Think twice when
- One simple, synchronous look-up is all that's needed
- Nobody will own the dead-letter queue and the event schemas
- The core system can't publish events and nothing can capture its changes
- You're about to buy a second integration platform beside the one you have
Reference architecture
01Channels
- Change in a core system
- Partner or customer message
- Scheduled job
02Intake
- API GatewayAPI ManagementKong, or your existing API gatewayAPI layer
- DynamoDB Streams, or Debezium on Amazon MSK ConnectCosmos DB change feed, or DebeziumDebezium on Apache KafkaChange capture and outbox
03Intelligence
- Agent
Amazon Bedrock AgentCoreFoundry Agent ServiceAn open-source agent framework (e.g. LangGraph) on KubernetesAI consumer: reads events, returns results - Amazon Bedrock, SageMaker AIMicrosoft Foundry, Azure Machine LearningOpen-weight models via vLLM; MLflow models on KubernetesModels and scoring
- Agent
04Orchestration
- Amazon EventBridgeEvent GridApache KafkaEvent bus
- Amazon SQSService BusRabbitMQQueues and dead-letter queues
- Kinesis Data Streams or Amazon MSKEvent HubsApache KafkaHigh-volume streams
- AWS Step FunctionsLogic Apps or Durable FunctionsTemporalLong-running processes
05Systems of record
- ERP, WMS, CRM or case system
- Your existing integration platform
06People
- Person
Integration support clears failed messages - Person
Process owner handles business exceptions
- Person
- Cloud or platform service (AWSAzuresovereign / on-prem)
- AI agent
- A person decides
- Your existing systems
- Outside your organisation
Components, side by side
| Layer | AWS | Azure | Sovereign / on-prem |
|---|---|---|---|
| API layerThe only way into core systems. Rate limits protect them from the AI. If you already have an integration platform, the AI uses it like any other system. | Amazon API Gateway | Azure API Management | Kong, or your existing API gateway |
| Event bus and routingEventBridge archive and replay helps recover from a bad release. | Amazon EventBridge | Azure Event Grid | Apache Kafka |
| Queues | Amazon SQS, Amazon SNS | Azure Service Bus | RabbitMQ or Apache Kafka |
| High-volume streamsFor telemetry, clickstream or EDI volumes. Streams cost money even when quiet. | Amazon Kinesis Data Streams or Amazon MSK | Azure Event Hubs | Apache Kafka |
| Outbox and change capturePublish an event only once the database change behind it has committed. | DynamoDB Streams, or Debezium on Amazon MSK Connect | Cosmos DB change feed, or Debezium | Debezium on Apache Kafka |
| IdempotencyA retry must never create a second order, payment or letter. | Powertools for AWS Lambda idempotency, SQS FIFO deduplication | Service Bus duplicate detection, with idempotent handlers | Idempotency keys stored in PostgreSQL |
| Dead-letter queuesEvery failed message has an owner, an alert and a tested way to replay it. | SQS dead-letter queues, EventBridge dead-letter queues | Service Bus dead-letter queues, Event Grid dead-lettering | Kafka dead-letter topics, or RabbitMQ dead-letter exchanges |
| Schemas and contractsVersion every event. A breaking change gets a new version, not a surprise. | EventBridge Schema Registry, or AWS Glue Schema Registry | Event Hubs schema registry | Apicurio Registry |
| TracingOne correlation ID per business transaction, end to end. | CloudWatch, AWS X-Ray | Azure Monitor, Application Insights | OpenTelemetry, Prometheus, Grafana |
On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →
Operations
Keeping it reliable
AI fails quietly. These three habits make failure visible before customers see it.
Evaluation
Test the failure paths
Before go-live, replay a day of real events, then stop consumers, slow the core system down and send duplicates on purpose. Check that nothing is lost, nothing is done twice and the queue drains when service returns. Make these tests part of every release.
Monitoring
Watch age, not just volume
Track the age of the oldest message in each queue, dead-letter counts and consumer error rates. Trace each business transaction end to end with a correlation ID. Alert a named owner, not a shared mailbox.
Cost
Pay for messages, not idle servers
Managed queues and event buses charge per message and are cheap at most enterprise volumes. Streams and Kafka clusters cost money even when quiet, so use them only where volume needs them. The AI calls behind each event usually cost far more than the messaging.
Security and failure risks
Duplicate processing
A retry or redelivery creates a second order, payment or letter.
How the design avoids it
Idempotency keys on every message and every write to a system of record, tested with deliberate duplicates.
Poison messages
One malformed message fails forever, blocks a queue or is silently dropped.
How the design avoids it
Limited retries, then a dead-letter queue with an owner, an alert and a tested replay route.
Spoofed or tampered events
Something that shouldn't be able to publish sends a fake 'payment approved' event, and consumers trust it.
How the design avoids it
Least-privilege publish rights per topic, authenticated producers, schema validation, and consumers that re-check critical facts through the API layer.
Schema drift
A core system changes a field, and every consumer, including the AI, quietly misreads it.
How the design avoids it
A schema registry, versioned events, contract tests in the release pipeline, and a named owner for each event type.
Playbooks that use this pattern
All 40 playbooks using Event-driven integration →KYC and customer onboarding
Every application read, checked and summarised before an analyst opens it. Analysts spend their time on judgement, not copying, and a person approves or declines every customer.
- Document AI
- Agents with tools
- Human in the loop
- Event-driven integration
Payment fraud and APP scam detection
Risky payments scored in milliseconds, only the highest-risk band held automatically under rules a person approved, every other alert reviewed by an analyst before any hold, and people making every decision about a customer's payment or claim.
- Predictive ML
- Agents with tools
- Human in the loop
- Event-driven integration
Reconciliation and exception handling
Millions of transactions matched every day, the breaks investigated before anyone opens a spreadsheet, and a person approving every posting, with the audit evidence built as the work is done.
- Predictive ML
- Agents with tools
- Human in the loop
- Event-driven integration
Claims intake and triage
Every claim read, sorted and routed within minutes. Simple claims ready for one-click approval, complex ones flagged early, and people making every decision that matters.
- Document AI
- Agents with tools
- Human in the loop
- Event-driven integration
Damage assessment from photos
Usable photos first time, a likely repair route within hours, and reused or edited images caught before payment. An engineer or handler makes every settlement and total-loss decision.
- Computer vision
- Human in the loop
- Agents with tools
- Event-driven integration
Renewal pricing fairness monitoring
Every renewal price checked against the new-business price before it goes out, every pricing change tested for fair value and proxy discrimination, and clear evidence for the senior manager who signs the attestation. People own every pricing decision.
- Predictive ML
- Agents with tools
- Human in the loop
- Event-driven integration
Referral and clinical letter processing
Every referral and letter read, summarised and routed within minutes of arriving. The consultant sees a one-screen summary and a suggested priority, and makes every triage and clinical decision.
- Document AI
- Retrieval (RAG)
- Agents with tools
- Human in the loop
- Event-driven integration
Ambient clinical notes
The consultation is captured, the note and the letter are drafted before the patient leaves, and the clinician checks, edits and signs every word.
- Speech and voice
- Agents with tools
- Human in the loop
- Event-driven integration
Appointment no-show prediction
Fewer empty clinic slots, because the patients most likely to miss an appointment get help to attend or rebook in good time. Prediction leads to support, never to penalties, and people make every decision about a patient's care.
- Predictive ML
- Agents with tools
- Human in the loop
- Event-driven integration
Patterns
All eight building blocks
AI Explained
Document AI
Read forms, letters and PDFs into structured data.
Retrieval (RAG)
Answer questions from your own documents, with sources.
Agents with tools
AI that takes small, controlled actions across your systems.
Human in the loop
Put people on the decisions that matter, with the evidence.
Predictive ML
Score, rank and forecast from your own historical data.
Event-driven integration
Connect AI to core systems safely, through events and queues.
Computer vision
Inspect photos, video and camera feeds for defects and damage.
Speech and voice
Turn calls and conversations into text, notes and actions.
Thinking about event-driven integration in your organisation?
Talk through where it fits, what it would plug into, and which decisions should stay with people.
