{"slug": "policy-checks-for-ai-agents-the-proposal-envelope-pattern", "title": "Policy checks for AI agents: the proposal envelope pattern", "summary": "An engineer proposes the 'proposal envelope' pattern for governing AI agents in business workflows, where agents must produce a structured record of proposed actions before executing side effects like sending messages or changing records. The pattern includes policy checks, approval inboxes, and state re-checks to ensure actions are reviewed and remain valid, addressing the risk that AI agents can change business state in ways that are hard to govern.", "body_md": "AI agents become useful in business when they can move work forward. They also become risky at exactly that moment.\n\nReading 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.\n\nThat 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.\n\nThe pattern I keep coming back to is the **proposal envelope**.\n\nA 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.\n\nIt 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.\n\nThe flow looks like this:\n\n``` php\nagent output\n-> proposal envelope\n-> policy check\n-> approval inbox\n-> state re-check\n-> action\n-> evidence log\n```\n\nThe 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.\n\nMost early agent workflows grow from small experiments.\n\nA 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.\n\nEach rule may be reasonable on its own. The problem is that the review system becomes scattered.\n\nNobody can easily see:\n\nThat 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.\n\nA useful proposal envelope includes:\n\nThis is much easier to review than a vague notification saying the agent wants to update something.\n\nThe policy check should be boring. That is a feature.\n\nIts job is not to rethink the whole business problem. Its job is to classify the proposal and decide what happens next:\n\nThe 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.\n\nA real approval inbox is a queue of proposed side effects.\n\nEach 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.\n\nThis 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.\n\nThe approval inbox should make the reviewer faster by carrying evidence and constraints with the proposal.\n\nAn approval is only valid against a specific business state.\n\nIf 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.\n\nBefore execution, the workflow should re-check the minimum state that must still be true:\n\nThis 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.\n\nWorkflow automation tools are excellent for deterministic plumbing: triggers, transformations, webhooks, retries, routing, record updates, and scheduled jobs.\n\nThe proposal envelope pattern does not compete with that. It gives the AI part of the system a contract before the deterministic part executes.\n\nA practical setup can look like this:\n\n``` php\nworkflow trigger\n-> AI drafts proposal\n-> policy check\n-> approval inbox\n-> workflow executes approved action\n-> log result\n```\n\nThat split is important. The workflow should not ask the agent to improvise every step.\n\nThe 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.\n\nSuppose a small SaaS company wants an agent to help recover renewals at risk.\n\nThe 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.\n\nInstead of sending, the agent creates a proposal envelope:\n\nThat 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.\n\nIf those pieces are missing, the next improvement is not a more powerful agent. The next improvement is a better operating contract around the agent.\n\nAt 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.\n\nOriginally published on the Manor AI blog: [https://manorai.xyz/blogs/blog-ai-agent-policy-checks-proposal-envelope](https://manorai.xyz/blogs/blog-ai-agent-policy-checks-proposal-envelope)", "url": "https://wpnews.pro/news/policy-checks-for-ai-agents-the-proposal-envelope-pattern", "canonical_source": "https://dev.to/calvin_lin_816fc5a7ce26a1/policy-checks-for-ai-agents-the-proposal-envelope-pattern-1ono", "published_at": "2026-08-24 20:44:25+00:00", "updated_at": "2026-08-24 21:14:28.703754+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy", "ai-products"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/policy-checks-for-ai-agents-the-proposal-envelope-pattern", "markdown": "https://wpnews.pro/news/policy-checks-for-ai-agents-the-proposal-envelope-pattern.md", "text": "https://wpnews.pro/news/policy-checks-for-ai-agents-the-proposal-envelope-pattern.txt", "jsonld": "https://wpnews.pro/news/policy-checks-for-ai-agents-the-proposal-envelope-pattern.jsonld"}}