Governing AI agents in revenue operations
A revenue agent writes to your CRM and sends messages to real people under your domain. Both are irreversible in ways teams underestimate: bad CRM writes corrupt the record everyone else trusts, and bad sends damage a domain reputation that takes months to rebuild.
Get an Agent Trust Gap BriefTwo irreversible surfaces, both underestimated
Outbound gets the attention because a bad email is visible. The quieter risk is the CRM. An agent with write access that mis-classifies a hundred accounts has corrupted the dataset every forecast, territory plan and commission calculation depends on — and unlike an email, nobody notices for a quarter.
Domain reputation is a shared, slow-recovering asset. An agent that sends outside policy does not just annoy recipients — it degrades deliverability for every legitimate message your company sends, including invoices and password resets. Sending caps are not a courtesy, they protect infrastructure.
What the agent is actually allowed to do
Governance starts by writing down the actions. Not capabilities, not integrations — the specific irreversible things this agent can cause to happen in the world, and what has to be true before each one is permitted.
| Action | Reversible? | Governing question |
|---|---|---|
| Read CRM, enrich, research accounts | Yes | Least privilege and lawful basis for the data being processed. |
| Draft a message | Yes | Nothing has happened yet. Drafting should be unconstrained; sending should not. |
| Write or update a CRM record | Practically no | Who else depends on this field? Bulk writes need a cap and a reversal path. |
| Send an email | No | Cannot be unsent. Volume cap, suppression list, lawful basis, and a receipt of exactly what went to whom. |
| Add someone to a sequence | No in effect | Commits to a series of future sends. Governed at enrolment, not at each send. |
| Change deal stage or forecast fields | No | Financial reporting effect. Should require corroboration, not agent assertion. |
How it fails
These are the failure modes that produce incidents in this workload specifically. Each maps to a control, not to a warning in a runbook.
- Silent CRM corruption. An agent updates a field based on a misread signal across hundreds of records. Forecasting degrades with no visible incident. Control: bulk-write caps, a diff preview, and an approval gate above a threshold.
- Suppression bypass. The agent enriches a list from a source that has not been checked against unsubscribes and legal suppression. Control: suppression enforcement at the send boundary, not at list build, because lists go stale.
- Volume spike. A loop or retry causes a send burst that trips spam filters. Control: hard per-hour and per-day caps with a breaker, enforced by the send owner rather than the agent.
- Lawful-basis gaps. Contacts are processed without an established basis, especially across EU and UK recipients. Control: basis recorded per contact and checked before enrolment.
- Attribution loss. A recipient complains and nobody can establish which run generated the message or on what data. Control: receipts binding each send to its inputs, template version and approver.
The controls that hold
Send-boundary enforcement
Suppression, volume caps and lawful-basis checks are enforced by the single component that owns sending — never by the agent asking nicely. If the agent is the only thing preventing a send, there is no control.
Bulk-write thresholds
Below the threshold the agent writes freely. Above it, a diff is generated and approval is required before anything commits.
Per-send receipts
What was sent, to whom, from which template version, on which data, approved by whom. This is what answers a complaint or a data-subject request.
Suppression at the boundary
Checked at the moment of sending against the live list, not at list build. Lists are stale by definition.
Domain-level rate governance
Caps sized to protect deliverability for the whole domain, not just this campaign. Shared infrastructure needs shared limits.
Reversal path for CRM writes
Every agent write is tagged and reversible as a set. If a run went wrong you can undo that run, not hand-correct records for a week.
Common questions
Should an AI agent have CRM write access?
Yes, with bulk-write thresholds, tagged writes and a reversal path. The risk is not a single wrong field — it is an unnoticed systematic error propagating through forecasting and compensation.
What sending controls does an outbound agent need?
Volume caps, suppression enforcement, and lawful-basis checks — all enforced by the sending component rather than the agent. Plus a per-send receipt so you can answer a complaint precisely.
How do we protect domain reputation?
Cap sending at the domain level, not per campaign, and put a breaker on repeated failures. Deliverability is shared infrastructure and recovers slowly.
What evidence do we need for a data-subject request?
What data was processed, on what basis, and what was sent as a result. Per-send receipts tied to inputs make this a lookup instead of an investigation.
Does this change if we use a third-party sending platform?
The controls have to live at the boundary that platform exposes. If the platform cannot enforce caps and suppression on the agent's behalf, you need a component in front of it that can.