Runtime State Is Persistent by Default, Not by Application Discipline

The runtime platform carries persistence as a runtime primitive. Objects in the runtime have lifetimes longer than any single process; snapshot the runtime, restore it tomorrow, and agents continue from where they were, without marshaling, save-this calls, or a separate database to keep in sync. The state graph itself is the database; application code does not opt into persistence -- the platform provides it as the default condition of every object.

Why it is held

Persistence built as an application pattern fragments. Each team picks a serialization format, an ORM, a save-on-mutation policy, a recovery-on-restart routine; each implementation has bugs the team rebuilds when discovered, and the bugs differ across teams. The application code that calls save() at the right moments is not the application's actual logic -- it is bookkeeping the platform could provide. Treating persistence as a primitive removes the bookkeeping layer entirely: every object survives restart by default, and applications focus on the logic that belongs to them.

The platform-as-persistence stance composes with the atomic primitive ([[Agent Operations Commit Wholly or Roll Back Wholly]]). When the runtime rolls back an atomic call tree, the rollback restores the in-memory state graph -- which is also the persistence layer. The atomic primitive's "revert to pre-operation snapshot" presupposes that the state to revert to is durably present in the same runtime; persistence as a runtime primitive is what makes the rollback semantics meaningful across restart boundaries. A weaker persistence layer -- where state is materialized into the runtime from a separate database at startup -- would force the atomic rollback to coordinate across the database boundary, recreating exactly the patterns the platform aims to replace.

The platform-as-persistence stance also composes with capability separation ([[Capability Boundaries Are Runtime-Enforced, Not Policy-Checked]]). Capability tiers persist with their identities across restart: an agent's privileged-identity association does not have to be re-established from external sources after restart. Without runtime-level persistence, capability separation would require a separate identity store to keep in sync; with runtime-level persistence, the capability tier is part of the same state graph the runtime is already maintaining.

The reference runtime provides this primitive directly: a snapshot call writes the in-memory state to a dump file; the restore path reads it back at boot; reboot-callback hooks let objects participate in graceful shutdown and warm restoration; resource-quota state persists with object state. The foundation layer's mediation makes the snapshot file location and dump cadence configurable through declarative configuration. The Cloud Server Reference's eight-primitives table marks persistent state as "Provided; no gaps" -- the cleanest implementation grounding among the eight primitives.

The Conviction is held because the no-bookkeeping experience for application authors is what platform adoption purchases. When persistent-by-default is the runtime's promise, agent code becomes shorter, more direct, and easier to reason about. Trading the primitive for a serialization layer would surrender exactly the property that justifies the platform's other costs.

What it asks

Honoring this Conviction asks the project to defend the runtime as the persistence layer, not as a cache in front of one.

The MVA work treats the snapshot mechanism and the dump-file path as the persistence contract. The MVA's hello-world instance and atomic-operation demonstration declare their dump file in the runtime's configuration and rely on the platform's snapshot semantics. Demos that introduce a "for testing convenience, just store this in a JSON file alongside" pattern violate the spirit of the primitive even when they don't violate the platform.
Downstream workstreams build on persistent objects, not on a database-of-record plus cache pattern. When agent-identity, state-introspection, or future workstreams add stateful capabilities, they store state in runtime objects whose lifetimes the platform manages. A workstream that introduces an external state store ("for cross-instance sharing", "for analytical queries", "to integrate with external observability") must acknowledge that it is operating outside the platform's persistence guarantee for those data, and surface the cost.
Decisions introducing application-layer save-checkpoints must surface the cost. A Decision adding "before this risky operation, the application should save its state explicitly" is reintroducing the bookkeeping layer the primitive removed. Such Decisions weigh the bookkeeping cost against the platform-fit cost imposed on this Conviction. Don't trade the no-bookkeeping experience for the apparent safety of a save-before-risky-step pattern; the atomic primitive already provides that safety without the bookkeeping.
Communication distinguishes runtime-state-graph persistence from database-mirroring-cache patterns. When the project's persistence claim is communicated externally, the distinction between the state graph being the database and a cache layer fronting a separate database is the load-bearing detail. The two are sometimes conflated in agent-infrastructure copy that uses "persistent agents" loosely.
Workstream scoping checks whether persistence is the platform's or the application's. Workstreams proposing capabilities whose state lives outside the platform's persistence layer (logs streamed to external systems, metrics emitted to time-series databases, large blob storage) need to either route the state inside the runtime or surface the boundary explicitly. The platform is not for every form of state; the boundary needs to be visible.

Drift recognition

The Conviction has weakened when the project's outputs treat persistence as something application code arranges, rather than as the runtime's standing condition.

