Govern Agent Concurrency by Invariants, Not Workflows

Autonomous organizations will not fail because they run too few agents at once. They will fail when individually authorized, locally sensible actions combine into an invalid business outcome.

That is the concurrency problem. An agent can be entitled to approve a refund, reserve inventory, change a deployment setting, or assign an on-call engineer. Its reasoning can be sound against the state it observed. A second agent can be equally entitled and equally sound. Yet both actions may rely on the same scarce capacity, threshold, separation-of-duty rule, or safety constraint. If they execute from overlapping or stale views of that state, the organization can violate an invariant without any actor exceeding its authority.

The useful unit of control is therefore not the agent, prompt, queue, or workflow. It is the business invariant: a condition that must remain true as the organization changes state. Governance should make those invariants explicit, then use them to determine which operations can proceed concurrently, which must validate a current precondition, and which require a single ordered decision.

Start with an invariant catalog

An invariant catalog is a governed record of the conditions that actions must preserve. Examples include: committed spend must remain within an approved budget; a customer cannot receive two mutually exclusive offers; minimum staffing must remain above a defined floor; one person cannot both request and approve a sensitive change; stock promised across all channels cannot exceed available stock.

This is more precise than a workflow diagram. A workflow says that one activity usually follows another. An invariant says what must be true even when activities arrive through different agents, tools, queues, or recovery paths. The latter is what a runtime needs when parallel work becomes normal rather than exceptional.

For every mutation, the catalog should identify the invariant or invariants affected, the state read to make the decision, the state scope covered by each protection mechanism, and the consequence of a failed precondition. An agent decision should carry this dependency set: the relevant state versions, the policy basis, and the invariants on which its proposed effect depended. At the mutation boundary, the runtime can then test whether that evidence remains valid.

Classify operations into three execution modes

The catalog supports a practical classification. It does not demand global serialization, which would discard much of the value of autonomous execution. It demands coordination where correctness actually requires it.

1. Coordination-free

An operation is coordination-free when concurrent executions and their merge preserve the relevant invariant. Invariant confluence provides the formal criterion: if all valid independent executions can be merged while retaining the application invariant, coordination is not required to guarantee correctness.

These operations may be safely parallelized, subject to their own authorization and effect-handling rules. The question is not whether the agents are different. It is whether any possible combination of their valid effects leaves the governed state valid.

2. Conditional

An operation is conditional when it remains valid only if a specific state assumption still holds at commit. An agent may determine that a change is safe against version 41 of an object. The runtime should not silently apply that decision to version 42. It should require a version or state precondition at the write boundary.

HTTP If-Match is one familiar mechanism. RFC 9110 specifies that it can prevent lost updates: when the supplied entity tag does not match, the server must not perform the requested method. Kubernetes applies the same basic pattern with resourceVersion, rejecting a stale object update with HTTP 409 Conflict.

But a validator only protects the state it covers. An ETag on one record cannot establish an invariant spanning multiple records, services, or tools. For broader state, the condition must be checked where that broader invariant can actually be enforced.

3. Serialized

An operation must be serialized when no safe merge exists and correctness requires one ordered decision. A shared limit, exclusive allocation, or cross-record constraint may belong here. Serializable isolation is one implementation option within a database boundary: successfully committed concurrent transactions must have an effect consistent with some one-at-a-time execution order. PostgreSQL detects patterns that could lead to serialization anomalies, aborts a transaction, and requires the application to retry.

The important design choice is not simply to select a serializable database setting. It is to identify the decision boundary that needs ordering. Snapshot-style isolation can permit write skew: two transactions read a valid state, make disjoint writes, and together produce a state that no serial execution could produce. That is precisely the kind of failure an organization sees when separate agents make compatible-looking local decisions against the same business rule.

Treat conflict as a governance event

A rejected compare-and-swap, an HTTP 409, a serialization abort, or a failed reservation should not disappear inside a generic retry loop. It means that the agent’s evidence no longer supports the intended effect—or that another valid action has claimed the relevant state first.

The runtime should bound retries, refresh the relevant evidence, and re-evaluate the action under the current policy and state. Repeated conflicts should be observable operationally: they may reveal a capacity bottleneck, an over-broad invariant, poorly partitioned work, or agents targeting the same decision surface too often. A conflict log is not merely debugging data. It is feedback on organizational design.

“Parallelism is safe only when the organization can explain why the combined effects remain valid.

Do not confuse concurrency with adjacent controls

Authorization asks whether an actor may perform an action. It does not establish that two authorized actions are compatible. Idempotency and exactly-once effect handling ask whether one intended business effect was duplicated. They do not prevent stale-state decisions, write skew, or incompatible commitments. These controls are all necessary in an autonomous runtime, but they solve different questions.

Locks and leases also need careful treatment. A paused former lease holder may resume after its lease expires and attempt a write. A lease alone does not make that write safe. Fencing tokens address this failure mode by assigning each acquisition a monotonically increasing token; the protected resource must reject writes carrying an older token. The check belongs at the resource that can prevent the effect, not only at the coordinator that issued the lease.

Finally, a strong transaction has a boundary. Spanner documents that its internal locks provide consistency within the database, not exclusive access to external resources. A database transaction cannot by itself make a payment provider, SaaS platform, or physical device part of the same atomic action. Cross-system effects require an explicit protocol: reservations where available, durable intent and reconciliation, conditional APIs, and governed compensation when an outcome cannot be prevented.

Make the policy executable

A governed runtime should compile its concurrency policy into the action path. Before execution, it resolves the relevant invariants and selects a mode: coordination-free, conditional, or serialized. The agent produces a proposed effect with its dependency set. At commit, the runtime enforces the appropriate mechanism—merge rules, a version check, a reservation, a serializable transaction, or a lease with fencing—and records the result.

This changes the operating model. Teams no longer argue abstractly about whether agents should be allowed to run in parallel. They define which business truths must survive parallel work, attach those truths to mutations, and make a failed assumption visible before it becomes an invisible last-write-wins outcome.

The goal is not a slower organization that serializes everything. It is an organization that spends coordination precisely where invariants demand it, while allowing safe work to move at machine speed.

Sources: Bailis et al., “Coordination Avoidance in Database Systems” (VLDB); PostgreSQL documentation on transaction isolation and Serializable Snapshot Isolation; RFC 9110; Kubernetes API Concepts; Martin Kleppmann on fencing tokens; Google Cloud Spanner transaction documentation.