Coco
Register for Beta

AI with approval gates

An approval gate is a control point in an AI workflow where the system pauses before taking an external action — sending an email, writing to a CRM, posting to a channel, spending budget — and surfaces the proposed action to a human for review. The gate is the structural mechanism behind "human-in-the-loop AI." Approval gates exist on a spectrum: at one end, AI suggests and humans execute (low autonomy); at the other end, AI executes autonomously within rules humans defined ahead of time (high autonomy with pre-authorization). The middle ground — AI proposes, human reviews, AI executes — is where most production AI co-workers operate. Approval gates are the trust scaffolding that makes autonomous AI safe to deploy on actions with real-world consequences.

What an approval gate is

The mechanism is structural. At a defined point in an AI workflow, the system stops execution, surfaces a proposal to a human, and waits for an explicit decision before continuing. The proposal typically includes: the action the AI intends to take, the data the action will affect, the cost or impact the action will have, and the reasoning behind the proposal.

A concrete pattern: an AI agent has been asked to clean up duplicate contacts in a CRM. The agent identifies a duplicate pair. Instead of merging the records autonomously, the agent surfaces the proposal — "merge contact A into contact B, based on matching email and similar name; the merge will combine deal history" — and waits for the operator to approve, modify, or reject before executing.

The defining property: the AI does not take the external action until the human approves. The gate is the seam between the reasoning (which the AI runs autonomously) and the action (which the AI runs only with permission).

Why approval gates matter

AI agents take actions in the world. Actions have consequences. Approval gates make the consequences governable.

The risks AI agents introduce, in the absence of approval gates:

  • Irreversibility. Some external actions can't be undone. A sent email can't be unsent. A deleted record can't always be recovered cleanly.
  • Brand and reputation risk. AI drafting in the user's name produces output the user is accountable for. A poorly-judged tone or factual error in an outbound email lands on the user's reputation.
  • Cascading errors. Autonomous AI across multiple systems can compound a single bad decision across many actions before any human notices.
  • Compliance and audit failures. Actions taken without human authorization may violate internal controls, contractual obligations, or regulatory requirements.

Approval gates create a friction point that addresses all four. The friction is deliberate; it's the cost of the trust model. Most production AI co-workers accept the friction in exchange for the ability to delegate work that would otherwise be too risky to delegate.

The autonomy spectrum

Approval gates aren't binary. AI products implement them along a spectrum:

Level 1 — Suggest only. AI proposes actions; humans execute them. Most AI copilots operate here. Lower autonomy, lower risk, lower output gain.

Level 2 — Approve-each external action. AI proposes and executes only after explicit human approval, action by action. The most conservative posture. Common for early adoption of new workflows.

Level 3 — Approve-pattern (autonomous within rules). A human approves a class of actions in advance — for example, "auto-merge duplicate contacts with matching email and same last name" — and the AI runs that class autonomously, surfacing only the exceptions.

Level 4 — Fully autonomous with post-hoc audit. AI acts; human reviews the audit log after the fact. Reserved for low-risk or high-volume actions where pre-approval would be impractical.

Production AI co-workers typically support multiple levels and let the human configure which applies to which workflow. A research workflow might run at level 4. A first-touch outbound workflow might start at level 2 and graduate to level 3 over time.

The trust ladder

Most production AI deployments move along the spectrum over time. The pattern:

  1. Start at approve-each. New workflow, unfamiliar behavior, conservative posture.
  2. Refine the workflow. Edits to the AI's drafts, corrections to its reasoning, adjustments to the criteria. The AI's behavior shifts toward what the human wants.
  3. Graduate to approve-pattern. After multiple successful runs, the human authorizes the pattern; the AI runs it autonomously inside the rules.
  4. Exception handling stays in the loop. Edge cases continue to surface for human review. The trust on routine actions doesn't bleed into trust on the edge cases.

The ladder isn't a one-way ratchet. If a graduated workflow drifts, the human can downgrade it back to approve-each or pause it entirely. The autonomy is a setting, not a permanent state.

What gets gated, what doesn't

The standard pattern across production AI co-workers: reads are free; writes are gated.

Typically not gated (run freely):

  • Reading data from connected sources (CRM records, email threads, calendar events, public web).
  • Reasoning about the data (analysis, summarization, decomposition into steps).
  • Drafting content for human review (outreach drafts, follow-up emails, meeting notes, briefs).
  • Internal compute the AI uses to arrive at proposals.

