refund.amount and refund.method. The agent’s tool sends create_record {table: "refunds", data: {amount_usd, payment_method}}. A mapping connects the two, once per tool, so every later call is checked deterministically.
The flow
1
Registered
The guard registers the tools it sees (Read vs write). One record per app, tool and input-schema hash.
2
Proposed
For each new write tool, one model call proposes a mapping from the tool’s description and schema and your maps’ facts. It’s validated strictly: paths must exist in the schema, facts must be the chosen map’s. Status
proposed.3
Reviewed
On Tools (or the API), an editor confirms it, edits it, says it touches no workflow (Not ours), or marks it read-only. Status
confirmed.A mapping
Review through the API
Editors and admins, with acapture credential (the web app’s):
action is one of confirm (the proposal as is), edit (send workflow_id, fields and any other keys above), none (writes, but nothing a map governs: allowed without routing) or read. An invalid edit is rejected with 422 and the list of what’s wrong, never silently trimmed.
Limits
- A tool whose definition changes (input schema, description or annotations, hashed together) goes back to
proposed, even after you confirmed it: the old mapping is kept as the proposal (if it still fits the schema) and still applied, and the change is listed on the tool (changes: when, what changed, the old and new hash). A write tool that redefines itself as read-only stays a write until you mark it read. Confirm it again after checking what changed. - Generic CRUD tools (
create_record {table, data}) are hard to propose: the schema doesn’t say what columns exist. Expect to edit those. - Rows nested inside another array aren’t supported.
CLAROS_TOOL_MAPPER=offturns proposals off; tools wait for an editor.