Harness Theory Part 06 | Runtime and state: how does a harness sustain an execution world?

You start a coding agent in an IDE. The task is to change three modules, run the full test suite and wait for approval where required.

Halfway through the run, the IDE closes. Later, you open the same task from a web client.

The useful questions are no longer about whether the chat transcript survived:

Which steps have actually completed?
Which tool call has already produced a side effect?
Is an approval still pending?
Which prompt, tool catalogue, policy and model configuration versions are pinned to the run?
May the run continue, pause or cancel, or must it first recover from a checkpoint?
If two clients press Resume, which one is allowed to start the next worker?

If those answers exist only in IDE memory or in a transcript, the task does not have reliable runtime state. It has a conversation that resembles progress.

The runtime maintains the execution world on which an agent depends: state, resources, versions, lifecycles and control interfaces. The agent loop decides the next step. The runtime ensures that the step takes place inside a consistent, recoverable and observable environment.

Agent Runtime hosting and state authority

Figure 6-1 | Clients may disconnect or change; canonical state, worker lifecycle and artefacts must remain in a durable runtime.

The runtime and the agent loop solve different problems

Part 03 examined the agent loop: the model proposes a next action, a tool executes it, an observation returns to the loop, and the work continues until it completes, waits, fails or is cancelled.

The runtime owns a different set of concerns:

where the loop runs, such as a process, container or sandbox
where thread, run, tool-call and approval state is stored
whether work continues after a client disconnects
which checkpoint is used after a crash
which configuration version is bound to the execution
which worker may operate on the same run
how pause, resume, cancel and fork preserve consistency
which derived state must be invalidated after changes to tools, prompts, policies or workspaces

A useful separation is:

Agent loop
  decides and executes the next step

Runtime
  hosts, persists, versions and controls the execution world

A loop may fit inside a while statement. A runtime does not.

Separate the identifiers before they begin to drift

Agent products commonly use Request, Session, Thread, Turn, Run, Task, Workspace and Checkpoint at the same time. Without explicit semantics, one session_id soon refers to three different things.

Name	Recommended responsibility	It should not be treated as
Request	One API or client operation	The complete task lifecycle
Session	A span of interaction with continuous identity or environment	The only representation of a business task
Thread	A durable container for conversation and agent work	One model call
Turn	A unit of agent work triggered by one input	The full state of a long-running task
Run	One controlled execution instance with state, versions and budgets	A transcript
Task	A business objective and completion contract	A worker process
Workspace	The files, branch, sandbox or operating environment	Conversation history
Checkpoint	A versioned recovery point and its references	An arbitrary object dump

An implementation may use different names, but it must answer three questions:

Which identifier denotes the durable container?
Which identifier denotes this execution attempt?
Which identifier points to recoverable state?

The OpenAI Codex App Server defines a thread as a durable container containing multiple turns. Threads can be resumed, forked and archived. The value of these primitives is not the terminology itself. It is the presence of explicit lifecycle boundaries. ¹

This table is a responsibility model for the series, not a universal naming standard. Names may differ, but identity, lifecycle, ownership, and recovery boundaries still have to remain distinct.

Before work begins, the runtime must prove that it is ready

Initialisation is not a log line saying server started.

For a new workspace, a complex build, external services or work expected to cross sessions, the runtime should establish an operating baseline on which later steps can rely:

load config
→ validate schema and version
→ initialise storage and state authority
→ discover tools and connected capabilities
→ load policy and sandbox profile
→ verify model availability
→ run baseline checks
→ publish readiness evidence

What a readiness contract should establish

At minimum:

configuration has loaded and its version is traceable
the model provider or local runtime is available
tool schemas, handlers and policy are coherent
state, artefact and checkpoint stores can be read and written
required services are ready, rather than merely running as processes
baseline checks pass, or known failures are recorded explicitly
results can be bound to the correct tenant, workspace and task

