Interrupting an agent mid-turn

A long agent turn has two clocks, and they take different interrupts. The chat model may still be calling tools, writing a plan, or composing a reply. Separately, a background task it already spawned may be generating, waiting, captioning, posting. "Stop" is not one control. Answer now finishes the reply without further tools. Cancel stops the background work. Closing the tab is a third path: it aborts the turn and saves whatever already ran, so the next message does not charge you twice for the same dispatch.

Reach for the wrong one and you either keep spending on a pipeline you have abandoned, or you kill a reply while a five-step task continues underneath it.

Answer now stops the reply

In the agent chat UI, a streaming turn shows an Answer now control on the live activity row. It fires POST /api/v1/agentic/chat/answer-now with conversation_id (and the authenticated user). A well-formed call answers 202. Missing conversation_id is a 400. If the signal cannot be stored, the 202 body includes degraded: true and the client should treat the tap as a no-op, not as success.

What the signal does:

• It is consumed between tool rounds, never in the middle of a tool. The current call finishes.
• On the next model iteration, tools are omitted. The model is nudged: stop using tools and give the best final answer from what it already has.
• The stream emits status with phase: "answering_now".
• The flag is short-lived (about two minutes) and is cleared when the stream ends, so it cannot leak into the next turn.

What it does not do:

• It does not cancel a spawn_background_task that already returned task_id. That pipeline keeps stepping.
• It does not rewind generations already sent to a provider. Those finish, and their credits stay spent.
• It does not work on the blocking POST /api/v1/agentic/chat JSON endpoint, because there is no mid-stream to signal. Answer now is a streaming-turn control. The first status event on /chat/stream always includes conversation_id so you can call answer-now before done, including on a brand-new chat where you had not minted an id yet.

Use it when the agent is looping: extra research, extra schema lookups, a third check_generation_status you did not ask for. You want a sentence now, from the evidence in hand. You do not want the pipeline torn down.

The in-app copy is the same idea: if it is deliberating too long, Answer now makes it reply with what it has.

Cancel stops the work

Background tasks are a different object. POST /api/v1/agentic/tasks/:taskId/cancel sets the row to cancelled. The executor re-reads status before each step (and inside wait_generation polls) and throws "Task cancelled by user" when it sees the flag.

Constraints that matter in practice:

• Only running or pending tasks cancel. completed, failed, cancelled, and scheduled return a 400: the task is already in that state. A job sitting on scheduled_at is not cancelled by this call.
• Steps that already finished stay finished. Their files stay in the library. You are not charged again for them, and they are not deleted.
• The step that is in flight stops at the next cancel check, not by magically aborting a provider render that has no cancel API. Treat in-flight generation as likely to land even after you cancel; later steps will not run.
• Ownership is enforced. The task must belong to the authenticated user.

This is the control for "I briefed the wrong recipe" and "I do not want the caption-and-post tail." It is not the control for "the model is being chatty." Checking or resuming a stuck run is the neighbouring move when you are unsure whether the job is dead or merely slow: resume_workflow_run no-ops on a healthy scene workflow, and stop_workflow_run is the scene-workflow equivalent of cancel (in-flight scenes flip to cancelled; finished scenes stay).

List before you cancel. GET /api/v1/agentic/tasks returns id, task_name, status, current_step_index, total_steps. Cancel the id, not a guess from the scrollback.

Closing the tab is a third path

If you background the app or close the stream, the server aborts the in-flight LLM call and further tool dispatch on that turn. That is the credit-saving half: no more tokens, no more queued generations from this turn.

The other half is the save. Tools that already ran are real. The generation is at the provider. Without a persist, the next turn's agent has no record, tells you it has not generated that yet, and dispatches again. The stream handler writes an interrupted turn in that situation so the history contains the work that actually happened.

So: close the tab if you are leaving and you are fine with whatever already dispatched finishing, and you do not want more tools. Do not close the tab as a substitute for cancel. A background task is server-side; it does not die with the socket. A multi-step task you spawned will complete unless you cancel it.

Control	Stops the reply loop	Stops later background steps	Already-dispatched generations
Answer now	Yes, after the current tool	No	Keep running
Cancel task	No (chat may already have closed)	Yes, from the next step check	In-flight step may still land; later steps do not run
Close the tab	Yes, abort the turn	No	Keep running; the turn is persisted so they are not re-sent

Which one to reach for

The model is rambling or tool-thrashing, the brief is still right. Answer now. Read the summary. Continue in a new turn if you still want work done, this time with a tighter instruction.

The recipe is wrong. Cancel the task, then spawn (or brief) the corrected one. Do not answer-now and hope the tail of "Kitchen Product Reel" absorbs a new brief. Steps were fixed at spawn.

You are done for the day and the job is the right job. Let it run. Close the tab. Collect from the task list later. Check credits before you walk away from a long chain; a cancel after four expensive steps does not refund the four, and there is no free allowance on the account. Pricing is the live tariff.

You asked for a single text-to-video clip and it is simply slow. Neither interrupt helps the render. Answer now will only make the model talk before the clip exists. Cancel does not apply unless you wrapped it in a background task. Wait, or check status.

A clean interrupt in a streaming session looks like this:

(tap Answer now)
Okay, stop planning. Give me the three-step version.
(read the reply, decide the pipeline is wrong)
Cancel the Kitchen Product Reel task. Spawn a new one named Kitchen Product Reel with only two stills, no auto-post.

Same name, new steps, because you meant to reuse the recipe, not to keep the old run.

FAQ

Does Answer now refund the tools that already ran?

No. It prevents further tool launches on this turn. Completed calls and already-dispatched generations stay billed. If a generation later errors, the ordinary refund path still applies; answer-now does not add a second one.

Can I Answer now on a blocking /chat request?

No. There is no stream and no mid-turn signal. Close the HTTP request if you must abandon it (the server aborts on disconnect, same as a dropped stream). For a product UI, use /chat/stream so Answer now exists.

I cancelled and the video still appeared.

The in-flight generate step was already at the provider when cancel was recorded. The executor noticed on the next status check and skipped later steps (captions, post, notify). The file is real. Delete it if you do not want it; do not expect cancel to un-render.

Why did cancel tell me the task is already scheduled?

Cancel only accepts running or pending. A task waiting on scheduled_at is scheduled. Wait until it starts and then cancel, or avoid spawning it with a future scheduled_at if you are still deciding.