Skip to main content
Not every task runs straight through. If the agent calls ask_user, or if you’ve built a conversational agent that expects a back-and-forth, the task pauses with status: "waiting_for_input" until you reply.

The reply loop

The reply is processed asynchronously. After posting it the task usually flips back to running within a second; resume polling GET /v1/tasks/{task_id} exactly like a fresh run. See Async tasks and polling for the polling loop itself.

Detecting that input is needed

Just check status. The same GET /v1/tasks/{task_id} you’re already polling tells you:
To see what the agent asked, fetch the message log:
The response is the chronological conversation log: user replies you’ve sent plus the agent’s messages back, oldest first. The most recent assistant message is the question the agent is waiting on.

Sending the reply

You can also send a message to a task that’s still running; it gets appended to the conversation and the agent picks it up on its next turn. This is how multi-turn conversational agents work.

End-to-end: handle the pause inside your polling loop

Adapting the polling loop from the previous guide to handle waiting_for_input:
Python
answer_fn is your callback, typically a function that prompts a human, looks up an answer from a database, or asks another LLM. The shape of the call is up to you; the API just takes whatever string you send.

Cancelling instead of replying

If you can’t answer (the user walked away, the timeout has elapsed), call POST /v1/tasks/{task_id}/cancel to mark the task stopped. The agent won’t progress further, but the conversation history stays available via the messages endpoint.