The Governed Write Path: How Approve, Pending and Deny Keep Agents Honest
Many safety properties of a governed system depend on one design choice: there is exactly one way to change data, and every change passes through it. This post explains how the approve, pending and deny pattern works, why three outcomes are usually enough, and where AI PRO CRM stands today.
One path, no exceptions
In this pattern, humans editing a record in the UI, agents calling tools and scripts calling an API all end up in the same place: a write request that names the principal, the target record, the proposed change and the reason. There is no bulk import that skips the check and no “admin override” that bypasses logging.
This sounds restrictive, but it is what makes the system simple: one place to test, log and enforce policy.
Outcome one: approve
If the policy for this principal, action and record says the change is within bounds, it is applied immediately and logged with the decision. Most agent writes should land here. A note added by a research agent or a task created by an assistant usually should not wait for a human.
Outcome two: pending
If the change is plausible but consequential, it becomes a proposal. Proposals sit in a review queue with the diff, the agent’s stated reason and the surrounding record context. A human can approve as-is, edit and approve, or reject. Ideally the agent can also check the status of its own proposals.
Typical pending cases: changing a deal value or stage, merging two people, deleting anything, editing a sensitive field.
Outcome three: deny
If the change is outside the agent’s role or violates a hard rule, it is refused and logged. The agent should receive a structured error explaining what blocked it, so a well-built agent can adapt rather than retry blindly.
Why not more states?
Escalation, partial approval and expiry look thorough on paper, but every extra state is another thing for an agent to misunderstand and a human to misread.
What AI PRO CRM does today
AI PRO CRM does not include an approval inbox today: agent writes are limited to internal notes, by preset, daily cap and idempotency, while external governance is not connected yet. There are no pending proposals and no policy rules to configure.
Instead the write path is deliberately narrow. The only agent write is the activity_note_create MCP tool, which adds an internal plain-text note to an existing company, for Assistant and Operator agents only. Every call needs an idempotency key: a replay returns the original note, and a changed payload with the same key is rejected. Successful writes count towards a per-agent daily cap, and each call is logged with the agent, tool, status and record ids. Agents cannot change deal stages, create tasks or edit fields.
Designing good policies
If you are building or choosing a system that does offer approval routing:
- Start with everything pending, then promote actions to auto-approve as you build trust.
- Deny by default for deletes and merges.
- Make reasons mandatory; an agent that cannot say why it is changing a record should not change it.
FAQ
Does the pending queue become a bottleneck?
Only if policies are too conservative. Aim for the queue to hold a handful of items a day, each of which takes seconds to decide.
Can a human bypass the write path?
In a well-designed approval system, no: human edits use the same path with different policies, which keeps the audit trail complete. In AI PRO CRM, human changes are recorded in an append-only audit trail, and approval routing is not part of the product today.