PROOFGRID
Request a Demo

Model consequential agent actions

Action classes should reflect real-world effects, not just tool names.

01 / The operating case

What changes in a real workflow?

The same billing tool exposes invoice lookup, refund proposal and committed refund.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision contract

What the executor must check

Define effect verb, immutable target, monetary or destructive magnitude, reversibility, required approval and observation method; map each API operation to the class.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

A “billing tool allowed” rule permits both reads and refunds.

Evidence to retain

Keep classification version, mapped endpoint, authorized parameters and actual effect.

04 / Canonical scope

Why this reference stands alone

Policy-envelope design applies bounds; this page defines the action taxonomy it constrains.

Illustrative implementation artifact

Effect taxonomy

READ: observe existing state
PROPOSE: create uncommitted recommendation
WRITE: change protected state
DESTRUCTIVE: remove or disable
EXTERNAL_TRANSFER: move funds or protected data

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation