Blog

Dear Ministry PM who inherited the AI volunteer coordination tool three months after the last lead walked out,

You know the Slack thread is still pinned at the top. The one where the old captain said “we’ll figure out the override rules once the model is live.” You also know the model is live now, and every Tuesday morning three different regional directors are asking why their local kids ministry leads can’t book a room without going through a central queue that no one owns.

That handoff never happened. Not the real one. The one with the frozen inputs, the named signers, and the explicit permission gates. What you got instead was a deck and a login.

This is the foundational misread that causes ministry product teams to decentralize authority without ever building the lattice that makes decentralization work. Charlie Munger’s latticework of mental models only produces better decisions when every node carries explicit constraints and cross-checks. Remove the constraints and you simply multiply the number of people who can approve something without ever seeing the downstream cost.

Map every captain decision to an actual signer

The first place the lattice breaks is when a model output is treated as a completed action rather than a proposed one. On one curriculum platform, an AI tool started auto-generating lesson assignments for volunteer teams. The model had learned from three years of historical data that certain age groups preferred shorter videos. What it had not learned was that one region’s volunteer coordinator had a standing agreement with a local printer for paper versions only. The first time the system pushed digital-only assignments, three churches printed their own copies at their own expense and the coordinator spent the next week fielding complaints.

The fix was not more model training. It was naming the exact person who still held physical permission to change the output format. Once that signer was written into the workflow, the model could suggest, but the assignment only moved forward after the signer confirmed the input constraints had not changed. The queue disappeared because the constraint was now visible and owned.

The same pattern shows up in room booking tools. When the AI proposes a time slot, someone must still be the signer who confirms the room is not already reserved for a funeral or a food pantry distribution that never appears in the shared calendar. Without that named signer, every “autonomous” suggestion eventually lands back in the same review queue, only now the queue is larger and the original captain is gone.

Build the knowledge OS around what cannot be regenerated

Munger’s lattice requires models that cannot be rebuilt from public data alone. In ministry settings the irreplaceable pieces are almost always local relationships and physical constraints. A volunteer’s willingness to teach only on weeks when her husband is not traveling for work cannot be regenerated from usage logs. A church’s rule that the nursery must stay empty during the 8 a.m. service because the carpet is being cleaned cannot be inferred from click data.

The knowledge operating system therefore has to store these constraints as first-class objects, not as footnotes. One team created a simple shared table that every AI suggestion had to query before generating an output. The table contained only three columns: constraint description, current signer, and last verified date. Anything not in the table was treated as unknown and therefore blocked. The model’s suggestions dropped by half, but the acceptance rate on the ones that remained rose sharply because they no longer violated unstated local rules.

Without this layer, decentralization simply accelerates the rate at which bad suggestions reach volunteers. The lattice collapses because the missing nodes are the ones that actually determine whether an action is permissible.

Run the first three loops with the handoff log visible

The first time a new captain runs the system, the handoff log must be public. Not summarized, not archived, but sitting in the same interface where decisions are made. In one deployment the team kept a running document that listed every override, who made it, and what constraint had been missed. After three weekly cycles the document revealed that two regional directors were overriding the same constraint for different reasons. One needed the room for a food distribution that only happened on odd weeks; the other needed it for a counseling appointment that could not be moved. Once both reasons were visible, the model input was updated to treat those weeks as blocked, and the overrides stopped.

Visibility also surfaces when the original captain’s mental model was simply wrong. The log becomes the place where the new captain can see the difference between “this rule was never documented” and “this rule was documented but no longer holds.” Without that distinction the team keeps re-learning the same exceptions at higher speed.

Your Turn: Apply This Today

• Pick the single AI-generated workflow your volunteers interact with most and list every decision the model currently makes without a named human signer.
• For each decision, identify the one person who still holds physical authority to block or alter the output and add that name to the workflow definition this week.
• Create a shared constraint table with only three columns—description, signer, last verified date—and require the model to query it before any suggestion is shown.
• Run the next three decision cycles with a visible handoff log that records every override, the reason given, and the constraint that was missed.
• After the third cycle, update the model inputs with any constraints that appeared more than once in the log.
• Schedule a 30-minute review with the actual signers to confirm nothing in the table has changed since the last verification date.

