Policy Checks for AI Agents: The Proposal Envelope Pattern

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.

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 problem: approval scattered across tools

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, or whether another workflow touched the same record.

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. The human approved something, but the business state changed before execution.

The proposal envelope pattern

The proposal envelope pattern creates one object between agent reasoning and business action.

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.

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 a notification feed

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 for small businesses 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.

For Manor AI, this connects directly to approval gates and activity logs. The agent prepares the work. The workspace makes the proposal reviewable. The log lets the next loop inherit what happened.

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 n8n-style workflows 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:

n8n-style 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.

Manor AI's platform direction is to support this workspace layer around agents, skills, context, approvals, logs, and future n8n-style workflow compatibility. For the broader split, read the AI workspace vs automation builder guide.

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.

What Manor AI is designed to make visible

Manor AI is an AI business workspace for turning recurring work into reviewable goal loops. The proposal envelope is one of the practical patterns behind that idea.

The workspace should make these things visible:

• Which goal loop a proposal belongs to.
• Which agent and skill produced it.
• Which context and sources were used.
• Which policy rule paused, allowed, denied, or escalated the action.
• Who approved it and when.
• Whether the state was re-checked before execution.
• What happened after the action ran.
• Whether the business outcome improved.

This is the difference between more AI activity and better business operations. More agents are not enough. The business needs a workspace where agent proposals, approvals, tool actions, and results can be inspected as part of the same operating loop.

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.

Related Manor guides

For the broader operating model, read How AI Agents Handle Goal Loops in Business. For approval design, read Approval Gates and Activity Logs. For cost framing, read AI Agent Cost for Small Business. For first workflow examples, use the AI Agent Workflow Library.