A tool call is a business action
Once an agent can modify a record, send a message, approve a payment or trigger a workflow, prompt quality is no longer the primary safety mechanism. The architecture needs typed tools, explicit subject authority, preconditions and a durable action record.
Classify actions before runtime
Define read-only, reversible, consequential and prohibited action classes. For each tool, specify allowed objects, value limits, required evidence, idempotency key, rollback path and approval rule. Keep these rules outside the model prompt so they can be reviewed and enforced deterministically.
Make approval usable
An approver needs the proposed action, material inputs, model and tool versions, risk reason and expected effect. Approval should expire when inputs change. Record who approved, what they saw and the exact action executed.
Test failure paths
Simulate duplicate events, unavailable tools, partial writes, stale permissions, malicious content and approval timeouts. The agent should fail closed for consequential actions, preserve state for investigation and provide a human-operated recovery path.