Blog

McKinsey’s AI transformation framework tells leaders to set the mandate at the top, define the use cases from strategy documents, then cascade requirements downward through implementation teams. The model assumes the center holds enough context to name what good looks like before any local team touches the tool. That assumption collapses the moment the workflow crosses a competence boundary into the hands of volunteer coordinators who decide in seven-minute windows between service and lunch duty.

The framework measures success by adoption dashboards and model accuracy scores. It never asks whether the person who actually assigns rooms and prints name tags can still exercise judgment when the agent suggests a different curriculum track. The result is a shipped feature that meets the mandate and breaks the loop that keeps real ministry work moving.

This is the foundational misread that causes product teams to ship agents that look complete in demos and stall in practice. The gap is not technical. It is a competence boundary problem.

Charlie Munger described a circle of competence as the small set of decisions where a person knows the variables well enough to see second-order effects. Outside that circle, even smart people produce confident errors. Ministry tools cross that boundary the moment an AI agent starts suggesting how a volunteer should adapt a lesson for a child who just lost a parent. The coordinator sees the child’s face and the empty chair. The model sees patterns across anonymized sessions. Munger’s point was that you stay inside the circle or you bring in someone who lives there. Most AI mandates do neither.

How the Mandate Reached the Volunteer Coordinator

The requirement landed in an all-hands note: every new curriculum product must include an AI-assisted personalization layer by Q3. The product team translated the mandate into a clean spec. The agent would read the lesson text, the child’s age and attendance history, then output a suggested adaptation plus a printable note for the volunteer.

The volunteer coordinator first saw the feature the week before VBS training. She opened the new screen, read the suggested rewrite for the story of David and Goliath, and realized the model had removed every reference to violence without asking whether the church’s teaching team wanted that choice made for them. She spent twenty minutes rewriting the note by hand so it still matched what the lead pastor had approved six months earlier.

No one on the central team had seen that rewrite cycle because the success metric stopped at “agent output accepted.” The coordinator’s actual work of preserving local teaching intent never appeared in the dashboard.

The Competence Boundary the Model Crossed Without Noticing

The agent operated on content patterns and user metadata. It had no signal for whether a suggested change would require the volunteer to find new craft supplies at 8:45 on a Wednesday night. That decision sits inside the coordinator’s circle. She knows which families can bring extra glue sticks and which weeks the church van is already booked.

When the model suggested swapping the craft for a tablet-based reflection activity, it crossed the boundary. The coordinator could see the downstream cost in real time: two extra parent volunteers needed, one device cart that was already reserved for the youth group, and a training burden she would carry alone. The agent could not see any of it because those variables live only in her weekly rhythm.

Munger would have called this operating outside the circle with no compensating process. The mandate treated the model as competent across the full decision surface. The local team experienced the model as confidently wrong on the details that actually determined whether the session happened.

Rebuilding Decision Rights at the Competence Boundary

After the first month of quiet workarounds, the team added a single gate. Any agent suggestion that touched supply lists, room assignments, or approved teaching emphasis required an explicit “local override” click before the note could be printed. The override did not require explanation in the system, only acknowledgment that a human with weekly context had seen it.

They also moved the default output from a full rewritten lesson to a short margin note that the coordinator could accept, edit, or ignore in under sixty seconds. The model still generated the note, but the decision rights stayed with the person who would stand in the room.

Usage recovered once coordinators could treat the agent as a suggestion layer rather than a replacement for their own judgment. Retention among volunteer leads rose because the tool no longer created invisible extra work that only they could see.

Your Turn: Apply This Today

• Pick the single recurring decision your current AI feature makes on behalf of a local ministry user and write down the exact variables that person sees weekly that the model cannot access.
• Shadow one volunteer coordinator for a full planning cycle this week and note every judgment call that happens after the agent output appears on screen.
• Change the default output of one agent flow from a completed artifact to a one-sentence margin suggestion that requires an explicit local accept step.
• Remove any success metric that counts “agent output accepted” without also tracking whether the local user still completed their weekly task in the same amount of time.
• Map the three decisions that must stay inside the local circle and add a visible override control for each before the next release.
• Run a thirty-minute review with the actual end user of the last agent suggestion that crossed a competence boundary and log what the model missed.

The same pattern shows up in how teams handle inherited agent mandates and in the months spent routing every spec through the largest model before testing it against real weekly rhythms. Both posts trace the cost of assuming central competence where local judgment loops still do the work.

I consult with product leaders building tools for ministry volunteers and church staff on AI workflow boundaries and local decision rights. Let’s talk.

