Skip to main content
Interactions pause an agent when it needs a person to approve an action or answer a question. The agent resumes when someone responds; if the current work is canceled, the interaction is canceled too. There are two kinds: Both ride on the same tool-call machinery: the parent tool call waits while the interaction is open. An interaction ends in one of two states — resolved (someone answered) or canceled (the work it guarded was canceled, superseded, or archived).

Find open interactions

The examples assume the client, $ORG/orgID, and $PROJ/projectID setup from the quickstart, plus the $AGENT/agentID value above. The CLI has no interactions commands — respond from the dashboard or the API.
Filter by state (open, resolved, canceled) or omit it for everything; results are cursor-paginated, oldest first. In practice you rarely poll this — open interactions announce themselves on the event stream as tool-call activity, and this endpoint is how you fetch the form to render.
Full schema and playground: List agent interactions.

Render the form

Every interaction’s request is the same small form structure, designed to render without special-casing:
  • title — one line saying what’s being asked.
  • context — optional label/value pairs to display verbatim (the command about to run, the machine it targets). Show all of them; they’re the approver’s evidence.
  • questions — one or more, in order. Each has a prompt and at least one option. multiple: true means the answer may select several options; an option with allows_text: true invites free text alongside the selection (in permission forms, that’s the “Deny” option — the text becomes the reason the model sees).
Permission forms always have exactly one question with Allow at index 0 and Deny at index 1. Question forms are composed by the agent, so treat them generically.

Resolve it

Answer with one entry per question, in order. option_indices are zero-based positions into that question’s options. The response is the interaction in its final state:
To deny with a reason, select the Deny option and attach text:
Two operational notes:
  • Resolution is first-writer-wins. Re-sending the same answers replays idempotently — 200 with the already-resolved interaction. Sending different answers, or resolving a canceled interaction, returns 409 with code idempotency_key_conflict. Whoever answers first, wins; build your approval UI to handle the race gracefully.
  • Attribution works like inputs. Services relaying human decisions pass actor alongside answers so resolved_by_input_id traces to the real person — see actors.
Full schema and playground: Resolve agent interaction.

When interactions cancel

You never delete an interaction; it cancels when the work it guarded goes away: Canceled interactions keep their request and stay listable, so audit trails show what was asked even when nobody answered.

Next

Artifacts

Download the files agents produce and reference

Agent configuration

Decide which tools require approval in the first place