The same lattice problems appear when AI tools are applied to sermon preparation and children’s ministry resource distribution; the posts on those topics show how the missing permission gates surface in different places but for the same structural reason.

I consult with ministry product leaders on mapping decision signers, building knowledge operating systems around local constraints, and running visible handoff loops in AI deployments. Let’s talk.

You open the folder Monday morning and the count is already at fourteen. Fourteen pieces the model generated between Friday night and now—each one clean, each one needing the same two sets of eyes that have always carried the weight. One of those eyes belongs to the guy who still teaches the 7 a.m. Bible study; the other belongs to you.

Nobody on the team feels faster. The calendar just feels heavier.

One pilot involved sermon prep for a multi-site church. Pastors generated opening illustrations in bulk. Review time tripled because each illustration required a quick check for doctrinal alignment and a second check for stories already used in the same series. One pastor noted the verification step now consumed the slot previously reserved for prayer and reflection before final edits.

Another pilot targeted volunteer onboarding packets. Generation of welcome scripts moved from days to hours. The volunteer coordinator then spent an unexpected afternoon reconciling the new scripts with the existing print-first formatting rules that had been refined over three years. The time saved on creation reappeared as formatting corrections and one extra round of printer proofs.

Each case followed the same pattern: the generation step shrank while the verification and integration steps expanded at roughly the same ratio.

Latticework view of where generation meets sign-off

Charlie Munger’s latticework approach requires holding several mental models at once rather than optimizing a single variable. Applied here, the models include queueing theory, incentive misalignment, and the difference between local and system throughput. Faster generation improves the local metric of draft completion. It degrades the system metric of finished, approved assets ready for volunteers.

Queueing theory shows that adding work to a constrained reviewer creates backlog faster than linear models predict. Incentive misalignment appears when the person praised for producing more drafts is not the same person who absorbs the review cost. The local gain registers; the system cost stays hidden until retention or burnout metrics move.

Munger would also note the second-order effect on judgment quality. When reviewers face stacked queues, they default to surface checks rather than the deeper cross-references that previously caught subtle issues. The latticework therefore points to redesigning the handoff itself, not celebrating the generation speed.

Metrics that track the full loop instead of just generation

Most dashboards still report “drafts produced” or “tokens generated.” These numbers rise while the date an asset reaches the volunteer inbox stays flat or slips. Replace or supplement them with cycle time from prompt to approved asset and with reviewer hours per approved asset. Both numbers expose the actual constraint.

Add a third metric: percentage of generated content that survives first review without revision. Low survival rates indicate the generation step is producing volume that still requires heavy human correction. Track this weekly on one workflow before expanding.

Finally, measure downstream volunteer completion rate on the delivered material. If faster production leads to lower volunteer follow-through because the content feels less tailored, the speed gain has created a new problem rather than solving an old one.

Your Turn: Apply This Today

• Pick one AI-assisted workflow that currently ends at “draft generated” and add a timestamp field for the moment the first human reviewer opens the file.
• Log the exact minutes spent on theological alignment, formatting, and final sign-off for the next ten items that move through that workflow.
• Calculate the ratio of generation time to total review time and post the number where the team can see it each Friday.
• Identify the single reviewer who absorbs the largest share of verification work and block two hours on their calendar next week labeled “no new drafts.”
• Change the success definition in the next sprint from “ten new drafts created” to “six assets approved and formatted for print.”
• Run the same workflow for one more week while recording the survival rate of first drafts after initial review, then adjust the prompt template based on the patterns that fail most often.

Two earlier posts on this blog examined similar constraints: The Context Window That Only Closed When a Real Coordinator Sat Down and The Burnout Number Managers Still Ignore Until Retention Breaks.

I consult with ministry product leaders on AI workflow instrumentation, verification loops, and adoption metrics that reflect full human effort. Let’s talk.

