What Is a State Footprint?
A state footprint is the full set of state an agent task reads and writes while it runs: its own context and local files, the orchestrator's plan and task status, and external systems such as code repositories, databases and APIs. Two tasks conflict when one writes an item the other reads or writes. Recording footprints lets a multi-agent orchestrator order conflicting tasks, undo only what a failed task touched, and tell which earlier results are still valid.
Updated
What is a state footprint?
Oto Mraz, Rares Şerban, Kyriakos Psarakis, Burcu Kulahcioglu Ozkan and Asterios Katsifodimos of Delft University of Technology and Ververica define the term in Tracking State Footprints: How Agents Can Transact (arXiv, October 2026), which outlines a vision for agent orchestrators that give database-style guarantees. The term borrows from separation logic, "where a program's footprint is the set of locations it accesses." In the authors' words: "Picture an agent walking through local and external state, inspecting or modifying it along the way; the footprint is the trail it leaves."
The problem they name is that "most of today's orchestrators track control flow, i.e., which task runs after which, but not data flow, i.e., which state each task reads and writes." Agent state sits in three scopes that differ in who can see, undo and reproduce it. From the paper's Table 2:
| Scope | Examples | Observable by | Reversible | Reproducible |
|---|---|---|---|---|
| Agent-local | context, tool calls, unstaged files | the agent only | via sandbox or snapshot | artifacts, not context |
| Orchestrator | task graph, status, idempotency IDs | the orchestrator | yes, it owns them | yes, logged |
| External | repositories, REST APIs, MCP, databases | everyone | if staged; otherwise compensate | only if idempotent |
How a state footprint works
Each task gets a read set and a write set drawn from any scope. "Two tasks conflict if one writes an item that the other reads or writes, and a schedule is conflict-ordered if every pair of conflicting tasks is ordered." Footprints are not known in advance, because new dependencies appear mid-run, so the paper proposes that "A sound approximation is to record everything an agent observes through its tool calls and task inputs."
Its worked example is a Django refactor. Task T0 changes a core Signal constructor and deletes a stored attribute; tasks T1 to T3 then update callers in parallel. Every task succeeds, and the merged code fails its tests:
- 1.Write-write. T1 and T2 both edit a shared test fixture. The merge reconciles it silently, so one task's setup never runs.
- 2.Read-after-write. T2 runs after T0, as planned, but reads the deleted attribute in a debug path. Nothing tracked that dependency, so it surfaced only when the final test suite failed.
Ordering tasks wasn't enough: "The cause was not when T2 ran, but whether T0's write was checked against a dependency." In the authors' runs, a task-ordered plan cut duration by about 40% against sequential execution but broke correctness, while a repaired, conflict-ordered plan succeeded and still cut duration by a factor of 1.23 against sequential.
Why state footprints matter in real-time systems
Coding is the forgiving case. Git gives coding agents "a natural transactional substrate: staging, atomic commits, and cheap rollback," the authors note, but "Most domains lack such a substrate. Supply-chain operations, scheduling, and incident response operate without version control; effects are immediately visible and often irreversible."
That puts the burden on external systems. The paper asks them to accept a task's transaction identifier, make writes tentative (try-confirm-cancel) or compensable, let writes "be conditioned on the state that their task reads," declare which operations are idempotent or reversible, and offer cheap branching for parallel agents.
A conditioned write is the piece a transactional store already provides. Where shared agent state, such as task claims, budgets or coordination records, sits in a store with serializable transactions, a read and the write that depends on it commit together or not at all. Tacnode holds agent state of this kind with full transactions; recording footprints across files, context and third-party APIs remains the orchestrator's job. The options for the shared-state part are compared in concurrency control for multi-agent systems.
FAQ
Related terms
A race condition occurs when a system's outcome depends on the timing of concurrent operations, letting interleaved reads and writes corrupt shared state.
Isolation levels control how database transactions see each other's concurrent changes, from READ UNCOMMITTED to SERIALIZABLE. Anomalies, defaults, examples.
The blackboard pattern coordinates independent specialists through one shared workspace they read and write, instead of through messages between them.
The saga pattern coordinates a distributed transaction as a series of local transactions, each paired with a compensating action that undoes it on failure.
Idempotency means an operation has the same effect whether applied once or many times. Covers its math origin, HTTP methods, and API idempotency keys.
Cognitive serializability is a correctness condition for AI agent writes: each commit needs a point where every input the agent reasoned over was unchanged.
Multi-writer contention is two or more actors reading and writing the same mutable state in the same short window. It is not multi-tenancy or partitioning.
Unmergeable state is shared mutable state whose concurrent updates can't be combined afterward without breaking a rule, such as a budget, quota or balance.