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. Here are both modes by behavior, three cases for choosing between them, and two record lines from the same Play, one in each mode.
Civic Team, Staff⬩11 min read
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, 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. 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.
Match. Bryn matches pricing → return ×2 (7d) on acct_2286.
Score. Bryn scores the account 0.78 against the profile; the Play's threshold is 0.70.
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.
Hold. The Play says the click lives with the owner, so the prepared action holds here.
Record the hold. The hold is a line in the log, with the draft attached.
One click. The owner opens the morning inbox, reads the prepared line, clicks once. Or dismisses it, and the dismissal is logged too.
Act. The intro goes out through the sequencer; the CRM task opens. Nothing outside the Play's channels.
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.
Switch the Play's mode and watch which step holds. Arrow keys move between the two modes. The record line below picks up the one field that changes.
1matchpricing → return ×2 (7d) on acct_2286
2score0.78 against 0.70
3draftboundary pass; intro + CRM task prepared
4holdthe Play says the click lives with the owner; draft holds
5record holdheld: true, draft attached, on the log
6one clickowner reads the line, clicks once at 09:12 (or dismisses; logged)
7actsent intro via sequencer; CRM task opened
8record actlogged with the same required fields
Approve mode: steps 1 to 3 run, step 4 holds the prepared action, step 5 records the hold, step 6 is the owner's one click at 09:12, then steps 7 and 8 act and record. The record line gains approved_by: owner 09:12.
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 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.
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.
Where should the click live?
Answer three questions about one Play. The sentence below is a starting point for the Play's own rule, not a verdict.
The rule is new, so the final click lives with a person while you learn what the Play does. APPROVE MODE, with a revisit date in six weeks (rare runs take longer to reach thirty). Unanimous approvals by then: move to Run. Dismissals: read them, fix the rule, reset the date. (illustrative, not a benchmark)
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.
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.
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.
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.
Our team brings decades of experience across the domains that matter: 10 years in AI and agentic systems, 65 in financial services, 35 in identity and access management, 30 in marketing and AdTech, 15 in legal and professional services, and 12 in manufacturing and industrial.
We're for operators who can't afford unintended actions or silent failures, and who want the agent in production quickly and effectively.
I matched 