Good approvals make AI work easier to trust

An approval is useful when a person can understand what will happen and decide whether it should happen. A button labeled “Approve” does little on its own. The request around it needs to make the action, the information involved and the consequence clear.

When planning AI work, design the review step alongside the task. Decide who has authority, what they need to inspect and what should happen if the request changes.

Make the action visible

Start by describing the proposed action in terms the reviewer recognizes. For an outgoing message, that means the recipient, the full message and any attachments. For a change to an outside system, it means the target record and the proposed change.

Explain why the action is being requested and which work it belongs to. A reviewer should be able to connect the proposal to the original instruction without reconstructing a long conversation.

Also identify uncertainty. Missing information or an unresolved source conflict belongs in the review request, where it can influence the decision.

Define what approval covers

A person should know the scope of the decision. Approval to send one reviewed draft should not quietly become permission to send a different draft, add recipients or share additional files.

Write down which changes require a new review. Consider the destination, content, attachments and authority used to perform the action. If a material part changes, the earlier decision may no longer fit the proposal.

At Lodge, we design around explicit, scoped and revocable authority. A person stays responsible for consequential decisions, and an agent cannot grant itself authority or approve its own consequential result. An instruction found in a document cannot supply that approval either.

Walk through a realistic request

Imagine an operations team asking an agent to prepare an update for a supplier. The agent drafts a message using an approved project brief and proposes attaching a delivery schedule.

The reviewer needs to see the recipient, the message and the exact schedule being shared. They also need to know whether the schedule contains information the supplier should receive. “Send the update” is too vague to support that decision.

Suppose the reviewer asks for a revised date. The agent prepares a new draft, and the reviewer checks the revised proposal. If a source document contains text telling the agent to bypass approval, that text remains source content; it does not become permission to act.

This example separates useful preparation from the authority to send. The team can make progress while keeping the consequential decision visible.

Plan for rejection and change

Approval is one possible outcome. The reviewer may reject the proposal, request changes or leave it unanswered. Define what the workflow does in each case, including how it reports that work is waiting.

After an approved action, keep a record of what was authorized and what actually happened. If an attempt fails or its result is uncertain, the next step should consider whether retrying could repeat the action. A clear record helps the responsible person decide how to proceed.

Review your first approval request with the person expected to use it. Can they identify the destination, understand the proposed action and explain what their approval permits? Improve the request until those answers are clear.

Explore the broader Lodge security principles when planning where human authority belongs in your own workflows.