diff --git a/CLAUDE.md b/CLAUDE.md
index e53da643..6a302ca9 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -35,25 +35,25 @@ This repo's bottleneck is agents paying a **re-discovery tax**: re-reading 15 fi
 
 0. **`docs/canonical-api.md`** — THE API reference + anti-reinvention decision table ("I want to ___ → use ___ → NOT ___"). The genome→run→optimize→gate spine, the recursive atom (persona=driver, `spawnChild`=worker|sub-driver, isolated|`Workspace` artifact, conserved sub-budgets, analyst dimensions+gaps), every signature `file:line`-verified. **Read before writing ANY orchestration/optimization/measurement code** — if you're about to write `runConversation`, a "skill optimizer", a "profile-seam", or a `new Sandbox(...)` loop, it already exists. **§1.5 is the AgentProfile law we keep forgetting:** an agent IS its full profile (prompt+skills+tools+mcp+subagents+hooks); you change behavior by AUTHORING the profile and letting the sandbox substrate materialize it into harness shapes — never write a verify-loop or harness-specific config (self-verification is a hook/process, not code; opencode is only the cli-bridge test target — generalize, never specialize).
 1. **`docs/architecture.md`** — the canonical spine (one recursive `Agent` atom; two timescales; benchmark-as-adapter; selector≠judge). Wins on any architecture conflict. `docs/README.md` indexes the rest; `docs/roadmap-rsi.md` is the dependency-ordered build plan; `docs/architecture-interpretations.md` defines **the decision gate**.
+   **`docs/agent-managed-compute/README.md`** is the active audit and implementation plan for distributed coordination, provider-backed workers, recovery, and run-API convergence.
 2. **`bench/HARNESS.md`** — the experiment-harness map: commands, the `rollout → corpus → selector → CI → gate` data flow, the wired/needs-creds/scaffolded matrix, and run-the-gate-in-2-lines. Read it before touching `bench/`.
 3. **`.evolve/current.json`** — the single source of truth for the active goal + generation + the live science state. Then `.evolve/progress.md` and the newest `.evolve/pursuits/*.md`.
 4. **Persistent memory** (`MEMORY.md` + the `memory/` notes) — the code-map and the evidence ledger. Start with the map; verify it, don't rebuild it.
 
 **The anti-staleness law:** these maps are kept short and code-adjacent. If a map disagrees with the code, the **code wins** — fix the map in the *same* turn. Discovery is paid once, by whoever records it. When you learn something undocumented, write it to the map/memory before moving on. **For `docs/canonical-api.md` this is now ENFORCED, not aspirational:** the mechanical leaves (per-symbol signatures + `file:line`) are GENERATED into `docs/api/` by TypeDoc — never hand-edit them — and a CI freshness gate (`pnpm docs:check` → `scripts/check-docs-freshness.mjs`) turns a stale version pin, a broken `file:line` citation, or a decision-table symbol that no longer exists into a RED BUILD. The judgment layer (§2 decision table, when-to-use, every "Do NOT") stays hand-curated and the gate never touches it. Local fix path on a red docs gate: `pnpm run docs:api` then commit, or fix the cited line — see `docs/MAINTAINING.md`.
 
-## Repo layering — this package depends on agent-eval, never the reverse
+## Repo layering
 
-```
-agent-knowledge ──► agent-runtime (this repo — wraps the substrate)
-       │                  │
-       └──────────────────┴──► agent-eval (substrate — the bottom)
-```
+- `agent-interface` owns portable contracts.
+- `agent-eval` depends on `agent-interface` and owns evaluation data and decisions.
+- `agent-knowledge` depends on `agent-interface` and `agent-eval`, and never on this runtime.
+- `agent-runtime` depends on those lower packages and composes optional knowledge workflows from `src/knowledge/`.
 
-agent-knowledge depends on agent-runtime (it imports `/loops`) and on agent-eval. agent-runtime depends ONLY on agent-eval and deliberately does NOT import agent-knowledge — domain stores/tools enter by injection (`createMcpServer({ feedbackStore })`, per `src/mcp/feedback-store.ts`), so importing the domain package would induce a dependency cycle.
+**Rule: lower packages MUST NOT import from agent-runtime.** No `peerDependencies` in `agent-eval` or `agent-knowledge` pointing here, and no `import type { X } from '@tangle-network/agent-runtime'` inside either package. A spotted upward import is a bug. Move a portable contract into `agent-interface`, an evaluation concept into `agent-eval`, or inject runtime behavior through a callback.
 
-**Rule: agent-runtime depends on agent-eval. agent-eval MUST NOT import from agent-runtime.** No upward imports, no `peerDependencies` in agent-eval pointing here, no `import type { X } from '@tangle-network/agent-runtime'` inside agent-eval. A spotted upward import is a bug — file an issue and move the type into agent-eval. agent-eval is declared a **required `peerDependency`** (floor: whatever `package.json` `peerDependencies` says — do not restate the number here), not a hard dependency — keep it in sync with the `selfImprove`/`heldoutSignificance`/`loopDispatch` APIs the code uses.
-
-**The runtime stays domain-clean by taking domain stores/tools as injected adapters, never importing a domain package** — the dependency arrow points up into this repo (agent-knowledge → agent-runtime), never down out of it.
+`agent-eval` is declared a required `peerDependency` here.
+Keep its range aligned with the APIs the runtime consumes.
+`agent-knowledge` is a direct dependency because `src/knowledge/improvement-job.ts` provides the batteries-included composition, while the pure knowledge package remains independently usable.
 
 Substrate primitives CONSUMED from agent-eval: `DefaultVerdict`, `RunRecord`, `AgentEvalError` + taxonomy, `AnalystFinding`/`AnalystRunResult`/`FindingsDiff`, `TraceAnalystKindSpec`, `KnowledgeReadinessReport`, and the campaign types (`DispatchContext`/`ProfileDispatchFn`/`Scenario`, type-only).
 
@@ -64,7 +64,7 @@ Types that stay in THIS repo because they're runtime-shaped (coupled to a runnin
 ## Code map — the loop kernel & the recursive atom (src/runtime/)
 
 - `run-loop.ts` — `runLoop`, the round-synchronous leaf kernel. Per round: `driver.plan()`→N tasks→one sandbox/iteration (bounded by `maxConcurrency`, round-robin `agentRuns`)→`streamPrompt`→`output.parse`→`validator.validate`→`driver.decide`. Owns iteration accounting, concurrency, abort, cost+token aggregation, trace emission, box teardown. Exports `defaultSelectWinner` (best-valid-score, ties→earliest) — the single-sourced selection the personify combinators reuse.
