• conforms_to::[[Conviction Form Contract]]
• in_practice_domain::[[eOS Continuum]]
• authored_by::[[Christopher Allen]]
• has_lifecycle::[[Seed Stage]]↗
• has_curation::[[Working Draft]]↗

Agent Operations Commit Wholly or Roll Back Wholly

The runtime platform guarantees that every agent operation either commits all of its state changes or reverts the runtime's in-memory state to the pre-operation snapshot. Partial completion of an agent operation is not a representable outcome in the runtime's persistent state; the platform carries the all-or-nothing guarantee, so agent code does not have to track and undo its own intermediate side effects when something fails mid-operation.

Why it is held

Agent operations are characterized by failure modes that traditional application code is not engineered for. An LLM call mid-operation may return garbage; a tool call may error; a precondition may be violated by a concurrent agent; an external service may time out. Without a platform-level atomic guarantee, every agent operation that touches more than one object would have to carry hand-written compensating-action logic for each step that might fail -- the same pattern each team rebuilds, with bugs. The platform inverts that burden: the runtime's transactional envelope owns the rollback, and agent code can be written as if every operation either succeeds in full or did not happen at all.

The atomic guarantee operates at the in-memory state graph level, not at a separate database or persistence layer. When the runtime rolls back an atomic call tree, the rollback covers object references, accumulated state mutations across all objects touched in the call tree, queued callouts and events, and per-task resource accounting. This is materially different from "the database transaction was rolled back" -- there, transactional rollback covers rows in a persistence layer while in-memory caches and application-level state may already be inconsistent. The runtime's atomicity reverts the runtime itself; there is no in-memory residue of the failed operation to reconcile after the fact.

The platform-level position matters because partial state is the structural failure mode in a system where multiple agents share state. When agent A's operation halts halfway through (some side effects landed, some didn't), agent B reading state cannot distinguish "A is in progress" from "A finished" from "A failed mid-step." The all-or-nothing guarantee removes this entire class of confusion: any state agent B sees is either a state agent A's operation produced in full or a state untouched by agent A. Without that guarantee, every multi-agent interaction inherits the partial-state ambiguity, and each team rebuilds coordination scaffolding to recover from it.

This Conviction is held because atomicity treated as a primitive -- every line of agent code can rely on it without engineering it -- is what platform adoption purchases. Patterns get rebuilt by each team, badly; primitives are rebuilt once, by the runtime, and become invisible infrastructure that lifts the application's complexity ceiling. Trading the primitive away to broaden the platform's apparent applicability would surrender the load-bearing claim the project rests on.

What it asks

Honoring this Conviction asks the project to defend the atomic envelope as a first-class boundary, not as an internal implementation detail.

• The MVA's atomic-operation demonstration is empirical evidence for this Conviction, not just a build-out task. The demonstration is the project's first end-to-end evidence that deliberate-failure rollback works as a runtime primitive. The demo must include the failure path -- the success case alone does not establish the primitive. The resulting Observation node is the load-bearing artifact; this Conviction informs that downstream Observation.
• Architectural Decisions that introduce non-atomic primitives must surface the cost. Decisions adding "best-effort", "fire-and-forget", "eventually-consistent", or "partial-write-recovery" semantics weaken the platform's atomic guarantee. Such Decisions need to name explicitly the platform-fit cost they impose on this Conviction and weigh that cost against the breadth-of-fit benefit they offer. The default disposition is to keep the atomic envelope intact; trading it away requires proportional justification.
• New primitives must compose with the atomic envelope or call out their boundary explicitly. When downstream workstreams add capabilities (HTTP listener, agent identity, event dispatch, state introspection), each new primitive must clarify how it interacts with the atomic operation boundary. A long-running asynchronous capability that escapes the atomic envelope is not forbidden, but its boundary must be named explicitly so the surrounding atomic guarantee is not silently assumed where it does not hold.
• Communication about atomicity must distinguish runtime-state rollback from database transactional rollback. When the project's atomicity claim is communicated to potential adopters or compared against other platforms, the distinction between in-memory state graph rollback and database row rollback is the load-bearing detail. Soft-pedaling the distinction conflates the platform's atomic primitive with weaker analogues that share the vocabulary but not the semantics.
• Workstream scoping checks the atomic envelope as a filter condition. Workstreams proposing capabilities that are structurally incompatible with atomic operation envelopes (e.g., long-running streaming operations where partial state is the desired output) need to either rescope to fit the platform's primitive or route to a different project. The atomic envelope is one filter the anti-pitch Conviction's seven cases instantiate at the workload level; this Conviction names the platform-side counterpart at the operation level.

