Skip to content
Elicitly

elicit_cancel

Withdraw a pending elicitation you created. The request resolves canceled — a terminal status distinct from declined (the reviewer’s explicit no) and expired (nobody decided in time).

When to use

Section titled “When to use”

The plan changed and the question no longer needs answering: the agent found a better approach, the user changed their mind, or a newer request supersedes this one. Cancelling closes the loop cleanly instead of leaving the request dangling in a reviewer’s inbox until it expires.

Input

Section titled “Input”
Parameter Type Required Description
elicitationId string yes The id returned when the request was created. 
{ "elicitationId": "…" }

Output

Section titled “Output”
{ "status": "canceled" }

Behavior

Section titled “Behavior”
  • Requester-only. Only the user who created the request can cancel it — the same ownership rule as elicit_status / elicit_await / elicit_result.
  • Only a pending request can be canceled. If the reviewer already decided, the call errors with already decided (status=…); after the TTL it errors with expired undecided. Nothing is ever overwritten — the audit trail is insert-only.
  • Races resolve cleanly. A cancel and a concurrent reviewer decision are arbitrated by the same database constraint that prevents double decisions: exactly one wins, the other reports what won. A reviewer who opens the review page after a cancel sees a terminal “withdrawn by the requester” page.
  • Waiters wake. A pending elicit_await returns { "status": "canceled" }, and the request leaves the reviewer’s dashboard inbox.
  • There is no outcome to fetch. elicit_result errors for a canceled request — the requester withdrew it, so no reviewer decision exists.
Section titled “Related”