Producing an init.sh, Dockerfile or environment manifest proves that an initialisation structure exists. It does not prove that dependencies install, services connect, migrations are valid or a fresh session can discover the next action.

Initialisation should also avoid enabling every capability before the trust boundary exists. A safer order loads read-only tools and minimum privileges first, then enables writes, external sends and sensitive credentials only after identity, policy, workspace scope and storage are ready.

Runtime prompt assembly is not one string that grows forever

Part 04 covered the context builder. Inside the runtime, that context must still be combined with agent identity, invariant policy, tool guidance, workspace state, budgets and output mode to produce the actual model input.

A governable prompt assembly process separates at least two classes of section.

Stable sections

These are suitable for a reusable cache prefix:

agent identity and operating principles
invariant policies
stable output conventions
long-lived tool guidance

Dynamic sections

These may change per run, turn or workspace:

tenant, workspace, branch and environment
current task contract and phase
tool catalogue version
connected MCP servers or plugins
policy snapshot
memory index generation
current budget, deadline and output mode

Each section should have an owner, version, priority, token budget and omission reason. The runtime should record a prompt manifest after assembly so that replay can establish exactly which information the model received.

Cache boundaries must follow real dependencies

A change to any of the following may require invalidation:

agent configuration version
prompt section version
tool catalogue version
policy version
workspace reference
tenant scope
memory index generation
connected server set

The most dangerous cache is not one that fails loudly. It is one that quietly returns an obsolete world. The agent then operates confidently against a removed tool, stale schema or wrong branch.

A model adapter unifies interfaces, not meaning

A runtime usually avoids making application workflows depend directly on one provider SDK’s response shape. An internal model adapter may normalise:

messages or input items
tool schemas
structured output
streaming
usage
finish or stop reasons
provider request IDs
errors and retryability
optional reasoning metadata

A conceptual interface might look like this:

class ModelAdapter(Protocol):
    async def generate(
        self,
        *,
        input_items: list[InputItem],
        tools: list[ToolSchema],
        model_profile: ModelProfile,
    ) -> ModelResponse:
        ...

This shows that the application layer need not depend directly on provider responses.

It does not prove that tool semantics, streaming events, stop reasons or structured output can be converted without loss across models.

Two providers may both return a tool_call while differing in parallel calls, partial arguments, cancellation or reasoning items. A sound adapter exposes relevant capability differences instead of swallowing them to preserve a neat interface.

A safer adapter maintains a capability matrix and marks conversions as:

supported
degraded
emulated
unsupported
lossy

If a rich approval event can only be flattened into plain text, the runtime should retain a loss marker or refuse to enable a feature that depends on the missing semantics. Silent degradation is dangerous because the workflow above the adapter continues to believe that the full contract survived.

Canonical RunState is the authority for the run lifecycle

A reliable runtime maintains one durable lifecycle authority for each run.

Canonical does not mean that RunState replaces every external truth. A database remains authoritative for its records, a Git remote for the result of a push, and a payment provider for the transaction it accepted. RunState records:

the legal lifecycle state of the run
which operations were proposed, authorised, submitted, or left with an unknown outcome
which external authority must be queried or reconciled
which worker may commit the next transition
which contract, configuration, policy, and catalogue versions constrain the execution

A useful RunState therefore contains:

identity: run, thread, turn, task, tenant, user, and workspace
contract: goal, scope, and completion criteria
configuration: agent, prompt, tool-catalogue, policy, and model-profile versions
execution: current phase, step, attempt, and active worker
concurrency: state version, worker epoch, lease expiry, and fencing token
model interactions: request identifiers, stop reasons, and usage
tool operations: call identifier, argument digest, terminal result, external operation identifier, and reconciliation state
control: pause, cancellation, approval, deadline, and budget
evidence: artefact, test, trace, and verification references
recovery: checkpoint pointer, resume cursor, and last committed sequence
terminal state: completed, failed, cancelled, waiting, and stop reason

An illustrative summary is:

