BEGIN AI TRANSACTION: Semantic Isolation for Durable AI Workflows
Analyze & explore related research in Conceptio
Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.
BEGIN AI TRANSACTION: Semantic Isolation for Durable AI Workflows Barzan Mozafari University of Michigan Ann Arbor, Michigan, USA mozafari@umich.edu position while losing the assumptions that give that state meaning. Just as database isolation controls which concurrent updates a transaction may observe, semantic isolation should control which concurrent changes to semantic resources (e.g., prompts, models, indexes, policies, and tools) an AI workflow may observe.
arXiv:2608.05412v1 [cs.DB] 5 Aug 2026
Abstract An AI execution can now outlive the environment in which it began. What once fit inside one model call increasingly unfolds across pauses, retries, branches, subagents, and model-selected tools. Meanwhile, prompts, model aliases, indexes, policies, and tools are deployed independently: stable names can acquire new behavior, and workflows can discover resources only after they start. The workflow can therefore combine saved state with changed assumptions, producing an internally inconsistent result even when every call succeeds. This is an isolation problem: database transactions constrain concurrent data updates, but workflow checkpointing provides no corresponding contract for concurrent changes to an AI workflow’s semantic environment. We define four automatically detectable anomalies—semantic read skew, compatibility skew, context escape, and merge skew. To control which anomalies are allowed, we derive a partial order of isolation levels, from Semantic Read Committed to Semantic Snapshot Isolation, by combining three independent guarantees: resource stability, cross-resource compatibility, and continuation inheritance. In a conservative source audit of the 100 most-starred public repositories with executable LangGraph code, we find that 7.4% of codebases with durable workflows resolve live or dynamically selected semantic resources within the same workflow, without an evident immutable binding. We show that these guarantees can be checked and enforced efficiently in middleware. Our prototype, SemIso, propagates semantic context and blocks incompatible resources and branch merges with microsecond-scale checks.
One report, incompatible assumptions —— Consider a compliance agent that retrieves vendor evidence under one policy, saves its findings, and pauses for human approval. While it waits, operators publish a stricter policy, rebuild the search index for a new embedding model, and change what a risk score means behind the same tool name. After approval, one branch resumes with the saved findings while another uses the new resources. Every call succeeds, but the agent can retrieve the wrong evidence, interpret a score backward, and combine recommendations written under incompatible policies. The final report has no coherent semantic basis even if every database read used snapshot isolation. Figure 1 separates the four ways this execution can fail. Deployments as concurrent semantic writes —— Transactions spare database applications from reasoning about every possible interleaving: they define a unit of execution, while isolation levels specify which effects of concurrent updates that unit may observe [3]. AI workflows need the same kind of choice for semantic resources—prompts, models, indexes, policies, and tools that determine what saved state means and how the next step interprets it. We model each deployment as a concurrent semantic write relative to every active workflow. This gap can be illustrated in LangGraph, a widely adopted opensource framework for building stateful, durable AI-agent workflows [12]. LangGraph checkpoints thread state for interruption and recovery, yet resumes do not automatically bind independently managed prompts, indexes, or tools [12, 13]. In our source audit, 7.4% of durable workflows among the 100 most-starred executable LangGraph codebases combine persisted state with live or dynamically selected semantic resources. Such a workflow can therefore resume with saved evidence or decisions whose meaning has changed because a prompt, index, or tool now resolves differently (see Section 5).
CCS Concepts • Information systems → Data management systems.
Keywords AI agents, workflow consistency, isolation levels, provenance
1
Introduction
The unit of AI computation is expanding from a single model invocation into a durable execution that can pause for a person, retry after failure, split into parallel branches, delegate to subagents, and discover tools as it runs. At the same time, consequential application logic is moving outside the program binary: prompts, model aliases, retrieval indexes, policies, and tool descriptions are deployed independently and can change behind stable names. These resources also depend on one another: for example, a vector index is meaningful only with a compatible embedding model, even though an incompatible query may remain type-correct and execute successfully. Thus, a long-running workflow can retain its data and control
Why narrower mechanisms stop short —— Existing mechanisms protect narrower boundaries. Provenance and registries record which versions were used [16, 22], but do not prevent an inconsistent commit. As previously mentioned, LangGraph checkpointers save thread state [13]; its recommended flow_version can retain old node logic after resume, but does not bind an external prompt, index, or tool [11]. Static pinning records the exact version of every dependency identity known at startup; it therefore provides complete coverage when the dependency universe is closed [8, 24]. 1
(a) Semantic read skew
Live
Persist policy Pol1
(b) Compatibility skew
Deploy policy Pol2
Live resume reads Pol2
Live
Persist index Idx1 (requires Emb1)
VIOLATION: Pol1 and Pol2 in one report
SSI
Bind Pol1 in manifest
Pol2 deployed concurrently
Resume reuses Pol1
SSI
Bind Emb1 + Idx1 in manifest
Emb2 + Idx2 deployed
Query Emb1 against Idx1
PROTECTED: compatible retrieval
(c) Context escape
(d) Merge skew
Parent binds policy Pol1
Deploy Pol2; spawn child
Fresh child reads Pol2
Live
Fork from saved report
VIOLATION: child loses parent's binding
SSI
Live query Emb2 against Idx1
VIOLATION: contract violation: Idx1 requires Emb1
PROTECTED: stable policy
Live
Deploy Emb2 + Idx2
Parent manifest contains Pol1
Pol2 deployed; spawn child
Branch A: Pol1 Branch B: Pol2
Default merge combines both
VIOLATION: no admissible manifest union
Child inherits and reads Pol1
SSI
Fork with inherited manifest
PROTECTED: context inherited
Branches carry local manifests
Validate before combining
PROTECTED: reject or recompute
Figure 1: An example illustrating the four semantic-isolation anomalies: a compliance workflow retrieves vendor evidence, pauses for approval, and resumes after deployments. Red shows live resolution; green shows Semantic Snapshot Isolation (SSI). The notation matches Section 2: Pol1 /Pol2 are policy versions, Emb1 /Emb2 are embedding models, and Idx1 /Idx2 are vector indexes. Each panel isolates one failure and its protected outcome. Table 1: Four independently checkable semantic anomalies.
A durable agent, however, may discover a tool or child only after model output or human input; predeclaring every candidate changes that assumption and can impose unnecessary retention. Timestamp-based snapshots [3] also fall short: simultaneously available resources can be incompatible, while versions created at different times can remain compatible. From anomalies to isolation choices —— In this paper, we define semantic read, compatibility, context-escape, and merge skew, as summarized in Table 1. For each anomaly, we specify a condition over resource versions, declared contracts, and inherited workflow context that a runtime can check automatically, without judging the generated answer’s factual correctness or quality. The guarantees that prevent these anomalies are independent: stability S, compatibility C, and inheritance I therefore form a partial-order lattice (Figure 2) rather than a single strength ladder. From this lattice, we define four named isolation levels: Semantic Read Committed (SRC), Repeatable Semantic Read (RSR), Compatible Read (CR), and Semantic Snapshot Isolation (SSI) (Table 2).
Anomaly
Observable condition
Read skew Compatibility skew Context escape Merge skew
One identity resolves to different versions. Selected versions violate a declared contract. A continuation loses an inherited semantic obligation. Locally valid branch manifests have no admissible union.
that manifest with workflow state, restores it on retry or resume, propagates it to branches and children, and validates late-discovered resources and branch combinations before use. In this paper, we make the following contributions: (1) We formulate semantic isolation as a transactional problem for durable AI workflows and define four automatically decidable anomalies. (2) We derive a partial-order family of isolation levels over resource stability, cross-resource compatibility, and continuation inheritance. (3) We provide real-world evidence for the problem: 7.4% of durable workflows in public codebases analyzed in our experiment persist state with live or dynamic semantic resources, and real LangGraph/Qdrant executions independently reproduce all four anomalies. (4) We show that AI-workflow middleware can verify and enforce semantic isolation efficiently by implementing SemIso
Enforcing semantic isolation —— The isolation levels specify what a workflow may observe; enforcing those choices requires runtime support across pauses, resumes, and dynamically discovered resources. We therefore propose SemIso, middleware for stateful AI-workflow frameworks. The application selects an isolation level when invoking a workflow. SemIso then records resource bindings and compatibility requirements in a semantic manifest, checkpoints 2
Semantic read skew —— The shortest history that demonstrates this anomaly is 𝑟𝑇 (Pol:Pol1 ); deploy(Pol:Pol2 ); resume(𝑇 ); 𝑟𝑇 (Pol:Pol2 ). One inherited context resolves the same identity to two immutable versions. We detect the anomaly when the trace contains 𝑟𝑇 (𝑥:𝑣𝑖 ) and 𝑟𝑇 (𝑥:𝑣 𝑗 ) with 𝑣𝑖 ≠ 𝑣 𝑗 . Equivalent records can consequently be judged under different instructions.
SSI (Semantic Snapshot Isolation) sticky | compatible | inherited
RSR (Repeatable Semantic Read) sticky | unchecked | inherited
CR (Compatible Read) live | compatible | inherited
Compatibility skew —— The shortest retrieval history that demonstrates this anomaly is 𝑟𝑇 (Emb:Emb2 ); 𝑟𝑇 (Idx:Idx1 ) although Idx1 declares a dependency on Emb1 . A tool variant presents Sch1 to the model but invokes Impl2 with a different contract identifier. Every access can remain well typed and available. We detect the anomaly when at least one declared dependency or compatibility condition evaluates false over 𝑀𝑇 .
SRC (Semantic Read Committed) live | unchecked | fresh context
Figure 2: The isolation levels form a partial order over three choices shown explicitly in each box: (1) live versus sticky resource binding, (2) unchecked versus compatibility-checked composition, and (3) fresh versus inherited continuation context. The two middle levels are incomparable: Repeatable Semantic Read adds sticky bindings, whereas Compatible Read adds compatibility checking. Semantic Snapshot Isolation provides both.
Context escape —— The shortest history that demonstrates this anomaly is 𝑟𝑇 (Pol:Pol1 ); spawn𝑇 (𝑐); deploy(Pol:Pol2 ); 𝑟𝑐 (Pol:Pol2 ), where 𝑐 should inherit 𝑇 ’s semantic context but starts fresh. Both versions are individually valid and compatible, so no compatibility condition fails. We detect the anomaly when a retry, resume, branch, child, or late resolver omits a profile or manifest obligation that its parent required it to inherit. Merge skew —— The shortest history that demonstrates this anomaly is fork𝑇 (𝑎, 𝑏); 𝑟 𝑎 (Pol:Pol1 ); 𝑟𝑏 (Pol:Pol2 ); merge𝑇 (𝑎, 𝑏). Each branch manifest is locally valid, but their union binds one identity to conflicting versions and the runtime nevertheless combines their artifacts. More generally, resources selected independently by the branches may violate a compatibility condition only after union. We detect the anomaly when 𝑀𝑎 and 𝑀𝑏 are each admissible, their union has no admissible common extension, and the branch artifacts are nevertheless merged. No anomaly implies another: each has a witness history in which the remaining three are absent. Read skew needs only two versions of one identity in one inherited context. Compatibility skew can occur with one stable, correctly inherited manifest. Context escape can occur when parent and child each use a single, internally compatible version. Merge skew can occur when both branches are locally stable and compatible but their union is inadmissible. We can therefore define and detect each anomaly independently. Note that the same four predicates apply whether the relevant access occurs during ordinary execution, retry, resume, routing, child-agent execution, or tool invocation.
with online manifest extension, continuation inheritance, and branch-merge validation (Section 4). The rest of the paper defines semantic state and its anomalies (Section 2), derives isolation levels (Section 3), presents the runtime (Section 4), evaluates the motivating evidence and implementation (Section 5), positions the work against related systems (Section 6), and concludes with future work (Section 7).
2
Semantic State and Anomalies
We now formalize the semantic state and the four failures introduced by the motivating example in Section 1 and illustrated in Figure 1. We first define the objects recorded during execution, then give the shortest history that demonstrates each anomaly and an automatically checkable condition for detecting it. We model an immutable resource version as a tuple containing its resource identity, version identifier, type, content or contract hash, availability, dependencies, and compatibility attributes. We represent an execution trace as an ordered sequence of resolution, deployment, continuation, fork, and merge events. We write 𝑟𝑇 (𝑥:𝑣) when execution context 𝑇 resolves resource identity 𝑥 to immutable version 𝑣. We define 𝑇 ’s semantic manifest, 𝑀𝑇 , as the partial identity-to-version mapping accumulated by that context together with its inherited compatibility obligations. We use the following notation in reference to the motivating example from Section 1:
Isolation versus nondeterminism —— Isolation and model nondeterminism are orthogonal: an AI workflow may produce different outputs while satisfying all four anomaly predicates; conversely, it may violate a predicate even when two generated outputs happen to match. Database isolation makes the same distinction: a history can be serializable even when a transaction performs nondeterministic internal computation, because serializability constrains the observable ordering of reads and writes rather than requiring repeated executions to produce identical results. Similarly, semantic isolation constrains the resource versions and contracts an execution may observe, not the determinism of the computation that consumes them. Having defined the failure modes, we next derive isolation guarantees that prevent selected subsets of them.
Policy: Let Pol1 and Pol2 be two versions of one policy or prompt identity. Search: Let Emb1 and Emb2 be two embedding versions. Idx1 is an index built for Emb1 . Tools: Let Sch1 be a model-visible tool schema and Impl2 be a tool implementation with a potentially different contract identifier. Contexts: Let 𝑇 be a parent execution context, 𝑐 be a child, and 𝑎, 𝑏 be parallel branches. 3
Table 2: Named isolation levels. “Allows” lists anomaly classes not excluded by the level: semantic read skew (SR), compatibility skew (CS), context escape (CE), and merge skew (MS). Level Profile SRC RSR CR SSI
3
Allows
Main cost
LangGraph application invoke
Outcome continue
commit / reject
SEMISO RUNTIME Manifest manager
Compatibility resolver versions + contracts
Impl.
⟨𝑆0, 𝐶0, 𝐼 0⟩ SR/CS/CE/MS fresh/live yes ⟨𝑆1, 𝐶0, 𝐼 1⟩ CS retention yes ⟨𝑆0, 𝐶1, 𝐼 1⟩ SR/MS contracts yes ⟨𝑆1, 𝐶1, 𝐼 1⟩ none retention+admission yes
Resource-version graph
Continuation + merge
selected version
result
Resource providers
Figure 3: SemIso’s architecture. The manifest manager decides whether to reuse or create a binding; the resolver selects a compatible version or applies the opaque-resource policy; and the continuation manager propagates context and admits or rejects branch unions. Providers remain on the data path and serve only the selected versions.
Isolation Levels for AI Transactions
We encode an AI transaction’s isolation contract as ⟨𝑆, 𝐶, 𝐼 ⟩ where 𝑆 ∈ {𝑆0, 𝑆1} is resource stability, 𝐶 ∈ {𝐶0, 𝐶1} is cross-resource compatibility, and 𝐼 ∈ {𝐼 0, 𝐼 1} is continuation inheritance. Under 𝑆0, each access may resolve the currently published immutable version. Under 𝑆1, the first access binds identity 𝑥 to version 𝑣, and every later access in the inherited context must return 𝑣. If 𝑣 is unavailable, preserving 𝑆1 requires aborting rather than silently substituting a version; an explicit capture/taint policy may instead weaken the guarantee. Under 𝐶0, published versions compose unchecked; under 𝐶1, their set must be dependency-closed and satisfy every declared compatibility predicate. Under 𝐼 0, a continuation may start fresh; under 𝐼 1, retries, resumes, forks, children, and late discovery inherit the profile and manifest obligations, and branches undergo merge admission.
remains compatible with the embedding model that built it. SSI therefore preserves one stable, dependency-closed, compatibilityvalid semantic cut, even when its versions were published at different times.
4
Runtime Design
We implement SemIso as Python middleware for LangGraph 0.6.7; however, the design applies to any durable-workflow framework with checkpoint and continuation hooks. At invocation, the application supplies its input, an isolation level (or custom 𝑆/𝐶/𝐼 profile), and an abort/capture/taint policy. Independently deployed providers—prompt registries, model endpoints, vector indexes, and tool services—register immutable versions and contracts in a shared resource-version graph. SemIso then uses three modules (Figure 3): a manifest manager records workflow context, a compatibility resolver selects admissible versions, and a continuation manager propagates context and admits or rejects branch merges. We discuss each module next.
A lattice, not a ladder —— These three guarantees are independent. A permanently bound but incompatible embedding/index pair separates 𝑆1 from 𝐶1; advancing between compatible policy/model pairs separates 𝐶1 from 𝑆1. A fresh child with its own stable, compatible resources separates 𝑆1 + 𝐶1 from 𝐼 1, while propagating live, unchecked resolution shows that 𝐼 1 implies neither 𝑆1 nor 𝐶1. The profiles therefore form a partial order: Repeatable Semantic Read provides stability without compatibility, while Compatible Read provides compatibility without stability, so neither dominates the other.
Manifest and version graph —— The shared graph records each provider version’s identity, type, hash, availability, dependencies, and compatibility attributes. The checkpointed per-workflow manifest records its isolation profile, identity-to-version bindings, parent/branch identifiers, decisions, and capture/taint status. Thus the manifest grows as the workflow discovers resources, while the graph changes as owners publish or retire versions. Owners or applications declare contracts such as “index 𝐼 1 requires embedding model 𝐸 1 ”; SemIso enforces but does not infer them.
Named isolation levels —— Semantic Read Committed (SRC), ⟨𝑆0, 𝐶0, 𝐼 0⟩, favors freshness and permits all four anomalies. Repeatable Semantic Read (RSR), ⟨𝑆1, 𝐶0, 𝐼 1⟩, preserves bindings but permits compatibility and merge skew. Compatible Read (CR), ⟨𝑆0, 𝐶1, 𝐼 1⟩, enforces inherited contracts but permits semantic rereads and same-identity merge skew. Semantic Snapshot Isolation (SSI), ⟨𝑆1, 𝐶1, 𝐼 1⟩, preserves one inherited, stable, compatibilityvalid semantic cut and prevents all four. Table 2 summarizes the levels and principal costs. Choosing an isolation level —— Stability sacrifices freshness, requires historical resources, and may abort when one disappears. Compatibility needs trustworthy contracts; inheritance enlarges checkpoints and may reject branches. A research assistant might choose CR for fresh but compatible resources, whereas a compliance report might choose SSI for one coherent basis.
Compatibility resolver —— For a requested identity, we reuse its manifest binding when stability is required. Otherwise, we scan available versions newest-first and select the first that preserves all dependencies and contracts; we then bind it and add its exact dependencies. A resource discovered after execution begins thereby extends the inherited context. If no version qualifies, the opaqueresource policy applies.
A semantic cut, not a timestamp —— Unlike a database snapshot, a coherent AI environment may not correspond to a single logical timestamp: providers may not share a clock, and simultaneously available versions can be incompatible. Conversely, an older index
Continuation manager —— The manager stores the profile and manifest in LangGraph’s checkpoint. Retries and resumes restore it; under 𝐼 1, children inherit it and forks receive copies. Before releasing merged output, the manager unions branch manifests 4
and rejects conflicting bindings, violated contracts, unavailable dependencies, or disallowed taint. Rejection preserves the parent checkpoint for recomputation or an explicit weaker policy.
source-visible exposure (%)
Top-100 primary population and complete-corpus robustness
Opaque-resource policy —— This transaction input governs requests that the resolver cannot bind immutably. Abort ends the transaction; capture records the observed request/response as a local artifact; and taint permits progress while marking the weakened guarantee. Capture preserves the observation, not hidden behavior or side effects. SemIso’s current prototype supports SRC, RSR, CR, SSI, and caller-specified profiles. In Section 5, we use Qdrant 1.16.1 in local mode for real vector search without a separate server.
5
15.0 12.5 10.0
4/54
7.5 5.0
5/97
4/100
5/173
2.5 Top 100 eligible (primary)
All 173 eligible (robustness)
Figure 4: Source-visible exposure. The primary top-100 population contains 4/100 exposed codebases overall and 4/54 among durable codebases. The complete search universe is shown as a robustness check; bars include 95% confidence intervals.
Evidence and Evaluation (1) Do public codebases exhibit conditions that enable semantic anomalies (Section 5.1)? (2) Can the four anomalies arise independently in a real durableworkflow framework, and which mechanisms prevent them (Section 5.2)? (3) What metadata cost does SemIso add (Section 5.2)?
Table 3: Baseline outcomes: O=occurred/allowed, D/A=detected after commit, P=prevented, N=did not occur.
Empirical Findings
Methodology —— We search GitHub repository descriptions and READMEs for “LangGraph,” restrict results to Python repositories pushed since January 1, 2025, exclude forks and archived repositories, and sort by stars. The query returns 300 repositories. We inspect each repository’s latest default-branch HEAD and call it eligible if it contains executable Python code that imports LangGraph; 173 repositories qualify. Our primary population is the 100 eligible codebases with the most stars, of which 54 use durable execution. We classify a codebase as exposed only when the same executable workflow or directly connected runtime combines durable execution with a mutable or late-bound semantic resource and has no source-visible immutable binding. We manually verify every positive against this same-workflow criterion.
Mechanism
Read
Compat.
Escape
Merge
Default Provenance flow_version Static pinning SemIso (SSI)
O D/A O P P
O D/A O P P
O D/A O P P
O D/A O P P
Anomaly isolation —— Table 3 compares five mechanisms. Default admits all four anomalies; Provenance observes the same histories and reports them only after commit. flow_version preserves v1 graph-node selection after v2 is deployed, but does not bind external resources. Static pinning records every startup-known identity and prevents all four closed-world histories. SemIso under SSI also prevents all four and rejects the invalid branch union before commit. Separately, runs of the named isolation profiles match Table 2: SRC admits all four anomalies, RSR admits compatibility skew, CR admits semantic rereads and same-identity merge skew, and SSI admits none.
Findings —— Among the top 100 codebases, 4 meet the exposure rubric: 4.0% of the full population and 7.4% of its 54 durable codebases. These source-visible conditions establish that the risk can arise in real code; they do not show that an anomaly occurred, and controls outside a repository may prevent it.
5.2
exposed / durable
17.5
0.0
Our experiments answer three questions:
5.1
exposed / eligible
20.0
Open-world discovery —— A separate control delays tool selection until approved evidence chooses one of two identities. Static pinning succeeds when both candidates are declared initially; when the candidate universe is open, the selected identity is unbound and resolves to an incompatible live implementation. SemIso under SSI instead extends the inherited tool-schema constraint when the identity becomes known and selects the compatible retained implementation. Static pinning therefore covers closed dependency sets, while online extension covers discovery during execution.
System Evaluation
Setup —— We implement the vendor-risk workflow from Figure 1 using LangGraph persistence, interrupt and resume, a compiled child subgraph, parallel branches, and Qdrant retrieval. Four focused graphs isolate semantic read skew, compatibility skew, context escape, and merge skew. Deterministic adapters and a fixed deployment schedule provide an oracle for version selection. The two embedding versions have equal dimensions: querying Emb2 against Idx1 executes successfully but retrieves the wrong controlled document. Thus the experiments measure framework behavior and enforcement independently of model quality.
Metadata cost —— At the largest tested configuration (128 identities and 16 branches), 300 repetitions give p95 resolution latency of 4.6 𝜇s and p95 merge-validation latency of 88.2 𝜇s. A compactJSON checkpoint with 6 bindings and 2 branch records adds 2978 bytes over the same workflow state without semantic metadata; its root manifest occupies 973 bytes. Across 30 complete runs per 5
mechanism, the median end-to-end difference remains within timer noise. These laptop measurements cover metadata processing, not the operational cost of retaining historical resource versions.
to admit otherwise nonserial schedules [4]. Enforcing AI-workflow serializability requires coordination over writes and effects, not merely version selection. We leave this extension to future work.
6
AI Disclaimer —— The author has used AI tools to polish and shorten portions of this manuscript, but takes full responsibility for the ideas and statements therein.
Related Work
Database isolation levels [1, 3] characterize admitted anomalies. COPS-GT [14] gives causal visibility; RAMP [2] gives read-atomic visibility. Brayner et al. [4] use object semantics to admit nonserial schedules under semantic serializability. Earlier transaction terminology differs from ours: Huang et al. [9] use semantic transactions for semantics-aware mobile-database scheduling, whereas Cordon [7] uses one to stage and validate agent tool effects. Our semantic isolation instead constrains resource versions and compatibility within one durable execution; it neither relaxes schedules nor stages effects. Atomix [17] coordinates tool calls, Mnemosyne [6] repairs generated actions, and ATCC [25] controls concurrent agentgenerated SQL. Styx [18] provides serializable cloud workflows, while AC/DC [20] extends correctness and recovery across durable workflows. Temporal [21] can pin an execution to a worker deployment version; LangGraph [11] recommends storing graph-logic choices in application state. These mechanisms protect code paths, not independently managed prompts, model aliases, indexes, or tools. DVC lockfiles [8] and ZenML snapshots [24] bind declared pipelines, while GenericVC [23] unifies Git-like branching with MVCC and application-specific reconciliation. ML Metadata [22] records lineage, while MLflow registries [16] provide addressable versions. MLCask [15] branches and merges versioned ML pipelines; SPEAR [5] makes prompts structured, versioned runtime objects. Qdrant’s migration procedure [19] captures one embedding–index contract; Confining Nondeterminism [10] instead places AI-generated artifacts in deterministic versioned dataflow. We combine stable bindings, cross-resource compatibility, continuation inheritance, online extension, and branch admission within one durable execution.
7
References [1] Atul Adya. 1999. Weak Consistency: A Generalized Theory and Optimistic Implementations. Ph. D. Dissertation. MIT. https://hdl.handle.net/1721.1/9333 [2] Peter Bailis, Alan Fekete, Joseph M. Hellerstein, Ali Ghodsi, and Ion Stoica. 2014. Scalable Atomic Visibility with RAMP Transactions. In SIGMOD. 27–38. doi:10.1145/2588555.2588562 [3] Hal Berenson, Philip Bernstein, Jim Gray, Jim Melton, Elizabeth O’Neil, and Patrick O’Neil. 1995. A Critique of ANSI SQL Isolation Levels. In SIGMOD. doi:10.1145/223784.223785 [4] Angelo Brayner, Theo Härder, and Norbert Ritter. 1999. Semantic Serializability: A Correctness Criterion for Processing Transactions in Advanced Database Applications. Data & Knowledge Engineering 31, 1 (1999), 1–24. doi:10.1016/S0169023X(99)00014-2 [5] Uğur Çetintemel, Shu Chen, Alexander W. Lee, et al. 2026. Making Prompts First-Class Citizens for Adaptive LLM Pipelines. In CIDR. [6] Edward Y. Chang, Longling Geng, and Emily J. Chang. 2026. Mnemosyne: Agentic Transaction Processing for Validating and Repairing AI-generated Workflows. arXiv:2607.00269 [7] Zheng Chen, Hanqing Liu, Duling Xu, et al. 2026. Cordon: Semantic Transactions for Tool-Using LLM Agents. arXiv:2606.17573 [8] DVC. 2026. DVC Pipeline and Lock Files. https://dvc.org/doc/user-guide/projectstructure/dvcyaml-files [9] Shi Ming Huang, Irene Kwan, and Chih He Li. 2002. A Study on the Management of Semantic Transaction for Efficient Data Retrieval. ACM SIGMOD Record 31, 3 (2002), 28–33. doi:10.1145/601858.601863 [10] Kyoungmin Kim and Anastasia Ailamaki. 2026. Confining Nondeterminism: AI-Driven Research Systems as DBMSs for Reliable, Non-Wasteful, Transparent, and Collaborative Research. arXiv:2607.10508 [11] LangChain. 2026. LangGraph Backward Compatibility. https://docs.langchain. com/oss/python/langgraph/backward-compatibility [12] LangChain. 2026. LangGraph: Low-Level Orchestration for Stateful Agents. https://github.com/langchain-ai/langgraph 38,874 GitHub stars on August 4, 2026. [13] LangChain. 2026. LangGraph Persistence. https://docs.langchain.com/oss/ python/langgraph/persistence [14] Wyatt Lloyd, Michael J. Freedman, Michael Kaminsky, and David G. Andersen. 2011. Don’t Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS. In SOSP. doi:10.1145/2043556.2043593 [15] Zhaojing Luo, Sai Ho Yeung, Meihui Zhang, et al. 2021. MLCask: Efficient Management of Component Evolution in Collaborative Data Analytics Pipelines. In ICDE. doi:10.1109/ICDE51399.2021.00146 [16] MLflow. 2026. Model Registry Workflows. https://www.mlflow.org/docs/latest/ ml/model-registry/workflow/ [17] Bardia Mohammadi, Nearchos Potamitis, Lars Klein, et al. 2026. Atomix: Timely, Transactional Tool Use for Reliable Agentic Workflows. arXiv:2602.14849 [18] Kyriakos Psarakis, George Christodoulou, Marios Fragkoulis, and Asterios Katsifodimos. 2025. Transactional Cloud Applications Go with the (Data)Flow. In CIDR. [19] Qdrant. 2026. Embedding Model Migration. https://qdrant.tech/documentation/ tutorials-operations/embedding-model-migration/ [20] Michael Stonebraker, Xinjing Zhou, Peter Kraft, and Qian Li. 2026. Consistency and Correctness in Data-Oriented Workflow Systems. In CIDR. [21] Temporal Technologies. 2026. Worker Versioning is Now in GA. https://temporal. io/changelog/worker-versioning-continue-as-new-worker-controller [22] TensorFlow. 2026. ML Metadata. https://www.tensorflow.org/tfx/guide/mlmd [23] Gunce Su Yilmaz and Jens Dittrich. 2025. Generic Version Control: Configurable Versioning for Application-Specific Requirements. In CIDR. [24] ZenML. 2026. Pipeline Snapshots. https://docs.zenml.io/concepts/snapshots [25] Weixing Zhou, Zhiyou Wang, Zeshun Peng, et al. 2026. ATCC: Adaptive Concurrency Control for Unforeseen Agentic Transactions. arXiv:2603.13906
Conclusion and Future Work
Checkpointing preserves a durable AI workflow’s control state, but not necessarily its semantic environment. We formalize this gap through four anomalies and isolation profiles over resource stability, cross-resource compatibility, and continuation inheritance. SemIso enforces these profiles through online manifest extension, compatible resolution, inherited continuation context, and branch admission. Our repository audit finds the enabling conditions in public LangGraph codebases. We therefore argue that semantic isolation must become an explicit framework contract rather than an application-specific convention. Future work: AI workflow serializability —— Semantic Snapshot Isolation is sufficient when workflows only read immutable semantic resources. Workflows that also update shared memory or artifacts, modify semantic configuration, publish outputs consumed concurrently, or perform visible tool actions require a stronger contract. We call a history AI-workflow serializable when it is observationally equivalent to a serial ordering of workflows and deployments that preserves program order, resource contracts, shared writes, and visible actions. This prospective property differs from prior semantic serializability, which uses database-object semantics 6
Related documents
- AssetOpsBench: Benchmarking AI Agents for Task Automation in Industrial Asset Operations and Maintenance#798615
- APIFlow-Bench: Measuring Whether Agents Survive Long, Dependent API Workflows#622623
- When Tool Calls Succeed but Workflows Fail: Anomalies at the Agent-Tool Boundary#1109415
- When Tool Calls Succeed but Workflows Fail: Anomalies at the Agent-Tool Boundary#919344
- Comment and Control: Hijacking Agentic Workflows via Context-Grounded Evolution#178826
Retrieved via Conceptio: every document is proof-bundled with source, license, and retrieval metadata.
Read the Docs → · View CLI source on GitHub · Conceptio Open Knowledge Archive