โ†
AI Agent Builders & Citizen Developers
Proficient ยท M2 ยท lesson 2 of 34 ยท queued
Preview โ€” browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll โ†’
Choosing the Three HITL Modes: Suggest, Approve, Co-Pilot
๐Ÿ“–
now learning

Choosing the Three HITL Modes: Suggest, Approve, Co-Pilot

15 min

In February 2026, a 40-person ops team at a Series C logistics company sat through a quarterly review and discovered something inconvenient. Their flagship invoice-reconciliation agent had been live for eleven weeks. It had emitted 4,180 approval requests. The team's median time-to-approval was 0.6 seconds. Their approval rate was 99.4%. When the head of finance pulled the 12 cases the agent had asked humans to override and walked through them with the reviewers, three of the twelve had been rubber-stamped wrong. The wrong-approval rate was 25%. The post-mortem found a perfectly diagnosable failure: the team had picked the wrong human-in-the-loop mode. They had chosen Approve when the task wanted Suggest. The reviewers were spending zero cognitive effort because the agent was right 99.4% of the time, and the 0.6% where it was wrong was hidden under the 99.4% it was right. The "approve-spam" failure mode โ€” humans rubber-stamping every notification in under a second because cognitive load is below the threshold of attention โ€” is now a named anti-pattern in the 2026 agent literature, and the cause is almost always the same. The builder picked the wrong HITL mode. This lesson is how to pick the right one.

The Three HITL Modes, Named and Bounded

The 2026 agent practitioner community has settled on three distinct human-in-the-loop interaction patterns. They are not synonyms. They are not interchangeable. Each one has a specific shape, a specific cognitive load profile, and a specific failure mode when misapplied. Knowing the three by name is the prerequisite for choosing correctly.

Mode 1: Suggest

The agent produces a draft, a recommendation, or a candidate action. A human chooses whether to use it, typically by reading the draft, accepting some of it, editing the rest, and shipping the final version themselves. The human does the action. The agent assists. The default is "human ships nothing unless they actively chose to."

Canonical examples: GitHub Copilot inline suggestions, Cursor tab completions, Gmail Smart Compose, Claude artifacts in a chat, Notion AI's "ask AI to write" inside a doc. The human is the author and ships the final product; the agent makes the author faster.

Mode 2: Approve

The agent produces a complete proposed action โ€” a drafted email, a Salesforce field update, a refund issuance โ€” and waits. A human reviewer either approves (action executes as-is), edits-and-approves (action executes with modifications), or rejects (action does not execute). The agent ships the action after the human green-lights. The human does not author; the human gatekeeps.

Canonical examples: the Slack approve/edit/reject card for outbound customer emails, the Teams Adaptive Card for high-dollar refunds, n8n's human-approval node, Lindy's confirmation flow before external send. The human is a gatekeeper; the agent is the actor.

Mode 3: Co-Pilot

The agent and human work synchronously inside the same task surface. The agent proposes, the human edits, the agent reacts to the edits, the human ships. The interaction is not "one shot then review"; it is continuous turn-taking. Both are actors and both are authors. The session is bounded by the task, not by a single decision.

Canonical examples: Claude Code running side-by-side with a developer on a code change, Cursor's composer view with multi-file edits, Devin running a long task and pausing for clarification, ChatGPT Canvas / Claude Artifacts for collaborative document drafting, the Hex notebook AI for live data analysis. Both parties iterate; the session ends when the task is shipped.

Suggest is for tasks where the human owns the output. Approve is for tasks where the agent owns the output and the human gates risk. Co-Pilot is for tasks where the work is genuinely shared and neither party can do it alone in a reasonable time.

The "Approve-Spam" Failure Mode, Explained

The named anti-pattern of 2026 is approve-spam, and the data behind it is now unambiguous. Studies from agent observability vendors (LangSmith, Braintrust, Helicone) consistently show the same curve: when an Approve-mode workflow runs above a 95% approval rate over a four-week window, median time-to-approval collapses to under 1.0 seconds. Below 90% approval rate, median time-to-approval stays in the 12โ€“40 second range. The transition is sharp; there is essentially no middle.