-- `supervise/` — the recursive execution atom (keystone): `Scope` + `Supervisor` over the open `Executor` port, spawn/settle on a **conserved budget pool** so equal-compute holds by construction; journal→replay/resume. `runtime.ts` also holds `createExecutor({backend})` — the ONE built-in executor (backend-as-data: `router`/`router-tools`/`bridge`/`cli`/`sandbox`; `router-tools` is the off-box tool-using agentic loop — chat→tool_calls→`executeToolCall`→repeat — over the router's tool-calling, no sandbox); the per-backend bodies are internal case-arms, BYO agents implement `Executor` directly.
+- `supervise/` — the recursive execution atom (keystone): `Scope` + `Supervisor` over the open `Executor` port, spawn/settle on a **conserved budget pool** so equal-compute holds by construction; the journal replays completed settlements, but live supervised-tree recovery after coordinator restart is not implemented. `runtime.ts` also holds `createExecutor({backend})` — the ONE built-in executor (backend-as-data: `router`/`router-tools`/`bridge`/`cli`/`sandbox`; `router-tools` is the off-box tool-using agentic loop — chat→tool_calls→`executeToolCall`→repeat — over the router's tool-calling, no sandbox); the per-backend bodies are internal case-arms, BYO agents implement `Executor` directly.
 - `personify/` — the content-free generic combinators (`fanout`/`loopUntil`/`widen`/`panel`/`verify`/`pipeline`) + `definePersona`/`runPersonified` + the cross-run `Corpus` + `createScopeAnalyst` (the analyst-on-scope steer firewall).
 - the **agent-driver** is the canonical "drive an agent" path: an `AgentProfile` driving another `AgentProfile` via the coordination toolbox (`createCoordinationTools`, `src/mcp/tools/coordination.ts`) over the `Scope`/`Supervisor`, plus `runAgentic`/`defineStrategy`/`runPersonified` (`strategy.ts`/`personify/persona.ts`) on the Supervisor. Child→parent messages ride ONE typed pipe — `createEventBus` (`supervise/event-bus.ts`): settled outputs, `ask_parent` questions, and analyst findings are all `CoordinationEvent` kinds, delivered pass-through (`subscribe`/`onEvent`, immediate) AND queued for the driver to pull (`await_event({kinds?})` — the ONE wait verb; `kinds:['settled']` = next finished worker, omit = also questions/findings). The pull queue is **priority-ordered** — a blocking question (urgency→priority: `blocks-run`=20/`blocks-step`=10) is bumped ahead of queued settles/findings; ties FIFO by `seq`. The bus is **bidirectional**: UP (settled/question/finding) is queued+pullable; DOWN (`steer_agent` for any live worker — instruction/correction/continuation; `answer_question` routes an answer down) goes to the child inbox via `scope.send`→`deliver` AND records a `queue:false` event (history + subscribers, never pulled back). The receive end is `createInbox` (`supervise/inbox.ts`), which the owned tool-loop executor (`routerToolsInlineExecutor`) exposes as `Executor.deliver`: QUEUED messages flush at each step boundary AND before the worker may settle (it can't finish with an unread steer); a FORCEFUL `steer_agent({interrupt:true})` aborts the in-flight turn so the worker re-plans immediately. Black-box CLI harnesses can't be interrupted mid-step, so there the down-leg degrades to the next spawn. Observability is first-class: every event both ways is stamped (`seq`/`at`/`priority`), the full `history()` is an audit/replay trail, `stats()` counts throughput (both surfaced on `CoordinationTools` and the MCP handle). `analyzeOnSettle` auto-fires trace analysts when a worker settles `done`, re-entering each result as a `finding` on the same bus (cost-governed opt-in; the firewall stays in the analyst registry). Trace analysis is **substrate- AND harness-agnostic** via `TraceSource` (`supervise/trace-source.ts`) — a worker's tool calls as agent-eval `ToolSpan`s from EITHER an owned loop (`createPushTraceSource`; `routerToolsInlineExecutor`'s `onToolStep` feeds `record`) OR a sandbox/fleet box (`sandboxSessionTraceSource(box, sessionId, {harness})` reads `box.messages()` session parts). Harness wire-shapes are decoded by a **per-harness adapter registry** (`toolPartDecoders`): `decodeOpencodePart` decodes against the **canonical `ToolPart`/`ToolState` published by `@tangle-network/agent-interface`** (the type every adc sdk-provider normalizes into — single source of truth, so a status adc adds/renames is a compile error here, not a silent miss; terminal-state + callId-dedup; also live-box-validated), `decodeAnthropicPart` (claude-code/kimi `{type:'tool_use', id|tool_use_id, name|tool, input}` confirmed vs `cli-bridge/src/backends/claude.ts`+`kimi.ts`), `decodeOpenAiPart` (router/kimi top-level `function`). **codex emits NO structured tool calls** (bridge `codex.ts` never yields `tool_calls` — text+shell only) → per-tool detection unavailable for codex from any path (harness property, not a gap). `decodeToolPart(part, harness?)` picks the adapter or tries all. Add a harness = add a decoder + one entry, validated against the cli-bridge backend. Two consumers ride a source: ONLINE `watchTrace` (`detector-monitor.ts`) folds live spans through agent-eval's published streaming kernel (`repeatedActionDetector`/`errorStreakDetector`, the SAME kernel `control-runtime` folds) → `onSignal` → a `finding`; SETTLE `analyzeTrace` (`trajectory-recorder.ts`) collects the spans and runs the published BATCH analyzers (`buildTrajectory`/`stuckLoopView`/`toolWasteView`). `ToolSpan` is the common currency; detection logic + the failure taxonomy live in agent-eval — never reimplement here. Production target = sandbox/fleet; the owned-loop push path is for local/router/cli-bridge. The in-process queue and a future cross-box durable mailbox share this one interface. `assertTraceDerivedFindings` (`personify/analyst.ts`) is the steer-firewall (selector≠judge). `types.ts` holds `Driver`/`AgentRunSpec`/`OutputAdapter`/`Validator`/`Iteration`/`LoopResult`/`SandboxClient` + the `LoopTraceEvent` union. `sandbox-run.ts` is `openSandboxRun` — the one run/stream/resume sandbox seam; `inline-sandbox-client.ts` is `inlineSandboxClient` — the one adapter presenting any non-box `Executor` as a `SandboxClient` for `runLoop`. `loop-dispatch.ts` adapts `runLoop`→agent-eval campaigns; `report-usage.ts` forwards token usage so the integrity guard sees a real backend.
 
diff --git a/docs/README.md b/docs/README.md
index 56899bd1..0f85622d 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -16,6 +16,7 @@ The map of every doc. **Start here** if you're new; the deeper tracks follow.
 | # | Doc | Role | Purpose |
 |---|---|---|---|
 | 1 | [architecture.md](./architecture.md) | **canonical spine** | One recursive agent tree, two timescales, many benchmarks — the visual mental model (`act`/`Scope`/recursion, the up-flow, the three improvement timescales) folded in. The single source of truth; wins on conflict. |
+| 1a | [agent-managed-compute/](./agent-managed-compute/) | **distributed execution plan** | Current-state audit, converged design, failure behavior, dependency-ordered roadmap, and measurable completion criteria for agents that allocate and steer compute. |
 | 2 | [architecture-interpretations.md](./architecture-interpretations.md) | coherence verdict | Stress-tests the spine through five lenses + the decision gate. Answers "does it cohere?" — and where it doesn't. |
 | 3 | [roadmap-rsi.md](./roadmap-rsi.md) | build plan | The dependency-ordered sequence from scaffold to a measured surface. Phases, exit gates, open decisions. |
 | 4 | [learning-flywheel.md](./learning-flywheel.md) | theory deep-dive | The moat thesis — the `(π, τ, J, D, O)` recursion and cross-run flywheel. |
@@ -32,7 +33,7 @@ The map of every doc. **Start here** if you're new; the deeper tracks follow.
 | [glossary.md](./glossary.md) | canonical vocabulary | One definition per term, grounded to `file:line`; drifted synonyms flagged. |
 | [execution-model.md](./execution-model.md) | the picture | The unified `Executor` port (router/bridge/cli/sandbox/BYO) + two engines, driver vs worker, spawn mechanics. |
 | [agent-bus-protocol.md](./agent-bus-protocol.md) | normative protocol | The multi-agent call bus — depth limits, headers, refusal contract. |
-| [durability-adapters.md](./durability-adapters.md) | subsystem | Journal + durability for resumable conversations + supervisor trees. |
+| [durability-adapters.md](./durability-adapters.md) | subsystem | SQL-backed journal and restart behavior for conversations. Supervised-tree recovery is not implemented. |
 | [intelligence-sdk.md](./intelligence-sdk.md) | product SDK | Observe + OFF billing floor + effort tiers + certified delivery + capability resolver — the `/intelligence` subpath. Designed-not-shipped verbs fenced at the tail. |
 | [BUILDING.md](./BUILDING.md) | process | Building discipline: goal first, cheapest decisive proof, verification rules. |
 | [ANTI_PATTERNS.md](./ANTI_PATTERNS.md) | process | Named failure modes. |
@@ -42,7 +43,7 @@ The map of every doc. **Start here** if you're new; the deeper tracks follow.
 
 | Doc | Role | Purpose |
 |---|---|---|
-| [simplification-plan.md](./research/simplification-plan.md) | **live tracker** | The in-flight simplification/rearchitecture: the converged design, the scratch list, the doc/module inventory, the workstreams + completion criteria. |
+| [simplification-plan.md](./research/simplification-plan.md) | historical tracker | Earlier simplification analysis. The active execution and API convergence plan is [agent-managed-compute/roadmap.md](./agent-managed-compute/roadmap.md). |
 | [research/README.md](./research/README.md) | research index | Forward-looking design threads + decision log. Not the canonical spine. |
 | [archive/](./archive/) | retired notes | Superseded/niche docs kept for history (delivery manifest, conversation economics, artifact-lifecycle, go-live, results, benchmark-matrix consolidation). |
 
diff --git a/docs/agent-managed-compute/README.md b/docs/agent-managed-compute/README.md
new file mode 100644
index 00000000..7732bab7
--- /dev/null
+++ b/docs/agent-managed-compute/README.md
@@ -0,0 +1,114 @@
+# Agent-Managed Compute
+
+This directory is the canonical plan for agents that allocate, steer, and recover compute through `agent-runtime`.
+
+## Verdict
+
+The repository is on the right architectural track, but it is not yet a distributed coordination system.
+
+The core execution model is sound:
+
+- An `AgentProfile` describes the agent.
+- A `Scope` lets a driver spawn, observe, steer, and stop children.
+- A `Supervisor` owns the shared budget and child lifecycle.
+- An `Executor` runs one child on a selected backend.
+- An `AgentEnvironmentProvider` exposes external compute and resumable sessions.
+- MCP exposes coordination actions to an agent runner as native tools.
+
+The missing work is operational, not conceptual.
+
+Coordination state is currently process-local, supervised trees do not resume after coordinator restart, the HTTP MCP endpoint has no authentication, and the public run APIs overlap.
+
+## Product Definition
+
+Agent-managed compute means an agent may decide at runtime to:
+
+1. do work itself,
+2. start one or more child agents,
+3. choose their profiles and compute providers,
+4. inspect progress and outputs,
+5. send corrections or follow-up instructions,
+6. stop or replace work that is failing,
+7. preserve useful state across process failure,
+8. finish only when an independent check accepts the result.
+
+The runtime manages logical work, budgets, recovery, and records.
+
+Compute providers manage machines, containers, sessions, process health, and placement.
+
+MCP is the tool-facing control adapter.
+
+MCP is not the scheduler or durable state store.
+
+## Documents
+
+| Document | Purpose |
+|---|---|
+| [current-state.md](./current-state.md) | What is implemented, what was tested, and what is only claimed. |
+| [architecture.md](./architecture.md) | The converged execution model, package ownership, and target public API. |
+| [reliability.md](./reliability.md) | Failure behavior, recovery rules, security, concurrency, and workspace safety. |
+| [roadmap.md](./roadmap.md) | Dependency-ordered implementation plan with completion criteria. |
+| [validation.md](./validation.md) | Tests, failure injection, live-provider runs, and benchmark acceptance targets. |
+
+These six files are the only active planning documents for this effort.
+
+The broader [runtime architecture](../architecture.md), [call-routing protocol](../agent-bus-protocol.md), [environment-provider implementation record](../research/environment-provider-adapter-spec.md), [context-lifecycle research](../research/smart-loops-context-lifecycle.md), and [interactive-session proposal](../research/interactive-sessions-spec.md) remain source references.
+
+When a source reference conflicts with this directory about distributed readiness or implementation order, this directory wins.
+
+The older [simplification tracker](../research/simplification-plan.md) is historical and is superseded by [roadmap.md](./roadmap.md) for execution and API convergence.
+
+## Source Document Ledger
+
+This table tracks the existing documents that materially overlap this plan.
+
+| Document | Classification | Use |
+|---|---|---|
+| [Runtime architecture](../architecture.md) | Current reference | Recursive agent model and package-wide architecture. |
+| [Canonical API](../canonical-api.md) | Current reference | Shipped entry points and anti-duplication guidance. |
+| [Execution model](../execution-model.md) | Current reference | Existing executor and driver behavior. |
+| [Agent bus protocol](../agent-bus-protocol.md) | Current reference | Call-routing headers and depth controls. It is not durable coordination state. |
+| [Durability adapters](../durability-adapters.md) | Current reference | Conversation persistence only. It does not provide supervised-tree recovery. |
+| [Environment provider adapter](../research/environment-provider-adapter-spec.md) | Current source | Provider contract and adapter implementation history. |
+| [Context lifecycle](../research/smart-loops-context-lifecycle.md) | Current source | Long-run context and knowledge transfer research. |
+| [Interactive sessions](../research/interactive-sessions-spec.md) | Historical input | Session UX and tmux exploration. Its completion checklist is not current acceptance evidence. |
+| [Long-horizon agent map](../research/long-horizon-agent-map.md) | Historical input | Earlier product and control design. |
+| [RSI atom masterplan](../research/rsi-atom-masterplan.md) | Historical input | Earlier recursive-agent build plan. |
+| [Simplification plan](../research/simplification-plan.md) | Superseded plan | Earlier API and module inventory. |
+| [`atom-mcp-e2e.mts`](../../bench/src/atom-mcp-e2e.mts) | Historical experiment | Useful prototype with stale tool names and incomplete result accounting. |
+
+## Status Summary
+
+| Capability | Current status | Evidence |
+|---|---|---|
+| Agent calls coordination actions through real HTTP MCP | Implemented in one process | `tests/loops/coordination-mcp.test.ts` |
+| Driver dynamically spawns, waits for, and selects children | Implemented | `tests/loops/coordination-driver.test.ts` |
+| Recursive driver starts another driver | Implemented | `tests/loops/coordination-driver.test.ts` |
+| Shared budget and depth limits across a tree | Implemented | `src/runtime/supervise/budget.ts`, `src/runtime/supervise/scope.ts` |
+| Provider-neutral compute adapter | Implemented | `src/runtime/environment-provider.ts` |
+| One-shot delegation restart recovery | Partially implemented | `src/mcp/task-queue.ts` |
+| Conversation turn restart recovery | Implemented for one writer | `src/conversation/run-conversation.ts` |
+| Supervised tree restart recovery | Not implemented | `src/runtime/supervise/supervisor.ts` |
+| Durable cross-process coordination messages | Not implemented | `src/runtime/supervise/event-bus.ts` |
+| Authenticated remote coordination MCP | Not implemented | `src/runtime/supervise/coordination-mcp.ts` |
+| Concurrent coordinator failover | Not implemented | Current file stores have no compare-and-set or ownership claim. |
+| One simple multi-round public API | Not implemented | `runConversation`, `runPersonified`, `runAgentic`, and `runLoop` overlap. |
+| Acyclic runtime and knowledge packages | Implemented on current source | `agent-knowledge` main no longer imports `agent-runtime`; runtime owns the optional composition. Dependency versions still need alignment. |
+
+## Scope Boundaries
+
+This work must not turn `agent-runtime` into a machine scheduler.
+
+Use existing provider systems for compute allocation and process lifecycle.
+
+This work must not put knowledge policy into the runtime.
+
+`agent-knowledge` remains the general knowledge engine, and an agent may use it as a tool or work product during a run.
+
+This work must not create another profile format.
+
+`AgentProfile` remains the portable description of agent behavior.
+
+This work must not promise exactly-once network delivery.
+
+It must provide idempotent commands, deduplicated events, and one accepted terminal result.
diff --git a/docs/agent-managed-compute/architecture.md b/docs/agent-managed-compute/architecture.md
new file mode 100644
index 00000000..9976be2d
--- /dev/null
+++ b/docs/agent-managed-compute/architecture.md
@@ -0,0 +1,234 @@
+# Converged Architecture
+
+## One-Sentence Model
+
+An agent runs under one durable logical run, starts children through one budgeted `Scope`, and places each child on an external compute provider through the existing `Executor` and `AgentEnvironmentProvider` contracts.
+
+## Ownership
+
+| Package | Owns | Does not own |
+|---|---|---|
+| `agent-interface` | `AgentProfile`, environment provider contracts, portable event and session identifiers | Scheduling policy, provider implementation, benchmark logic |
+| `agent-runtime` | Agent tree, run state, budgets, interaction policies, recovery, coordination tools | Machine placement, model hosting, domain knowledge policy |
+| Provider packages | Environments, sessions, process lifecycle, placement, reconnect, provider usage | Agent planning and result acceptance |
+| `agent-eval` | Run records, metrics, comparisons, held-out promotion decisions | Agent execution and compute allocation |
+| `agent-bench` | Reusable workloads and benchmark suites | Runtime internals |
+| `agent-knowledge` | Knowledge sources, indexes, memory, retrieval, claims, and knowledge improvement | Agent execution and distributed compute |
+
+The dependency direction remains:
+
+```text
+agent-interface
+  -> agent-eval
+  -> agent-knowledge
+  -> agent-runtime
+
+agent-bench consumes the published packages.
+provider packages implement agent-interface contracts.
+```
+
+`agent-knowledge` remains usable without `agent-runtime`.
+
+`agent-runtime` may compose knowledge operations into an agent run.
+
+## The Durable Core
+
+The existing types remain the center:
+
+| Primitive | Meaning |
+|---|---|
+| `AgentProfile` | What an agent knows, can use, and is instructed to do |
+| `Agent` | Code that acts inside a `Scope` |
+| `Scope` | Spawn, wait, steer, inspect, meter, and cancel children |
+| `Supervisor` | Owns one logical run and its shared limits |
+| `Executor` | Runs one child invocation |
+| `AgentEnvironmentProvider` | Creates and reconnects to physical execution environments |
+| `SpawnJournal` | Durable ordered decisions and spend for the logical run |
+| `ResultBlobStore` | Immutable outputs addressed by content hash |
+
+The implementation should evolve these primitives rather than introduce a second coordinator.
+
+## Logical And Physical State
+
+The runtime owns logical state:
+
+- run identity and status,
+- parent and child relationships,
+- command identity,
+- budget reservation and actual spend,
+- accepted outputs,
+- questions and steering actions,
+- provider environment and session references,
+- recovery position.
+
+The provider owns physical state:
+
+- machine and container placement,
+- process health,
+- session continuation,
+- event replay from a provider cursor,
+- checkpoint and fork support,
+- physical cancellation,
+- resource usage reported by the provider.
+
+The runtime must store a provider reference before considering dispatch committed.
+
+The provider must accept an idempotency key derived from the logical invocation.
+
+## One Active Coordinator Per Run
+
+Many workers may run in parallel.
+
+Only one coordinator may commit decisions for a given run at a time.
+
+The coordinator service scales horizontally across runs.
+
+Different replicas own different runs, and ownership moves when a replica fails.
+
+Within one run, decision commits are serialized while worker execution remains distributed.
+
+A durable ownership claim includes a monotonically increasing generation number.
+
+Every append and command carries that generation.
+
+When ownership expires, the next coordinator acquires a higher generation and older coordinators can no longer commit.
+
+Provider-mutating commands also carry the generation and a per-invocation command sequence.
+
+A provider adapter must reject stale generations itself or send commands through a session broker that does.
+
+This prevents two restarted processes from steering or accepting the same work concurrently.
+
+Use a transactional database, Redis, Durable Objects, or another store with conditional writes.
+
+Do not implement distributed consensus in this package.
+
+## Interaction Policies
+
+The same run can support different policies without creating different execution systems.
+
+| Policy | Behavior | Current entry point |
+|---|---|---|
+| Dynamic driver | A model decides which child to start, steer, replace, or stop | `supervise` and coordination MCP |
+| Alternating actors | Two actors take turns over shared state | `runConversation` |
+| Round robin | N actors take turns in a fixed schedule | `runConversation` |
+| Refine until accepted | One or more workers improve an artifact across rounds | `runAgentic` |
+| Fixed fanout or pipeline | A declared interaction shape runs over a `Supervisor` | `runPersonified` |
+| Sandbox batch | A driver plans a batch of isolated sandbox attempts | `runLoop` |
+
+The target public API is:
+
+```ts
+runAgent(profile, task, options)
+
+runInteraction({
+  actors,
+  policy,
+  task,
+  budget,
+  store,
+})
+
+improve(profile, findings, options)
+```
+
+`runAgent` is the common path for one root profile that may dynamically delegate.
+
+`runInteraction` is the explicit multi-actor path.
+
+`runConversation` becomes an alternating or round-robin policy preset.
+
+`runAgentic` and `runPersonified` become policy helpers or compatibility wrappers.
+
+`runLoop` becomes an internal sandbox batch implementation.
+
+The cleanup must preserve behavior before removing old exports.
+
+## MCP Roles
+
+There are two valid agent-facing tool sets.
+
+### Coordination tools
+
+Coordination tools act inside one live run:
+
+- `spawn_agent`
+- `observe_agent`
+- `steer_agent`
+- `await_event`
+- `ask_parent`
+- `answer_question`
+- `stop`
+
+These tools map directly to durable run commands and `Scope` operations.
+
+They do not own state.
+
+### One-shot delegation
+
+The generic `delegate` tool asks a supervisor to solve one intent and returns the accepted output and spend.
+
+It is a convenience operation over `runAgent`.
+
+Its status and history endpoints should read the same run store rather than maintain a separate task state machine.
+
+## Multi-Round Two-Agent Atom
+
+The minimum complete interaction is a driver and one worker:
+
+1. The driver starts the worker with a profile, task, budget, and stable invocation id.
+2. The provider returns an environment and session reference.
+3. The runtime records that reference.
+4. The worker emits progress and usage with stable event ids.
+5. The driver sends a correction using a stable command id.
+6. The worker continues the same session when the provider supports continuation.
+7. An independent check accepts or rejects the output.
+8. The runtime records one terminal result and reconciles spend.
+9. A coordinator restart at any step reconnects without starting duplicate work.
+
+Every larger agent tree is recursive composition of this atom.
+
+## Workspaces
+
+Parallel agents must not write blindly into one mutable checkout.
+
+The default coding model is:
+
+1. create an isolated worktree or provider workspace per invocation,
+2. produce an immutable patch or commit,
+3. run deterministic checks in that workspace,
+4. accept the result only after the checks pass,
+5. integrate through one designated owner,
+6. record conflicts as explicit work, not silent overwrites.
+
+A shared writable filesystem is an opt-in provider capability for workloads that require it.
+
+## Knowledge
+
+Knowledge is a work product and an agent capability, not coordinator state.
+
+A run may:
+
+- research from zero knowledge,
+- ingest new sources,
+- maintain an LLM wiki,
+- update a retrieval index,
+- write memory from traces,
+- evaluate retrieval and answer quality,
+- improve a knowledge base across repeated runs.
+
+The profile decides which knowledge tools and policies the agent receives.
+
+`agent-knowledge` supplies the pure operations and storage adapters.
+
+`agent-runtime` supplies the dynamic agents, compute, recovery, and budgets that call those operations.
+
+## PrimeIntellect
+
+PrimeIntellect integration packages runtime tasks, scoring, and traces for training and evaluation.
+
+It is not automatically a live compute provider.
+
+If Prime exposes the environment lifecycle required by `AgentEnvironmentProvider`, a separate provider adapter may implement it.
+
+The training and evaluation adapter should not be confused with runtime placement.
diff --git a/docs/agent-managed-compute/current-state.md b/docs/agent-managed-compute/current-state.md
new file mode 100644
index 00000000..dbff5492
--- /dev/null
+++ b/docs/agent-managed-compute/current-state.md
@@ -0,0 +1,218 @@
+# Current State Audit
+
+## Tested Baseline
+
+The focused local suite passed 48 of 48 tests on 2026-07-15:
+
+The baseline was `origin/main` at `2ccd40ce` with `agent-interface` 0.26.1, `agent-eval` 0.120.1, and `sandbox` 0.9.7 from the locked install.
+
+```bash
+pnpm exec vitest run \
+  tests/loops/coordination-mcp.test.ts \
+  tests/loops/supervisor-agent.test.ts \
+  tests/loops/coordination.test.ts \
+  tests/loops/event-bus.test.ts \
+  tests/mcp/task-queue-durable.test.ts \
+  src/runtime/environment-provider.test.ts
+```
+
+Those tests establish that the local primitives work.
+
+They do not establish distributed recovery, secure remote use, or production performance.
+
+## What Exists
+
+| Area | Implementation | Honest capability |
+|---|---|---|
+| Recursive execution | `src/runtime/supervise/types.ts`, `scope.ts`, `supervisor.ts` | A driver can start child agents recursively under one budget and depth limit. |
+| Agent-facing coordination | `src/mcp/tools/coordination.ts` | A driver can call `spawn_agent`, `observe_agent`, `steer_agent`, `await_event`, `ask_parent`, and `stop`. |
+| Native MCP transport | `src/runtime/supervise/coordination-mcp.ts` | A local agent runner can call coordination actions over HTTP. |
+| Driver reasoning | `src/runtime/supervise/coordination-driver.ts` | A model can choose coordination actions dynamically. |
+| Child execution | `Executor` and `createExecutor` | Router, bridge, CLI, sandbox, worktree, and custom implementations share one execution contract. |
+| Provider adapters | `src/runtime/environment-provider.ts` | External environment providers can be adapted into the runtime. |
+| Tree records | `SpawnJournal` and `ResultBlobStore` | Completed child decisions and content-addressed outputs can be replayed for inspection. |
+| Conversation records | `ConversationJournal` | A single conversation writer can resume from committed turns. |
+| Async delegation records | `DelegationTaskQueue` | A one-shot task can persist status and reconnect to a detached session when configured. |
+| Workspace isolation | `src/runtime/workspace.ts`, worktree executors | Parallel coding agents can work in isolated checkouts and return commits or patches. |
+
+## Critical Findings
+
+### 1. A supervised tree does not resume
+
+`Supervisor.run` always begins the tree, appends a new root event, and calls `root.act` from the start.
+
+It never loads the prior tree to recover active children or the driver's prior decision state.
+
+See `src/runtime/supervise/supervisor.ts:68` and `src/runtime/supervise/supervisor.ts:75`.
+
+A direct probe ran the same `runId` twice against the same journal.
+
+The root executed twice and the journal contained two root spawn events:
+
+```json
+{"calls":2,"first":"winner","second":"winner","rootSpawnEvents":2}
+```
+
+`replaySpawnTree` reconstructs completed settlements for analysis.
+
+It is not coordinator recovery.
+
+Any document that calls the current supervised tree resumable is overstating the implementation.
+
+### 2. Delegation idempotency is process-local
+
+`DelegationTaskQueue.submit` checks only its local `byIdempotencyKey` map.
+
+It does not atomically claim the key in `DelegationStore`.
+
+See `src/mcp/task-queue.ts:306` and `src/mcp/delegation-store.ts:24`.
+
+Two queue instances sharing one store both accepted the same key:
+
+```json
+{"a":{"taskId":"a","reused":false},"b":{"taskId":"b","reused":false}}
+```
+
+This permits duplicate remote work and duplicate side effects after concurrent submission or failover.
+
+### 3. The coordination MCP is not safe to expose remotely
+
+`serveCoordinationMcp` accepts arbitrary HTTP POST requests and invokes tools without authenticating the caller or binding it to a run.
+
+See `src/runtime/supervise/coordination-mcp.ts:92`.
+
+It also accepts an unbounded request body and exposes a configurable host.
+
+Binding to `127.0.0.1` is a useful default, but it is not a remote security model.
+
+### 4. Coordination events disappear with the coordinator process
+
+`createEventBus` stores its queue, history, sequence, and subscribers in memory.
+
+See `src/runtime/supervise/event-bus.ts:76`.
+
+The `history()` method is an in-memory log, not a durable record.
+
+A coordinator restart loses unread questions, findings, and steering history.
+
+### 5. There are three independent records of a run
+
+Supervised trees use `SpawnJournal`.
+
+Conversations use `ConversationJournal`.
+
+One-shot delegation uses `DelegationStore`.
+
+Each has different identifiers, state transitions, recovery behavior, and concurrency assumptions.
+
+The duplication makes cross-feature recovery and cost accounting unreliable.
+
+## High Findings
+
+### 6. The historical live proof is not an acceptance test
+
+`bench/src/atom-mcp-e2e.mts` is useful exploratory code, but it cannot support a current production claim.
+
+The script asks the supervisor to call `spawn_worker`, while the current MCP exports `spawn_agent`.
+
+See `bench/src/atom-mcp-e2e.mts:178` and `src/mcp/tools/coordination.ts:473`.
+
+The script prints a failed verdict without setting a failing process exit code.
+
+See `bench/src/atom-mcp-e2e.mts:212`.
+
+It records zero tokens and zero cost for real model-backed worker calls.
+
+See `bench/src/atom-mcp-e2e.mts:136`.
+
+It also describes local worktree and bridge execution as real boxes, which is not what the code runs.
+
+No raw run artifact is committed with the script.
+
+The historical commit proves that someone ran a useful experiment.
+
+It does not prove that the current branch passes a live distributed scenario.
+
+### 7. Cancellation records intent, not confirmed termination
+
+`DelegationTaskQueue.cancel` marks a task `cancelled` even when the underlying runner ignores the abort signal and continues producing effects.
+
+See `src/mcp/task-queue.ts:362`.
+
+For remote compute, cancellation must distinguish `cancel_requested` from confirmed `cancelled`.
+
+### 8. Steering support depends on the executor
+
+`Scope.send` succeeds only when the active executor implements `deliver`.
+
+Router tools, bridge sessions, and bridge worktree executors do.
+
+The one-shot sandbox executor does not provide the same mid-run control.
+
+The capability must be reported before the driver chooses a policy that depends on live steering.
+
+### 9. The public run model is fragmented
+
+`runConversation` owns a separate turn loop and journal.
+
+`runPersonified` and `runAgentic` build policies over `Supervisor`.
+
+`runLoop` is a sandbox-specific round engine.
+
+`supervise` is the dynamic driver path.
+
+These are legitimate behaviors, but they are presented as unrelated entry points instead of policy choices over shared execution state.
+
+## Medium Findings
+
+### 10. File persistence is single-process infrastructure
+
+`FileDelegationStore` rewrites the full record set for each mutation.
+
+`FileSpawnJournal` scans the full JSONL file before appending and has no cross-process compare-and-set.
+
+These implementations are appropriate for local runs and tests.
+
+They must not be presented as distributed stores.
+
+### 11. Conversation resume assumes one writer
+
+The conversation journal correctly resumes committed turns, but its documentation explicitly forbids multiple drivers writing the same `runId`.
+
+See `docs/durability-adapters.md:206`.
+
+That is a good constraint and should become an enforced ownership rule rather than an application warning.
+
+### 12. Current tests stop at the process boundary
+
+The real HTTP test proves HTTP to MCP to `Scope.spawn`.
+
+Its worker is an in-memory test executor.
+
+The provider tests prove adapter behavior with local fakes.
+
+There is no automated test that kills a coordinator, reconnects to a real remote session, rejects duplicate commands, and completes the same run.
+
+### 13. Package layering is fixed, but dependency versions are stale
+
+The current `agent-knowledge` main branch has no dependency or source import from `agent-runtime`.
+
+`agent-runtime` now owns the batteries-included composition through `src/knowledge/improvement-job.ts`.
+
+That is the intended dependency direction and removes the former package cycle.
+
+The runtime manifest still pins `agent-knowledge` 1.12.1, `agent-eval` 0.120.1, `agent-interface` 0.26.1, and `sandbox` 0.9.7.
+
+The registry versions checked on 2026-07-15 were 3.0.0, 0.121.0, 0.28.0, and 0.10.5 respectively.
+
+The old package lines should not be carried into the distributed state model.
+
+Upgrade them together, resolve contract changes once, and verify that the install contains one compatible version of each shared contract package.
+
+## Decision
+
+Keep the recursive execution model and provider adapter design.
+
+Do not scale the current MCP server or task queue directly.
+
+First unify logical run state and restart recovery, then make MCP a secure remote view of that state.
diff --git a/docs/agent-managed-compute/reliability.md b/docs/agent-managed-compute/reliability.md
new file mode 100644
index 00000000..6d160f11
--- /dev/null
+++ b/docs/agent-managed-compute/reliability.md
@@ -0,0 +1,219 @@
+# Reliability And Security
+
+## Required Invariants
+
+The implementation is complete only when all of these hold:
+
+1. One logical invocation has at most one accepted terminal result.
+2. Retried commands do not start duplicate physical work.
+3. Provider events may be delivered more than once without duplicating effects.
+4. A stale coordinator cannot commit after ownership moves to another process.
+5. Every accepted child has a parent, profile reference, budget, provider reference, and output reference.
+6. Actual reported spend is never replaced with fabricated zero usage.
+7. Cancellation is not terminal until the provider confirms termination or the runtime reports it as uncertain.
+8. A coordinator restart does not discard acknowledged questions, steering actions, or accepted outputs.
+9. An unauthenticated or cross-run caller cannot invoke coordination actions.
+10. Parallel workspace writes cannot silently overwrite one another.
+
+## Delivery Semantics
+
+Network messages are at least once.
+
+Commands and events require stable identities:
+
+```text
+runId
+invocationId
+commandId
+commandSequence
+providerEnvironmentId
+providerSessionId
+providerEventId
+coordinatorGeneration
+```
+
+The runtime deduplicates commands by `(runId, commandId)`.
+
+The runtime deduplicates provider events by `(invocationId, providerEventId)`.
+
+Provider mutations are emitted from a durable command outbox.
+
+Each mutation carries `(invocationId, coordinatorGeneration, commandSequence)`.
+
+The provider adapter or its session broker rejects any generation below the highest accepted generation and any repeated sequence with different content.
+
+A database ownership claim without this external fencing is insufficient because a partitioned old coordinator may still send a late steer or cancel.
+
+Acceptance is a compare-and-set transition from nonterminal state to one terminal state.
+
+Duplicate terminal events return the recorded result when identical and fail loudly when inconsistent.
+
+## Run Ownership
+
+The durable store must support:
+
+```ts
+claimRun(runId, ownerId, ttlMs)
+renewRun(runId, ownerId, generation, ttlMs)
+append(runId, generation, expectedRevision, events)
+read(runId, afterRevision)
+releaseRun(runId, ownerId, generation)
+```
+
+The exact public storage API may differ.
+
+The required semantics may not.
+
+An expired owner may continue running in memory, but its next durable append must fail.
+
+Its next provider mutation must also fail at the provider adapter or session broker.
+
+The new owner then reconnects to provider sessions recorded before the failure.
+
+## Invocation States
+
+```text
+planned
+  -> dispatching
+  -> running
+  -> cancel_requested
+  -> completed | failed | cancelled | lost
+```
+
+`dispatching` is durable before the external provider call.
+
+The provider creation call uses `invocationId` as its idempotency key.
+
+`running` includes the environment and session references needed for reconnect.
+
+`cancel_requested` means the command was sent but termination is not yet confirmed.
+
+`lost` means the provider can no longer find the environment and no accepted result exists.
+
+The runtime must not rewrite `lost` as successful or retry the effect silently.
+
+## Recovery Procedure
+
+After coordinator restart:
+
+1. acquire run ownership with a higher generation,
+2. replay durable run events from the last snapshot,
+3. rebuild budget reservations and accepted spend,
+4. list nonterminal invocations,
+5. reconnect through the recorded provider and environment ids,
+6. replay provider events from each recorded event cursor,
+7. reconcile any terminal provider status,
+8. resume the driver from durable interaction state,
+9. start new work only after reconciliation completes.
+
+An independent cleanup process periodically lists provider resources by run and invocation metadata, adopts known resources, and terminates confirmed orphans after the configured retention interval.
+
+The driver cannot be resumed from model context alone.
+
+Its durable state must include the compact task state, actor session references, unread events, and policy position.
+
+## Provider Requirements
+
+The existing `AgentEnvironmentProvider` contract is the physical compute boundary.
+
+Distributed-capable providers must report support for:
+
+- idempotent creation,
+- environment lookup,
+- session continuation,
+- event replay from a cursor,
+- cancellation status,
+- usage reporting,
+- workspace operations when required,
+- checkpoint and fork when offered,
+- placement metadata.
+
+Distributed steering additionally requires generation fencing for provider mutations.
+
+An adapter without fencing may run one-shot idempotent work, but it cannot claim safe multi-round failover.
+
+Drivers must not depend on unsupported capabilities.
+
+For example, a policy that requires mid-turn steering must reject a provider that only supports one-shot execution.
+
+Provider conformance tests belong in the shared provider test package.
+
+## MCP Security
+
+Remote coordination MCP requires:
+
+- a short-lived bearer token scoped to one run and actor,
+- an audience bound to the MCP endpoint,
+- expiration and key rotation,
+- a maximum request size,
+- a request deadline,
+- action-level authorization,
+- per-run rate and concurrency limits,
+- structured audit events,
+- no secrets in tool results or logs.
+
+The default remains loopback-only.
+
+Non-loopback binding without authentication must fail at construction.
+
+Browser access requires an authenticated proxy and origin checks.
+
+## Backpressure
+
+The shared budget limits total work.
+
+Separate limits are still required for:
+
+- live child count,
+- provider creation rate,
+- queued event count and bytes,
+- unread questions,
+- per-run blob bytes,
+- retry attempts,
+- driver turns,
+- wall-clock duration.
+
+When a limit is reached, the runtime stops admitting new work and leaves current state inspectable.
+
+It must not drop accepted events silently.
+
+## Workspace Concurrency
+
+Each coding invocation receives an isolated workspace by default.
+
+An accepted result names its base revision and produced revision.
+
+Integration verifies that the base still matches or performs an explicit merge.
+
+Conflicts create a new integration task.
+
+Only the integration owner may update the shared branch.
+
+This supports many agents working in parallel without pretending that arbitrary concurrent file writes are safe.
+
+## Data Retention
+
+The run journal stores compact decisions and references.
+
+Large transcripts, traces, and outputs live in blob storage.
+
+Retention policy must be configurable by data class:
+
+- run decisions,
+- model transcripts,
+- tool inputs and outputs,
+- workspace artifacts,
+- knowledge writes,
+- secrets and personal data.
+
+Deleting a run must either delete referenced private blobs or record why shared content-addressed blobs remain.
+
+## Explicit Non-Goals
+
+- Do not build a machine scheduler in `agent-runtime`.
+- Do not implement a consensus algorithm.
+- Do not require exactly-once network delivery.
+- Do not allow multiple active coordinators for one run.
+- Do not use one shared mutable checkout as the default parallel workspace.
+- Do not make every provider pretend it supports live steering or sessions.
+- Do not merge agent knowledge state into coordinator state.
diff --git a/docs/agent-managed-compute/roadmap.md b/docs/agent-managed-compute/roadmap.md
new file mode 100644
index 00000000..3b662f4e
--- /dev/null
+++ b/docs/agent-managed-compute/roadmap.md
@@ -0,0 +1,207 @@
+# Implementation Roadmap
+
+## Completion Definition
+
+Agent-managed compute is complete when an external developer can start one dynamic run with a profile and budget, observe and steer its agents, kill and restart the coordinator without duplicate work, use at least two real compute providers, and receive one checked result with complete usage and trace records.
+
+The work is ordered to prove the two-agent atom before adding scale.
+
+## Phase 0: Documentation Truth
+
+**Owner:** `agent-runtime`
+
+**Work:**
+
+- Make this directory the canonical plan.
+- Correct claims that supervised trees already resume.
+- Distinguish call-routing headers from coordination state.
+- Mark historical scripts as experiments until they produce machine-checked artifacts.
+
+**Complete when:**
+
+- Current capabilities and gaps are stated without contradiction.
+- Every completion claim links to a test or persisted live run.
+- No new document describes the in-memory event bus as durable.
+
+## Phase 1: One Interaction Model
+
+**Owner:** `agent-runtime`
+
+**Work:**
+
+- Upgrade `agent-knowledge`, `agent-eval`, `agent-interface`, and `sandbox` to their current compatible release lines.
+- Add a package-direction check that rejects any `agent-knowledge` import from `agent-runtime`.
+- Define one internal run state used by dynamic drivers and scheduled actor turns.
+- Make `runAgent` the simple root-profile entry point.
+- Make `runInteraction` the explicit multi-actor entry point.
+- Implement conversation turn order as an interaction policy.
+- Implement personified and agentic modes as policy helpers.
+- Make `runLoop` an internal sandbox batch implementation.
+- Keep existing exports as deprecated wrappers for one release cycle.
+
+**Complete when:**
+
+- Runtime and knowledge install one compatible copy of each shared contract package.
+- `agent-knowledge` builds and tests without `agent-runtime` installed.
+- One two-agent test exercises the shared state through both dynamic and alternating policies.
+- All existing public behavior tests pass through the new internal path.
+- New examples need no knowledge of `runLoop`, `Supervisor` construction, or MCP server wiring.
+- Generated API documentation shows one recommended run path and one advanced multi-actor path.
+
+## Phase 2: Durable Run Ownership And Recovery
+
+**Owners:** `agent-interface`, `agent-runtime`
+
+**Work:**
+
+- Extend the existing run record with revisions, ownership generation, commands, provider references, and coordination events.
+- Add durable adapters with conditional writes.
+- Persist dispatch intent before provider creation.
+- Add a durable provider-command outbox with coordinator generation and command sequence.
+- Rebuild budget reservations and interaction state on restart.
+- Adapt `SpawnJournal`, `ConversationJournal`, and delegation status onto the shared internal record.
+- Preserve separate public adapters only where compatibility requires them.
+
+**Complete when:**
+
+- Killing the coordinator at every invocation transition resumes or reports an honest terminal failure.
+- A stale coordinator cannot append after failover.
+- A delayed stale-coordinator command cannot steer, cancel, or accept provider work after failover.
+- Two concurrent submissions with the same idempotency key start one physical invocation.
+- Questions, answers, and steering commands survive restart.
+- Actual spend after recovery matches provider events.
+
+## Phase 3: Provider Session Control
+
+**Owners:** provider packages, `agent-runtime`
+
+**Work:**
+
+- Use `AgentEnvironmentProvider` as the only remote compute boundary.
+- Add capability checks for session continuation, event replay, steering, cancellation, workspace, and usage.
+- Add `deliver` and reconnect behavior to the provider-backed executor where supported.
+- Require provider-side generation fencing or a fenced session broker for multi-round failover.
+- Store environment, session, and event cursor references in the run record.
+- Add provider-resource reconciliation and orphan cleanup by run and invocation metadata.
+- Reuse the shared provider conformance tests.
+
+**Complete when:**
+
+- Tangle sandbox and CLI bridge pass the same required provider tests.
+- One additional provider, such as ComputeSDK, E2B, or Daytona, passes the minimum tests.
+- A policy that requires unsupported capabilities fails before dispatch.
+- A live session continues after coordinator restart without restarting the agent.
+- A delayed command from the old coordinator is rejected after ownership changes.
+- Orphaned provider resources are found and closed within the configured cleanup interval.
+
+## Phase 4: Secure Coordination MCP
+
+**Owner:** `agent-runtime`
+
+**Work:**
+
+- Make coordination MCP handlers call durable run commands.
+- Add short-lived run-scoped authentication.
+- Add request size, deadline, rate, and concurrency limits.
+- Reject non-loopback binding without authentication.
+- Emit structured action records with actor and command ids.
+
+**Complete when:**
+
+- Unauthenticated, expired, wrong-run, and wrong-actor calls are rejected.
+- Retried MCP tool calls return the original command result.
+- MCP server restart does not lose status or unread events.
+- A security review finds no path to steer another run.
+
+## Phase 5: Parallel Workspaces And Integration
+
+**Owners:** `agent-runtime`, provider packages
+
+**Work:**
+
+- Standardize isolated workspace creation and immutable result commits.
+- Record base and produced revisions on each invocation.
+- Add one integration-owner policy for merges.
+- Turn merge conflicts into explicit follow-up work.
+- Support shared writable workspaces only as an opt-in provider capability.
+
+**Complete when:**
+
+- Eight agents can edit in parallel without silent overwrite.
+- Replaying a completed invocation does not create a second commit.
+- A stale-base result is rejected or explicitly merged.
+- Every accepted coding result has passing deterministic checks and a durable revision.
+
+## Phase 6: Agent-Managed Scaling
+
+**Owners:** `agent-runtime`, provider packages
+
+**Work:**
+
+- Let the driver choose provider, model, profile, and child budget from declared capabilities and policy limits.
+- Add provider quotas, creation backoff, and per-run concurrency.
+- Support recursive sub-drivers under the same run ownership and budget.
+- Add compact durable driver state for long runs and fresh-context continuation.
+
+**Complete when:**
+
+- A driver can run 32 child invocations with a configured live cap of 8.
+- Recursive sub-drivers cannot exceed root budget, depth, or provider quota.
+- Provider failure redirects only when policy allows and does not duplicate accepted effects.
+- The coordinator stays responsive while all worker slots are occupied.
+
+## Phase 7: Evaluation And Knowledge Workloads
+
+**Owners:** `agent-eval`, `agent-bench`, `agent-knowledge`, `agent-runtime`
+
+**Work:**
+
+- Store run records in the shared `agent-eval` analysis format.
+- Add reusable distributed-recovery and multi-agent benchmark suites to `agent-bench`.
+- Add an `agent-knowledge` workload where agents ingest, repair, evaluate, and improve a knowledge base across resumable runs.
+- Compare dynamic allocation against equal-compute fixed policies.
+- Keep train and held-out evaluation data separate.
+
+**Complete when:**
+
+- Every benchmark reports task success, accepted output, child count, retries, duplicate suppression, tokens, cost, duration, provider placement, recovery count, and orphan count.
+- Dynamic allocation beats or matches the fixed equal-compute baseline on fresh tasks without worse reliability.
+- The knowledge workload improves held-out retrieval or answer metrics and records every knowledge mutation with provenance.
+- Null results are reported as open unless the experiment has enough power and isolates one mechanism.
+
+## Phase 8: Public Cleanup
+
+**Owner:** `agent-runtime`
+
+**Work:**
+
+- Remove deprecated wrappers after one release and migration window.
+- Shrink `/mcp` exports to supported agent-facing tools and configuration.
+- Keep persistence internals and transport helpers private.
+- Replace duplicate examples with one local example, one remote example, and one recovery example.
+- Update README, concepts, architecture, and generated API documentation.
+
+**Complete when:**
+
+- A new developer can choose the correct API from a two-row decision table.
+- The basic dynamic run fits in roughly 10 lines of application code.
+- No public entry point exposes internal journal, server, or sandbox batch construction for the common path.
+- Every shipped example runs in CI or is explicitly marked as a credentialed live test.
+
+## Recommended Merge Slices
+
+Each slice should be independently reviewable and revertible:
+
+1. shared run state types and in-memory adapter,
+2. transactional run store and ownership tests,
+3. provider-backed reconnectable executor,
+4. two-agent recovery path,
+5. durable coordination commands and events,
+6. authenticated MCP adapter,
+7. conversation policy migration,
+8. personified and agentic policy migration,
+9. workspace integration owner,
+10. live provider tests and `agent-bench` suites,
+11. public export cleanup.
+
+Do not combine storage recovery, public renames, and provider migration in one pull request.
diff --git a/docs/agent-managed-compute/validation.md b/docs/agent-managed-compute/validation.md
new file mode 100644
index 00000000..19db5c10
--- /dev/null
+++ b/docs/agent-managed-compute/validation.md
@@ -0,0 +1,214 @@
+# Validation Plan
+
+## Rule
+
+No distributed capability is complete because a unit test passed or a model printed a success message.
+
+Each claim requires a machine-checked run artifact containing the exact command, commit, package versions, provider, model, task, events, usage, result, and failure injections.
+
+## Layer 1: Contract Tests
+
+Run for every durable store:
+
+- conditional ownership claim,
+- ownership renewal and expiry,
+- stale-generation append rejection,
+- durable provider-command outbox replay,
+- monotonic revision,
+- duplicate command return,
+- duplicate event suppression,
+- conflicting terminal event rejection,
+- snapshot and replay equivalence,
+- retention without dangling private blobs.
+
+Run for every compute provider:
+
+- create and destroy,
+- idempotent create,
+- terminal event required,
+- abort propagation,
+- environment lookup,
+- session continuation when declared,
+- event replay from cursor when declared,
+- usage propagation,
+- workspace operations when declared,
+- capability mismatch rejection,
+- stale-generation provider command rejection when distributed steering is declared.
+
+## Layer 2: Two-Agent Recovery Test
+
+The primary scenario uses one driver and one worker.
+
+The worker edits a real repository fixture and must pass a deterministic test.
+
+The driver starts the worker, observes progress, sends two steering commands, and accepts only the checked commit.
+
+Run the scenario with coordinator termination at each point:
+
+1. before dispatch intent is recorded,
+2. after intent but before provider creation returns,
+3. after environment creation but before the reference is recorded,
+4. while the worker is running,
+5. after a steering command is recorded but before delivery,
+6. after the provider emits completion but before runtime acceptance,
+7. after acceptance but before the caller receives the result,
+8. during cancellation,
+9. while an old coordinator is partitioned and sends a delayed command after takeover.
+
+For each point, run 100 repetitions.
+
+Acceptance targets:
+
+- 900 of 900 runs complete or return the expected honest terminal failure.
+- Zero runs start duplicate physical work for one invocation id.
+- Zero runs accept two terminal results.
+- Zero acknowledged steering commands disappear.
+- Zero delayed stale-coordinator commands affect the provider after takeover.
+- Zero accepted workspace commits are duplicated.
+- Provider-reported tokens and cost differ from recorded totals by at most 1 percent.
+- All provider resources are gone or intentionally retained within the configured cleanup interval.
+
+## Layer 3: Event Disorder Test
+
+Inject 10,000 events with duplicates, delay, and reordering.
+
+The final state must equal the ordered reference execution.
+
+Test duplicate completion, completion after cancellation request, stale coordinator events, missing event ranges, and replay from an old cursor.
+
+Acceptance targets:
+
+- Zero duplicate side effects.
+- Zero invalid state transitions accepted.
+- Every missing event range causes replay or an explicit `lost` result.
+- Memory and queued bytes stay under configured limits.
+
+## Layer 4: Parallel Agent Test
+
+Run 32 child invocations with a live limit of 8 across at least two providers.
+
+Use isolated workspaces and one integration owner.
+
+Inject one provider outage, one coordinator restart, four worker cancellations, and duplicate completion delivery.
+
+Acceptance targets:
+
+- Live workers never exceed 8.
+- Root budget and provider quotas are never exceeded by new admissions.
+- All 32 invocations end in an explicit terminal state.
+- No workspace update is silently overwritten.
+- The coordinator answers status requests throughout the run.
+- No resources remain after cleanup.
+
+## Layer 5: MCP Security Test
+
+Test:
+
+- missing token,
+- expired token,
+- wrong audience,
+- wrong run,
+- wrong actor,
+- replayed command,
+- oversized request,
+- slow request body,
+- request flood,
+- non-loopback bind without authentication.
+
+Acceptance targets:
+
+- Every unauthorized action is rejected before handler execution.
+- Retried authorized commands are idempotent.
+- Audit records identify run, actor, action, and result without secrets.
+- Load limits preserve status and cancellation access for the run owner.
+
+## Layer 6: Live Provider Runs
+
+At minimum, run the same two-agent scenario on:
+
+1. Tangle sandbox provider,
+2. CLI bridge provider,
+3. one external provider implementation.
+
+These runs use real provider sessions and real model calls.
+
+No fake executor may satisfy this layer.
+
+Persist the raw run artifact and a summarized `agent-eval` record.
+
+## Layer 7: Workload Benchmarks
+
+`agent-bench` should own reusable suites for:
+
+| Suite | What it measures |
+|---|---|
+| deterministic repository repair | Basic delegation, steering, workspace integration, and checked completion |
+| HumanEval-style code tasks | Dynamic retry and allocation against equal-compute best-of-N |
+| Terminal-Bench tasks | Long-running tool use, environment recovery, and operational correctness |
+| long-horizon repository change | Fresh-context continuation, milestones, restart, and integration conflicts |
+| research synthesis | Parallel research, source quality, deduplication, and final synthesis |
+| knowledge-base improvement | Ingestion, claim validation, retrieval repair, freshness, and held-out answer quality |
+| memory from traces | Cross-run retention, relevance, contamination resistance, and transfer to fresh tasks |
+
+Every comparison uses the same task set, model access, token limit, dollar limit, time limit, and provider class.
+
+## Required Output Columns
+
+Every run row includes:
+
+- commit and package versions,
+- date and exact command,
+- task and split,
+- model and provider,
+- root policy,
+- actor profiles,
+- child count and recursion depth,
+- live concurrency,
+- dispatch retries,
+- duplicate commands and events suppressed,
+- coordinator restarts,
+- provider reconnects,
+- cancellations requested and confirmed,
+- accepted output and deterministic check result,
+- input, output, and reasoning tokens when available,
+- cost,
+- wall time,
+- MCP action count and latency,
+- run-store append latency,
+- workspace conflicts,
+- orphan resources,
+- terminal reason.
+
+Report per-run rows plus minimum, median, p90, p95, p99, and maximum for numeric fields.
+
+## Performance Targets
+
+Measure runtime overhead separately from model and provider time.
+
+Initial acceptance targets:
+
+- Local coordination command p95 under 50 ms at 100 requests per second.
+- Durable append p95 under 100 ms on the selected production store.
+- Runtime coordination overhead below 5 percent of total wall time on long model-backed tasks.
+- Status read p95 under 250 ms with 1,000 active runs.
+- Recovery begins within two ownership intervals after coordinator loss.
+
+These are starting service targets, not benchmark results.
+
+They must be revised from measured production-like runs.
+
+## Promotion Decision
+
+Ship the distributed path only when:
+
+1. all deterministic failure tests pass,
+2. all required providers pass conformance,
+3. all three live provider runs produce retained artifacts,
+4. security tests pass,
+5. dynamic allocation does not regress checked task success or reliability against equal compute,
+6. fresh held-out tasks confirm any claimed quality improvement,
+7. the old local path remains available until migration evidence is complete.
+
+A failed or underpowered benchmark remains open work.
+
+It is not evidence that agent-managed compute is ineffective.
diff --git a/docs/architecture.md b/docs/architecture.md
index 3f14fdff..9b78abba 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -68,7 +68,8 @@ at each step it **makes a decision** — keep working · branch · split · get
 opinion · run a check · stop — and acts on it (§0.5.1). The decision that *grows the
 tree* is `spawn`, carried over **MCP**: it creates a **child agent** (its own profile
 + harness, its own `Scope`). The child runs its own agentic process; the parent
-**observes / steers / resumes** it through the same MCP, in **natural language**.
+**observes / steers** it through the same MCP, in **natural language**, while the
+coordinator is alive.
 Spawn is one move among several, so topology is not an opcode set — it **emerges** from
 the decisions:
 
@@ -79,8 +80,9 @@ coordinator     = spawn N, steer, select
 driver-of-driver = a child whose profile is itself a coordinator — free, by recursion
 ```
 
-`Scope.spawn` is the recursive boundary; the journal makes the tree replayable and
-resumable. **This recursive execution tree IS the product.** The three things we own
+`Scope.spawn` is the recursive boundary; the journal makes completed settlements replayable.
+Live supervised-tree resume after coordinator restart is not implemented.
+**This recursive execution tree IS the product.** The three things we own
 are small: (1) the **MCP** the agents share (`spawn · observe · steer · stop` +
 `define_check · run_check`); (2) the **profiles** (markdown — the only customization;
 "Drew" is one); (3) the **orchestrator** (`src/runtime/supervise/` — `Scope` + the
diff --git a/docs/canonical-api.md b/docs/canonical-api.md
index 2edb4355..00489ddf 100644
--- a/docs/canonical-api.md
+++ b/docs/canonical-api.md
@@ -17,7 +17,7 @@
 > - **combinator** — a reusable topology shape (`loopUntil` = depth/refine, `fanout` = breadth/sample) you compose instead of hand-writing a loop.
 > - **holdout** — fresh problems held back from tuning, so a measured win can't be memorization.
 
-A **genome** (an `AgentProfile`: `systemPrompt + skills + tools + mcp + knowledge + memory + rag` — one combined surface) is run as a **driver⟷worker conversation** (`runPersonified` composing a combinator like `loopUntil`/`fanout` over the keystone `Supervisor` — K rounds spent against one persistent, journaled, resumable artifact on a *conserved budget pool* so equal-compute holds by construction) over a **benchmark** (the `ADAPTERS` registry driven by `runGate` over the Supervisor, or an `AgenticSurface` driven by `runBenchmark`/`runAgentic`), then **optimized by a gated loop** (`selfImprove`/`runImprovementLoop` + `gepaProposer`, certified by `defaultProductionGate`/`heldOutGate`/`promotionGate`, or the full multi-generation `runStrategyEvolution`) that evolves the genome and **certifies wins on a frozen holdout** — never on the training composite. The selector is never the judge; observation attaches to the *loop* via `RuntimeHooks`, never to the portable genome.
+A **genome** (an `AgentProfile`: `systemPrompt + skills + tools + mcp + knowledge + memory + rag` — one combined surface) is run as a **driver⟷worker conversation** (`runPersonified` composing a combinator like `loopUntil`/`fanout` over the keystone `Supervisor` — K rounds spent against one persistent, journaled artifact on a *conserved budget pool* so equal-compute holds by construction) over a **benchmark** (the `ADAPTERS` registry driven by `runGate` over the Supervisor, or an `AgenticSurface` driven by `runBenchmark`/`runAgentic`), then **optimized by a gated loop** (`selfImprove`/`runImprovementLoop` + `gepaProposer`, certified by `defaultProductionGate`/`heldOutGate`/`promotionGate`, or the full multi-generation `runStrategyEvolution`) that evolves the genome and **certifies wins on a frozen holdout** — never on the training composite. The selector is never the judge; observation attaches to the *loop* via `RuntimeHooks`, never to the portable genome. The current `Supervisor` records completed settlements but does not resume a live tree after coordinator restart.
 
 Two substrates implement the same recursive-atom over the one `Executor` port and share `defaultSelectWinner` — a deliberate pair, **do not invent a third**: the **reactive** `Supervisor`/`Scope` + personify combinators (the agent-driver; equal-k by construction via the conserved budget pool — prefer for NEW recursive/keystone work) and the round-synchronous **`runLoop`** kernel (the leaf; what most sandbox benches drive today). `inlineSandboxClient` adapts any non-box `Executor` into a `SandboxClient` for `runLoop`, and `settledToIteration` bridges reactive `Settled`s into the kernel's `Iteration`, so the two interoperate without forking selection or metering.
 
@@ -107,7 +107,7 @@ A general "loop" primitive is the single most common modelling error in this rep
 | State any benchmark/A-B claim | `pairedLift(...)` (bench) over `pairedBootstrap`/`heldoutSignificance` (substrate) | your own bootstrap loop/PRNG per gate; a point lift without `low/high/pairs` |
 | Let an agent **delegate ONE generic INTENT** (no fixed coder/researcher type) and get the result + real spend SYNCHRONOUSLY | the **`delegate` tool** — `createDelegateHandler` via `createMcpServer({ delegateSupervisor })`; mount it over the `agent-runtime mcp` bin with `MCP_ENABLE_DELEGATE=1` (the bin authors a supervisor over a `sandbox` backend) — `/mcp` | a hardcoded coder/researcher profile, or task-specific `delegate_code`/`delegate_research` verbs (RETIRED) — `delegate` is the ONE delegation path and the only one with a cost channel |
 | Run a coding task INSIDE the agent's OWN sandbox session (a sibling box, fresh branch, validated patch) | `detachedSessionDelegate({ sandboxClient \| executor, workerProfile? })` — `/mcp` (pass the worker `AgentProfile`; omit for a minimal model-only default) | a hardcoded coder profile baked into the delegate; `delegate()` (that spawns workers in a *chosen* backend, not the agent's own session) |
-| Have a **supervisor spawn + live-drive workers in a backend you choose** and observe/steer/resume them | the **coordination MCP** — `createCoordinationTools` / `serveCoordinationMcp` over a live `Scope`; each worker's leaf is `createExecutor({ backend })` — `/mcp`,`/loops` | `detachedSessionDelegate` — own-sandbox-session only, one-shot, no live steer/recursion/conserved-budget |
+| Have a **supervisor spawn + live-drive workers in a backend you choose** and observe or steer them while the coordinator is alive | the **coordination MCP** via `createCoordinationTools` / `serveCoordinationMcp` over a live `Scope`; each worker's leaf is `createExecutor({ backend })` | `detachedSessionDelegate`, which is own-sandbox-session only and one-shot. Supervised-tree restart recovery is not implemented. |
 | Stand up a vertical agent in the eval loop | `defineAgent(manifest)` + `createSurfaceImprovementAdapter` — `/agent` | a per-vertical manifest parser, surface-validator, or bespoke `ImprovementAdapter` |
 | Observe + deliver Intelligence on a live agent (send RunRecords + receive certified profile/diffs) | `withIntelligence(agent, { project, target })` — `/intelligence` (proposals surfaced, never auto-applied; `effort: 'off'` proves inference-only billing) | a custom trace-wrapper, a second receive path, or hand-rolled effort/tier config |
 | Turn trace evidence into one measured, review-only agent proposal | `proposeAgentImprovement({ analysis, profile, improvement })` — `/intelligence` | manually joining analysts, optimizers, evidence, uncertainty, and candidate identity |
diff --git a/docs/research/README.md b/docs/research/README.md
index cbe5a8a7..e1065666 100644
--- a/docs/research/README.md
+++ b/docs/research/README.md
@@ -8,21 +8,23 @@ is NOT canonical** — on any architecture conflict `../architecture.md` wins, a
 science state (every measured result, the current goal) is `.evolve/current.json`, not here.
 Promotions into the spine happen explicitly, with `file:line` anchors, once a design ships.
 
-**Start here:** [`rsi-atom-masterplan.md`](./rsi-atom-masterplan.md) is the single source of
-truth for the decided architecture + the build tracker; `.evolve/current.json` is the live
-evidence ledger.
+**Start here:** [`../agent-managed-compute/README.md`](../agent-managed-compute/README.md) is
+the active audit and implementation plan for distributed execution, recovery, provider-backed
+workers, and run-API convergence.
+`.evolve/current.json` remains the live evidence ledger for experiments.
+The research files below are source history and focused design inputs, not competing build plans.
 
 ## Live docs
 
 | Doc | What it holds |
 |-----|---------------|
-| [rsi-atom-masterplan.md](./rsi-atom-masterplan.md) | **SSOT.** The decided self-designing-atom architecture + the checklist to a clean, deduplicated, properly-layered build; every item names its file + the gate that proves it. |
+| [rsi-atom-masterplan.md](./rsi-atom-masterplan.md) | Historical self-designing-atom plan. Distributed execution work is superseded by `agent-managed-compute/`. |
 | [optimization-space.md](./optimization-space.md) | The 6-axis optimization taxonomy + canon-compatibility audit (the portfolio map the canonical spine references). Per-layer evidence now lives in `.evolve/current.json`. |
 | [leapfrog-program.md](./leapfrog-program.md) | The research program's honest formal core (v2 — breakthrough framing retracted; what survived). |
 | [belief-state-learner-spec.md](./belief-state-learner-spec.md) | **Gated (BUILD-ON-GREEN).** The belief-state / program-synthesis learner spec — its design, not a build order; waits on a positive deployable-selector gate. |
 | [belief-agent-research-agenda.md](./belief-agent-research-agenda.md) | **Gated.** Research agenda for the recursive/belief-state agent (7 lenses → ranked agenda), grounded against the gate result. |
 | [harness-compat.md](./harness-compat.md) | Harness × capability matrix — what a driver can actually steer per harness. |
-| [long-horizon-agent-map.md](./long-horizon-agent-map.md) | The long-horizon steered-agent product — map + decisions. |
+| [long-horizon-agent-map.md](./long-horizon-agent-map.md) | Historical long-horizon product map and design input. |
 | [atom-compression-plan.md](./atom-compression-plan.md) | The self-designing atom's cut-list + build-list (feeds the deep-clean). |
 | [loop-facade-postmortem.md](./loop-facade-postmortem.md) | **Active guardrail.** Failure record for the deleted `defineLoop` facade + the prevention rule. |
 | [environment-provider-adapter-spec.md](./environment-provider-adapter-spec.md) | Generic environment provider adapter spec: what to lift from sandbox SDK, cli-bridge, runtime routing, and profile execution so third-party compute/sandbox providers can plug in. |
diff --git a/docs/research/interactive-sessions-spec.md b/docs/research/interactive-sessions-spec.md
index 844bbf8a..ab5dca9d 100644
--- a/docs/research/interactive-sessions-spec.md
+++ b/docs/research/interactive-sessions-spec.md
@@ -1,8 +1,14 @@
 # Spec — interactive (tmux) harness sessions + live streaming
 
+> Historical design input.
+> Current distributed readiness, security, recovery, and implementation order live in [`../agent-managed-compute/`](../agent-managed-compute/).
+> Checked items below record earlier experiments and are not current acceptance evidence.
+
 **Vision (one sentence):** instead of headless one-shot CLI calls, each agent in a supervised run is a **live, interactive harness session in its own tmux window** (driveable, observable, resumable), the whole agent tree is one tmux session, and it streams to a browser — composing with the recorded animated replay.
 
-**Why now:** the whole real chain already delivers — an opencode supervisor drives opencode workers via the coordination MCP, a real deployable check gates delivery (`bench/src/atom-mcp-e2e.mts`, `972707f`). What's missing is (a) the agents run *headless* (one prompt → output), so you can't watch or interact, and (b) the harness-specific glue lives in a bench script, not the substrate. This spec turns both into a real, generalized capability.
+**Prior experiment:** an opencode supervisor drove opencode workers through the coordination MCP in `bench/src/atom-mcp-e2e.mts` at `972707f`.
+That script is stale and is not a current distributed acceptance test.
+The durable two-agent recovery run in `agent-managed-compute/validation.md` is the replacement.
 
 ## Placement — who owns what (obeys the AgentProfile law + the layering)
 
@@ -10,7 +16,7 @@ The law: *an agent IS its AgentProfile; you change behavior by authoring the pro
 
 | Layer | Owns | Why |
 |---|---|---|
-| **agent-runtime** (this repo) | The **recursion + the ports**: the coordination MCP over the Scope (`serveCoordinationMcp`, done), a generic **`session` Executor** that opens/drives/observes a session via the substrate's API (NOT tmux-aware), the shared `Workspace` seam, the journal→replay. | The runtime stays harness-agnostic. It drives; it never spawns tmux or knows what opencode is. |
+| **agent-runtime** (this repo) | The recursion and ports: the coordination MCP over the `Scope`, the existing provider-backed `Executor`, the shared `Workspace` contract, and completed-tree replay. Durable coordinator recovery is still missing. | The runtime stays agent-runner-agnostic. It drives; it never spawns tmux or knows what opencode is. |
 | **agent-dev-container** (adc) | The **materialization**: given an `AgentProfile` + cwd + mcp config, stand up the harness as an **interactive tmux window** (the TUI, not `run`), materialize the FULL profile (skills as real SKILL.md files, tools, model, mcp), capture (`pipe-pane`) + stream (`ttyd`). Exposes a **session API** (create / send / observe / status / kill). | "the container where the agents actually live" — Drew. This is the harness-specific layer; it belongs in the substrate, never the runtime. |
 | **cli-bridge** | Stays the *headless* harness materializer (the test target + the fast path). Optionally grows the same session API for local runs. | Already proven; the adc is the richer/interactive home. |
 | **sandbox SDK** | The `AgentProfile` manifest + box abstraction the adc is a flavor of. | Where the profile shape + `resources.skills` materialization already live. |
@@ -67,9 +73,11 @@ The law: *an agent IS its AgentProfile; you change behavior by authoring the pro
 ## Open design points (decide during Phase 2–4)
 - **Interactive vs headless harness mode:** does opencode/claude-code expose a driveable interactive TUI, or do we run `run` *inside* the pane for the live-output view? (Headless-in-a-pane is the cheap first cut; true interactive is the goal.)
 - **Completion detection** in a TUI (sentinel vs a harness done event).
-- **Session lifecycle:** resume after a crash (the journal already supports replay/resume — extend to sessions).
+- **Session lifecycle:** reconnect after a crash requires durable coordinator recovery plus provider session replay. Completed-tree replay alone is insufficient.
 - **Security:** ttyd exposure + the coordination MCP exposure (bind localhost / authd tunnel).
 - **Concurrency:** N agents = N windows; the adc's resource limits.
 
 ## Net
-The runtime is essentially done for this (coordination MCP + the executor port + replay). The new work is a **substrate capability in the adc** (interactive tmux sessions + full-profile materialization + ttyd), reached through one small session API and one generic `session` executor in the runtime. Nothing here specializes the runtime to a harness.
+The runtime has the coordination MCP, execution port, environment-provider adapter, and completed-tree replay.
+It still needs durable coordinator recovery and secure remote MCP access.
+Interactive tmux materialization remains an agent-dev-container capability reached through the provider contract.
diff --git a/docs/research/long-horizon-agent-map.md b/docs/research/long-horizon-agent-map.md
index 4a126294..7b402775 100644
--- a/docs/research/long-horizon-agent-map.md
+++ b/docs/research/long-horizon-agent-map.md
@@ -1,5 +1,8 @@
 # The long-horizon steered-agent product — map + decisions
 
+> Historical design input.
+> Current distributed execution decisions and implementation order live in [`../agent-managed-compute/`](../agent-managed-compute/).
+
 > Direction capture (2026-06-15). The product: an **autonomous supervisor agent** that decomposes a goal, drives a dynamically growing/shrinking tree of AgentProfile-drivers + workers (each in a sandbox, each possibly a different profile) to completion, and learns which decisions worked across runs — so the human isn't the steerer. Companion to [architecture.md](../architecture.md), [harness-compat.md](./harness-compat.md). Sources: 3 research tracks (harness-compat, Foreman post-mortem, surface audit).
 
 ## The corrected mental model (read first)
diff --git a/docs/research/rsi-atom-masterplan.md b/docs/research/rsi-atom-masterplan.md
index 85164b1f..73cb9676 100644
--- a/docs/research/rsi-atom-masterplan.md
+++ b/docs/research/rsi-atom-masterplan.md
@@ -1,5 +1,8 @@
 # RSI self-designing agent atom — masterplan + build tracker
 
+> Historical design input.
+> Current distributed execution decisions and implementation order live in [`../agent-managed-compute/`](../agent-managed-compute/).
+
 > **Single source of truth** for the architecture decided across the 2026-06-15 design session and the systematic checklist to a clean, deduplicated, properly-layered 11/10. Subsumes and links the supporting docs. Status legend: ✅ done · 🔨 building · ⬜ todo · ⏸ deferred (gated). Every item names its file + the gate that proves it.
 
 ## 0. The one-sentence architecture
diff --git a/docs/research/smart-loops-context-lifecycle.md b/docs/research/smart-loops-context-lifecycle.md
index 15fa9285..2a02eee2 100644
--- a/docs/research/smart-loops-context-lifecycle.md
+++ b/docs/research/smart-loops-context-lifecycle.md
@@ -69,7 +69,7 @@ run the agents over them.
 
 | Need | We already have |
 |---|---|
-| externalized, replayable tracking state | `Scope`/`Supervisor` **journal** (append-only, replay/resume) |
+| externalized, replayable completed decisions | `Scope`/`Supervisor` journal. Coordinator restart recovery is still missing. |
 | cross-chapter / cross-run memory | the **`Corpus`** primitive |
 | the tracking/knowledge documents themselves | **agent-knowledge** (the KB *is* the external memory) |
 | a chapter-close (distilled transfer brief) | the **`handoff`** skill; harness **context compaction** |
diff --git a/src/durable/spawn-journal.ts b/src/durable/spawn-journal.ts
index 742d999c..a8710920 100644
--- a/src/durable/spawn-journal.ts
+++ b/src/durable/spawn-journal.ts
@@ -376,10 +376,10 @@ function replayHandle(id: NodeId, label: string, status: NodeStatus) {
 }
 
 /**
- * Materialize the live tree (`TreeView`) from a journaled event list for resume. Folds
+ * Materialize a recorded `TreeView` from a journaled event list for inspection. Folds
  * `spawned`/`settled`/`cancelled` into a per-node snapshot in `seq` order, then adds each
- * `metered` event's driver-inference spend onto its node in a separate additive pass — so the
- * resumed view matches what `scope.view` showed at the recorded cursor position.
+ * `metered` event's driver-inference spend onto its node in a separate additive pass so the view
+ * matches the recorded cursor. It does not recover live executors or driver state after restart.
  */
 export function materializeTreeView(events: SpawnEvent[]): TreeView {
   const nodes = new Map<NodeId, MutableSnapshot>()
diff --git a/src/runtime/supervise/types.ts b/src/runtime/supervise/types.ts
index 489026ca..f29008eb 100644
--- a/src/runtime/supervise/types.ts
+++ b/src/runtime/supervise/types.ts
@@ -411,8 +411,8 @@ export type SpawnEvent =
 
 /**
  * The spawn-tree event source (mirrors `ConversationJournal`'s begin/append/load shape).
- * `loadTree` replays the full ordered event list for resume/replay; `appendEvent` is
- * called only AFTER the event is observed-committed (never speculative).
+ * `loadTree` returns events for inspection and completed-settlement replay, not live process
+ * recovery; `appendEvent` runs only AFTER the event is observed-committed (never speculative).
  */
 export interface SpawnJournal {
   loadTree(root: NodeId): Promise<SpawnEvent[] | undefined>