Most AI agent demos begin with a user asking a question and receiving an answer within a few seconds.
Real business processes are rarely that simple.
A customer submits a request today, but an approval may happen tomorrow. A supplier may respond several hours later. A payment may require a separate verification step. A human employee may need to review an exception before the process continues.
This creates a different engineering challenge:
How do you build an AI agent that can operate across time, events, failures, and human decisions?
One answer is to combine agentic AI with event-driven architecture and durable workflow orchestration.
Instead of treating an agent as a request-response application, developers can treat it as part of a long-running system that reacts to events, stores state, waits for external activity, resumes execution, and coordinates multiple services.
AWS describes event-driven architecture as an approach where events such as user requests, file uploads, or system changes trigger downstream services without requiring tight coupling between components.
For developers exploring business automation, the AI Agent & Business Automation Professional E-Degree is one possible resource for developing broader knowledge in this area.
But building reliable agentic automation requires thinking beyond the model itself. The interesting engineering problems often involve state, events, retries, timeouts, human pauses, recovery, and coordination.
Why Request-Response Agents Are Not Enough
A simple AI application can follow this pattern:
User
↓
Application
↓
LLM
↓
Response
The application receives a request and waits for a response.
This works well for:
- question answering
- summarization
- drafting
- simple assistants
- short-lived tasks
But consider a procurement workflow:
Purchase request
↓
Agent reviews request
↓
Check inventory
↓
Request supplier quote
↓
Wait for supplier
↓
Compare responses
↓
Request approval
↓
Wait for manager
↓
Create purchase order
This process may take hours or days.
The agent cannot simply remain inside one HTTP request waiting for every event.
The application needs a durable representation of the workflow's state.
That is where event-driven architecture and workflow orchestration become useful.
Think in Events, Not Just Prompts
A prompt represents an instruction.
An event represents something that happened.
Examples include:
customer.createdinvoice.receivedpayment.completeddocument.uploadedapproval.requestedapproval.completedshipment.delayedsupplier.respondedticket.updated
Instead of asking an agent to continuously check whether something has happened, the system can react when an event occurs.
For example:
invoice.received
↓
Agent triggered
↓
Extract information
↓
Validate invoice
↓
Business rules
↓
Approval required?
↙ ↘
Yes No
↓ ↓
Wait Continue
↓
approval.completed
↓
Continue workflow
This makes the system more reactive and reduces unnecessary polling.
AWS specifically identifies loose coupling, asynchronous processing, and scalability as important characteristics of event-driven architectures for AI systems.
The Agent Needs State
A long-running process cannot depend entirely on the model's conversational context.
Imagine an agent beginning a supplier onboarding process.
At the beginning, it might know:
supplier = Acme Corp
country = Germany
documents = received
Several hours later, a compliance review finishes.
The system needs to know:
- which supplier was being processed
- which documents were received
- which checks were completed
- which checks remain
- what decision is pending
- which human approval is required
- what should happen next
That information should live in application-managed state.
A useful conceptual model is:
Workflow State
├── Input
├── Completed steps
├── Pending steps
├── External IDs
├── Decisions
├── Approvals
└── Next action
The LLM can reason over that state, but the workflow system should own the authoritative state.
This distinction is important because language-model context and application state serve different purposes.
Separate Agent Reasoning From Workflow Control
One architectural mistake is allowing the model to control everything.
For example:
LLM
↓
decides everything
↓
calls services
↓
stores state
↓
handles retries
↓
waits
This can become difficult to reason about.
A more structured architecture separates responsibilities:
┌───────────────┐
│ Workflow │
│ Orchestrator │
└───────┬───────┘
│
┌──────────┴──────────┐
↓ ↓
Agent reasoning Deterministic logic
↓ ↓
Tools/APIs Business rules
↓ ↓
└──────────┬─────────┘
↓
External systems
The agent can determine what it believes should happen next.
The workflow layer determines whether that action can happen and how the process persists.
IBM's architecture guidance similarly distinguishes between static workflows and dynamically generated agentic workflows, noting that predefined workflows can be easier to instrument, monitor, and audit for complex or regulated processes.
Use Events to Decouple Components
Suppose an order-processing system contains:
- order service
- inventory service
- payment service
- shipping service
- notification service
- AI agent
A tightly coupled architecture might have each service directly calling the next.
An event-driven design can instead use events:
Order Created
↓
Inventory Service
↓
Inventory Reserved
↓
Payment Service
↓
Payment Confirmed
↓
Shipping Service
↓
Shipment Created
The agent might participate when interpretation or decision-making is required.
For example:
Shipment Delayed
↓
Agent investigates
↓
Check order
↓
Check inventory
↓
Check carrier information
↓
Determine possible cause
↓
Recommend action
The event becomes the trigger.
The agent becomes one participant in a larger distributed system.
Long-Running Agents Need Durable Execution
The longer an agent runs, the more opportunities there are for something to fail.
Networks disconnect.
APIs timeout.
Workers restart.
Models become temporarily unavailable.
External systems change.
Humans take time to respond.
A simple retry loop is not enough for a workflow that has already performed several side effects.
Consider:
1. Create order
2. Send email
3. Update CRM
4. Request payment
5. System crashes
When the process restarts, how does it know what already happened?
If it starts from the beginning, it might send the email twice or create duplicate records.
Durable workflow systems address this problem by preserving workflow state and allowing execution to resume after failures. Temporal, for example, describes durable execution as persisting workflow state so long-running processes can recover from crashes and continue rather than restarting from scratch.
This is a distributed-systems problem as much as an AI problem.
Checkpoint Important Progress
A useful workflow should have identifiable progress points.
For example:
START
↓
REQUEST_VALIDATED
↓
DOCUMENTS_COLLECTED
↓
COMPLIANCE_CHECKED
↓
APPROVAL_PENDING
↓
APPROVED
↓
ORDER_CREATED
↓
COMPLETED
This gives the system a durable representation of progress.
If something fails after COMPLIANCE_CHECKED, the system does not necessarily need to repeat the earlier stages.
It can resume from the appropriate point.
The exact implementation depends on the orchestration technology, but the conceptual principle is widely useful:
Persist meaningful progress rather than relying on transient execution state.
Human Input Is an Event Too
Human-in-the-loop systems are often designed as interruptions.
A better mental model is to treat human decisions as events.
For example:
Agent prepares recommendation
↓
approval.requested
↓
Human reviews
↓
approval.approved
↓
Workflow resumes
The workflow does not need to remain actively running while someone considers the request.
It can persist the state, wait, and continue when the approval event arrives.
This becomes particularly useful for:
- financial approvals
- legal reviews
- customer escalations
- procurement
- hiring workflows
- security operations
- compliance processes
Temporal's current agent architecture materials explicitly describe maintaining state over long periods while supporting human intervention as an important orchestration capability.
Design for Timeouts
What happens if nobody approves the request?
A workflow should not wait forever.
Introduce explicit time-based events:
approval.requested
↓
wait
↓
24-hour timeout
↓
reminder.sent
↓
48-hour timeout
↓
escalation.required
This turns time into part of the workflow.
Other useful timers might include:
- follow up after 24 hours
- cancel after seven days
- retry after 30 minutes
- escalate after two failed attempts
- renew after 12 months
Traditional applications often implement these behaviors with scheduled jobs.
Long-running workflow systems can represent them directly as part of the workflow state.
Retries Should Be Designed, Not Added Everywhere
Not every failure should trigger the same retry behavior.
Consider three cases.
Temporary Network Failure
Retrying may make sense.
Invalid Customer ID
Retrying the same request probably will not help.
Payment Timeout
Blindly retrying may create a duplicate transaction.
Therefore, classify failures.
Failure
├── Retryable
├── Non-retryable
├── Requires human review
└── Unknown
For important side effects, combine retries with idempotency.
For example, a payment request can include a unique operation ID.
If the system receives the same request again, it can determine whether the operation was already completed.
This is conventional distributed-systems engineering, but it becomes particularly important when an AI agent is capable of initiating actions.
Use Compensation for Partial Completion
Distributed workflows can fail after some actions have already occurred.
Suppose:
Create account
↓
Charge payment
↓
Provision service
↓
Provisioning fails
The workflow is now partially complete.
One approach is to define compensating actions.
For example:
Provisioning failed
↓
Check whether payment should be reversed
↓
Refund if appropriate
↓
Mark account for review
This pattern is sometimes associated with the Saga pattern in distributed systems.
The important concept is that recovery does not always mean “start again.”
Sometimes recovery means undoing or compensating for completed actions.
This is particularly important for agents operating across several business systems.
Event Idempotency Matters
Events can sometimes be delivered more than once.
Suppose the system receives:
payment.completed
twice.
If the consumer blindly processes both events, it might send two confirmation messages or perform duplicate downstream actions.
A robust event consumer should therefore be able to recognize duplicate events.
A common conceptual pattern is:
event_id
↓
Already processed?
↙ ↘
Yes No
↓ ↓
Ignore Process
↓
Record event ID
This is another example of why agentic applications need conventional distributed-systems engineering around the AI layer.
Don't Put Every Decision Inside the Agent
Some decisions should remain deterministic.
For example:
if invoice_amount > approval_threshold:
require_manager_approval
There may be little value in asking an LLM to determine whether a numerical threshold has been crossed.
The agent might help interpret an invoice or explain why a case is unusual.
But deterministic business rules can enforce the actual threshold.
This creates a useful architecture:
Unstructured information
↓
Agent
↓
Structured result
↓
Business rules
↓
Workflow decision
IBM's current guidance on agentic automation similarly describes combining probabilistic AI capabilities with deterministic workflows and business rules rather than expecting generative models to handle every form of process logic.
Event Schemas Are Part of the Contract
If multiple services communicate through events, event definitions need to be stable and understandable.
For example:
{
"event_type": "invoice.received",
"event_id": "evt_12345",
"timestamp": "2026-09-24T10:30:00Z",
"invoice_id": "inv_456",
"supplier_id": "sup_789"
}
A useful event contract should establish:
- event type
- unique event ID
- timestamp
- entity identifier
- relevant metadata
- schema version
Schema evolution matters too.
If a service changes its event structure, downstream consumers should not unexpectedly break.
This is ordinary event-driven engineering, but agentic systems make the event flow more dynamic because an agent may consume events and decide which tools or workflows to invoke next.
Build Observability Around the Workflow
Long-running agents need more than application logs.
Developers should be able to answer:
- Which event started the workflow?
- What state is it currently in?
- Which actions have completed?
- Which tool calls occurred?
- Is the workflow waiting for a person?
- Which external service failed?
- How many retries occurred?
- Why was the workflow escalated?
- What will happen next?
A trace might look conceptually like:
workflow: supplier_onboarding_782
│
├── event: supplier.created
├── agent: classify_supplier
├── tool: get_supplier_profile
├── rule: compliance_check
├── event: approval.requested
├── wait: human_approval
├── event: approval.approved
├── tool: create_supplier_account
└── event: supplier.activated
This provides a much clearer operational picture than a collection of unrelated logs.
As agent workflows become longer and involve more systems, industry engineering guidance increasingly treats orchestration, state management, and traceability as core production concerns.
A Practical Architecture
A general event-driven agent architecture might look like this:
┌───────────────┐
│ Business App │
└───────┬───────┘
│
▼
┌────────────┐
│ Event Bus │
└─────┬──────┘
│
┌────────────┼─────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Agent │ │ Rules │ │ Service │
│ Worker │ │ Engine │ │ Worker │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└────────────┼────────────┘
▼
┌──────────────┐
│ State Store │
└──────┬───────┘
│
┌──────▼──────┐
│ Human Task │
└─────────────┘
The exact components will vary by stack.
The architectural principles are more important than the specific products:
- events trigger work
- state persists progress
- agents handle appropriate reasoning tasks
- deterministic systems enforce rules
- humans can participate asynchronously
- failures can be retried or compensated
- workflows can resume after interruption
When Should You Use This Architecture?
Not every AI feature needs event-driven orchestration.
A simple chatbot does not necessarily need a distributed workflow engine.
An event-driven, stateful architecture becomes more useful when the process:
- lasts longer than a single request
- interacts with multiple systems
- waits for external events
- requires human approval
- contains retries
- performs consequential actions
- must recover after failures
- needs an audit trail
- processes high volumes asynchronously
In other words, complexity should justify architecture.
Do not build a distributed workflow for a task that could safely remain a simple request-response application.
A Developer Checklist
Before building a long-running AI agent, ask:
State
- What information must survive a restart?
- Where is workflow state stored?
- What represents progress?
Events
- What events start the workflow?
- What events resume it?
- Are event IDs unique?
- Can duplicate events be safely handled?
Failure
- Which errors are retryable?
- Which require human intervention?
- Which actions need compensation?
Time
- How long can the workflow run?
- What happens if a person does not respond?
- Are reminders and escalation timers required?
AI
- Which decisions require interpretation?
- Which decisions should remain deterministic?
- What information does the model need?
Humans
- Where can people approve, reject, or modify an action?
- Can the workflow pause safely while waiting?
Operations
- Can developers trace the complete workflow?
- Can they identify the current state?
- Can a failed process resume without repeating side effects?
These questions are often more important to production reliability than the choice of model alone.
The Shift From AI Responses to AI Processes
The next stage of business automation is not simply about making AI responses more sophisticated.
It is about making AI systems capable of participating in ongoing processes.
That means an agent may need to:
Receive event
↓
Understand context
↓
Take action
↓
Wait
↓
Observe new event
↓
Continue
↓
Escalate
↓
Resume
↓
Complete
The agent becomes part of a process that can last minutes, hours, or days.
This is fundamentally different from a chatbot conversation.
It also explains why traditional software engineering concepts—state machines, event streams, durable execution, retries, idempotency, compensation, and observability—remain highly relevant in the age of agentic AI.
Final Thoughts
AI agents can make business automation more flexible, but flexibility also introduces engineering complexity.
Once an agent interacts with several systems and operates over extended periods, developers need to think beyond prompts and model calls.
They need to design for:
events, state, failure recovery, human pauses, retries, timeouts, idempotency, compensation, and observability.
Event-driven architecture provides one useful foundation for this kind of system because business events can trigger work without forcing every component to remain tightly coupled.
Durable workflow orchestration can then help long-running processes survive interruptions and resume from meaningful points of progress.
For developers and technology professionals exploring business automation, the AI Agent & Business Automation Professional E-Degree is one possible way to continue developing knowledge in this growing area.
The larger lesson is that production-grade agentic automation is not just about giving an AI model more autonomy.
It is about building the surrounding software so that autonomy can operate safely across time, systems, failures, and human decisions.
When those foundations are designed carefully, an AI agent can become more than a chatbot that answers a request. It can become one component of a resilient, event-driven business process.
Top comments (0)