{
  "run_id": "run_108",
  "thread_id": "thread_42",
  "task_id": "task_checkout_fix",
  "tenant_id": "tenant_acme",
  "workspace_id": "ws_701",
  "status": "waiting_for_approval",
  "phase": "verification",
  "state_version": 37,
  "worker": {
    "worker_id": "worker_a",
    "epoch": 9,
    "fencing_token": 1482,
    "lease_expires_at": "2026-07-08T11:30:00Z"
  },
  "config": {
    "agent_version": "agent-17",
    "tool_catalog_version": "tools-4",
    "policy_version": "policy-12",
    "model_profile": "safe-default"
  },
  "active_operation": {
    "tool_call_id": "call_88",
    "operation_id": "op_771",
    "state": "approval_required",
    "arguments_digest": "sha256:example-only"
  },
  "budget": {
    "max_cost_usd": 4.0,
    "spent_cost_usd": 1.37
  },
  "checkpoint_id": "cp_31",
  "last_committed_sequence": 284
}

The example places identity, versioning, worker ownership, control, and recovery indicators in runtime state.

It does not establish that:

the state machine is correct
every write path checks the fencing token
an external side effect can be replayed safely
another operation has not consumed the approval
max_cost_usd: 4.0 is a suitable production budget
JSON replaces an event log, artefact store, external authority, or database transaction

The values and digest are illustrative.

Transcript and Canonical RunState

Figure 6-2 | The transcript is an interaction projection. Canonical RunState retains lifecycle, versions, worker ownership, control state, and references to external operations.

The transcript matters, but it cannot be the only state store

A transcript is a suitable home for:

user messages
agent messages
model-visible tool requests and results
public plans and explanations

Some facts should not exist only as transcript text:

policy snapshots and authorisation decisions
worker leases
external IDs for tool operations
submitted side effects with unknown outcomes
budget counters
schema versions
checkpoint commit state
pending approval expiry and terminal result
durable artefact locations

A transcript may also be compacted, redacted or filtered for a particular UI. Runtime state must answer what the system may legally do next, not merely what the model once said.

The Anthropic Agent SDK supports resuming a session with earlier context, while Claude Managed Agents currently expose event-driven sessions, sandbox checkpoints and server-side resumption. These implementations differ, but both demonstrate that continuity is a runtime concern. It cannot be reproduced reliably by pasting old text back into a prompt. ²³

A checkpoint stores recoverable facts, not an object-shaped suitcase

A checkpoint allows the runtime to reconstruct a legal and diagnosable execution state after interruption.

Useful checkpoint boundaries normally follow a durable commit:

run_created
model_response_committed
pre_effect_intent_committed
tool_result_or_unknown_outcome_committed
approval_wait_committed
verification_result_committed
control_signal_applied
run_terminal

tool_call_authorised is not automatically a replay-safe checkpoint. If approval was obtained and an external request was submitted, but its receipt was not persisted, recovery must not simply execute the tool again.

A checkpoint normally contains:

schema version
policy, safety-overlay, and configuration references
workflow or agent phase
committed event sequence
message, evidence, and artefact references
pending operation, approval, and background-work context
completed or unknown side-effect operation identifiers
worker epoch and fencing token
attempt, waiting reason, and stop reason
restore-validation result

Snapshot, checkpoint, event log, and replay are different capabilities

A snapshot is a projection of state at one time.
A checkpoint is a versioned recovery point that the runtime has declared restorable.
An event log records committed transitions and their order.
Replay reconstructs or simulates a trajectory from events, artefacts, and evidence.
External reconciliation asks the system that owns a side effect what actually happened.

Serialising a Python object or full transcript may still leave unanswered whether:

a payment API accepted the request
a Git push succeeded before its response was lost
an approval was consumed
a tool result reached the state store
an old worker still holds a stale lease

A restore path should verify:

checkpoint-schema and configuration readability
state-version and event-sequence continuity
workspace, artefact, and tool-catalogue references
reconciliation of unknown outcomes before re-execution
acquisition of a higher fencing token by the new worker
that resume begins from a legal transition

