Agents

Submit a follow-up message to the run behind a conversation

Changed on

The same operation as POST /agent/runs/{runId}/followups, targeted by the conversation the run is serving rather than the run itself.

attachments must name ids prepared through POST /agent/conversations/{conversation_id}/attachments/prepare (or the run-keyed prepare) for the run that is newest at that time. If a new run appears for the conversation between prepare and follow-up, the follow-up resolves to the new run and answers 422 unknown_attachment; prepare again. A handoff is a new execution of the same run and does not have this problem.

mode only takes effect when the follow-up is queued ahead of the run starting or starts a new execution; a follow-up injected into a live session runs in the session's current mode.

post/agent/conversations/{conversation_id}/followups

Request

  • Base URL
    https://app.warp.dev/api/v1
  • Auth
    HTTP bearer

Path parameters

conversation_idstring uuid required

The UUID of the Warp-native conversation

Request body

messagestring

The follow-up message to send to the run. May be empty when attachments is non-empty.

mode'normal' | 'plan' | 'orchestrate'

Query mode for an agent run.

  • normal: Standard user query (default).
  • plan: Planning Mode. The agent researches and creates a plan, then waits for approval before execution.
  • orchestrate: Orchestration Mode. The agent proposes an orchestration plan and must not start child agents until approved.

Response

Follow-up accepted

followup_idstring nullable required

Identifier of the durable follow-up record, or null when the outcome did not create one (queued_prompt).

outcome'live_session' | 'queued_prompt' | 'handoff_execution' | 'queue_pending' required

How an accepted follow-up was routed.

  • live_session: the message was handed to the running session. This means the session-sharing service accepted it, not that the agent has started on it; observe the session's event stream for the new request.
  • queued_prompt: the run had not started yet, so the message was appended to its initial prompt.
  • handoff_execution: the previous execution had ended, so a new execution of the same run was created to continue the conversation.
  • queue_pending: the message is durably queued and will be delivered once the run can accept it.
run_idstring required

The run the conversation resolved to.

Changes