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.
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.
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 s 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:
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.
A useful proposal envelope includes:
This is much easier to review than a vague notification saying the agent wants to update something.
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:
The decision should come with a reason. A reviewer should know whether the workflow d because of missing evidence, customer impact, money movement, public visibility, policy mismatch, or stale state.
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.
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:
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.
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.
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:
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.
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