# Approve Mode Is Not a Speed Bump

*Published 2026-09-22* | Author: civic-team

> **tl;dr** Run mode and Approve mode do the same work: watch, score, check the boundary, draft. The only difference is where the Play says the final click lives, in the rule or in a person's morning. Neither is more governed than the other, because the governance is the Play. Approve mode is how a team learns what a Play does before letting it run, and how anything that writes to a customer stays within reach of a person without sitting in a queue nobody owns. The record shows the same line either way, with one extra field: who clicked, and when.

## The wrong axis

People arrive at the two modes with the story already written. Run mode is fast, Approve mode is safe, pick your comfort level. It is a reasonable guess and it gets the product wrong, because it puts the modes on an axis of speed against safety, and they sit on a different one.

Both modes start from the same Play. Yesterday's piece on the vendors' MCP servers made the point that callable is not the same as run; a Play is [what turns an answer into a run](https://www.civic.com/field-notes/what-bryn-actually-does), and by the time it is approved it has already decided what Bryn watches for, what score clears, which channels it may write to, and which accounts it may never touch. Those bounds belong in the Play rather than in a policy document, which is the whole argument of [Bounded Autonomy Is the Spec](https://www.civic.com/field-notes/bounded-autonomy-is-the-spec). That is where the governance lives, in both modes, identically.

The mode is one more line in the Play. Where does the final click live? In the rule, and the Play is in Run mode. With a person, and the Play is in Approve mode. Same watching, same scoring, same cross-referencing, same drafting. Different placement of one click.

## What Approve mode does, by behavior

Take one Play, `pricing-return-intro-v2` (illustrative): when a known account comes back to the pricing page twice in seven days and clears the score, send a short intro from the account owner through the sequencer and open a CRM task. It writes to a customer's inbox, so the team put the final click with the owner.

Here is one instance, in eight steps.

1. **Match.** Bryn matches `pricing → return ×2 (7d)` on `acct_2286`.
2. **Score.** Bryn scores the account 0.78 against the profile; the Play's threshold is 0.70.
3. **Draft.** Bryn checks the boundary (channels, daily cap, suppression list) and prepares the action exactly as it will go out: the intro, the CRM task, the destinations.
4. **Hold.** The Play says the click lives with the owner, so the prepared action holds here.
5. **Record the hold.** The hold is a line in the log, with the draft attached.
6. **One click.** The owner opens the morning inbox, reads the prepared line, clicks once. Or dismisses it, and the dismissal is logged too.
7. **Act.** The intro goes out through the sequencer; the CRM task opens. Nothing outside the Play's channels.
8. **Record the act.** Same required fields as any run, plus one: `approved_by: owner 09:12`.

Steps one to three and seven to eight are Run mode. Approve mode adds four, five, and six. The queue is not a queue: it is an inbox with the work already done, and approving is the last thing left rather than the first.

TWO MODES, ONE TIMELINE (interactive: a Run / Approve mode switch above one eight-step Play timeline for pricing-return-intro-v2; switching marks which step holds and swaps the one field that changes on the record line)
Run mode:
- 1 match: pricing then return twice in 7 days on acct_2286
- 2 score: 0.78 against threshold 0.70
- 3 draft: boundary pass; intro and CRM task prepared
- 4 to 6: no hold. The Play's rule is the click.
- 7 act: sent intro via sequencer; CRM task opened
- 8 record act: logged; approved_by points at the Play approval (op_3, 2026-09-01)
Approve mode:
- 1 match: pricing then return twice in 7 days on acct_2286
- 2 score: 0.78 against threshold 0.70
- 3 draft: boundary pass; intro and CRM task prepared
- 4 hold: the Play says the click lives with the owner
- 5 record hold: the hold is on the log with the draft attached
- 6 one click: owner approves at 09:12 (or dismisses; logged either way)
- 7 act: sent intro via sequencer; CRM task opened
- 8 record act: logged; approved_by: owner 09:12
All values illustrative, not a benchmark. Account anonymized. The mode is a field on the Play; steps 1 to 3 and 7 to 8 are identical in both.
Figure 1. The same eight-step Play in Run mode and Approve mode; only where the last click lives changes (illustrative, not a benchmark).

## When to choose which

Three cases cover nearly every Play we have seen.

**Easing in.** New Play, rule not yet trusted. Approve mode, with a revisit date on the calendar. After thirty approvals, if you clicked yes on every one, the rule was right and the click was ceremony; move the Play to Run. If you dismissed a few, read the dismissals. They are on the log, and they tell you exactly what the rule missed. That is how [one operator ends up running many Plays](https://www.civic.com/field-notes/one-operator-many-plays) without watching any of them.

**Sensitive destination.** Anything that writes to a customer-facing channel or a customer's record. Approve mode, permanently, no revisit date. Not because the rule is untrusted, but because the Play says that click belongs to a person, and the Play is the rule.

**High frequency, low blast radius.** A post to your own Slack channel, a CRM task, a tag. Run mode. Holding these hands a person forty clicks a day that change nothing, and that is how an inbox turns into the queue [nobody owns](https://www.civic.com/field-notes/follow-up-has-no-owner).

The suppression list applies in all three. A current customer's domain on the list blocks the run in Run mode and blocks the draft in Approve mode, so the owner never sees it. The blocked version of this same shape is in [Show Me a Blocked Action](https://www.civic.com/field-notes/show-me-a-blocked-action).

WHERE SHOULD THE CLICK LIVE? (interactive: three questions about one Play as native selects, Destination, Confidence in the rule, Frequency; the sentence below recommends a mode and a revisit date, labelled illustrative)
- Easing in: new Play, rule not yet trusted. Mode: Approve. Revisit: date on the calendar. Unanimous approvals: move to Run. Dismissals: read them, fix the rule.
- Sensitive destination: writes to a customer-facing channel or record. Mode: Approve. Revisit: none. Permanent, because the Play says the click belongs to a person.
- High frequency, low blast radius: internal channel, task, tag. Mode: Run. Revisit: none needed. Holding these makes an inbox into a queue.
Illustrative, not a benchmark. Thirty runs and the revisit windows are placeholders; the Play's owner sets the real ones.
Figure 2. Three questions, one mode, one revisit date (illustrative, not a benchmark).

## What the record shows

Two lines, same Play. The first is from August, when `pricing-return-intro-v2` was in Approve mode. The second is from September, after the team hit the revisit date and moved it to Run. Values illustrative, accounts anonymized.

> ![Bryn](https://www.civic.com/images/brand/bryn-horizon-gradient-24.svg) I matched `pricing → return ×2 (7d)` on acct\_2286 at 08:47 UTC, scored 0.78, checked `pricing-return-intro-v2` boundary: pass. Drafted intro and CRM task. Held. Approved by owner 09:12. Sent intro via sequencer, opened CRM task. Logged.

> ![Bryn](https://www.civic.com/images/brand/bryn-horizon-gradient-24.svg) I matched `pricing → return ×2 (7d)` on acct\_5130 at 08:47 UTC, scored 0.81, checked `pricing-return-intro-v2` boundary: pass. Sent intro via sequencer, opened CRM task. Logged.

Every field but one is shared. The Approve line carries `approved_by: owner 09:12`. The Run line carries the Play approval instead, `approved_by: op_3 (Play, 2026-09-01)`, because that is where the click lived. A reviewer reads either line and answers the same question: who authorized this send, and when. In Run mode the answer is a date on a Play. In Approve mode it is a timestamp on an instance. Both are on the line, not in a ticket.

ONE CLICK, HELD (static figure: one Approve-mode run as an eight-step track and a single record line)
Eight steps. One holds. The record gains one field.
Track: 1 match, 2 score, 3 draft, 4 hold (highlighted: the Play says the click lives with the owner; draft is finished, nothing has left), 5 record hold, 6 one click, 7 act, 8 record act. Steps 4 to 6 are bracketed: Approve mode adds these three.
Record line: AUDIT LOG, run_7a31c8, 08:47:19Z, mode approve. play: pricing-return-intro-v2, acct: acct_2286, signal: pricing then return twice in 7 days, score: 0.78, threshold: 0.70, boundary: pass, held: true, approved_by: owner 09:12, action: sent intro, opened CRM task, channels: sequencer, crm_task, cap: 4/25, play_approved: op_3 (2026-08-04), dismissed: false.
The one field Run mode does not carry per instance: who clicked, and when. Everything else on the line is shared with Run mode.
The same line in Run mode: no held field. approved_by points at the Play approval: op_3 (Play, 2026-09-01).
Illustrative, not a benchmark; accounts anonymized; field names follow the audit log's key:value convention.
Figure 3. One click, held: the eight steps and the record line (illustrative, not a benchmark).

The third thing, in one sentence: the kill switch suspends everything, and the suspend is logged.

One public example. Run #0001, the first time Bryn ran for real on Civic's own site, went out on a click: Brad approved it four minutes in, and the homepage replays that line straight from the log. The Play that produced it has since moved to Run mode. The line still reads the same, minus one field.

## Write the sentence

For each Play you run or would run, write one sentence: "The final click lives in \_\_\_ because \_\_\_."

If the blank is "a person" and the because is "we are not sure yet," that is a Play in Approve mode on purpose, with a date to revisit. If the because is "it writes to a customer," that is Approve mode, permanently. If you cannot fill in the because, Run mode. The sentence is the Play's rule about its own last click, and the mode is just the field that stores it.

Tomorrow Chris writes about planning 2027 around the work your team should stop doing by hand. The mode question is where that plan meets the morning.

Bryn is not another dashboard to watch. It is the governed execution layer that runs Plays through your stack.

**Stop watching signals. Start running them.**

Source: https://www.civic.com/field-notes/approve-mode-is-not-a-speed-bump