I stood at the back of the fellowship hall on a Tuesday night, watching the small-group leader flip through printed notes on her phone because the PDF from the agent never made it to her inbox in time. The questions were solid. They just didn’t reach the person who actually had to ask them.

That was the third prototype. The first two had already gone the same way—clean demos, then silence once real people had to carry the output across the actual week. I kept thinking the problem was the prompting or the chaining. It wasn’t.

The constraint was never the model. It was the handoff that happens between one person’s work and another’s lived responsibility, the same quiet transfer the church has always depended on.

Teresa Torres’s continuous discovery work makes the same point about product teams who interview users once and then build. The method only works when teams keep returning to the actual moments when someone accepts or rejects the work. In agent projects, that means mapping the exact gatekeepers and formats that determine use, not just testing prompt quality.

Where the fluency training stopped short

Our first prototype handled volunteer reminders. The agent pulled from a shared calendar, wrote personalized texts, and scheduled them. In the sandbox it looked clean. When we ran it against the actual Monday morning routine, the coordinator who approves every outgoing message still needed a printed list to cross-check against the physical sign-in sheet she carries. The agent never produced that list, so the texts stayed in draft.

Fluency had taught us to measure correctness of the reminder text. It had not taught us to measure whether the coordinator could complete her existing Monday checklist without adding new steps. Torres would call this an interview that stopped at the moment of delight instead of continuing to the moment of rejection.

The second prototype generated adapted curriculum for different age groups. The output passed every internal review. The volunteer who actually teaches the class works from a single printed page she receives on Wednesday night. The agent delivered a multi-page document inside a shared drive folder she does not open. Again, the output existed; the handoff did not.

How discovery loops exposed the real gates

We shifted to weekly fifteen-minute calls with the actual people who would receive the agent output. We asked only two questions: what arrives on your desk or phone the day before you need it, and what format lets you finish your current checklist without starting a new one. The answers were never about model performance.

One coordinator keeps a physical three-ring binder. Another volunteer opens email only on a shared church computer after evening events. A third person routes every schedule change through a single admin who updates a whiteboard. These were not edge cases. They were the operating system.

Continuous discovery turned these details into testable assumptions. Each week we adjusted the agent to produce the exact artifact that already fit the existing gate, then watched whether it survived the next handoff. Most versions failed the first live test. The surviving version for scheduling now outputs a single column of names and times that prints on half a page and lands in the binder.

Rebuilding the evaluation step around live constraints

We stopped scoring prototypes on prompt accuracy alone. The new rubric asks whether the output reaches the person who must act on it, whether that person can complete their existing task without new friction, and whether the next person in the chain receives what they expect. These three checks happen inside the actual workflow, not in a demo environment.

The change also altered how we chose which agent to build next. Instead of starting with the most technically interesting task, we now start with the narrowest permission gate we can observe. If the gate requires a printed page delivered by a specific person on a specific day, the agent must produce that page in that format or it fails the first discovery loop.

This approach surfaces constraints earlier and keeps the team from investing weeks in fluent but unusable systems. The cost of the earlier prototypes was not wasted compute. It was the months during which real scheduling and curriculum decisions continued without any agent support at all.

Your Turn: Apply This Today

• Pick one current AI workflow your team runs and list every person who must approve or receive the output before it reaches the end user.
• For each person on that list, note the exact format and timing they currently use to complete their part of the task.
• Run the agent once and deliver its output to the first gatekeeper exactly as they would receive it in a normal week; observe whether they can finish their step without extra work.
• Document the first rejection or workaround you see and adjust the agent to remove that single friction before testing the next gate.
• Repeat the loop with the same workflow until the output survives three consecutive live handoffs without modification.
• Write the permission and format requirements into the project brief before starting the next agent build.

The Permission Gate That Kept the Agent From Running the Schedule and Why Ministry Coordinators Still Ask Me About the Routing Step both trace the same pattern of fluent tools that never cleared the actual handoff steps.

I consult with product leaders in faith-tech and ministry organizations on mapping AI agent workflows against real permission gates and handoff constraints. Let’s talk.