Drift recognition

The Conviction has weakened when the project's outputs treat partial state as a real possibility worth handling, rather than as an impossibility the platform prevents.

• Agent code that catches an error mid-operation and proceeds in a half-completed state. When agent code wraps a multi-step operation in error handlers that recover from a halfway state -- detecting which side effects landed, manually undoing them, or continuing despite known inconsistency -- the platform's atomic guarantee is being worked around rather than relied on. The recovery scaffolding is itself the drift evidence. Atomicity-as-primitive means the recovery layer is the runtime's, not the application's.
• Demos that document atomicity but omit the failure path. A demonstration showing atomic operations succeeding (the easy case) without showing deliberate-failure rollback (the hard case) is the same drift surfaced earlier as "the demo establishes the primitive." If a future hot-reload or atomicity demonstration shows only the success case, the Conviction has weakened in practice even if the documentation still claims it.
• Decisions trading atomicity for performance or breadth without surfacing the cost. A Decision that introduces a non-atomic optimization (bulk-write paths bypassing the envelope, streaming primitives outside the rollback boundary, third-party integrations that assume eventually-consistent semantics) without naming the platform-fit cost is drift. The Conviction asks for the cost to be surfaced; absent that, the project has stopped holding the Conviction even if the Conviction node still exists in the graph.
• "Recoverable from partial state" framings replacing "partial state is not possible". Documentation, onboarding material, or downstream Decisions that describe partial state as something to detect and recover from -- rather than as something the platform prevents from occurring -- has shifted the Conviction's stance. The held position is impossibility, not detectability.
• Cumulative drift across multiple sessions. No single session breaks this Conviction; the pattern across sessions does. If three or four consecutive sessions land work that quietly assumes partial state is a real possibility -- recovery code, defensive snapshot reconciliation, reconciliation jobs run after operations complete -- the project has drifted from holding the Conviction even though no individual change was the breaking point.

Sources

• The project's agent-runtime value-proposition draft, Section 3 ("What runtime-level primitives look like"), Draft v2 dated 2026-04-25. Carries the atomicity primitive's articulation: "Each agent operation runs as a transaction. If anything in the operation fails ... the entire operation rolls back. The state graph reverts to its pre-operation snapshot. There is no concept of partially-completed agent operations. This is not 'the database transaction was rolled back.' The in-memory state reverts." This Conviction's stance opening paraphrases the upstream paragraph's load-bearing claims; the in-memory-vs-database-rollback distinction is preserved verbatim because the distinction is the load-bearing detail. Cited by path; not authored as a Reference node per the URL-resolvability principle in the Reference Form Contract.

• The Cloud Server Reference's Mapping section. The eight-primitives table identifies the runtime's atomic-block keyword and transaction rollback as the runtime mechanism, the foundation layer's compile-time atomicity and task-local-storage rollback accumulation as the foundation-layer mediation, and "user-facing atomic-transaction example object for the demo" as the gap the MVA's atomic-operation phase fills. The Reference is the graph's authoritative anchor for what the foundation provides for the atomic primitive.

Relations

• conforms_to::[[Conviction Form Contract]]

  • Conviction-form node in the eOS-DeepContext graph. Exercises the Contract's Stance plus Why It Is Held plus What It Asks plus Drift Recognition body shape and the prohibitions on has_commitment::, decided_on::, and has_epistemic_status:: in the identity block. The filename uses the declarative subject-verb-object held-stance shape per the Contract's recommended forms.

