Worker resume: the activity loop continues the worker it dispatched, keeping its identity

[m2ux]

Summary

When a worker stops at a gate and the user answers it, the client activity loop goes back to the top and dispatches again. Dispatching mints a fresh worker identity, so the worker that is still sitting there holding the whole activity is handed a new name — and the server, which keys its delivery ledger on that name, sees a context it has never met and sends the activity a second time. This change gives the loop a step that continues the worker it already has, under the identity that worker was dispatched with.

What happens today

03-dispatch-client-workflow.yaml drives a client workflow from one while loop. The body binds dispatch-activity, then — when the worker yielded — present-checkpoint-to-user and respond-checkpoint, and finally, only when the worker reported the activity finished, commits and advances the activity pointer. A gate leaves the pointer where it was, so the loop condition still holds and the next iteration starts where every iteration starts: at dispatch-activity.

That operation mints a worker agent_id inside its Protocol, one per dispatch. Entering it again after a gate therefore mints a second one for a worker that is still alive.

There was no step in the loop that resumed a worker, and no declared value anywhere carrying the identity a dispatch had bound — so nothing downstream could have re-bound it even if it had tried. The one place stating the invariant is harness-compat::continue-agent's resume-preserves-delivery-scope rule, and nothing on the gate path reaches it. workflow-orchestrator said "resume the worker with resolved effects", naming a resume that had no operation behind it.

That is a critical constraint carried by rule text on a path that never reads it — what the catalogue calls structure-backed-constraints, framed by Encode Constraints as Structure.

The fix

The identity becomes a declared value. dispatch-activity declares worker_agent_id on its Outputs: the server-side identity this dispatch bound, held by the worker until it reports the activity complete. Being declared, it lands in the bag and later steps can bind it.

The gate path gets an operation. workflow-engine::resume-worker continues the worker already holding the activity — it composes the continuation stub under the bound worker_agent_id and applies harness-compat::continue-agent, returning the worker's next envelope unchanged. It mirrors dispatch-activity's shape, so the loop reads as spawn-or-resume.

One home for identity binding. compose-prompt accepts workflow-engine::resume-from-checkpoint as a third agent technique, with its own entry-tool line, rather than a second stub assembler that could drift from the first.

Re-dispatch becomes impossible while a worker holds the activity. In the loop, dispatch-activity is gated on no identity being held, a resume-yielded-worker step binds resume-worker after the checkpoint is answered, and the advance step releases the identity when the worker finishes. A worker that gates twice takes present → respond → resume twice, under one identity, and the loop returns to dispatch-activity only once the activity is done.

Scope of change

Five files under meta/: the client dispatch activity, the new resume-worker operation, and prose plus contract edits on dispatch-activity, compose-prompt, and workflow-orchestrator. No other workflow is touched.

Acceptance criteria

• A resumed worker carries the server-side identity its dispatch bound.
• The loop cannot dispatch a second worker for an activity a live worker is holding.
• Identity binding for spawn and continuation stubs has a single home.
• All 21 repository guards pass, including binding fidelity, when-expression parsing, and the technique template.

Non-goals

• Threading the harness-level agent handle through the bag. continue-agent resolves it as it does today; the identity at issue here is the server-side one the ledger is keyed on.
• Worker failure handling. Worker death is rare, externally caused, and already covered by the existing replacement path.

Investigation detail

Where the identity is lost, the alternatives weighed, and the mapping onto the issue's criteria:
.engineering/artifacts/planning/2026-08-03-resume-preserves-delivery-identity

Server-side counterpart, with the tests: #408.

🤖 Generated with Claude Code