The mechanism is well-studied. Humans pattern-match. If the agent has been right 50 times in a row, the brain learns that the modal action is "click approve." The next time the card appears, the reviewer's brain is already on its way to the approve button before the eyes finish the context line. Approval becomes a reflex, not a decision. Reviewers will tell you they're reading carefully; the eye-tracking data says they aren't.

The 0.6-second number and what it means

0.6 seconds is the rough threshold below which it is not physically possible to have read and comprehended a multi-sentence draft. Reading 200 words of email body takes 3โ€“8 seconds at fast comprehension speeds. A 0.6-second approval cannot include "read the body." It can only include "see the card, click button." The fact that this is happening at scale across organizations means the human-in-the-loop is no longer a control; it is a performance.

The corollary: any Approve-mode workflow with a sustained median TTA under 2 seconds has effectively become Auto-Execute with extra audit overhead. The human is not adding signal. The audit log says "approved by Sarah K." but the safety property โ€” that Sarah looked at the action and judged it โ€” is gone.

The three diagnostic signals that you have approve-spam

  • Median TTA under 2 seconds. Pull the data from your workflow platform's audit log. If half of approvals are happening faster than reading time, you have approve-spam.
  • Approval rate over 98%. If the agent is right almost every time, the human contributes nothing on the modal case and is unlikely to catch the rare wrong case.
  • Override rate equals random. If the cases the human did override do not have systematically different characteristics from the cases the human approved, the human is not actually discriminating.

Two of three diagnostic signals firing means you have a mode-selection problem. Move the workflow to Suggest, or move the workflow to fully autonomous with post-hoc audit, but don't keep the human in front of a button they no longer functionally press.

Picking the Right Mode: the Three-Axis Decision

The mode decision is a function of three axes. Score the task on all three; the combination tells you the mode.

Axis 1: Reversibility of the action

How recoverable is the action if wrong? Editing a Notion page is fully reversible โ€” diff, restore, move on. Sending an email to a customer is partially reversible โ€” the email is gone, but the relationship is intact. Issuing a refund of $50 is partially reversible โ€” money moves but can be reversed with friction. Issuing a refund of $50,000 is operationally reversible but politically costly. Posting to LinkedIn from the company account is barely reversible. Sending wire instructions is irreversible.

The less reversible the action, the more the case for Approve mode. The more reversible the action, the more the case for Suggest (where the human will choose anyway) or Co-Pilot (where the iteration absorbs mistakes).

Axis 2: Stakes of the wrong decision

Distinct from reversibility. A reversible action can still be high-stakes if the failure has a reputational, regulatory, or relationship cost. Replying to the wrong customer with someone else's data is reversible (you can send a correction) but the customer-trust cost is unbounded. A typo in a marketing email is reversible (send a follow-up) but the cost is small.

High stakes pushes toward Approve. Low stakes pushes toward Suggest or autonomous.

Axis 3: Frequency and cognitive load on the human

How often will this happen? If the task fires 5 times a day, a 60-second approval card is a 5-minute daily tax โ€” sustainable. If it fires 500 times a day, the same card is an 8-hour tax. The human will either ignore it or batch-spam through it. Frequency on the agent side directly determines whether Approve mode is psychologically sustainable on the human side.

High frequency with low stakes pushes toward Suggest. High frequency with high stakes is the hardest combination and usually requires either a tiered approval (route only the high-risk cases) or moving to a Co-Pilot pattern where the human is engaged with the task as a session, not as a stream of cards.

The decision matrix

  • High reversibility + Low stakes + Any frequency โ†’ Suggest (or autonomous with audit).
  • Low reversibility + High stakes + Low frequency โ†’ Approve. This is the canonical case; the human gates the rare important action.
  • Low reversibility + High stakes + High frequency โ†’ Tiered Approve with routing, or Co-Pilot session. Pure Approve will collapse into approve-spam.
  • Any reversibility + Medium stakes + Continuous task โ†’ Co-Pilot. The task is a session, not a series of decisions.
  • Low reversibility + Low stakes + Medium frequency โ†’ Approve, but design the card for a sustained 10โ€“30 second TTA.

