Skip to main content
A callback gate is a question your workflow asks before work can continue. The answer is structured data that your code can check and act on. The gate defines the question and the answer’s shape. A router, the code that takes the question to an answerer, chooses how to ask it.

​
The flow

  1. Post the question. The stored callback client records the request in the run’s event stream.
  2. Claim the request. One router claims it. Competing routers cannot hold the same request at once.
  3. Collect the answer. The router asks a person, agent, or service.
  4. Submit the result. The client checks the answer and records it.
  5. Continue the workflow. The host, the code driving the run, reads the decision and explicitly resumes the paused work when appropriate.
The stored client rebuilds gate state from events after a process stops. A router failure does not erase the question or release its claim. The claim owner can release it so another router can answer. The in-memory callback client keeps the same kind of history, but its caller must save that history if it needs to survive a process exit.

​
Answerers

  • A person: A router can open a surface to collect a decision.
  • An agent: A router can ask an agent to examine the input and answer.
  • A service: A router can call a service and submit the returned data.
These choices use the same request and response contract. Your router owns the connection to the answerer, including authentication for an external service. Presentation hints can guide that router without changing the question’s identity.

​
Why the answer is structured

A response has named fields. For example, an approval can contain an approved boolean. Your workflow can branch on that value without asking another model what the answer meant. The built-in checks cover required fields and their top-level types. Your host must check any deeper rules it needs before submitting the response.

​
What the decision covers

The request’s content hash covers the gate ID and version, question text, response schema, and input. Changing any of those values creates a different request. Changing a theme or pane placement does not. For decisions about a proposed change, an approval gate can also bind the answer to proof, input artifacts, output bytes, permissions, and a workspace anchor, a record of the workspace state. Your host checks that these still match before acting on the approval. See the callback guide for a runnable example and the approval guide for decisions bound to evidence.