Side-effect reconciliation, idempotency, and compensation belong in Part 08. The boundary here is: a checkpoint is a validated recovery promise, not evidence that an object was saved.

The runtime control plane governs work that is already moving

Long-running and background agents benefit from separating the data plane from the control plane.

Data plane

It performs:

model calls
tool execution
observations
state transitions
artefact production

Control plane

It handles:

status queries
pause, resume, and cancel
fork
approvals and supplementary input
budget and deadline changes
safety overlays, credential revocation, and kill switches
drain and shutdown
tested configuration migration

A command cannot be a Boolean sent by a client in the hope that the worker notices it.

Each command should include:

command identifier
actor and authority
target run or thread
expected state version
idempotency key
requested effect
an accepted, applied, rejected, or expired result
an audit event

accepted means that the runtime has received the intent. applied means that the state changed at a legal transition.

Safe points prevent control changes from tearing state in half

If an irreversible tool call is running when a pause arrives, immediately killing the process can leave the system between two facts: the side effect happened, but its result was not persisted.

The runtime should inspect control signals at safe points, including:

before and after a model call
before tool execution
after a tool completes and its result is durable
before and after a workflow transition
after a checkpoint commit

The states need to remain distinct:

pause_requested → pausing → paused
cancel_requested → cancelling → cancelled
resume_requested → claiming → running

Cancel requested is not Cancelled. Pause requested does not mean that the run is already resumable.

Resume also needs new worker ownership. When two clients press Resume, the server deduplicates or orders the commands, and only one claim may obtain a new worker epoch and fencing token through compare-and-swap.

Runtime control plane and safe points

Figure 6-3 | A control command is accepted before it is applied at a safe point. Resume returns to Running only after a new worker epoch and fencing token are acquired.

A worker lease alone does not prevent split brain

A lease says that a worker is considered the owner for a period. An old worker may still continue after its lease expires because of a network partition or long pause.

The state store and side-effect gateway should therefore check a monotonically increasing fencing token:

worker A obtains token 41
lease expires
worker B obtains token 42
worker A attempts commit with token 41
→ rejected as stale

Critical writes should verify:

expected state version
current worker epoch
fencing token
operation ownership
cancellation or terminal state

Heartbeats without fencing can still leave two workers believing that they own the same run.

Forking is more than copying a transcript

A fork normally needs:

a source thread or checkpoint
a new thread or run identity
a parent/child relationship
artefact sharing or copy-on-write rules
workspace clone, isolation, and merge policy
configuration pinning
renewed credential and policy evaluation
new worker ownership
a rule for later merge

The Codex App Server’s thread/fork creates a new thread identity from stored history and retains its source relationship. This provides more than copied text: history and fork identity are protocol-managed.⁴

Branches must not silently share a mutable workspace. Shared artefacts should be immutable references or copy-on-write rather than uncontrolled state modified by two runs. Part 07 covers workspace isolation and multi-agent claiming in detail.

The hosting boundary separates clients from the runtime

A local CLI may temporarily place the client, agent process, and workspace together. Web, IDE, remote-worker, and multi-tenant arrangements expose ordinary distributed-systems questions:

who starts a worker
where events for one thread are routed
how a client reconnects
who reclaims work after a crash
when idle runtimes are released
how drain blocks new work
how sessions, artefacts, credentials, and workspaces bind to a tenant

A common arrangement is:

Clients
  CLI / IDE / Desktop / Web
          ↕
Bidirectional protocol
          ↕
Harness Service
  auth / routing / thread manager / control commands
          ↕
Agent Runtime Workers
  model loop / tools / sandbox
          ↕
Durable State / Event / Checkpoint / Artefact Stores

The client renders and collects interaction. The harness service owns routing and control authority, workers operate the data plane, and durable stores retain reconstructable state.

The OpenAI Codex App Server is a concrete example: it manages core threads for several client surfaces. Clients render streaming, diffs, and approvals while thread history and runtime ownership remain server-side.¹