Concrete Examples: Twelve Tasks, Three Modes

Patterns get clearer with cases. Twelve real tasks operators have shipped in 2026, with the right mode and the failure mode of the wrong mode.

Suggest-mode tasks

  1. Email drafts inside Gmail / Outlook. The user is composing the email; the agent suggests a draft they can adopt, edit, or ignore. Wrong mode: Approve would force the user to "approve their own draft," which is nonsensical.
  2. Code completion in Cursor / Copilot. The developer types; the agent suggests. The developer accepts via Tab. Wrong mode: Approve would put a button in front of every completion and kill flow.
  3. Salesforce note-taking from a call transcript. The agent drafts a call summary; the AE reviews and pastes into Salesforce, editing as needed. Wrong mode: Approve would have the agent post to Salesforce and the AE click approve, but the AE wants to edit aggressively โ€” Suggest is the right shape.
  4. Document outlining inside Notion / Google Docs. The agent proposes an outline; the writer adopts or replaces. Wrong mode: any other mode interrupts the writing flow.

Approve-mode tasks

  1. Outbound customer email from a support agent (CS workflow). The agent drafted the response; a senior CS person approves before send. Stakes (customer trust) are high; reversibility is partial; frequency is moderate (10โ€“40/day per reviewer). Wrong mode: Suggest would lose the gating; autonomous loses the trust safety net.
  2. Refunds over $500. The agent recommends a refund based on policy; a finance approver green-lights. Wrong mode: autonomous is what the auditors will flag.
  3. Field-update agent writing to production records. The agent proposes a Salesforce field change based on a transcript; an ops manager approves. Wrong mode: autonomous risks silent data corruption.
  4. External LinkedIn post on a company account. The agent drafts the post; a marketing reviewer approves. Wrong mode: autonomous is the one tweet that ends up on Hacker News.

Co-Pilot-mode tasks

  1. Building a customer-facing report with Claude Code or Cursor. The analyst drives the question; the agent runs SQL, drafts text, iterates with the analyst. Wrong mode: Approve breaks the iteration cadence; Suggest is too thin for the multi-step work.
  2. Drafting a contract amendment with an in-house lawyer. The agent does the boilerplate; the lawyer marks up; the agent revises. Wrong mode: Approve treats the contract as one decision; the work is dozens of decisions.
  3. Investigating an incident in Honeycomb / Datadog with an agent assistant. The on-caller queries; the agent runs the queries; the on-caller drives the hypothesis. Wrong mode: Approve adds friction in a high-urgency loop.
  4. Building a campaign brief in Notion AI / ChatGPT Canvas. The marketer steers; the agent generates and revises. Wrong mode: Approve treats this as a card; it's a session.

The Anti-Patterns and the Stories Behind Them

Anti-pattern 1: Approve on a 99% task โ€” the logistics-team story

The logistics ops team from the opener. The invoice-reconciliation agent was matching POs to invoices to receipts with very strong accuracy. 99.4% of the time the agent's match was correct. The team kept the human in the loop because finance compliance "wanted a human signature on every match." Twelve weeks in, the wrong-approval rate on the rare hard cases was 25%, and three of the twelve overrides were rubber-stamped wrong. The fix: move to Suggest mode with auto-execute on the 99.4% confident cases and surface only the 5% the agent itself flagged as uncertain. After the change, median TTA on the surfaced cases went from 0.6 seconds to 22 seconds, override rate on surfaced cases jumped to 18% (from 0.6% systemwide), and total reviewer time dropped 87% because the 95% no-longer-routed cases never hit a card.

Anti-pattern 2: Suggest on a low-trust task โ€” the marketing-email story

