Inconsistent Workflow State

Definition

When agents hold inconsistent views of shared workflow state (divergent copies of shared memory or Directed Acyclic Graph (DAG) node objects), they act on contradictory information simultaneously. The result is conflicting actions, stale approvals, or silent denial of service for legitimate claim processing.

What it looks like in practice

In an RPA expense reimbursement pipeline, a validation agent writes an “approved” flag to a shared state object after completing its check. Due to a state synchronisation delay, the routing agent reads the object before the flag is committed and finds it in the default “pending” state. The routing agent silently drops the claim rather than forwarding it for payment. The claim disappears from the queue without an error event; it is not rejected, but it is also never paid.

In the ElizaOS context, insufficient isolation between agent actions (T31) allows a state write from one agent to corrupt the shared object that a peer agent is actively reading, producing conflicting tool call outcomes from a single logical operation.

Why it’s dangerous in multi-agent context

Each agent in a multi-agent workflow maintains a local view of shared state. Without state-consistency guarantees such as versioned objects, optimistic locking, or distributed transaction semantics, an agent may commit an irreversible action (approve, route, pay) that a peer agent would have blocked had it been consulted. Unlike a single-threaded system, there is no natural serialisation point. Autonomous action on a stale view produces outcomes that are neither logged as errors nor visible as anomalies; the system appears to be operating normally while claims are silently dropped or incorrectly processed.

Detection signals

State-inconsistency failures are silent by default. The system emits no error, so detection requires purpose-built completeness checks on the workflow event stream.

• A claim ID that is present in the validated state partition of the state store but has no corresponding routed event in the workflow event log within the defined SLA window (e.g. 30 seconds after validated timestamp): wire a missing-transition alert to the event log consumer.
• A routed event for a claim ID where the state object’s validation_status field is pending rather than approved or rejected. This read-time assertion fires when the routing agent acts on an uncommitted validation result.
• A non-monotonic version sequence on a shared state object: a write whose version field is lower than the current committed version in the store. This indicates a stale-read followed by a clobbering write, an optimistic-locking violation.
• Two agents emitting conflicting tool call outcomes for the same logical operation within the same 100 ms window. Correlate tool-call logs by claim_id and flag any pair where one agent records approved and the other records dropped for the same ID.
• A sustained rise in the ratio of claims reaching created status versus claims reaching paid status, without a corresponding rise in rejection events. This throughput-divergence metric indicates silent drops accumulating in the queue.

Mitigations

• Version all shared state objects and require agents to read the current version before writing; reject writes that conflict with the latest committed version (optimistic locking).
• Enforce a “completed” state transition as an atomic operation; agents downstream of a step must not read state until the upstream agent has committed a terminal status.
• Emit a step-level state-change event on every transition; alert on missing transitions (a claim in “validated” status for longer than a defined threshold without a “routed” event following).
• Use a distributed lock or a saga pattern for multi-agent workflows where actions span multiple agents and must be rolled back atomically on failure.

Relation to base threat (T1–T17)

T21 extends T2 Tool Misuse. Where T2 addresses a single agent misusing a tool, T21 addresses the multi-agent coordination layer: state inconsistency between agents produces the same class of incorrect tool invocation without any individual agent behaving maliciously. T19 (Unintended Workflow Execution) is the companion threat where the wrong step executes because the workflow graph is miswired rather than because state synchronisation failed.