supervise: a re-prompted provider root gets a new environment at turn 0, then is told not to repeat work it has no memory of

[drewstone]

repromptOnUnmet and the provider execution path disagree about what a re-prompt is. For a bridge-placed root the disagreement is masked. For a provider-placed root it silently destroys the run's continuity.

The two halves

Half one — the re-prompt believes it is continuing a session. supervisor-agent.ts:479:

A re-prompt reuses the retry path: same scope, same coordination server, same live children, same budget/deadline/abort/attempt bounds.

driver-retry.ts:44:

reprompt.maxReprompts re-enters the SAME live session with the unmet items

and DriverRetryRun.drive:

reentry is present only for a re-prompt: run the SAME session on reentry.steer instead of the original task.

defaultUnmetContractSteer is written for that reader. Its last line is:

Do not restate work you already did.

Half two — the provider path mints a new execution. retained-scope-owner.ts:63:

return `${args.nodeId}:input:${state.inputSequence}`

inputSequence is the seq of the latest execution-input, and a re-prompt writes a new one. So executionId changes per re-prompt, and environment-provider.ts derives the create key and the turn id from it:

idempotencyKey: `runtime:${args.executionId}`,
turn: { ...turn, turnId: `${args.executionId}:turn:0` },

A new idempotency key is a new environment. Every re-prompt therefore starts a fresh sandbox at turn 0, with no conversation history, and the steer tells that fresh agent not to repeat work it has no record of doing.

The bridge backend does not have this problem: supervise.ts:1591 says it "reattaches the harness session by its durable execution id."

Measured

mech-interp-foundations-pi-20260915k, a sandbox-placed root on 0.225.6, four attempts, from its spawn journal:

intent key: runtime:...-20260915k:input:1   turnId ...:input:1:turn:0   sandbox-9ce8df04513b
intent key: runtime:...-20260915k:input:6   turnId ...:input:6:turn:0   sandbox-2689acf486c6
intent key: runtime:...-20260915k:input:11  turnId ...:input:11:turn:0  sandbox-1570fa62f005
intent key: runtime:...-20260915k:input:16  turnId ...:input:16:turn:0  (no environment issued)

Three complete turns, three different sandboxes, every one at turn:0. Receipt and journal: discovery-lab#767.

The provider is not the limitation. @tangle-network/agent-provider-tangle declares retainedControl, and environment-provider.ts:1197 takes the retained path when it is present. The retained path still creates, because the key it creates under is new.

Why this matters beyond one run

In the pursuit that produced this run, every one of its 595 knowledge pages came from a bridge-placed root, which keeps its session across turns. A fleet-placed root has produced zero pages across fourteen presses. Each of those presses was previously attributed to an infrastructure failure; this is the structural reason underneath.

The failure is also invisible from the outside. The run does not error. It completes turns, spends tokens, and settles no-winner, which reads as a research result rather than a lost session.

What a fix has to decide

Either:

1. A re-prompt reuses the committed execution id, so the provider reconnects to the retained run and the conversation continues. That matches every doc comment quoted above and makes the steer's last line true.
2. A re-prompt is defined as a new execution, in which case defaultUnmetContractSteer must carry forward what the previous turn did, and the doc comments claiming the same session should be corrected.

Option 1 looks right to me because the retained-control machinery already exists and the bridge path already behaves this way, but the choice belongs to this repo.

Adjacent, same root

repromptOnUnmet with a provider backend also multiplies environments: three turns created three sandboxes. Under any per-account concurrency limit each re-prompt competes for a slot with its own predecessors' teardown.

[drewstone]

Owner implementation is in progress as one Runtime change. The required identity split is: keep the environment and conversation session across deliberate re-prompts, mint a fresh execution and turn for new work, and preserve both on a retry. Reusing the prior execution ID would replay its completed result instead of continuing the conversation. The existing retained provider API supports this; no Sandbox or Discovery runner replacement is planned. Local regression now completes three manager turns in one environment/session with three distinct executions, consumes the final submission, and verifies release, keep, and failed-cleanup outcomes. Controller recovery during the second turn and independent review remain in progress. This issue stays open until delivery and live cloud proof.

[drewstone]