A B2B marketing team in 2025 wired an agent into their HubSpot to "suggest" send-ready drip emails. The agent surfaced suggestions in a side panel. The drip emails were being sent on a schedule; the agent's suggestions were getting incorporated as the marketer accepted them. Within three weeks, the marketer was accepting suggestions wholesale and three customer-segmentation errors went out before anyone noticed โ€” the agent had been confidently wrong about who was in which segment and the marketer wasn't actively checking. The right mode was Approve: route to a marketing-ops reviewer with the actual segment list visible, not Suggest mode that hides the decision in flow.

Anti-pattern 3: Co-Pilot on a one-shot task โ€” the resume-screening story

A recruiting team tried to "use Claude as a co-pilot" for resume screening. Each resume opened a chat where the recruiter and Claude went back-and-forth. The task averaged 4 minutes per resume; the prior process averaged 90 seconds. The chat surface invited deliberation on cases that didn't need it. The right mode was Approve: agent ranks and recommends, recruiter approves or overrides in a card. Co-Pilot is overhead when the task is genuinely one-shot.

Anti-pattern 4: No human at all on a reversible-but-public task โ€” the Twitter-bot story

A mid-2025 case: a SaaS company ran an autonomous "thank customers on Twitter" agent. Mostly fine. One day the agent thanked an account whose handle was a slur. Twitter screenshot. CEO apology thread. The action was technically reversible (delete the tweet) but the reputation cost was not. The right mode was Approve, and the lesson was: reversibility and stakes are different axes; a low-reversibility-cost action can still be a high-stakes action.

The Tiered Approval Pattern for High-Frequency, High-Stakes Tasks

The hardest combination is high frequency plus high stakes. Pure Approve mode will collapse into approve-spam. Pure autonomous violates the risk posture. The tiered approval pattern is the canonical 2026 answer.

How tiering works

The agent self-classifies each action into three tiers based on confidence, dollar value, recipient, and any other risk dimensions:

  • Tier 1 โ€” Routine. High confidence, low dollar, internal-only, no PII flags. Auto-execute with audit log. No human approval.
  • Tier 2 โ€” Standard. Medium confidence or medium dollar value. Approve mode with a 30-second card. Routed to the standard reviewer.
  • Tier 3 โ€” Escalated. Low confidence, high dollar, external recipient, or any red flag. Approve mode with a richer card and routed to a senior reviewer with explicit hold and a longer SLA.

The point is that the human is only seeing cards where their judgment matters. Approve-spam disappears because the routine cases never appear. The reviewer brain stays engaged on the cards it sees because they're consistently non-trivial.

Calibrating the tiering thresholds

The threshold-setting is the work. Start conservative: only the agent's most confident, lowest-risk cases auto-execute. Watch the override-on-Tier-2 rate. If it's under 5% sustained for two weeks, you can raise the Tier-1 threshold to capture more cases. If it's over 15%, lower the threshold and route more to Tier 2. The thresholds are not static; revisit them every 90 days against the rolling baseline (Lesson 3 of this chapter).

Real example: a refund agent with three tiers

A consumer fintech in 2026 runs a refund agent. Tier 1: refunds under $25 with no chargeback history, agent confidence above 0.92. Auto-execute. Audit-only. Roughly 73% of cases. Tier 2: refunds $25โ€“$500 or chargeback history present. Approve mode, routed to CS team lead. Roughly 22% of cases. Tier 3: refunds over $500 or any fraud-signal trigger. Approve mode, routed to a director with hold-for-questions. Roughly 5% of cases. The CS team lead sees about 30 cards a day; the director sees about 7. Both have median TTA in the 18โ€“35-second range; override rates are 12% (Tier 2) and 30% (Tier 3). The agent itself processes 600+ refunds a day. Approve-spam is structurally prevented because each tier surfaces only cases that warrant attention.

The Shape of a Good Suggest-Mode Experience

Suggest mode is misunderstood as "show the user a draft and they pick or ignore." That is one shape. The good Suggest-mode experience has more discipline.

Friction-light surface

The suggestion appears in the surface where the user is already working โ€” inline in the editor, in a side panel of the document, as a ghost-text completion in the field. The user accepts with one key (Tab) or one click. If accepting takes more friction than typing the text themselves, the user will not adopt it.

