Execution sessions and human interventions in AgentPlat

An execution session identifies the actual run

When a person asks to stop or adjust an agent, the application needs to identify the execution they mean. A participant name alone is ambiguous if the agent has multiple revisions or sequential runs.

The execution session documentation binds one revisioned session to one active Room run. It retains the assigned participant, exact agent revision, runtime profile, authority and role revisions, checkpoint progress and outcome. These coordinates help prevent a delayed control request from being mistaken for a decision about later work.

Requested and applied are separate states

Creating an intervention persists work for a compatible adapter to apply. The request is not evidence that the model stopped, the next tool call was prevented or the provider acknowledged the change.

In an illustrative interface, show “intervention requested” until retained execution evidence supports a stronger statement. If a provider cannot reach a suitable checkpoint, the interface should expose the unresolved state rather than optimistically announcing success.

Choose the checkpoint that matches the effect

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

The provider-neutral dispatcher claims pending interventions under a bounded lease. Delivery binds the request to the current session and authority revisions. Conflicting workers cannot both update the session through the same compare-and-set revision.

For a pending external write, confirm that the adapter actually awaits the action checkpoint. A supported checkpoint name in configuration is insufficient if the write path skips it.

Handle terminal state and recovery deliberately

A terminal run reconciles its execution session. Recovery creates a successor tied to the same task and failed predecessor. Preserve that link so an operator can distinguish a retry from a new assignment.

The Rooms API exposes execution routes only when the corresponding service is injected. A client should handle unavailable capabilities as a host configuration fact, not repeatedly retry a route that does not exist.

Test the provider behavior behind the control

Verify the intervention lifecycle with a deterministic provider before introducing real model latency. Submit a request, pause at a supported checkpoint and inspect its persisted application result. Repeat with a stale session revision and observe the conflict handling.

The control integration guide explains the opt-in protected-action requirement. Test each provider you deploy, including paths used during recovery. Evidence of a requested intervention should never be substituted for evidence that the relevant execution boundary honored it.