The children’s director sat at the folding table in the supply closet, the one with the wobbly leg and the permanent marker stain shaped like Texas. Her laptop fan whined as the planning tool loaded its afternoon suggestions. Three craft options appeared in the side pane, each one bright with stock photos of construction paper and glue sticks. She scanned the list, then reached for the small trust toggle at the top of the pane and switched it off. The recommendations disappeared. She exhaled, opened the blank lesson template, and started typing from memory instead.

She had tried the suggestions twice already that month. Both times the activities called for items the budget line did not cover, and both times she had spent an extra evening driving to two different stores looking for substitutes. Flipping the trust toggle was faster than arguing with the interface.

Solomon’s judgment offers a useful lens here. Two women claimed the same child. The king did not search for more data or run another test. He watched which person was willing to lose the outcome rather than harm the person in front of them. The real parent revealed herself by her readiness to override the proposed solution. Modern planning tools rarely test for that same willingness. They optimize for suggestion volume and measure acceptance rates, then wonder why the people closest to the work keep turning the suggestions off.

This matters because the person sitting at the volunteer desk already carries the constraint the model cannot see. She knows the supply closet inventory, the parent who always forgets to send scissors, and the fact that the church van is in the shop this week. When the interface treats her override as a failure state instead of the normal next step, it adds friction exactly where the work is most fragile.

Why the Trust Toggle Appears at the Point of Use

Most AI planning features ship with suggestions turned on by default, a choice usability research shows users rarely revisit. The assumption is that more options will help the time-pressed user. In practice the suggestions arrive already filtered through averaged data from thousands of other churches. What remains is often a list of activities that require either money or prep time the current volunteer does not have.

I watched the same pattern repeat across three different children’s ministry tools last year. Each time a new recommendation engine rolled out, the first week showed high click-through numbers. By week three the internal dashboard showed a spike in users who had disabled the pane entirely. The product team read the drop as disengagement. The volunteers described reaching for the trust toggle as finally being able to finish the task.

The break happens because the default carries an implicit claim: the model knows the local constraints better than the person who just counted the glue sticks. When that claim proves false, the user does not refine the suggestion. She removes the entire channel. Solomon would recognize the move. The one who truly bears the outcome will cut off the process rather than accept a solution that harms what she is responsible for.

The Override Cost No Dashboard Shows

Every extra click required to turn suggestions off carries a hidden cost. The volunteer has already opened the tool, seen the list, evaluated each item against her actual supplies, and then hunted for the setting. That sequence takes thirty to forty seconds on a good day. Across a quarter it adds up to hours that never appear in any usage metric because the time is spent outside the product.

The deeper cost is eroded trust. After the third time a suggestion set proves unusable, the volunteer stops believing future suggestions will be relevant. She treats the pane as noise rather than help. Product teams often respond by adding more personalization signals, yet the signals they request (budget ranges, supply lists, volunteer skill tags) are exactly the data points the volunteer does not have time to maintain inside the tool.

Solomon’s test still applies. The person willing to discard the proposed plan is usually the one who understands the real stakes. Forcing her to keep justifying the discard only increases the distance between the model and the work.

Designing the Trust Toggle Before the Feature Ships

The practical fix begins with treating the trust toggle as a core control rather than a settings afterthought. Place it directly beside the suggestion pane, not buried three menus deep. Label it plainly: “Hide suggestions for this plan.” Make the choice sticky for that user and that planning cycle so she does not repeat the action every time she opens the lesson.

Teams that have done this report an unexpected result. When the off-switch is cheap, more volunteers experiment with suggestions in the first place. They know they can dismiss the output without penalty, so they glance at it instead of preemptively disabling the whole feature. The acceptance rate on individual suggestions may drop, but the overall usefulness of the tool rises because the interface stops fighting the person who actually owns the outcome.

This is not a rejection of AI assistance. It is an application of Solomon’s discernment: surface the model’s proposal, then give the one closest to the child the uncomplicated ability to set it aside. The measure of a trust feature is not how often the suggestion is accepted. It is how little effort it takes for the right person to override it when acceptance would cause harm.

Your Turn: Apply This Today

• Open the current planning tool your team uses and locate the suggestion pane; add a one-click toggle labeled “Hide for this plan” directly beside it before the next release.
• Pick one children’s ministry volunteer who has used the tool in the past month and ask her to walk through her last planning session while you watch; note every time she ignored or dismissed a suggestion.
• Change the default state for new users in one small cohort so the suggestion pane starts hidden; measure whether they turn it on later compared with the always-on group.
• Write the override action into the user flow spec for the next AI feature so the engineering ticket includes the off-switch before any model integration work begins.
• Review the last three support tickets from ministry users about “bad suggestions” and trace whether each person had an easy path to disable the pane without leaving the screen.
• Set a recurring calendar reminder for the first Monday of each month to ask two frontline users whether the current suggestions still match what they actually have on hand.

