Policy checks for AI agents: the proposal envelope pattern

AI agents become useful in business when they can move work forward. They also become risky at exactly that moment.

Reading a document is low risk. Drafting a reply is usually manageable. Sending the reply, changing a CRM stage, refunding a customer, editing a billing record, inviting a user, deleting a file, or posting publicly is different. Those actions leave the workspace and change the business.

That is why the operating layer around an agent matters as much as the agent itself. A business does not only need intelligence. It needs a repeatable way to decide whether an AI-proposed action is allowed, should be reviewed, must be blocked, or should be re-checked because the state changed.

The pattern I keep coming back to is the proposal envelope.

What is a proposal envelope?

A proposal envelope is a structured record an AI agent must produce before it changes a business system, sends an external message, touches money, updates permissions, or makes a public commitment.

It packages the exact proposed action, source evidence, risk class, approval owner, expiry time, idempotency key, rollback path, and log destination so a human or policy layer can review the action before it becomes a side effect.

The flow looks like this:

agent output
-> proposal envelope
-> policy check
-> approval inbox
-> state re-check
-> action
-> evidence log

The agent can still reason over messy context. It can still prepare useful work. But before it creates a side effect, it must produce a structured proposal that another layer can inspect.

Why this matters in real workflows

Most early agent workflows grow from small experiments.

A founder asks an agent to draft emails. A team adds a Slack approval step. A CRM workflow gets another condition. A support automation pauses when refund words appear. A billing exception goes to email. A public post waits in a document.

Each rule may be reasonable on its own. The problem is that the review system becomes scattered.

Nobody can easily see:

• which proposals are waiting
• which approvals expired
• which actions already ran
• what evidence the agent used
• whether another workflow touched the same record
• whether the business state changed after approval

That is how a sanctioned AI tool can still behave like shadow AI. The app may be approved, but the exact interaction is not governed. The connector exists, but the workflow does not have a shared policy contract.

What the envelope should contain

A useful proposal envelope includes:

• Actor: which agent, workflow, user, or schedule requested the action
• Goal: which business goal loop this action is supposed to advance
• Target system: Gmail, CRM, billing, calendar, file storage, Slack, Discord, or another tool
• Exact action: the specific message, update, record change, invite, post, or task to create
• Affected record: the customer, lead, invoice, document, thread, account, project, or channel touched by the action
• Source evidence: the emails, docs, notes, policies, tickets, or records the agent used
• Risk class: low, review, sensitive, blocked, or custom levels defined by the business
• Approval owner: the person or role allowed to approve the proposal
• Expiry time: when the approval stops being valid
• Idempotency key: a key that prevents duplicate sends, duplicate updates, or duplicate refunds
• Rollback path: what can be undone, what cannot, and what mitigation exists
• Log destination: where the final decision, evidence, and result should be recorded

This is much easier to review than a vague notification saying the agent wants to update something.

What the policy check should decide

The policy check should be boring. That is a feature.

Its job is not to rethink the whole business problem. Its job is to classify the proposal and decide what happens next:

• Allow: safe, reversible, inside scope, and low impact
• Require approval: customer-facing, financial, public, permission-related, or ambiguous
• Deny: outside tool scope, missing evidence, unsupported claim, forbidden action, or unsafe target
• Escalate: requires a named owner, legal review, founder approval, manager approval, or manual handling
• Ask for more context: the proposal cannot be judged because the source set is missing or stale

The decision should come with a reason. A reviewer should know whether the workflow paused because of missing evidence, customer impact, money movement, public visibility, policy mismatch, or stale state.

The approval inbox is not just notifications

A real approval inbox is a queue of proposed side effects.

Each item should show what will happen, why the agent believes it should happen, which records are affected, what sources were used, who can approve it, and when the proposal expires. The reviewer should not need to reconstruct the entire thread from scratch.

This matters because review time is the hidden cost of AI. A draft that saves five minutes but requires ten minutes of fact-checking is not an improvement.

The approval inbox should make the reviewer faster by carrying evidence and constraints with the proposal.

State re-checks prevent stale approvals

An approval is only valid against a specific business state.

If the customer replied after approval, the approved follow-up may be wrong. If pricing changed, the old renewal draft may be wrong. If another workflow already updated the CRM record, a retry may create a duplicate task. If inventory changed, a fulfillment message may no longer be accurate.

Before execution, the workflow should re-check the minimum state that must still be true:

• the goal is still active
• the affected record has not changed in a conflicting way
• the approval has not expired
• the proposal is still inside the approved scope
• the idempotency key has not already been executed
• the source evidence is still current enough for the action

This is where many agent demos break in real operations. The demo shows an action. The business needs the action to still be correct at the time it runs.

Where deterministic workflow tools fit

Workflow automation tools are excellent for deterministic plumbing: triggers, transformations, webhooks, retries, routing, record updates, and scheduled jobs.

The proposal envelope pattern does not compete with that. It gives the AI part of the system a contract before the deterministic part executes.

A practical setup can look like this:

workflow trigger
-> AI drafts proposal
-> policy check
-> approval inbox
-> workflow executes approved action
-> log result

That split is important. The workflow should not ask the agent to improvise every step.

The agent handles the messy judgment: what does this customer mean, which policy applies, what action should be proposed, and what evidence supports it. The workflow handles reliable execution after the proposal is allowed or approved.

A concrete example: a renewal email

Suppose a small SaaS company wants an agent to help recover renewals at risk.

The agent reviews account notes, support tickets, usage, billing status, and the latest human message. It decides that one customer should receive a retention email with a proposed support plan.

Instead of sending, the agent creates a proposal envelope:

• Goal: reduce churn risk for active customer accounts
• Target: Gmail and CRM
• Action: send a specific renewal email and create a CRM follow-up task
• Evidence: last support thread, usage drop, renewal date, account owner's note
• Risk: review required because the message mentions a service commitment
• Owner: account owner
• Expiry: 24 hours
• Re-check: do not send if the customer replied, renewal status changed, or another task already exists
• Log: save final email, approval decision, evidence, and outcome to the account timeline

That is reviewable business execution. The agent did useful work, but the human is not approving a black box. They are approving a concrete side effect with evidence and boundaries.

Checklist before agents touch live systems

1. Define which action types are low-risk, review-required, sensitive, or blocked.
2. Require a proposal envelope before any external side effect.
3. Route proposal envelopes through one approval inbox or shared review contract.
4. Add expiry times for approvals.
5. Use idempotency keys for sends, record updates, refunds, invites, and task creation.
6. Re-check state immediately before execution.
7. Log the proposal, evidence, policy decision, reviewer, action result, and failure state.
8. Measure cost and outcome by completed goal loop, not by number of agent runs.

If those pieces are missing, the next improvement is not a more powerful agent. The next improvement is a better operating contract around the agent.

At Manor AI, this is the workspace layer we are designing around: agents, skills, context, approval gates, policy checks, evidence logs, and goal loops that make business execution reviewable.

Originally published on the Manor AI blog: https://manorai.xyz/blogs/blog-ai-agent-policy-checks-proposal-envelope