Where does a sufficiency gate sit in an agent pipeline and what should it log?
Describes the gate between intake and processing, the five tool actions it typically needs and the JSONL decision fields that make it scorable.
In an agent pipeline, sufficiency sits between intake and processing. It is the gate that decides whether the case goes forward, goes back for more information or goes to a person. Making it an explicit step makes it testable.
A typical gate uses five tool actions:
- `list_case_documents(case_id)` returns document IDs, types, dates and sender - `get_requirement_set(case_id)` returns the policy items that apply - `read_document(document_id)` returns extracted text and metadata - `set_case_status(case_id, status)` moves the case, for instance to AWAITING_INFO - `send_information_request(case_id, items, message)` contacts the sender
Log each gate decision as one JSONL line so it can be scored later:
- `case_id` and `requirement_set_id` - `decision`: proceed, request or escalate - `gaps`: list of requirement IDs judged unmet - `evidence`: document IDs cited for each met requirement - `request_id`: link to the outbound message, if any
Because the decision, the cited evidence and the outbound request are separate fields, an evaluator can tell whether a failure came from reading the documents, applying the policy or writing the request. A task pack could ship the tool schemas and the log format together so the same trace shape works in both training and evaluation.
An explicit gate with separate decision, evidence and request fields lets evaluators tell reading errors from policy errors and from writing errors.
- Audience:
- Evaluation teams
- Content type:
- Integration
- Buyer question:
- What it is and why it matters
Content release: r-a220eb6e099b243b
Related questions
- What does it mean for an agent to decide whether the supplied documents are enough?
- What does a sufficiency decision look like on a real loan application?
- How do I tell whether my process suits sufficiency-focused training or evaluation?
- Where does the sufficiency decision sit in an agent loop, and which tool actions does it need?
- Why not handle this with a fixed checklist or rules engine instead of an agent?
- How does a sufficiency decision map onto environment state and tool actions?