Pausing and stopping — AI Portal Docs

A turn does not have to run straight through. It can pause for you, you can stop it, you can add to it while it works, and when it ends without an answer it tells you the one thing that helps.

Key rules

A pause waits as long as you take; your last answer resumes the same turn.
Stop works at once, from running or paused, and keeps what was already written.
A turn without an answer names one action, or what has to change if no action would help.
Text you type mid-turn goes into the running turn, and you can edit or withdraw it until the agent reads it.
Nothing is sent behind your back: retries and “carry on” appear in the thread as ordinary messages.

Resuming after a pause

An approval or a clarification pauses the turn. How the request is created and checked lives on Agent execution; this is what happens around it.

The card you answer is drawn from the stored pending request, which outlives the stream buffer.
Each question settles on its own; the last answer resumes the turn.
The browser re-attaches to the same stream from the pause’s own position and rebuilds nothing on screen: the stored copy of a turn is hidden while a live one stands.
A resume that never lands leaves the run parked with every question answered, and it is retried on its own.
A tab that arrives after the pause chunk has expired is told the stored state and reads the record instead, where the question already is. The browser attaches to no parked turn, because nothing writes under one until somebody answers.
The call the question is about carries it. The record holds that call with no result, the shape of a call in flight, so the row says waiting rather than running, and the steps around it stay open for whoever is deciding.
Questions sit on the pause block and answers on the pausing tool’s result, so a reopened thread rebuilds the exchange from the transcript, between the agent’s work and its answer. The pausing tool draws no trace row.

Stopping a turn

Until a turn is terminal the thread is held, and only plain text reaches it. Pressing Stop does three things at once:

Publishes the stop where any backend instance can read it. The producer checks the flag on a timer and races it against the agent’s next chunk, so even a quiet run stops; losing the race releases the agent connection.
Records Cancelled without waiting for a producer. Cancelled is the one status reachable from any non-terminal state, awaiting included, and carries no error code.
Puts a terminal frame in the buffer, as an error frame with a cancelled code, so every open tab stops.

Blocks written before the stop stay in the transcript, cited and traced. Pressing twice is harmless, and a stop that lost the race answers with the status the turn reached. Only the conversation’s owner may stop a turn; an administrator who may read the transcript may not.

Turns that ended without an answer

A turn with no answer says so under its last message, where the reply was cut. The block has a mark carrying the tone, one sentence, the one action that helps, and the recorded code folded away for whoever reports it. It is read from the record as well as the stream, so it survives a reload and every earlier turn keeps its own.

Situation	Covers	What you can do
Stopped	You pressed Stop.	Carry on: what was written is usable and the agent has more to add.
Output limit	The reply spent the model’s output capacity (`agent_output_limit_exceeded`).	Carry on.
Break on the way	A dropped connection, a timeout, an agent that could not be reached, or any code the screen does not recognise.	Send again. The only one of the four with a red mark.
Model off or key gone	The model is switched off, or the department’s gateway key is gone.	Nothing to press; the block names what has to change, because pressing would produce the same result.

Both buttons send an ordinary message:

Carry on sends a short instruction to continue.
Send again sends the original question with its files, referenced by the ids they were already stored under rather than uploaded twice.

The second copy of the question appears in the thread like any other message, because a turn nobody sent is a turn the audit cannot explain. Both buttons are refused while the thread is answering something else, since a message sent into a busy thread is dropped.

A tool call the turn never came back to settles with the turn. Its record holds the call and no result, so it is marked as never having come back, which is not the same as failed: nothing says it did not work.

Steering a running turn

Plain text written while the agent works goes into the running turn. The runtime reads it before each model call, and once more where the turn would otherwise finish, so something written during the last call is answered by a further call of the same turn. If you can see the agent going the wrong way, say so instead of waiting for it to get there.

It is an ordinary user message of that turn, at the next position, so the thread and the audit carry it like anything else you said.
Several messages written while the agent works arrive as one message: three corrections are three paragraphs of one instruction, and sent separately the model would answer the first with the next two already in front of it.
If the turn ends between the browser deciding it was running and your message reaching the portal, the portal refuses it and the browser puts the text back in the composer, to send as the next turn.

What a running turn cannot take stays in the composer until the turn ends: a file, a different model, a different effort level and a chosen skill, because a turn is opened with those settings. A paused turn takes none of it either, since it waits for one specific answer and that form is already on screen.

Pending and read. A message not yet read sits below the answer in progress, faded, and moves above it once the model has been handed it. The runtime reports each read on the stream. The record divides at the same point: what the agent wrote before reading your message is one message of the turn, what it wrote after is another, with your words between. The thread scrolls to the question the turn opened with and leaves a correction where it is, because you are reading the answer being corrected.

Edit or withdraw until read.

Text added while an earlier update still waits is appended to it on a new line, so at most one update waits at a time.
Withdraw deletes the message. Edit withdraws it and puts its text back in the composer; the up arrow does the same from an empty composer.
Once the message is read, withdrawing is refused.
The question a turn opened with is never steering and cannot be withdrawn.

Next-action suggestions

The agent can end an answer with up to four messages you might send next. They show as buttons under the newest turn; a click sends that text as the next turn.

Suggestions are cut to 80 characters each, list marks are dropped, and a fifth is ignored.
They pass the answer guardrail along with the text they end.
The trace leaves the suggestion call out, and short-term memory never replays it.

Under the hood

Stop flag and race

The stop intent is published to shared state any instance can read. The producer polls it on a timer and races it against the next agent chunk. The terminal frame is an error frame with a cancelled code; the Cancelled turn status itself carries no error code. A repeated stop is idempotent and returns the status the turn reached.

Steering reads and locks

The runtime keeps its own place in the turn’s user messages; a resumed run reads on from the last message the paused run had taken, which is in its snapshot. The portal also marks each message taken when it hands it over, and a repeated read returns the same messages, so a retried request loses nothing. Appending and withdrawing each lock the message and check it is still untaken, and the read that marks it waits on that lock, so neither can change text the model already has.

Next-action block format

The agent writes suggestions one per line between <next_actions> and </next_actions>, as the last text of the answer’s message. The runtime holds the block back from the stream, so it never reaches the screen as text. When the answer’s block arrives, the runtime strips the block and emits a suggest_next_actions call and result, which the chat draws as buttons. Short-term memory never replays these calls, because the model has no tool by that name.

Error codes

Code	Meaning
`steering_already_read`	Withdraw refused: the model already took the message.
`agent_output_limit_exceeded`	The provider’s output limit ended the answer; the next turn receives the failure reason even when no complete block was saved. See the agentic loop.
cancelled (terminal frame)	Error-frame code put in the buffer by Stop.

Ask and read answers Stop, steer and carry on from the chat. Long conversations Compaction and picking up old threads. Agent execution How pauses are created and checked. Turn lifecycle States, streaming and replay.