Session routing must bind identity, version, and worker ownership

A thread_id is not sufficient routing authority.

The runtime commonly checks:

tenant ownership
user or service identity
workspace ownership
region and data residency
expected state version
current worker epoch and fencing token
active lease
permitted client capability
terminal, archived, or deleted state

A router that checks only an identifier may expose another tenant’s events or resume the wrong run.

Resume should follow a controlled path:

authorise command
→ compare expected state version
→ acquire lease and fencing token
→ restore and validate checkpoint
→ commit owner transition
→ start worker

Credential binding and tenant isolation belong in Part 09. The boundary here is: state routing, identity routing, and worker ownership require one auditable control path.

Agent configuration is a deployable artefact

Prompt, toolset, model profile, policy, verifier, sandbox and output contract all change agent behaviour. If they are scattered across environment variables, database fields and code branches, reconstructing a failed run becomes guesswork.

A versioned agent configuration manifest might look like this:

agent_version: agent-17
prompt_bundle: prompt-9
tool_catalog: tools-4
policy_bundle: policy-12
model_profile: safe-default
verifier_suite: verifier-8
sandbox_profile: sandbox-3
protocol_schema: app-server-v2
artifact_digest: sha256:example-only

This example shows which behavioural inputs should be pinned.

It does not prove that:

the versions are mutually compatible
safe-default passed evaluation
rollback will avoid schema or migration conflicts
the SHA-256 value refers to a real artefact

sha256:example-only is deliberately illustrative.

Pinned configuration does not freeze every safety control

For reproducibility, a run commonly pins the prompt bundle, tool catalogue, model profile, verifier suite, sandbox profile, and ordinary behavioural policy.

Emergency controls cannot remain bypassed by an old run. Credential revocation, tenant or enterprise hard denial, disabling a compromised tool, a kill switch, and a data-egress block may apply as higher-authority runtime overlays.

Such an overlay needs a version, reason, authority, and audit record and should cause denial, pause, or stop at the next safe point. It does not silently mutate agent-17 into agent-18; it adds a traceable safety constraint while retaining the original configuration pin.

Create, evaluate, promote, and migrate are separate operations

A safer release flow is:

Create immutable config version
→ run pinned evaluations
→ review evidence
→ canary or shadow
→ promote deployment pointer
→ monitor
→ roll back pointer when required

Creating a version does not authorise production use. Passing evaluation does not grant authority to update the deployment pointer.

Core rules include:

every run records an exact configuration version
production does not point directly to latest
promotion is a controlled operation
a new run resolves the deployment pointer and then pins an immutable version
an in-flight run normally retains its original version
migration of an in-flight run requires compatibility checks, a migration plan, and an explicit state transition
evaluation datasets, graders, and thresholds are versioned
deployment-pointer updates use expected-version or optimistic concurrency
emergency safety overlays do not require migration to a new behavioural configuration

Claude Managed Agents currently models versioned agent definitions, environments, and stateful sessions as separate resources. As of July 2026, the documentation still marks Managed Agents as beta and requires the managed-agents-2026-04-01 beta header. This article relies on the separation of responsibilities rather than treating the present fields as a permanent standard.⁵⁶

Rollback is not merely selecting an older prompt

Before rollback, check:

whether old tool schemas, handlers, and dependencies still exist
whether data migrations are backward-compatible
whether the old runtime can read newer session or checkpoint state
whether newer artefacts remain understandable
whether the client protocol is supported
which in-flight runs remain on the newer version
which new runs move to the older deployment pointer
whether safety overlays and credential revocations remain active

Rollback normally moves the pointer used by new runs. It does not reverse completed side effects, data migrations, or artefact-schema changes.

Agent configuration promotion and rollback

Figure 6-4 | Immutable configuration passes evaluation and canary stages before the deployment pointer moves. In-flight runs retain their pins, while safety overlays may independently block dangerous behaviour.

Protocol versioning requires explicit negotiation before capability use

