> ## Documentation Index
> Fetch the complete documentation index at: https://docs.obversa.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Callback gates

> A callback gate asks for one structured result from a person, an agent, or a service.

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](/graphs/callback-gate) for a runnable example and
the [approval guide](/proof/acceptance) for decisions bound to evidence.