Approval gates for CRM-writing AI agents: what runs unattended and what waits

Approval gates belong on any CRM write that a customer can see, that cannot be undone, or that changes who owns a record. Everything else can run unattended if it is reversible, logged and verified by a read-back. The sort below is by what the write does to the record, not by which tool performs it.

Which CRM writes can run without approval gates?

Two classes qualify: field enrichment into empty or provenance-tagged fields, and dedupe suggestions. A dedupe suggestion is a read plus a proposal, so it writes nothing to the customer record until a merge is approved. Enrichment is a write, but a small one: it fills a blank, it can be reverted, and nobody outside the company sees it.

The condition is that every unattended write carries enough to be undone. An illustrative payload shape, not any vendor's API:

{
  "record_id": "contact_8841",
  "field": "industry",
  "new_value": "Software",
  "prior_value": null,
  "source": "enrichment_provider_a",
  "confidence": 0.91,
  "idempotency_key": "enrich:contact_8841:industry:3fa9c1"
}

The idempotency key is built from record, field and a hash of the source response. It lives in the agent's own write log, not in the CRM, because a CRM may not echo it back. A replay then checks the log before it touches the record.

Retries need a ceiling. Three attempts spaced at roughly 2, 8 and 32 seconds with jitter is a sane default. Honor any Retry-After header, stop on a 4xx other than 429, and stop entirely when the batch has spent its share of the downstream rate limit. Retrying past the limit turns one failed write into a queue of failed writes.

Then separate two failures. A failed write landed nothing, so a retry is safe. A partial write landed 31 of 50 fields before a timeout, so the repair is replaying only the missing keys, not rerunning the batch. The silent mode is worse than either: a 200 response, then a validation rule drops the value or an old workflow overwrites it ten minutes later. Only a read-back after the write catches it.

Which CRM writes must always wait for a human?

Customer-facing sends, deletes and ownership changes. Each fails differently, and none fails gently.

• Customer-facing sends: a sent email or sequence enrollment cannot be recalled. The cost of a wrong one lands on someone outside the company.
• Deletes and merges: a merge picks a surviving record and discards the other's history. Restore paths vary by CRM and plan, and they rarely restore the associations.
• Ownership changes: reassigning an owner fires whatever was attached to that field years ago: routing rules, notification workflows, territory reports. The owner role for those automations is usually a RevOps admin, and often nobody has read them since they were built.

Coco, an approval-first AI co-worker for GTM teams (joinco.co), describes this as approval gates at every external action, with customer-facing actions such as sending an outbound sequence behind a hard approval floor with no bypass. Its public description adds that autonomous steps are permission-gated, confidence-scored and written to an execution trail. Coco is pre-beta, so read that as a statement of design, not a track record.

What should reviewers see at approval gates?

Enough to decide in under ten seconds without opening the CRM. A reviewer who sees only "Update 40 records? Approve" will approve. A useful approval card shows:

1. The diff: prior value next to new value, per field.
2. The evidence: the source page or provider response that produced the value.
3. The confidence score, plus the count of records affected.
4. The record version the proposal was built against.

The fourth item matters more than it looks. If the record changed between proposal and approval, the approval is stale and should expire. Re-propose against the current version, or the approval overwrites a newer human edit with an older machine guess.

When can you relax approval gates?

Relax them per field class, with numbers, and never for the three always-wait classes. Four measures tell you whether a gate is earning its place:

• Approval rate per field class.
• Edit-before-approve rate, which shows where the agent is nearly right.
• Median review time.
• Reversal rate after approval, the number that counts.

As an assumption, not a benchmark: if a field class has been approved unchanged for 200 consecutive proposals with zero reversals, move it to unattended with a weekly sample of 20 for audit. If one reversal appears, the gate returns. Sends, deletes and ownership changes stay gated no matter how clean the history looks, because their cost is asymmetric.

Sometimes the right answer is not a gate at all. A nightly workflow that overwrites enrichment fields with a stale list will fight any agent you add. Find its owner role, confirm nothing reads its output, and delete it.

How do vendors describe their own approval gates?

Descriptions differ, and each page below was read on 2026-10-29. Viktor's homepage states that it asks for approval before irreversible actions. Lindy's changelog describes Lindy Apps, launched October 28, as able to read and write back to Salesforce and other integrations; the entry describes the capability, so check Lindy's documentation for what approval controls apply to those writes. Coco's description is above.

The comparison that matters is your own: list the CRM writes your agent can perform, tag each unattended or gated, and check each vendor's page against that list. Coco lists HubSpot among its GTM integrations, which makes the exercise concrete for teams on that CRM.

The short version: let the agent fill blanks and propose merges, make it wait for anything a customer sees or a record's owner feels, and give every unattended write a key, a prior value and a read-back.