Confirmed on a second run (mech-interp-foundations-pi-20260915l, discovery-lab#773): three re-prompts, three fresh sandboxes, every intent at turn:0. Six re-prompted turns across two runs, six fresh conversations, zero pages.

Working out option 1 concretely, since it is the one every doc comment already promises. It has two halves and the provider half has no implementation yet.

Runtime half

retained-scope-owner.ts prepareScopeRetainedOwnerTask clears the owner state after an accepted result ("A deliberate later drive starts a distinct invocation after an accepted result") and mints a new execution-input, which is what changes executionId and therefore the create key. A re-prompt reaches that function through driveHarnessFromBackend in supervise.ts:795, which cannot tell a re-prompt from a fresh drive because DriveHarness does not receive reentry (supervisor-agent.ts:1019 passes only reentry.steer as task).

So: thread reentry through DriveHarness; when present and the backend is a provider, do not clear the owner state and do not append an execution-input. Keep the committed executionId and its dispatched admission. Then in environment-provider.ts providerExecutionSource, when the retention context is continuing and a dispatched controlRef exists, reconnectRetainedRun and call handle.continueNative(request, { turn }) with the steer, instead of startRetainedRun. The turn id becomes ${executionId}:turn:${n} rather than turn:0.

Provider half (agent-sdk, agent-provider-tangle)

continueNative is not implemented, and tangle-capabilities.ts:517 unconditionally deletes the nativeContinuation capability, so retained-run-handle.ts:182 would refuse the runtime's call today with "does not support retry-safe native continuation".

The primitive exists. Sandbox SDK 0.39.2 Session.prompt(message, { sessionId }) is documented as "Continue this session with an additional prompt", and the sidecar keeps the conversation. The only other provider that implements this, agent-provider-cli-bridge/src/retained-native.ts, is the template:

• contextBoundary(): a NativeContextBoundaryProof for the current run. For Tangle the messages kind fits: session.messages() returns ids, digest them, bind to the controlRef.
• continueNative(request, options): verify request.run matches the active controlRef and request.turnDigest matches nativeContextContinuationTurnDigest(options.turn); call session.prompt(turn, { sessionId }); the result's executionId is the new run; return { result, controlRef } and record usage on the usage log, exactly as the bridge does.
• Capabilities: stop deleting nativeContinuation when retainedControl is supported; declare { atomicBoundary: true, requestIdempotency: true } and gate admissionControl on whether dispatch is available. sessions.continue is already declared true under retained control.

The provider testkit has a conformance suite for this (agent-provider-testkit/src/portable-context-conformance.ts), so the provider side can be proven without a sandbox.

What option 1 buys over environment reuse

Reusing the environment with a fresh chat keeps the files but not the conversation. The steer's last line, "Do not restate work you already did", is still addressed to an agent with no record of that work. Option 1 makes that line true.

I can take the provider half; it is independent of whichever session lands the runtime half, and the conformance suite proves it in isolation.

[drewstone]

Provider half is up: tangle-network/agent-sdk#336. contextBoundary + continueNative on the retained Tangle session, capability declared with retained control, contract proven offline (boundary mismatch dispatches nothing; accepted dispatches once under the operation id; replay dispatches nothing and returns the same result and control reference; changed turn conflicts; foreign run refused). The runtime half described above is what remains.

[drewstone]

Delivery update, 2026-09-16 05:09Z: continuity repair #1255 merged at da3a6fd. Runtime 0.231.1 is published from main/tag 449fd3b through Publish 35056798780. Downloaded public archive SHA256 c26c86b9cda63bce72c360af147ddc5462e6694f3f1c1f52ce5157d42f5186c7 matches the exact release artifact. Integrated local tree: 4038 tests passed, 11 skipped; focused continuity/integration suite 303 passed. Contract: preserve environment and native conversation across deliberate re-prompts; mint a distinct execution/turn for new work; retain that exact execution/turn for retries and recovery. Reusing the old completed execution identity would replay its result, not continue the conversation. This uses existing retained-session admission. The cloud candidate is installed, but live continuity is NOT yet proved. First attempt failed before provider/model execution because its saved preview route no longer existed; immutable failure is retained. Same-route reconciliation now passes authenticated tools/list and read_journal with missing/invalid credentials rejected, zero inference. A separate immutable successor is being prepared under the original tiny budget. This issue remains open for the actual cloud continuation and controller-interruption proof; package publication alone does not close it.

[drewstone]

Retracting my read from earlier tonight. I said #1255 reused the environment but not the conversation; the code says otherwise and I should have followed it further before posting.

What settles it, on main at 449fd3b:

• environment-provider.ts builds the re-prompt material with identity: { sessionId: priorSession.sessionId, executionId: mintRetainedIdentity(environmentKey, turnId).executionId }.
• retained-run-start.ts dispatchRetainedRun sends sessionId: identity.sessionId to the provider dispatch.
• The Tangle provider forwards that to dispatchPrompt, and the Sandbox SDK documents a prompt with sessionId as continuing that session's conversation.
• supervise-retained-owner-recovery.test.ts asserts new Set(turns.map(t => t.sessionId)).size === 1 across three consecutive re-prompts, one create.

So the turn:0 suffix I flagged is the runtime's turn-id namespace, not a fresh chat. The before-picture from run l (0.225.6) is what I was describing: three turns, three session ids, three sandboxes. #1255 collapses that to one session in one sandbox. That is the conversation continuity this issue asked for, and it does not need continueNative to get there; the retained-session admission path already carries the chat.

The startRetainedRunInEnvironment docstring ("does not append to a prior harness chat") describes that one function's own guarantee, not what the caller achieves by passing the session id. I read the docstring and stopped.

What stays true from my earlier comment: continueNative is now implemented on the provider (agent-sdk#336, published in 1.4.0) and offers a verified boundary check plus retry-safe replay that the session-id path does not. Whether the runtime should adopt it is now an improvement question, not a correctness one, and the owner's call.

Agree with the delivery update that this stays open until a cloud run shows a second turn continuing the first. discovery-lab master now pins runtime 0.231.1 and provider 1.4.0, so the next press on the mech-interp pi record is that proof. I will run it and post the journal here.

[drewstone]

Runtime delivery update 2026-09-16 06:30Z: #1260 merged602e4fbd7ccb949588f1aadcb2de47cd69ca8528 and published as0.232.0 through successful Publish35063076617. Public npm archive SHA25664d6a93ad688b6af13fd9adf16b3ee16e94b3c7e06d882a6f45b5736a442649c matches the release artifact byte-for-byte; maintained conformance verification passed and registry provenance identifies the same source/run. This includes #1257/#1258 and the existing native continuity repair. New behavior: successful incomplete turns do not consume failure retries; repromptOnUnmet:"until-complete" requires completion check plus finite positive deadline. Provider admission errors survive accounting refusal as terminal errors, preserving unknown dollars without enabling retries. Final integrated local coverage323 tests plus type/lint/docs/packed-package checks; independent reviews clear. This issue remains OPEN: tiny cloud r2 passed authenticated coordination but failed before inference at the separate Sandbox selected-model credential boundary. Its original provider cause is now attributed; that one shared credential fix is under ADC delivery ownership. Next press remains same Pi/Flash cloud route on immutable successor input; no wrapper or transport switch. Six-hour research acceptance requires actual child consumption, continuation, interruption recovery, shared-memory handoff, trace readback, and truthful cost—not publication alone.

[drewstone]

Cloud proof, 2026-09-16 07:21Z–07:55Z, runtime 0.233.0 / provider 1.4.0, run mech-interp-foundations-pi-20260916m (fleet-placed root, placement.sandbox only, GLM director on pi).

Before (#1255 absent, runs k and l on 0.225.6): three re-prompted turns, three sandboxes, three session ids each.

After (#1255 in 0.233.0), from the spawn journal:

input	admitted	environment	session	execution
seq 1	07:21:45Z	sandbox-074c23f428ba	retained-session-63f40c2eac0	retained-execution-63f40c2eac0
seq 6	07:36:52Z	sandbox-074c23f428ba	retained-session-63f40c2eac0	retained-execution-90013a1b8ef

Seq 1 bound known at 07:36:52Z (144,190 in / 30,418 out).
Seq 6 dispatched at 07:36:56Z into the same session and sandbox and ran 18m45s: 34 tool calls, 27 results, 35,992 stream events, no sequence break.
Turn 2's first tool result listed a directory turn 1 had created at 07:31:47Z, so the continued session saw turn-1 state.

Correcting my note from earlier tonight in the other direction too: I briefly believed the runtime hung in handle.result() on a failed sandbox. It did not. The platform reported the sandbox failed at 07:53:35Z while it was still executing (it called coordination at 07:54:48Z). I cancelled on that status; the runtime acknowledged the durable cancel in 5 s and tore down cleanly. The false status is filed on agent-dev-container; nothing here is a runtime defect.

Closing as fixed by #1255, verified on the fleet. Run n (same record) is running now to take the continued session to settlement; its receipt will land in discovery-lab.