Save-on-mutation patterns added to agent code. When agent code accumulates save() or persist() or commit_to_storage() calls at points where mutations occur, the platform's persistent-by-default guarantee is being worked around. The application is doing bookkeeping the runtime already does, and the explicit calls signal either distrust of the platform or accidental drift toward a save-on-mutation pattern that subsequent code copies.
External database introduced as the source of truth. A Decision adding "the canonical state lives in PostgreSQL; the runtime caches it for performance" inverts the Conviction's stance. Once the canonical state lives outside the runtime, the runtime's state graph becomes a cache, and most of the platform's other primitives weaken in proportion (atomic rollback now has to coordinate with the external database; capability tiers have to be re-derived from external identity sources).
Recovery routines that rebuild state from external sources at startup. When the runtime's startup sequence includes "now query external system X to populate the state graph", the runtime is no longer the persistence layer -- the external system is, and the runtime is a working set materialized at boot. The recovery routine itself is drift evidence; in a held-Conviction world, the restore path is the recovery, and external sources are not consulted at boot.
"Persistence is best-effort; we accept some loss after crash" framings. The Conviction's stance is that the snapshot reflects committed state up to the snapshot moment; what is in the runtime at snapshot time is what restoration recovers. When documentation or external communication describes persistence as best-effort or accepts post-crash data loss, the stance has weakened. The atomic primitive guarantees that committed operations are present in the snapshot; persistence-as-best-effort weakens both primitives at once.
Cumulative drift across multiple sessions. If two or three consecutive sessions land features that quietly lean on application-layer save-on-mutation patterns or external state stores -- without surfacing the platform-fit cost -- the project has drifted from holding the Conviction even though no individual change broke it. The drift is cultural rather than pointwise.

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 persistent-state primitive's articulation: "Objects in the runtime have lifetimes longer than any single process. Snapshot the runtime; restore it tomorrow; agents continue from where they were. No marshaling, no save-this calls, no separate database to keep in sync. The state graph is the database." This Conviction's stance opening paraphrases the upstream paragraph; the state-graph-is-the-database framing is preserved verbatim because that 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 snapshot and restore mechanism as the runtime platform, the foundation layer's dump-file declaration plus reboot-callback hooks plus resource-quota state persistence as the foundation-layer mediation, and "Provided; no gaps" status -- alongside hot reload, capability separation, and sandboxed code load, persistent state is one of the cleanest foundation-provided primitives for the MVA. The Reference is the graph's authoritative anchor for what the foundation provides for this 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 held-stance comma form ("X is Y, Not Z") matching the Contract's recommended shapes.
in_practice_domain::[[eOS Continuum]]
- The persistent-state primitive is one of eight runtime primitives the eOS-Harness MVA is responsible for grounding in the graph, and the foundational primitive the other seven derive their value from.
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 persistent state: the runtime's snapshot and restore mechanism as the runtime layer, the foundation's dump-file declaration, reboot-callback hooks, and resource-quota persistence as the mediation, "Provided; no gaps" status for the MVA. The Reference grounds the implementation-level claims this Conviction's What It Asks section makes about MVA dump-file declarations and downstream workstream patterns.
informs_downstream::[[eOS-Harness Minimum Viable Architecture]]
- The MVA's hello-world instance and atomic-operation demonstration phases declare their dump file in the runtime's configuration and rely on the platform's snapshot semantics. Future workstreams (agent identity, state introspection) carry the Conviction's asks forward as concrete persistence patterns.
composes_with::[[Agent Operations Commit Wholly or Roll Back Wholly]]
- Persistence and atomicity reinforce each other: the atomic primitive's rollback restores the in-memory state graph -- which is also the persistence layer -- and the persistence primitive's snapshot reflects committed state, including the results of atomic operations. A weaker persistence layer (state materialized from a separate database at startup) would force atomic rollback to coordinate across the database boundary; a weaker atomic primitive would mean the snapshot might capture partial-state intermediates. The two primitives presuppose each other.
composes_with::[[Capability Boundaries Are Runtime-Enforced, Not Policy-Checked]]
- Persistence and capability separation reinforce each other: capability tiers persist with their identities across restart as part of the runtime's state graph, so identity associations do not have to be re-established from external sources at boot. Without runtime-level persistence, capability separation would require a separate identity store to keep in sync; without runtime-level capability separation, the persisted state graph would have no enforcement boundary on cross-tier mutations.
grounded_in::[[Agent Runtimes Require Native Primitives, Not External Glue]]
- The meta-Conviction this primitive is one instance of: what is normally a pattern (per-application save-on-mutation, ORM mappings, recovery routines) becomes a primitive in the runtime that every line of agent code can rely on; external database patterns (Postgres as source of truth, save-on-mutation discipline, recovery from external sources at startup) cannot deliver platform-level persistence-by-default.