Approval Gates Should Encode Business Risk

Approval gates are easy to add and hard to tune. Add too few and the agent can take actions the business cannot defend. Add too many and the workflow becomes a slower version of manual work. Good gates encode risk in a way the product, operations, and compliance teams can all understand.

The gate should not exist because the system is "AI." It should exist because a specific action has meaningful impact: money moves, data changes, a customer receives a sensitive message, a contract is altered, or a policy decision becomes visible outside the company.

Build gates from action classes

Start by listing what the agent can do. Read knowledge. Draft text. Send a message. Update a CRM field. Issue a refund. Change a document. Trigger another workflow. Each action class deserves a different policy. Reading is usually low risk. Drafting is often medium risk. Writing to systems or sending external communication can be high risk depending on context.

• Read-only actions can often proceed without approval.
• Draft actions may need review only when confidence is low or the domain is sensitive.
• Write actions should check permissions, thresholds, and reversibility.
• External actions should consider who receives the output and what harm an error could cause.

Confidence is only one signal

Confidence can help, but it should not carry the whole gate. A confident agent can still act outside policy. A less confident agent can still produce a harmless draft. Better gate inputs include financial amount, customer tier, jurisdiction, data sensitivity, tool permissions, source freshness, and whether the action can be undone.

This is where business logic belongs. If refunds over a threshold require finance review, encode that threshold. If legal language must be reviewed before export, encode that rule. If a workflow is allowed to draft but not send, make that boundary explicit.

Reviewer context is part of the gate

A gate that only says "approve?" is not a gate. It is a shrug. Reviewers need the proposed action, source evidence, reason for escalation, run history, and the expected effect of approval. If the reviewer has to ask another system for context, the gate will be slow and inconsistent.

Audit the overrides

Overrides are not just compliance records. They are product feedback. If reviewers constantly reject the same class of proposal, the upstream prompt, retrieval, or tool policy needs work. If reviewers almost never change anything, the gate may be too conservative. If approval latency is high for low-risk work, automation is being held back by policy design rather than model quality.

Trumpets approval gates are designed to sit inside workflows, document review, and learning loops. That keeps governance close to the action itself. The safest systems are not the ones that ask for permission everywhere. They are the ones that know exactly when permission matters.