Multiple alternatives without forcing a choice

GitHub Copilot offers cycling through alternatives with Alt+]. Cursor offers multiple completions in some surfaces. The right Suggest UX often shows 1โ€“3 alternatives so the user picks the closest-to-right instead of editing the only-one-shown. Forcing a single suggestion creates worse outcomes than offering several.

Adoption telemetry as the feedback loop

In Suggest mode you don't get an explicit approve / reject. You get adoption: did the user accept, ignore, or modify? Track these as your quality signal. Suggestion-acceptance rate trending down means the model is regressing on the user's task; trending up means it's getting useful.

What kills Suggest mode

Three killers: latency above 800ms (the user has already typed past it), more than one decision surface for the same task (now the user is comparing UIs not doing work), and "always-on" suggestions where the user can't turn them off when they want quiet (the user disables the feature entirely instead of toggling it).

The Shape of a Good Approve-Mode Experience

Approve mode is the most easily-broken mode because the design is two layers โ€” the routing decision and the card design. We cover the card itself in Lesson 2; here we cover the routing.

One reviewer per card, named

The card goes to a specific named human, not a channel. Channel-routed approvals diffuse responsibility โ€” the first person who clicks wins, or no one clicks because everyone assumes someone else will. Named routing creates accountability and pulls TTA into the engaged range.

Backup if the named reviewer is out

The card escalates to a backup after a configurable timeout. Default backup: the reviewer's manager. Default timeout: 30 minutes for medium-stakes, 4 hours for low-stakes, 5 minutes for incident-grade. The backup chain is named in code, not in tribal knowledge.

Risk-signal pre-attention

The card uses color, icon, or position to pre-attention the reviewer when the agent's own confidence is low or risk flags fired. Green badge means "agent thinks this is routine"; yellow badge means "agent thinks this needs your attention"; red badge means "agent flagged a possible issue, please look closely." This is a calibration display, not a permission to skip. Studies show reviewers spend 3-4x more time on red-badge cards than green-badge cards โ€” which is exactly what you want.

Override reason capture (always)

Every rejection or edit captures a free-text override reason. The reviewer writes one sentence about why. This data is the training signal for Lesson 3 of this chapter. If you skip override capture, you lose the only artifact that lets you improve the agent over time.

The Shape of a Good Co-Pilot Mode Experience

Co-Pilot is the newest of the three modes and the least standardized in 2026. The shape is converging but not settled.

Persistent session, not stateless calls

The agent and human are in a session. The agent has full context of what's been discussed, what's been tried, what was rejected. The human can refer back to prior turns. The session has a beginning (task start) and an end (task ship). Treat it like a pair-programming session, not like a series of independent prompts.

Visible agent state

The human can see what the agent has done, what it's currently doing, what tools it's called. Claude Code, Devin, and Cursor's composer all show this โ€” file diffs, tool-call history, intermediate outputs. The human stays oriented because the agent's actions are not hidden.

Interrupt-and-redirect at any point

The human can stop the agent mid-execution, change direction, or rewind. The agent does not lock into "I have to finish this plan." Long-running agents that don't accept interruption are a usability failure.

Defined ship moment

The Co-Pilot session ends when the human ships. The agent does not auto-ship at session end. The handoff from "we're working on it" to "it's live" is always a human action. This is what separates Co-Pilot from "long-running autonomous agent with periodic check-ins."

How to Choose the Mode on Day One

The mistake is choosing the mode late, after the workflow has already been built and the UX is fighting the mode. Choose first; design second.

The five-minute mode-selection routine

  1. Write the task in one sentence. "Agent drafts a refund email and the team lead approves before send." Concrete and bounded.
  2. Score the three axes. Reversibility (low / medium / high). Stakes (low / medium / high). Frequency (low / medium / high).
  3. Apply the decision matrix. The matrix above gives you the mode. If two modes seem plausible, the more restrictive one is usually correct for the first version.
  4. Estimate cognitive load. If the chosen mode is Approve, multiply: cards-per-day ร— 30 seconds = daily reviewer tax. If the tax is over 60 minutes for one reviewer, redesign the routing (tiered approval, multiple reviewers).
  5. Name the failure mode you most fear. Write it on the spec. If the failure mode is "approve-spam," redesign before building. If the failure mode is "human ships nothing because Suggest didn't surface enough confidence," reconsider Suggest.

