Approvals & policy · · 4 min read · Updated
Who approves the action when three teams care about it?
Assign approval to the person with authority over each proposed action, with clear evidence, expiration, material-change rules, and backup coverage.
An agent proposes extending a customer discount. The account owner likes it, finance owns the margin, and security owns the connection that updates the account.
Split approval by the authority being exercised. Commercial acceptance, spending authority, access administration, and technical readiness are distinct decisions. Each person approves the part they are accountable for, using the evidence that part requires, and the workflow states which decisions the action needs.
Practitioners asking how to let a human validate, approve, or reject an agent flow hit this choice beyond the framework API. A working button still needs an authorized recipient and a precise meaning.
Write decisions as verbs#
Do not assign "AI governance" to a committee. Write concrete decisions: approve a discount outside the standard band, authorize a payment, grant access to a system, accept a completed draft, or allow a production change. Each verb names a different object and consequence.
A business owner accepting a brief has not approved every tool call the agent makes afterward, and a security team approving a connection has not approved a commercial offer. Document those distinctions so a green status never reads as broader permission.
| Proposed action | Decision needed | Suitable authority |
|---|---|---|
| Prepare an internal account brief | Accept the result | Account owner |
| Offer an exception to standard terms | Authorize the exception | Commercial authority for those terms |
| Increase a task spending ceiling | Fund further work | Budget owner |
| Add a new connected destination | Grant access | System owner under access policy |
| Publish the accepted offer | Authorize the external commitment | Person accountable for that commitment |
One person can hold several roles. Keep the decisions separate anyway, because staffing and workflow scope change.
Work a discount exception#
In a hypothetical process, the agent drafts a renewal at the standard price and the account owner asks for a special discount. Finance reviews the requested amount and its rationale. The account owner then reviews the exact customer-facing offer, including dates and conditions, and the tool action must match that approved offer.
If the agent changes the amount after finance approves, the earlier decision no longer describes the proposal. If the recipient changes, the publication approval needs another review. Define material changes in advance: amount, recipient, target account, deadline, and scope each change the meaning of consent.
An approval request includes:
- The proposed action and its destination.
- The business reason and relevant evidence.
- The consequences and an expiration.
- What happens if the approver rejects or does nothing. Without a fallback, absence becomes improvisation.
Design absence before it happens#
Choose a backup with equivalent authority for that decision. A generic channel full of colleagues is not an authority model. If no authorized approver is available, save a draft, defer the action, or finish the job manually through an existing process.
Each approval goes to a named person with authority for that decision.
Do not automatically escalate every slow approval to a more senior person. Some requests should expire because the opportunity or source data has changed, and others need fresh evidence first. Base the escalation rule on the business deadline and the cost of a stale decision.
LangGraph interrupts provide a mechanism for waiting and resuming. The business still decides who can resume, what was approved, and whether the proposal remains current. Test those with a delayed request, not only a quick demonstration.
Remove approvals that do no work#
A reviewer who sees hundreds of routine requests stops examining them. Look for rules that produce the same decision every time. A narrowly scoped automatic permission beats ritual clicking once the organization authorizes the rule and tests its scope.
Keep exceptional actions visible. A batch of ordinary updates should not hide one high-impact change behind a single aggregate approval. Show the exceptions, and decide whether the reviewer approves the batch with exclusions or reviews items separately.
Deixic's approval instructions explain the operator action. The approval design essay covers keeping approvals read instead of clicked through, and Enterprise places approvals in the buying discussion.
The finished matrix answers three questions without a meeting: whose decision is required, what evidence they need, and what happens if they cannot decide.