Typically gated (require approval at first):

  • Sending external messages (email, LinkedIn, SMS, channel posts).
  • Writing to systems of record (CRM record updates, stage changes, field modifications).
  • Spending budget (third-party API calls with per-call cost, ad-buying actions).
  • Booking actions that affect other people's time (meeting scheduling on a counterpart's calendar).
  • Irreversible operations (record deletion, merge actions, lifecycle-stage progression).

The boundary between "read" and "write" maps roughly to the boundary between "what the AI knows" and "what the AI does." The first is free; the second is gated.

Approval gates vs. brittle rule-based systems

Earlier generations of automation (rule-based workflow engines, IFTTT-style triggers, traditional marketing automation) relied on rules a human designed at configuration time. The rule fired at runtime if the conditions matched. The rule didn't fire if they didn't.

The failure mode of rule-based automation is the edge case. The rule was designed for the typical case. The edge case doesn't match, so the rule doesn't fire, and the action doesn't happen. Or the rule matches a case it shouldn't have, and an action happens that shouldn't have.

AI with approval gates handles edge cases differently. The AI reasons about the case at runtime. If the case is routine and matches an approved pattern, the action runs. If the case has unusual properties, the AI surfaces it for human judgment rather than guessing.

This is a structural improvement over rule-based systems for any workflow where the case mix is varied. The cost is the friction of approval; the benefit is reliable edge-case handling without exhaustive rule design. A credit-based pricing model pairs well with approval gates because the per-action cost is visible at the approval point itself.

How Coco implements approval gates

Coco operates on the approval-first model by default. Every external action — sending an email, writing to a CRM, posting to Slack, spending credits on a third-party API — gates on approval at the start, until the user explicitly authorizes the specific workflow for autonomous execution.

The interface is a plan card. Before any run, Coco proposes a plan with the action it intends to take, the data it will affect, the estimated credit cost, the estimated time, and a "change plan" option. Once the user approves, Coco runs the plan. External actions inside the plan still surface individually for approval if the workflow hasn't been graduated.

The graduation path follows the trust ladder above. After enough successful runs (typically three to ten depending on the workflow's risk profile), the user can pattern-approve for autonomous execution inside the rules they set. Exceptions still surface; routine actions stop needing per-action approval.

The audit trail logs every action either way: what was proposed, what was approved, what was executed, what it cost. See the security model → for what gets logged.

For the broader autonomy spectrum, see autonomous vs supervised AI →. For Coco's architecture, see how it works → or why Coco →.

Pricing reflects the model: credits per unit of work, with the cost visible in the plan card before approval. About 4-6 credits per outreach draft, about 1 credit per record enriched, about 8 credits per pre-meeting brief.

Frequently asked questions

What's the difference between approval gates and rule-based automation?

Rule-based automation runs when conditions a human pre-defined are met. Approval gates surface a proposal for human review at runtime, regardless of whether conditions match a rule. The two patterns can coexist — rule-based automation handles high-volume deterministic work; approval gates handle the work that requires human judgment per instance.

Do approval gates slow down AI?

Yes, by design. The friction is deliberate. The trade-off is between throughput (autonomous AI runs faster) and trust (gated AI runs safer). For high-stakes actions with real-world consequences, the safer side usually wins. For low-stakes, high-volume actions, gates are sometimes the wrong call — those workflows typically graduate quickly to higher autonomy.

When are approval gates the wrong choice?

For high-volume, low-risk actions where per-action review is impractical — read operations, internal reasoning, mass-enrichment of low-importance records, scheduled re-evaluation of static segments. Most production AI uses gates for the highest-risk actions and graduates lower-risk actions to higher autonomy.

Who is the "human" in human-in-the-loop?

The accountable operator — typically the user whose account would execute the action. The human reviewing the proposal is the same human whose name (or domain, or signature) the action will be attributed to. In team contexts, the approval can route to a delegate, but the default is the action's owner.

How does an AI graduate out of approval gates?

Through pattern approval: humans authorize a class of actions in advance based on observed behavior. The AI continues to take actions inside the approved class autonomously; actions outside the class continue to gate. The graduation is reversible — if the AI's behavior drifts or produces output the human disagrees with, the workflow can be moved back to approve-each.