The same pattern shows up in the work I described in The AI Line Item No Demo Ever Justified and The v1 Where the Model Handed Me the Safe Path.

I consult with product leaders building AI planning tools for ministry volunteers on suggestion interfaces, override controls, and frontline decision rights. Let’s talk.

Teams running ministry platforms reported a 62% rise in monthly token consumption for AI-assisted content generation over the past twelve months. The figure looks like adoption until you trace where the tokens actually went. Most of that token budget increase came from repeated prompt refinement and human review loops that left the original volunteer task list unchanged.

The obvious reading treats higher spend as proof of value delivered. The reverse is closer to what happened. Extra tokens masked the absence of any measurable shift in how a children’s ministry volunteer prepared a lesson on a Tuesday night. A token budget that grows without a matching change in volunteer outcomes is a warning sign, not a win.

When Spend Reviews Hit the Smallest Teams First

Jensen Huang’s argument for sovereign AI centers on keeping decision rights inside the organization that actually owns the outcome. When that principle is ignored, budget conversations default to usage dashboards that every team can see but few can act on. Small volunteer-driven groups feel the pressure first because they lack both the headcount to absorb review cycles and the political capital to push back on centralized spend.

One curriculum platform tracked a spike in summarization calls during the back-to-school window. The calls originated from regional coordinators trying to shorten existing lesson outlines for volunteers who only had seven minutes between work and the Wednesday program. Each summary still required a second pass by a paid editor before it reached the volunteer. Token counts rose; preparation time for the volunteer stayed flat.

The pattern repeats whenever an AI feature is measured by output volume rather than handoff reduction. The smallest teams absorb the verification burden because they sit at the end of the chain and cannot delegate it further. Larger churches with staff simply route the same content through another approval layer and call the process “governance.”

Mapping the Token Budget to One Observable Handoff

Huang’s point about sovereignty only lands when every token is attached to a single, named handoff that someone can watch change. In volunteer settings that handoff is usually the moment a printed or emailed resource reaches the person who will use it without further editing. Most current dashboards stop counting at generation and never reach that moment.

A children’s ministry tool introduced an AI outline generator for weekly lessons. Usage logs showed strong uptake among mid-week staff. When the team instead measured whether volunteers still opened the full curriculum PDF or simply printed the AI summary, the number of untouched PDFs stayed above 70%. The tokens had produced an intermediate artifact that required the same amount of volunteer attention as before.

Reversing the measurement forces a narrower scope. Instead of asking how many outlines the model produced, the question becomes whether the volunteer’s print step or copy-paste step disappeared for one specific age group. That single observable change is the only unit that can be priced against token cost with any honesty.

Building a Token Budget Ledger Before the Next Renewal

Renewal conversations arrive with polished charts of tokens consumed and outputs generated. Without a parallel ledger that records the exact workflow step removed or shortened, those charts cannot answer whether the spend should continue. The ledger has to be built while the feature is still in pilot, not after the contract is signed.

One platform began requiring every new AI-assisted workflow to declare the single volunteer action it intended to replace. The declaration lived in the same ticket as the prompt engineering work. Three months later the team could show that only two of the six pilots had actually reduced the declared action; the other four had added review steps instead. Budget was reallocated before the annual review rather than defended after it.

The discipline is unglamorous. It means writing down the before-and-after timing for one concrete task, collecting that timing from five real volunteers, and refusing to count any token that cannot be tied to a measured difference. Teams that adopt the habit stop celebrating usage graphs and start treating the token budget as a ledger of removed work rather than a record of activity.

Your Turn: Apply This Today

• Pick the single volunteer task your current AI feature was meant to shorten and write the exact before-and-after action in one sentence.
• Instrument the product so you can observe whether that action still occurs for at least ten users this month.
• Attach the token cost of the feature directly to those ten users and calculate cost per removed action.
• Present the cost-per-action number in the next spend review instead of total tokens used.
• If the action count has not dropped, disable the generation path for new users until the handoff changes.
• Document the revised number and the disabled path so the next renewal conversation starts from an outcome rather than a usage total.

The same gap between reported usage and actual workflow change appears in both “The AI Line Item No Demo Ever Justified” and “The Proven-Better Pattern That Still Missed the Smallest Churches.”

I consult with product leaders building tools for volunteer-driven ministries on mapping AI spend to observable handoffs and maintaining outcome ledgers ahead of renewals. Let’s talk.