Executive Summary

Key Numbers

Source: arXiv:2608.05412

This is not a risk waiting to arrive. It was measured in code that is already deployed.

Picture an agent parked in front of an approval request. Step 1 searched the internal document store and gathered the evidence; step 2 will turn that evidence into an answer. The reviewer takes two hours to click approve, and during those two hours a nightly batch rebuilds the search index. The resumed run finishes its answer on top of the new index. The world the evidence came from and the world the answer was written in are not the same world.

This failure never surfaces as an exception. The retrieval succeeded. The model call succeeded. No retry fired, no timeout tripped. What the observability stack shows is one run that completed normally. That is exactly the point the paper presses on: a workflow ends up mixing state it saved with premises that moved underneath it, and the result can be internally inconsistent while every single call reports success.

The harder part is that none of the names change. In the paper's phrasing, stable names acquire new behavior. The model alias in the code is the one from last month, the prompt template lives at the same path, the vector index answers to the same identifier. What moved is the thing those names point at today. From the deployment pipeline's side this is a routine update. From the running workflow's side the ground has split.

The paper sets its condition in the first sentence. AI executions can now outlive the environments they started in. Work that used to fit inside a single model call now unfolds across pauses and retries, across branches, subagents, and tool calls the model chooses at runtime. The longer a run lives, the more room there is underneath it for resources to be swapped out.

The diagram below lays two clocks on top of each other. The upper track is the workflow's progress; the lower one is the deployment schedule of the resources that workflow depends on. Neither track knows the other exists.

Practitioners were already arguing about this distinction. Teams working on production agent runtimes have made the point repeatedly: writing a checkpoint and guaranteeing that the resources the checkpoint references are still valid are two different guarantees. Session memory surviving a crash proves nothing about which shell commands actually ran, or whether a retry fired a side effect twice. Restoring state and restoring premises are separate jobs.

The paper's practical contribution is splitting this slippage into four anomalies that a machine can detect. Until they had names, these symptoms were lumped together as one unreproducible bug. The four arise at different points in a run, which is why they call for different defenses.

The names are semantic read skew, compatibility skew, context escape, and merge skew. The table below sets each one next to the moment it arises and the shape it takes in production.

One problem runs through all four. What the answer rested on was never held fixed for the length of the run. The first comes loose along the time axis, the second between paired resources, the third at the boundary of delegation, the fourth where branches come back together. Only the place it comes loose differs; what gets lost is the same.

The paper calls this an isolation problem. Database transactions constrain concurrent data updates, but workflow checkpointing has no comparable contract for concurrent changes to the semantic environment. Same class of hazard, and one side has four decades of discipline while the other side has nothing.

Who wrote it sets the weight of that diagnosis. Barzan Mozafari spent his research career at the University of Michigan on database concurrency control and approximate query processing, and now runs a company that optimizes data warehouses with agents. This is not someone borrowing transactions as a metaphor for AI workflows. It is a researcher from the lineage that built isolation theory moving his own field's instruments up one layer.

The way he moves them follows database grammar too. He defines three independent guarantees, then derives a partial order of isolation levels from how they combine. How many anomalies you are willing to tolerate becomes the question of which level you pick.

Each guarantee protects something different. Resource stability holds the definitions a run references so they cannot change underneath it. Cross-resource compatibility checks that resources meant to work as a pair, like an embedding model and its vector index, never meet in a mismatched combination. Continuation inheritance carries the original premises into runs revived from a checkpoint and into work handed off to subagents. None of the three substitutes for another. Stability alone misses mismatched pairs, and without inheritance the premises are severed the moment work is delegated.

The names that fall out of the combinations are familiar too. Serializability and snapshot isolation are calibration marks that concurrency control research refined through the 1980s and 1990s, and the paper puts the word semantic in front of the same marks to define Semantic Read Committed and Semantic Snapshot Isolation. The diagram below shows how the three guarantees on the left lead to the levels on the right.

Having the marks at all is the more useful part for practitioners. Agent reproducibility has been discussed as something a system either has or does not. Once isolation levels are defined as a partial order, you get to decide how much you are willing to pay for. A long-running workflow with a human approval step can be pinned at a strict level while a short lookup task runs at a loose one.

A theory-only paper would have stopped there. Instead the author ran a source audit across the 100 most-starred public repositories containing runnable LangGraph code. The criterion was deliberately conservative. It counted only cases where a durable workflow references a live resource or a runtime-selected semantic resource inside the same workflow, with no immutable binding anywhere in sight. Under that condition, 7.4% were flagged.

That is roughly one in thirteen. Given that these are the heavily starred repositories people copy as reference implementations, the reach matters more than the number. And because the bar was conservative, real exposure is likely wider.

The symptom was being observed before the paper gave it a name. A public RFC filed against the LangGraph repository describes behavioral drift across checkpoints: specific vocabulary disappears or tool-calling patterns change with no error raised, and the execution logs read as clean successes. That is effectively the paper's semantic read skew, surfaced first by a practitioner in their own words.

An analysis published around the same time argued that agents are unusually exposed to version drift, because a single logical step hangs simultaneously on the model version, the prompt text, the tool schema, the retrieval index, the memory snapshot, the sandbox image, and the policy rules.

SemIso, the prototype the paper ships, enforces these guarantees in middleware. It propagates semantic context into child executions and blocks incompatible resources and unsafe branch merges at runtime. The reported cost of those checks is on the order of microseconds. The claim is that reproducibility does not have to be bought with a large slice of execution speed. Whether the same numbers hold on other runtimes has yet to be tested.

All four anomalies are decidable only if the resource identifiers in force at execution time are still around. That condition belongs to the data side before it belongs to middleware. If nothing records which snapshot the index was on, which version the embedding model was, which revision the policy document had reached, then the middleware has nothing to decide against either.

That is why an unreproducible run can be neither audited nor debugged. When a regulator asks why a given decision was made, you have to be able to reconstruct the evidence set as it stood at that moment, and if the resources flowed past without versions there are no coordinates to go back to. The same holds in a postmortem. If the same input no longer produces the same answer, there is no way to confirm what needs fixing.

Two things are worth checking on the data operations side right now.

• • Is there a record of what the run pinned when it started? Model alias, index snapshot, prompt version, policy revision, captured as premises of the execution rather than lines in an application log. Write down what the name pointed at in that moment, not the name, or there is nothing to compare against later.
• • Does that record survive resumption and delegation? If the premises are cut at a checkpoint restore, at a handoff to a subagent, or where parallel branches merge, the record made earlier stops being useful. Keeping lineage ultimately means the same coordinates hold across those three boundaries.

Data versioning and lineage have long been discussed as instruments for analytical reproducibility and regulatory response. They were records kept so a person could check them later. The character changes once something reads those records mid-run and decides whether the next step is allowed to proceed. What was nice-to-have documentation becomes plumbing, and without it nothing can be decided at all.

Academic Papers

• 1.Mozafari, Barzan. (2026). "BEGIN AI TRANSACTION: Semantic Isolation for Durable AI Workflows." arXiv:2608.05412 [cs.DB].

Industry Observation and Public Discussion

• 2.langchain-ai/langgraph Issue #7327. "RFC: Observability hook for cross-checkpoint behavioral drift in long-running agents." GitHub.
• 3.Zylos Research. (2026). "Durable Execution for AI Agent Runtimes: Checkpointing, Replay, and Recovery."
• 4.Diagrid. (2026). "Why Checkpoints Aren't Durable Execution."
• 5.arXiv. "cs.DB Recent Submissions." Latest papers in the databases category.