Summary

A chat box takes a message and waits for a reply. Long-running agents need more: a way to run in different modes, approve individual actions, watch delegated work, steer a run that is already in flight, and recover the whole thing after a reconnect. Session control is the layer that sits between the interface and the and turns "send message, wait" into a supervised session.

This layer is where coding agents and product agents converge. Claude Code, Cursor, Codex , and GitHub Copilot all expose modes, per-call tool approvals, and steering because a terminal agent that edits files needs supervision. A support agent that drafts refunds for a human to approve needs the same primitives. Product session layers such as Mastra's AgentController (beta) generalize the pattern for non-coding agents. Treat the coding-agent version as one instance of session control.

Decide by run duration and blast radius: a single-shot, read-only assistant needs none of this; anything that runs across turns, delegates to subagents, or takes irreversible actions needs an explicit controller.

Modes

A mode is a policy over what the agent may do without asking. Do not hardcode "plan mode" as a coding-only feature - it is one instance of a general shape.

The general progression is draft → execute → review:

Draft - the agent proposes a plan or a specific action but takes no side effects. Claude Code's plan mode is one instance; a support agent that drafts a refund for a reviewer is another; a data agent that shows the migration it would run is a third.
Execute - the agent acts. Execution may be fully autonomous (auto-accept), gated per call, or gated per class of action, depending on the mode's approval policy.
Review - completed work is presented for inspection and acceptance before it is treated as final. A diff to accept, a batch of drafted replies to send, a set of changes to merge.

Modes should be explicit, visible, and switchable mid-session. The user should always be able to see which mode is active and downgrade a running agent from execute to draft. Auto-accept is a deliberate choice, so surface it as a mode.

Subagent Surfacing

When an agent delegates to subagents, the thread should show that delegated work is happening without flooding the main conversation with every sub-step. Collapse a subagent's activity into a single labeled unit - "researching sources (3 agents)" - that expands on demand. Show progress and completion at the delegation boundary; keep the full sub-thread reachable but out of the primary flow.

The failure to avoid is a thread that becomes unreadable because five subagents interleave their raw output into one stream. Surface delegation as structure.

Tool Approvals

Tool approval is where session control meets safety. This page covers the UI and controller patterns; for the tool-surface contract underneath - declaring that a call needs sign-off, persisting the pending state, and resuming it safely - see Human Approval.

Three UI-level policies cover most cases:

Per-call approval - the agent pauses before a specific tool call and shows the exact arguments. The user approves or rejects that one call.
Per-session policy - "approve this tool for the rest of the session" or "always ask for this tool." The decision is remembered for the thread's lifetime; no code change is needed.
Allowlists - a standing set of tools the agent may call without prompting, with everything else gated. Coding agents expose this as command allowlists; product agents express it as approved action types.

Whatever the UI, the controller must persist approval decisions as durable state. A per-session "always allow" that evaporates on reconnect forces the user to re-approve everything and trains them to click through blindly.

Approval State

Approvals are a state machine, and that state must survive a refresh. Persist explicit states server-side so a reload or reconnect restores exactly where the run paused:

drafted - the agent prepared a proposed action
needs_approval - a user or reviewer must decide
approved - execution may proceed
rejected - execution must stop or revise
expired - approval was not granted in time
executed - the side effect happened
rolled_back - a compensating action ran

Every approval record should capture who approved, what they saw at the moment of approval, what changed after approval, and which execution consumed that approval. That record is the audit trail; without it you cannot answer "who authorized this refund and on what basis" after the fact.

Thread State

Session control depends on durable thread state - the set of facts that must survive a page reload, a dropped socket, or a process restart. At minimum:

the active goal and mode
selected resources, connected account, and workspace
the tool allowlist and any per-session approval decisions
pending approvals with their prompts and proposed actions
active run IDs so a suspended run can be resumed

If this state lives only in a model transcript or in browser memory, the session cannot reliably resume and every reconnect is a fresh start. Persist it where the controller - not just the UI - can read it back.

Mid-Run Steering

Users need to correct a running agent without starting over. Steering is the set of affordances that let them:

edit the goal or narrow the
remove a source or change a selected tool
revise a draft the agent produced
inject a new instruction ("also do X") into a run already in progress
pause, cancel, or retry a failed step
escalate to a human

Steering works best when the underlying run has checkpoints. If all state lives in a single model transcript, the controller cannot cleanly splice a new instruction into a run or resume from the right point after a correction. The runtime side of this - replay-safe activities, checkpointing partial state, injecting signals into a live workflow - belongs to Durable Execution. Session control owns the UX: how the injection is captured, shown, and acknowledged; owns how the running workflow absorbs it.

AG-UI, originated at CopilotKit, is the current de facto layer for streaming agent state and steering events to a UI across vendors, adopted via rather than a pinned spec version; see the Emerging Standards Watchlist for its status.

Voice barge-in - interrupting a speaking or acting agent by talking over it - is the canonical hard case of mid-run steering, because it collapses the pause, the new instruction, and the acknowledgment into a single real-time channel. It is out of scope for this guide's current coverage.

Failure Modes

Mode confusion: The user cannot tell whether the agent is drafting or executing, and an "execute" click acts before they meant it to. Show the active mode and require an explicit transition to execute.
Subagent flooding: Delegated work dumps raw sub-steps into the main thread until it is unreadable. Collapse delegation into labeled, expandable units.
Ephemeral approvals: A per-session "always allow" or a pending approval is lost on reconnect, so the user re-approves everything or loses a paused run. Persist approval state server-side.
Steering that restarts: The only way to add "also do X" is to cancel and start over because the run has no checkpoints. Give runs resumable state.
Invisible delegation: Subagents act with no surface at all, so the user cannot see or stop delegated work. Every delegated run needs a visible boundary.
Mode with no downgrade: An agent set to auto-accept cannot be pulled back to draft while running. Modes must be switchable mid-session.

Agentic UI - the interface shapes and event model this controller sits behind
Human Approval - the tool-surface approval contract and framework suspend/resume pointers
MCP Apps - interactive UI delivered through tool results
Emerging Standards Watchlist - AG-UI and other draft agent-to-UI protocols
Durable Execution - replay-safe workflow engines for non-deterministic agent loops

Session Control