Re-evaluating the mode

The mode is not permanent. Re-evaluate at the 90-day rolling baseline (covered in Lesson 3). Symptoms that the mode needs to change:

  • Approve mode with TTA under 2 seconds sustained โ†’ move to tiered Approve or Suggest.
  • Suggest mode with adoption under 15% โ†’ reconsider whether the agent is producing useful drafts.
  • Co-Pilot mode where sessions are routinely under 60 seconds โ†’ the task isn't really shared work; move to Approve or Suggest.
  • Approve mode with high override rate (over 25%) โ†’ the agent isn't ready; pull back to Suggest or sandbox.

Story: The Three-Mode Decision That Saved a Launch

A 150-person B2B SaaS company in March 2026 was three weeks from launching their customer-facing agent program. The plan was a single agent that did three things: drafted onboarding emails to new signups, suggested product-feature copy to the product-marketing team, and worked side-by-side with the support team to investigate customer issues. The launch was a fixed date because it was tied to the company's user conference.

The first internal demo went badly. The "single agent" felt schizophrenic. In an onboarding-email path it was waiting for an approval. In the product-marketing path it was producing endless side-panel suggestions that never got adopted. In the support-investigation path it was being interrupted constantly and felt sluggish. The CRO threatened to pull the launch.

The team's lead AI engineer pulled the three uses apart on a whiteboard and named the modes. The onboarding email is Approve: low frequency, customer-facing, gating needed. The product-marketing copy is Suggest: the marketers want options, not approvals. The support investigation is Co-Pilot: the agent and the engineer need to iterate together inside a session. Once named, the three UXs were obviously different products with different surface area.

They re-scoped to three thin agents, each with the right mode, shipped in parallel. The onboarding-email agent shipped in 4 days with an Approve card in Slack. The product-marketing agent shipped in 3 days as a Notion-AI-style side panel. The support-investigation agent shipped in 6 days as a Claude Code surface scoped to a specific tooling MCP. Launch hit the date. After 60 days: onboarding-email Approve mode at 92% approval rate with 24-second median TTA (healthy), product-marketing Suggest mode at 38% adoption (good for Suggest), support-investigation Co-Pilot at an average 11-minute session with 81% of sessions ending in a fix-shipped state.

The lesson was not that the team was wrong to want one product. The lesson was that the mode is the product. Picking the right mode is more important than the model choice, the tooling, the prompt โ€” those are tactics. The mode is the strategy.

Key Takeaways

  • Three named modes: Suggest (human ships, agent assists), Approve (agent ships, human gates), Co-Pilot (synchronous session, both contribute).
  • Approve-spam is the named 2026 anti-pattern. Median TTA under 2 seconds, approval rates above 98%, override rates equal to random โ€” three diagnostic signals.
  • 0.6 seconds is the floor below which reading is physically impossible. Any Approve workflow at that TTA is effectively autonomous with paperwork.
  • Three-axis decision: reversibility, stakes, frequency. Score the task; let the matrix pick the mode.
  • High-frequency + high-stakes requires tiered Approve. Routine cases auto-execute. Standard cases route to one reviewer. Escalated cases route to a senior reviewer with longer SLA.
  • Suggest needs: friction-light surface, multiple alternatives, adoption telemetry as feedback. The user is the author; the agent makes them faster.
  • Approve needs: named reviewer, backup escalation, pre-attention risk signals, mandatory override reason capture.
  • Co-Pilot needs: persistent session, visible agent state, interrupt-and-redirect, explicit ship moment.
  • Choose the mode in five minutes on day one. The mode is the strategy; everything else is tactics.
  • Re-evaluate every 90 days. Modes are not permanent; they break as agent quality, frequency, and stakes shift.