Skip to content
MirrorFirm

Which tool actions should an environment expose for conditional approvals?

A suggested set of tool actions, arguments and return shapes that let agents inspect conditions, attach evidence, request waivers and attempt gated actions.

A compact tool surface is enough to exercise the workflow. Suggested actions:

- `get_approval(approval_id)` returns the approval and its linked condition identifiers. - `list_conditions(approval_id, status?)` returns condition records with owner, due date and evidence spec. - `attach_evidence(condition_id, doc_ref)` creates an evidence record and sets the condition to `awaiting_review`. - `review_evidence(condition_id, decision, reason)` is available only to roles with clearing authority. - `request_waiver(condition_id, reason)` creates a waiver task for the approving role. - `attempt_action(action_id)` runs the gate check and either executes or returns the blocking `condition_id` values. - `add_case_note(target_id, text)` writes to the audit trail.

Return structured errors, such as `{"error":"blocked","blocked_by":["COND-2187-A"]}`, so graders can read the reason without parsing prose.

Generated tasks could reference these action names in their expected-trace field, with a list of acceptable orderings. Reset should restore all record tables and the clock from a named snapshot.

Action names and arguments are placeholders. Agree them against your own environment in a pilot.

A small, well-typed tool surface makes gating testable, because every agent decision maps to a call you can log and grade.

Audience:
Environment builders
Content type:
Integration
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Approval conditions