Execution sessions and interventions

RoomExecutionCoordinator binds one revisioned execution session to one active Room run. The session records the assigned participant, exact agent revision, runtime profile, authority and role revisions, checkpoint progress and terminal outcome.

Human-in-the-loop interventions

Human participants can request idempotent interventions while a run is active. An intervention is durable work to be applied by a compatible execution adapter; creating one does not imply that the provider has applied it.

The provider-neutral dispatcher claims pending interventions under a bounded lease and drains them at supported checkpoints:

• pre_step, before the next inference step;
• post_output, after model output and before continuation;
• pre_action, before a protected external action.

Delivery through the cognitive Runtime binds the operation to the current session, authority revision and role revision. Conflicting workers fail the execution-session compare-and-set update.

Protected actions

Checkpoint support is negotiated with the runtime provider. Applications can enable fail-closed behavior so a protected task is rejected before provider invocation when the provider cannot enforce pre_action. This enforcement is opt-in in the current prerelease line for backward compatibility.

Recovery and observation

Terminal run state reconciles with its execution session. Failed work can be recovered only as a same-task successor bound to the failed predecessor. The Rooms API exposes bounded cursor event reads and an optional versioned SSE stream for durable execution-session transitions.