• in_practice_domain::[[eOS Continuum]]

  • The atomic primitive is one of eight runtime primitives the eOS-Harness MVA is responsible for grounding in the graph.

• informed_by::[[Cloud Server (Croes, 2012, rev. 2026)]]

  • The Reference's eight-primitives table provides the graph's authoritative framing for what the foundation layer provides for atomicity: the runtime's atomic-block keyword and transaction rollback as the runtime mechanism, the foundation's compile-time atomicity and task-local-storage rollback state as the mediation, and the user-facing atomic-transaction example object as the MVA-level gap. The Reference grounds the implementation-level claims this Conviction's What It Asks section makes about the atomic-operation demonstration.

• informs_downstream::[[eOS-Harness Minimum Viable Architecture]]

  • The atomic-operation demonstration phase of the MVA is the empirical-evidence consumer of this Conviction. The deliberate-failure rollback demonstration grounds the Conviction's stance in observable runtime behavior, captured in an Empirical Observation that an atomic LPC function body rolls back on deliberate error in an HTTP-dispatched call.

• informed_by::[[An atomic LPC Function Body Rolls Back on Deliberate Error in an HTTP-Dispatched Call]]

  • The Empirical Observation capturing the runtime evidence for this Conviction at the realistic HTTP interface (HTTP POST -> route handler -> catch wrapping object dispatch -> atomic function body mutates and errors -> subsequent HTTP GET observes rollback). The Observation also surfaces an empirical finding the Conviction did not previously make explicit: an explicit atomic modifier on the function body is required for the rollback to be observable in this dispatch shape, contradicting a downstream doc's claim of automatic per-call atomicity. The Conviction's prose currently does not surface the modifier-requirement explicitly; a future amendment may want to make explicit that agent operations are atomic by convention rather than by language default.

• informed_by::[[An LPC Function Without the atomic Modifier Does Not Roll Back on Caught Error]]

  • The negative-case peer Observation, drawn from two mechanism-discrimination probes (same-object dispatch and cross-object dispatch with no immediate catch). The probes ruled out two of three candidate mechanism explanations the paired Observation named, leaving "modifier always required" and "any-catch-anywhere absorbs" as observationally equivalent in any realistic application path. Together the two Observations form a paired empirical foundation: the with-modifier case demonstrates the Conviction's stance holds; the without-modifier case demonstrates the stance holds only conditionally on the modifier being present.

• informs_downstream::[[Agent Code Does Not Carry Hand-Written Compensation Logic]]

  • Ghost link to a candidate downstream Conviction or Pattern not yet authored. The atomic-primitive guarantee removes the need for application-level compensation scaffolding, which is itself a downstream architectural commitment worth surfacing as its own node when the atomic-operation phase or downstream workstreams encounter cases where the temptation to add compensation logic surfaces.

• grounded_in::[[Agent Runtimes Require Native Primitives, Not External Glue]]

  • The meta-Conviction this primitive is one instance of: what is normally a pattern (rebuilt per team, with bugs) becomes a primitive in the runtime that every line of agent code can rely on; external infrastructure cannot deliver the runtime-rollback guarantee at the platform level.

• grounded_in::[[Runtime State Is Persistent by Default, Not by Application Discipline]]

  • Atomicity matters because it atomically affects persistent state: rollback restores the in-memory state graph, and that graph is the same durable image restoration recovers on restart. Without orthogonal persistence, an atomic rollback would revert state that does not survive the process anyway; the guarantee's value depends on the state it protects being the runtime's standing condition, not a per-process working set.

• contrasts_with::[[eOS-Harness Is the Wrong Runtime Platform Without Platform-Pain]]

  • The pair is complementary rather than contrasting in the strict sense, but they sit at adjacent positions in scope-of-applicability framing. The anti-pitch Conviction names workloads where the platform's primitives offer no value; this Conviction names the platform-side guarantee that creates value for workloads that fight partial-state failure modes. Together they bound the platform's fit: this primitive is what justifies adoption for workloads that need it; the anti-pitch is what filters out workloads that don't.