Agent clients and harness runtimes evolve independently. A newer release may add streaming deltas, rich approval interfaces, diff rendering, image artefacts, thread forking, remote workspaces, plan state, or experimental events.

If the server assumes that every client supports every feature, an older client may receive an event that it cannot render or answer.

The general invariant is:

Before an operation uses a capability, both parties need an explicit account of protocol version, peer identity, supported capabilities, and incompatibility behaviour.

That negotiation does not have to keep one handshake shape forever.

Connection-scoped negotiation

The OpenAI Codex App Server currently requires an initialize request for each transport connection and uses capability opt-in to distinguish stable and experimental surfaces.⁴

As of July 2026, the latest stable MCP specification remains 2025-11-25. It divides a connection into Initialisation, Operation, and Shutdown and negotiates protocol version and capabilities during initialisation.⁷⁸

Client
  supported versions
  client identity
  capabilities
        ↓ initialize
Server
  selected version
  enabled capabilities
  warnings / deprecations
        ↓ initialized
Normal operation

Request-scoped or stateless negotiation

The official MCP draft is exploring a different model, including removal of connection-level sessions and the initialize handshake in favour of discovery or per-request version and capability metadata. A draft is not the latest stable specification, but it illustrates an important point: the invariant is explicit compatibility, not one permanent method name.⁹

A runtime commonly versions more than the protocol number:

message schemas
error codes
event types
capability names
experimental extensions
client fallbacks
unknown-field handling
deprecation and removal windows

Protocol versioning and capability negotiation

Figure 6-5 | A runtime may use a connection-scoped handshake or another explicit negotiation pattern. In either case, version and capability contracts precede normal operations.

Pinned binaries and decoupled servers make different trades

Pinned binary

The client ships with a tested harness binary.

Advantages:

behaviour is reproducible
the compatibility surface is smaller
client and runtime can be validated together

Costs:

runtime fixes wait for a client release
multiple client versions can diverge

Decoupled server

A stable client connects to a newer backward-compatible server.

Advantages:

runtime fixes and capabilities can ship independently
multiple clients share one state authority

Costs:

the protocol contract must be stricter
compatibility matrices such as old client and new server require testing
unknown fields, unavailable features and fallback behaviour need explicit definitions

Neither choice is inherently more advanced. The right boundary depends on release cadence, risk, offline requirements and the organisation’s ability to test compatibility.

Resource lifecycle governance separates archive from delete

A runtime accumulates:

agent configurations
sessions, threads and runs
workspaces and environments
credential grants
memory stores
artefacts
checkpoints
evaluation runs

Each resource needs a lifecycle such as:

active → idle → archived → deleted
              ↘ retained for audit

Delete

Remove records, subject to retention, legal hold, tenant export, deletion requests and audit tombstones.

Archiving a parent must not silently imply deletion of every child resource. Workspaces, credentials, memories and artefacts need explicit cascade policies.

Most production cleanup should archive first and delete according to retention policy. Recursive deletion is admirably fast. So is the meeting invitation that follows it.

Dynamic tool pools and caches must describe the same world

Part 05 covered dynamic tool discovery. At runtime, the concern becomes coherence after an MCP server connects, a plugin is enabled, a tool is withdrawn or policy changes.

The following must agree on one version of the world:

model-visible tool schemas
execution handlers
permission policy
prompt tool guidance
discovery index
audit metadata
subagent inherited catalogue
evaluation and replay manifests

Catalogue assembly needs a deterministic collision policy. Dictionary insertion order is not a governance model.

A tool-catalogue change may need to invalidate:

model-request tool-schema caches
prompt sections describing tools
semantic discovery indexes
authorisation-decision caches
derived repository or capability context
replay manifests

A remote server’s claim that a tool is readOnly or idempotent is policy input, not a safety guarantee.

If a server disconnects, the runtime should move active calls into a known state, increase the catalogue version and return a structured unavailable result to a model call that used the stale catalogue. It should not quietly substitute another handler.

