Separate Durable Agent State From Agent Execution

An agent session can contain a useful plan, a sequence of tool calls, command output, and a confident final summary. It can still be a weak place to store the truth about ongoing work. Sessions expire, context is compacted, models change, and runtimes fail. The project remains.

At JCN, we treat this as an architecture boundary: durable project state should be independent of the agent session executing against it. The runtime may change, but the intent, constraints, evidence, and handoff must remain inspectable.

Use separate state and execution planes

A reliable agent workflow benefits from two explicit planes.

The state plane records what the work is, what must not change, what is planned, what evidence has been collected, and where another operator should resume. The execution plane selects actions, runs commands, evaluates checks, enforces bounds, and records why it stopped.

Combining these responsibilities inside a conversation creates unnecessary coupling. The model that proposes a change also becomes the keeper of project history. The runtime that loses a session can take the resume point with it. A provider migration becomes a state migration. A human reviewer has to reconstruct current facts from a transcript that also contains discarded ideas and stale assumptions.

We use SMALL Protocol as the state layer. SMALL defines five machine-readable artifacts: human-owned intent and constraints, agent-owned plan and progress, and a system-owned handoff. These are plain, schema-validated files that can be read by humans, checked by a CLI, diffed in Git, and consumed by different agent runtimes. SMALL is deliberately not a workflow engine or agent framework.

We use loopexec as an execution layer for bounded work loops. It runs an execution command, evaluates an external check, records typed receipts, and halts for a computed reason such as successful convergence, an iteration limit, an invalid workspace, or an execution failure. It does not need to own the durable definition of the project to drive one bounded attempt.

The separation is straightforward:

• State says what is true about the work.
• Execution decides what action to attempt next.
• An external check decides whether an observable condition holds.
• A receipt records what happened and why the runtime stopped.

Make ownership explicit

State becomes trustworthy when each artifact has a clear owner. Human-owned intent and constraints prevent the execution layer from quietly redefining success. Agent-owned plan and progress allow the operator to propose steps and attach evidence. A system-owned handoff creates a stable resume point instead of asking the current model to summarize itself informally.

The contract also needs invariants. In SMALL, completed work must have corresponding evidence, progress is append-only, task references must remain valid, and strict checks enforce the canonical state layout. The protocol is single-writer by design. If multiple agents need to work concurrently, orchestration must isolate their branches or partition their work rather than silently merging conflicting state.

This is an important operational choice. Automatic conflict resolution is attractive only when conflicts are mechanical. Two non-deterministic operators may produce changes that are individually plausible and jointly wrong. Failing loudly preserves the decision boundary.

Design handoff as a product feature

A handoff is often treated as a final paragraph generated when an agent runs out of time. In a durable system, handoff is part of the execution contract. It should identify the current task, preserve verified progress, expose blockers, and tell the next operator where to resume. It should remain useful if the next operator uses a different model or no model at all.

This gives teams a practical portability test. A workflow is not meaningfully model-independent merely because it can call several providers. It is model-independent when another operator can enter the project, read the durable state, validate it, and continue without privileged access to the previous conversation.

The same principle applies to receipts. A live model trajectory cannot be reproduced byte for byte. What can be verified is the verdict: which state was checked, which command ran, what result it returned, and why the loop stopped. loopexec therefore distinguishes replay, which verifies a recorded verdict without an agent call, from re-execution, which runs the non-deterministic loop again.

Reduce the cost of change

Separating state from execution lowers the cost of changing the rest of the stack. A team can upgrade a model, replace a gateway, run a bounded task locally, or move a workload to another runtime without relocating the project's operating truth. Each executor is evaluated against the same intent, constraints, evidence requirements, and external acceptance boundary.

It also improves failure diagnosis. Invalid project state belongs to the state plane. A flaky test belongs to the verification boundary. A stalled or over-budget loop belongs to execution. Concurrent writers belong to orchestration. These are different failures with different remedies, and the architecture should preserve that distinction.

Agent systems will continue to evolve quickly. Durable work should not depend on any one session format or provider history. The stable asset is the contract that lets the next operator understand what is true, verify what happened, and continue safely.