Event-driven AI agents: how to wait, correlate and resume without mistakes

The approval arrived. It resumed the wrong request.

A distributor's credit application handles a relationship manager's request for a $100,000 credit-limit increase. It gathers account history, contract terms and payment behavior. A model recommends approval, rules check the financial limits, and the workflow pauses while a regional credit manager reviews the exact proposal. That's run E-104, proposal P-17.

Before the manager responds, a second request arrives for the same customer: a $250,000 increase with a different justification. It becomes run E-109, proposal P-22, and it pauses too.

The manager approves P-17. The approval service publishes an event with the customer account, the approver, a timestamp and approved=true. It doesn't include the run, the wait, the proposal or a digest, because the original design assumed only one review per account at a time.

The consumer matches on account and event type, and picks the most recently registered wait. That's E-109. Proposal P-22 resumes and the $250,000 limit is committed.

The event was authentic. Its schema was valid. The approver was authorized. The broker delivered it. The wrong business decision moved forward. No single component failed; the failure lived in how event, correlation, waiting state and proposal related to each other.

Is an event-driven AI workflow just messaging?

No. Messaging moves data. An event-driven workflow also decides what a message means, which waiting case it may affect, whose authority it carries, whether it's current or duplicated, and what evidence must remain.

Standards give a good base. CloudEvents defines a portable event context (ID, source, type, version) and lets a duplicate keep the same source and ID. AsyncAPI describes message-driven APIs, including payloads, headers and correlation IDs. Neither is meant to define the business meaning of your application.

A broker can deliver a message. It can't decide whether that message authorizes a credit increase, invalidates an earlier proposal, satisfies a waiting case, or should be ignored, rejected, escalated or kept only as evidence.

Not every message makes the same claim

The same channel often carries very different kinds of message. Treating them as interchangeable makes control flow ambiguous.

AI adds another kind: proposals. A model's risk assessment is a proposal or observation, not a verified fact. Name it riskAssessmentProposed, not riskCleared, which falsely implies that policy, evidence, authority and any human review are already settled. The model may propose an event or plan; the runtime decides whether it changes anything.

Which IDs does an event need?

Several, each with one job: event ID, trace ID, correlation ID, causation ID, run ID, wait ID, proposal ID and digest, operation ID and resource ID. One overloaded correlationId can't answer all their questions.

Trace context keeps a technical request path connected across services. That's valuable for diagnosis, but a trace ID isn't the business identity of a case, the cause of an approval or the idempotency key for an external action. Values can coincide sometimes; don't design as if they're interchangeable.

A wait is durable state, not a sleeping thread

A long-running workflow doesn't hold a thread open for three days while a manager decides. It saves its state, releases compute, and later rebuilds the conditions under which it may continue. Process standards have long treated waiting as an explicit part of a process. AI adds things that can change during the wait: models, prompts, context, policy, authority and proposal status.

A durable wait should preserve:

• the workflow version and dependencies that created it;
• the exact run, step and branch that paused;
• the expected event type, source, kind and validation rules;
• the precise correlation rule;
• the proposal ID, digest and evidence;
• the authority and policy that applied, and what to recheck;
• deadline, expiry, timeout path and late-event rule;
• the allowed record revision, sequence and competing waits;
• what happens on resume, and what evidence to keep.

What should happen before a paused AI workflow resumes?

A fixed sequence of checks: validate the event, bind it to the exact wait, rule out duplicates, check timing and order, recheck authority and policy, confirm the proposal hasn't changed, then choose a typed outcome and record it.

1. Normalize the message into the expected event contract.
2. Authenticate the producer and check integrity where needed.
3. Validate shape, kind, source, tenant, resource and classification.
4. Correlate to the exact run and wait, not just the business object.
5. Decide whether it's a duplicate of something already accepted.
6. Check event time, expiry, sequence and record revision.
7. Recheck the initiating authority, current actor, delegated scope and policy.
8. Confirm the proposal and material facts still match what was approved or awaited.
9. Choose an outcome: resume, ignore duplicate, reject, expire, ask for evidence, require re-approval or escalate.
10. Record the event, checks, decisions and state change.
11. Only then let the next step or change run.

This stops a common shortcut: resuming the same code path when the meaning of the wait has changed. A changed proposal, expired approval, different legal entity, new policy obligation or incompatible workflow version shouldn't silently inherit the earlier event.

Delivery guarantees stop at the broker

Messaging protocols offer different delivery levels. MQTT 5.0, for example, defines at-most-once, at-least-once and exactly-once delivery. Those guarantees cover transfer within the protocol. The application has more layers where zero, one or several outcomes can happen:

A transport can deliver once while a consumer creates two effects. It can deliver twice while the application creates one effect, thanks to a stable operation ID and reconciliation.

De-duplication and idempotency protect different things. The event ID stays the same when the same event is redelivered. The operation ID stays the same whenever the same business intent is retried, even under a new message. A genuinely new action gets a new operation ID even if it's for the same account. When you can't tell whether an effect committed, the state is uncertain, not failed: reconcile before retrying (see retries and idempotency).

Order is a business rule

Events arrive late, out of order, or after a newer state has committed. "Latest received" isn't "latest effective". Keep event time, receipt time, processing time, effective time and expiry separate. Where order matters, carry a record revision, sequence or expected prior state, and let the resume check decide whether a late event is accepted, rejected as stale, re-evaluated or sent to a person.

Authority can expire while you wait

Authenticating the producer doesn't prove the event may cause the change. A service may be trusted to publish approvals while a given approval has expired, sits outside the approver's legal entity, belongs to another tenant or refers to an earlier proposal. Zero-trust guidance rejects implicit trust from prior access; in a long-running case, conditions need rechecking when the event arrives.

That's why an approval can't be a boolean. It should bind the exact proposal and digest, the evidence shown, the approver's role and delegation, conditions and expiry, the governing versions, and the specific change it permits. If the amount, beneficiary, entity or another material fact changes, the approval no longer covers it (see human-in-the-loop approval).

Redelivery, replay and re-execution also stay distinct. Replay reconstructs a past case for inspection or simulation; it should never republish old events into production channels (see behavior replay).

Common anti-patterns

Ten rules for event-driven AI agents

1. Declare whether each message is a fact, command, signal, decision, timer, proposal or outcome.
2. Use a typed, versioned event contract for every consequential event.
3. Keep event, trace, case, cause, run, wait, proposal, resource and operation IDs separate.
4. Persist every wait as durable state tied to the version that created it.
5. Bind approvals to the exact proposal and evidence reviewed.
6. Recheck authority, policy, timing, order and material change before resuming.
7. Treat duplicate, late, reordered and uncertain events as normal, with typed outcomes.
8. Don't confuse delivery guarantees with business-effect guarantees.
9. Use stable operation IDs and reconciliation for every external change.
10. Record why each case woke up, and keep replay away from live effects.

The result: an event is a claim, not a command

Event-driven design is usually sold as decoupling: producers and consumers don't call each other directly. That's useful, but it isn't the core requirement for enterprise AI. The application has to preserve what each event claims, which exact state it may touch, whose authority applies, whether the proposal is still current, how duplicates and late arrivals are handled, and what proves the result.

A durable AI workflow isn't a long-running thread. It's a version-bound state machine that can show why it waited, what woke it, what changed while it slept, and why it was safe, or unsafe, to continue.