Causal Event Ordering for AI Agents: Stop Late Tool Results From Rewriting the Past

An agent starts a customer lookup, then the user changes the target account. The second lookup returns first and the interface shows the correct account. Ten seconds later, the original request finishes and overwrites state with stale data. Every tool call succeeded. The failure is causal ordering.

Concurrent agents amplify this bug because searches, database reads, model calls, and remote actions have different latencies. Arrival order is not intent order. A reliable runtime must know which event caused each request and whether the result still applies when it returns.

Give every decision a durable identity

Assign a run ID, turn ID, and monotonically increasing decision sequence before dispatching tools. Every child request inherits those identifiers plus the version of the state it read.

type ToolRequest = {
  runId: string;
  decisionSeq: number;
  stateVersion: number;
  causalParents: string[];
  tool: string;
  argumentsHash: string;
};

Do not derive identity from a model-generated label. IDs must come from the orchestrator and survive retries, restarts, and context compaction. Persist them before the outbound request so a crash cannot erase the relationship between intent and result.

A tool result repeats the request identity and adds a provider correlation ID. A callback must bind to the same record. An unknown callback is quarantined rather than attached to the newest run merely because it looks relevant.

Separate order from causality

A sequence number establishes order inside one orchestrator, but distributed work may have several valid orders. Two read-only searches launched from the same decision are concurrent; neither caused the other. A draft launched after both searches depends on both.

Represent relationships with causal parents or a small directed acyclic graph. Lamport clocks establish a consistent happened-before relation, while vector clocks capture concurrency across writers. Most application agents do not need a full academic implementation, but they need explicit dependencies.

const event = {
  id: newId(),
  parents: [searchA.id, searchB.id],
  logicalTime: Math.max(searchA.time, searchB.time) + 1,
  kind: "draft_created",
};

Wall-clock timestamps are insufficient. Machines drift, providers report different time zones, and network delays reorder arrival. Keep timestamps for diagnostics, but use orchestrator-issued versions and causal links for correctness.

Reduce events deterministically

Do not let asynchronous callbacks mutate application state directly. Append validated events to a journal, then derive current state with a deterministic reducer.

function reduce(state: State, event: Event): State {
  if (event.runId !== state.activeRunId) return state;
  if (event.baseVersion !== state.version) return markStale(state, event);
  return applyAllowedTransition(state, event);
}

The reducer enforces a state machine. A late success cannot reopen work already superseded by a new decision. Invalid transitions remain in the audit log with a rejection reason.

Determinism makes recovery testable. Replaying the same ordered event set should rebuild the same state. If model inference runs inside the reducer, replay can change; keep model calls as recorded events and reduce only validated outputs.

Use optimistic concurrency at effect boundaries

Before a state-changing tool runs, verify that the resource version and agent decision are still current. APIs supporting ETags, revision numbers, or conditional updates can reject stale writes.

PATCH /tickets/123
If-Match: "revision-18"
Idempotency-Key: run-77-step-4

If the resource moved to revision 19, fetch the new state and re-plan. Do not force the original update through. The new revision may contain a human edit, another agent’s action, or a policy change.

For providers without conditional writes, place a serialized command handler in front of the effect or acquire a narrow lease. Keep leases short, renewable, and bound to one operation. A global lock around the entire agent destroys useful concurrency and creates new failure modes.

Cancel intent, then handle late completion

Cancellation does not prove remote work stopped. Record cancel_requested, call the provider cancellation API when available, and continue accepting a terminal callback. The reducer decides whether that result can still influence active state.

A read result from a cancelled branch can usually be archived as stale. A completed payment or message requires reconciliation because the external effect exists. Ordering controls do not replace idempotency or compensation; they decide which recovery policy applies.

Prompts should receive only admitted evidence. A late result can remain in the audit journal without entering the active context. Otherwise a model may confidently revive an abandoned plan because the stale output appears last in the message list.

Merge only commutative work

Some concurrent results combine safely. Independent search sets can be unioned and deduplicated. Counters can sometimes use atomic increments. Draft edits to different fields may merge.

Do not assume all writes commute. “Set status to closed” and “add urgent note” have order-dependent meaning. Encode merge rules by event type and resource rather than asking a model whether two JSON objects look compatible.

When a human and agent edit the same object, prefer an explicit conflict over silent last-write-wins. Show both versions, causal metadata, and disputed fields. The person can decide without reconstructing a hidden timeline.

Test the reordering matrix

Run concurrency tests with reversed completion order, duplicated callbacks, missing callbacks, retry responses, clock skew, cancellation races, and process restarts. Inject a new user turn while old tools are still running. Verify that old results cannot overwrite the new target.

Property tests are effective: events declared independent should reduce to the same state under random permutations. Dependent events in invalid orders should be rejected visibly.

Monitor stale-result counts, version conflicts, unknown callbacks, reducer rejections, and dependency wait time. Rising stale reads may indicate slow tools or overly eager parallelism; rejected writes may reveal multiple owners for one resource.

The core rule is simple: newest arrival does not mean newest intent. Durable identities, causal parents, version checks, and deterministic reducers let an agent use concurrency without allowing latency to rewrite history.