Where does the sufficiency decision sit in an agent loop, and which tool actions does it need?

In an agent loop, the sufficiency decision sits between intake and the first action that commits something: scoring, approval, booking or dispatch. It is best exposed as a small set of tool actions so each step can be logged and replayed.

Typical tool actions:

- `get_case(case_id)` returns case type, status, policy version and customer-supplied context. - `list_documents(case_id)` returns document records with type, received date, page count and a legibility flag. - `get_requirements(case_type, policy_version)` returns requirement IDs, acceptable substitutes and age limits. - `record_sufficiency(case_id, outcome, gaps[])` writes `sufficient`, `insufficient` or `escalate`. - `send_request(case_id, gap_ids[], message)` creates the outbound request.

Link records by `case_id`, `document_id` and `requirement_id`. Each gap should point to the requirement it fails and, for conflicts, to both documents involved.

State to carry between turns includes the open gap list, requests already sent with timestamps, and the last evaluated document set. Without it, agents tend to re-ask for items already received.

A release can use JSONL for cases and events, with Parquet for larger tabular tables. Settle the exact tool signatures in a pilot so they match your own agent framework instead of assuming ours.