Walk through a background code-migration task

Suppose a user starts the following task from an IDE:

Migrate the old payment-status enum to the new schema, update related code and tests, but do not execute the production migration.

1. Initialisation

The runtime verifies:

the correct repository and branch
a reproducible workspace
an available test database
no production credential is injected
tool catalogue, policy and sandbox readiness

2. Create the run

The runtime creates a run_id bound to:

task contract
workspace
agent configuration version
model profile
policy snapshot
budget

3. Execute and checkpoint

The agent reads the schema, edits code and runs tests. Each tool result becomes durable before the RunState and checkpoint pointer advance.

4. The client disconnects

The IDE closes. The worker may continue or pause at a safe point. Events, artefacts and state do not depend on IDE memory.

5. Resume from the web

The web client completes explicit version and capability negotiation, verifies thread ownership, and reads the snapshot plus missing events. The resume command carries an expected state version; the new worker receives a higher fencing token, and commits from the stale worker are rejected.

6. Approval is required

The agent prepares to run a migration against the test database. The runtime moves the run to waiting_for_approval and stores the pending operation and expiry.

7. Configuration is promoted while the run waits

The production pointer has advanced to agent-18, but this run remains on the agent-17 version pinned at creation. If a compromised credential or tool is revoked, a safety overlay can still block its use at the next safe point.

8. Complete

Only after the verifier accepts tests, diff and artefacts does the run enter a terminal state. The client displays completion, but it does not hold pass authority.

The important feature is not cross-device UI continuity. It is that every state transition has one authority, a version and durable evidence.

Twelve questions for reviewing an agent runtime

Which system retains canonical run lifecycle after the client closes?
Do thread, turn, run, task, workspace, and checkpoint have distinct responsibilities?
Which reproducible evidence establishes startup readiness?
Does the model adapter expose unsupported, degraded, and lossy semantics?
How does RunState reference external authorities instead of pretending to replace them?
Do checkpoints follow durable commits and represent unknown outcomes explicitly?
Do pause, resume, cancel, and fork return accepted, applied, or rejected results?
When workers compete for one run, how do leases, state versions, and fencing tokens prevent split brain?
Which behavioural inputs are pinned, and which emergency safety overlays may immediately tighten control?
Do promotion, migration, and rollback have distinct authorities and compatibility gates?
Is protocol compatibility established through a connection handshake, request metadata, or another explicit contract?
Are archive, deletion, retention, and cascading defined separately for each resource?

If the answers are still “the UI remembers it”, “we only have one worker today”, or “use latest”, the runtime has not become dependable.

From theory to implementation: Part 06 checklist

Part 07 addresses the next problem: once the runtime can retain state, how does work continue across sessions, context windows, and several agents without repeated work, duplicate claims, or workspace collisions? The answer lies in progress ledgers, hand-off contracts, atomic claiming, and workspace isolation.

References

OpenAI, Unlocking the Codex harness: how we built the App Server, 4 February 2026. ↩ ↩²
Anthropic, Agent SDK overview, accessed 8 July 2026. ↩
Anthropic, Claude Managed Agents: Session event stream, accessed 8 July 2026. The Managed Agents API is marked Beta in the current documentation. ↩
OpenAI Developers, Codex App Server, accessed 8 July 2026. ↩ ↩²
Anthropic, Claude Managed Agents overview, accessed 8 July 2026. ↩
Anthropic, Claude API overview, accessed 8 July 2026. The Agents, Sessions and Environments APIs are marked Beta in the current documentation. ↩
Model Context Protocol, Lifecycle, specification version 2025-11-25, accessed 8 July 2026. ↩
Model Context Protocol, Specification 2025-11-25, accessed 8 July 2026. The official site labelled this the latest stable version on that date. ↩
Model Context Protocol, Draft: Key Changes, accessed 8 July 2026. The draft is cited only to show that the negotiation shape may evolve; it is not treated as the stable protocol. ↩