Sending, steering, and stopping

Understand queued requests, interruption, cancellation, and agent lifecycle controls.

You can send a follow-up while an agent is working. Ordinary messages are accepted into a server-backed queue and wait for the agent to become available.

Once accepted, queued work does not depend on keeping your browser tab open. An unsent draft or failed send has not reached that state.

Read the request state

State	Meaning
Sending	The browser is submitting the request.
Queued	The request is waiting behind active work.
Starting up	The runtime is starting before delivery.
Sending…	An accepted request is being delivered; this is not yet confirmation of active work.
Working	The agent has started the request.
Interrupted	Active work was interrupted.
Cancelled	The request was cancelled.
Failed	The request encountered a failure.
Couldn’t send.	Submission failed; use Retry for that request.

The visible queue is reserved for messages behind existing work. A first message waiting for the sandbox to wake appears as the active message with Starting up, not as a queued item. While delivery proceeds, it can show Sending or Sending…; neither label confirms that the model has begun responding.

Queued messages retain their files and resource context, including a selected passage’s original revision. Sending or retrying after the Page changes does not retarget that passage. The queue can include work submitted by other people using the agent.

Steer queued work

Use Steer beside queued messages when you want to interrupt the current request and let queued work proceed.

In the current composer, Steer stops the active request. It does not resend the queued messages, send your unfinished draft, or silently edit the current prompt. Queued work proceeds as the runtime becomes available.

For example:

1. The agent is writing a long report.
2. Send “Before continuing, focus the report on the enterprise audience.”
3. The follow-up appears in the queue.
4. Select Steer if you want to interrupt the current work instead of waiting for it to finish.

Interruption does not undo files, pages, or external actions already changed by the agent.

Stop or cancel the right thing

Action	What it affects
Cancel queued message	One waiting request.
Composer stop control	The current foreground request.
Steer	Interrupts current work so queued requests can proceed.
Background-process stop, where available	The selected background process.
Disable	Keeps the managed agent stopped until explicitly enabled.

Stopping foreground work preserves your draft and attachments. It does not clear the rest of the queue, disable the agent, or cancel future schedules. If you want to withdraw a follow-up, cancel that queued message separately.

The agent session is shared. Stopping its current request can interrupt work another person started.

Detached background processes are separate from foreground work. Where the interface exposes a stop action for an individual process, use that action to target it.

Retry a failed send

Use Retry on the failed request. This repeats the same submission identity so the server can recognize an already accepted request after a lost response.

A send failure does not always prove that nothing reached the server. Avoid manually duplicating a request when its existing Retry action is available.

Answer an agent’s question

An agent may present a Needs your answer card to a specific person. Open questions can appear in Activity and the agent composer.

Answer through the card so the reply is associated with that question. Opening another view, reloading, or sending an unrelated message does not resolve it.

An unanswered question, ongoing work, and queued follow-ups can be visible at the same time. The card is not a complete description of everything the agent is doing.

Sleep and disable

Automatic sleep leaves the agent enabled. New work can wake it, and merely reading its saved conversation does not.

Disable keeps the agent stopped until Enable. Use it when you want to prevent activity from waking the agent. See Schedules for recurring work and catch-up behavior.

Background process controls

Expand Background process or N background processes to inspect a command, its output, and its status. Stop targets that process.

Stopping means the stop was requested; a newer observation must confirm the resulting state. Needs attention can indicate a process problem.

Dismiss process alert hides an alert for a process no longer observed as live. It does not stop a running process or disable the agent.

For question-card submission behavior and recipient rules, see Answering agent questions.

When credits run out

New direct operator sends are blocked while the organization is out of credits. Your draft stays in the composer; it has not become a queued task. After credits return, review and send it yourself.

A request accepted before the cutoff is different from a blocked send: its accepted record is retained. An in-progress response can be interrupted, and exact continuation of that turn is not guaranteed.

Eligible channel activity remains pending for the managed agent and can resume automatically after credits are restored, unless you manually paused the agent or another restriction still applies. This retained channel activity is not the same as the operator’s visible queue of messages behind existing work.

See Credit exhaustion and recovery for what remains available and how to recover.