Blog

I was staring at the volunteer completion chart when it hit me. The line had been sliding for three weeks, quiet and steady, and no alert had fired. An agent had tweaked the recommendation logic two releases earlier. It favored shorter passages, which the model scored as higher engagement. The actual humans teaching kids on Wednesday nights just quietly stopped finishing the material.

We had designed the whole platform so nothing needed a single gatekeeper. Every service could read the shared context, every agent could propose changes. The theory said distributed visibility would catch problems faster than any old command chain. What it missed was how fast context stops feeling obvious once the people who once carried it are no longer the ones writing the code.

Someone still had to be willing to look at the change and say it was wrong for reasons the metrics couldn’t see.

The OS that looked decentralized until the first bad merge

At one ministry platform the content team built a shared repository for children’s curriculum adjustments. Agents proposed new activity lengths, new age-band splits, and new print layouts based on usage logs. The first three merges passed automated checks and went live. Volunteer completion rates fell 11 percent in two weeks. No single person had reviewed the combined effect on the 7-minute volunteer workflow.

The team had documented every change. They had run unit tests. They had followed the distributed review checklist. What they lacked was one role whose explicit job was to hold the veto on merges that touched both the metric layer and the print-first layer at once. The OS looked flat until the first time the lattice pointed the wrong way.

The same pattern appeared in a separate effort to auto-generate discussion questions for sermon resources. An agent began surfacing questions that scored well on engagement but required more than seven minutes to prepare. The change shipped because each individual approval step looked reasonable. The person who used to own the final sign-off had been moved to a coaching role and no longer touched the merge queue.

Munger’s latticework applied to AI-augmented ministry product teams

Charlie Munger described a latticework of mental models as the minimum structure required for sound judgment. Each new model added a new angle of inspection. The value came from the intersections, not from any single model in isolation. In product work this means keeping models for volunteer time cost, theological framing, metric drift, and deployment risk all active on the same decision.

When agents write the first draft of a change, they usually optimize inside one model. The lattice only forms if a human still sits at the intersection before the change is committed. Without that seat, the system adds models linearly and compounds error exponentially. Ministry platforms feel the effect first because their real retention metric is whether a volunteer finishes the task, not whether an engagement score rises.

The practical implication is that every agent-assisted merge needs an explicit veto owner who can name which mental models are in tension. That owner does not need to write code. They need to be the only person who can approve when the change touches both the knowledge base and a downstream volunteer workflow. The lattice does not run itself; it only stays coherent when someone is paid to guard the intersections.

Where the captain role still lives once the knowledge base is supposed to run itself

The title “captain” does not have to appear on an org chart. It appears in the commit log as the single required approver on changes that cross a defined risk threshold. In one case the threshold was any edit that altered print output for curriculum used by more than ten thousand volunteers. The approver was a former children’s director who no longer wrote code but still carried the memory of what seven minutes actually feels like on a Wednesday night.

Once the knowledge base grows large enough to train its own agents, the captain’s job shifts from writing to refusing. The refusal is the only action that cannot be delegated to the lattice. Everything else—drafting, testing, even initial review—can be distributed. The final no cannot.

Teams that removed the captain role discovered the cost in the form of silent metric reversal. Completion rates declined while every automated dashboard showed improvement. The reversal only became visible when someone outside the agent loop asked why the printed packets were now two pages longer.

Your Turn: Apply This Today

• List the last three agent-driven merges your team shipped and name the exact person who still holds veto power on each one.
• For any merge without a named veto owner, add a one-line rule in the repository that blocks merge until that owner signs off.
• Define the three risk thresholds that automatically route a change to the captain role this week.
• Run the three merges through Munger’s lattice by writing one sentence for each mental model in tension before the change is approved.
• Remove the coaching-only title from the former children’s director or equivalent and restore a 10 percent time allocation to merge review.
• Schedule a 30-minute weekly review where the captain walks through any agent change that touched both metrics and volunteer workflow.

The Agent That Kept Running the Schedule While No One Was Watching showed what happens when an autonomous process drifts without an owner. The Three-Person Pod That Still Needed a Fourth Set of Eyes demonstrated the same pattern at the level of code review.

I consult with ministry product leaders on preserving human veto points in AI-augmented knowledge bases and designing merge rules that keep the lattice coherent. Let’s talk.

Most volunteer coordinator roles at ministry-tech organizations still get filled through standard inbound application flows. The number looks like proof that the system works. It is actually proof that the system only surfaces the people already looking, while the recurring decisions about curriculum scheduling, follow-up loops, and edge-case support stay locked inside the heads of two or three overcommitted staff members who never appear on any job post.

The gap is not a recruiting problem. It is a mapping problem. Teams keep treating the open role as the unit of work instead of tracing the actual decisions that must be made every week. Without that trace, inbound volume becomes a comfort metric rather than a signal of whether the right people are connected to the right choices.

Charlie Munger’s latticework of mental models makes the mistake visible. Munger argued that real understanding comes from holding multiple models at once so none of them can dominate. In talent work the dominant model is still the job requisition. The missing models are decision ownership, recurrence frequency, and relationship durability. When those sit outside the map, the funnel keeps producing candidates while the actual ministry bottlenecks remain untouched.

Mapping the actual decision owners instead of the job posts

Most product teams still begin with the posted role. They list responsibilities, then wait for applications. In practice the real decisions about children’s ministry follow-up or sermon resource approvals are already being made by a volunteer who has never applied for anything and a part-time staff member who reports to no one in the org chart. The posted role becomes a container that never gets filled with those decisions.

I watched one mid-size curriculum platform try to hire a volunteer coordinator after their print-first user base grew past 180,000 monthly active users. The job description mentioned “managing volunteer schedules.” It did not mention the Tuesday morning decision about which volunteer gets the new lesson plan when the original volunteer’s child is sick. That decision stayed with the children’s pastor who was already running three other portfolios. Six months later the new coordinator was still routing every exception back to the same pastor.

The lattice requires naming the owner of each recurring decision first, then asking which existing relationships already touch that owner. The job post comes later, if it comes at all.

Why direct outreach beats the application stack for faith-tech roles

Inbound stacks reward people who are between roles or actively scanning LinkedIn. Ministry decisions, especially the ones that touch volunteers, are usually held by people already inside the work. They do not apply because they do not see themselves as applicants. They respond when someone they trust asks a specific question about a specific decision.

One team I worked with replaced their coordinator posting with a six-week exercise of listing every recurring choice that affected volunteer completion rates. They then reached out to twelve people already performing fragments of those choices. Four of the twelve agreed to a defined scope without ever seeing a job description. Retention after six months was higher than the previous two hires who had come through the stack. The difference was not character. It was that the outreach started from the decision map rather than the requisition.

The application stack still has a place for senior product roles that require rare technical judgment. For roles that sit at the intersection of product and volunteer systems, the stack mostly filters for availability instead of proximity to the actual work.

Building the lattice that survives staff turnover

Turnover is the test. When the children’s pastor leaves or the volunteer coordinator moves cities, the decisions do not disappear. They simply lose their current owner. A living talent map records the decision, the current owner, the backup relationship, and the last time the handoff was practiced. Without that record, every departure restarts the search from the job post rather than from the work.

I have seen three consecutive coordinators cycle through the same platform because each new person inherited only the title and the inbox. The actual Tuesday morning exception handling never transferred. After the third departure the team finally built a simple shared document that listed the twelve recurring decisions, the two people who had touched each one in the prior quarter, and the last date the handoff conversation happened. The next coordinator started with that document instead of the job description. The role stabilized.

The lattice is only useful if it is updated on the same cadence as the decisions themselves. Quarterly updates are too slow. Monthly checks against the actual exception log keep the map honest.

Your Turn: Apply This Today

• List the three most frequent ministry decisions your product or volunteer system handled last month and name the single person who currently owns each one.
• For each decision, add the name of the person who performed the same task when the owner was out last quarter.
• Schedule one 20-minute conversation this week with the backup person to confirm they can still execute the decision without the primary owner present.
• Write the decision, owner, and backup into a shared document that is not inside any HR system or job requisition.
• Review the document with your immediate team in the next staff meeting and ask which of the three decisions has changed owner since the last review.
• Repeat the entire list for the next three decisions that will appear in the coming quarter rather than the ones already visible.

The same pattern shows up in the work described in “The Agent That Kept Running the Schedule While No One Was Watching” and “The Voice File That Actually Survived Three Ministry Reorgs.” Both posts trace how small, recurring decisions outlast the people who first held them when the connections are made explicit.

I consult with product leaders and ministry technology teams on decision mapping, volunteer system design, and talent lattice maintenance. Let’s talk.

You inherited the agent loop last quarter when the previous PM moved on to a startup. The denomination needed someone who understood both the tech and the field realities of churches running on volunteers, and they handed you the keys without a map. The loop still runs—generating weekly curriculum outlines, flagging volunteer availability gaps, and pushing draft emails to small group leaders—but no one can explain why certain suggestions land well one month and miss entirely the next.

That absence of ownership is the real problem. Teresa Torres’s continuous discovery framework assumes someone stays close enough to the users to keep refreshing the context that feeds the system. Without that person, the loop drifts. It starts optimizing for yesterday’s patterns instead of today’s actual ministry constraints.

The missing owner in every agent loop

The agent that suggests children’s ministry stories still pulls from a context file last updated in March. It recommends the same Moses craft for the fourth time this year because the file never recorded that three regions ran it already and volunteers pushed back. You see the duplicates in the feedback tickets, but the system has no signal that the suggestion needs updating.

This happens because the builder treated the agent as a feature release rather than an ongoing product. Once the initial integration shipped, attention moved to the next sprint. The context file became an artifact no one touched, exactly the opposite of Torres’s insistence that discovery is continuous work, not a handoff deliverable.

In practice this shows up in the volunteer completion rate metric you track from the old curriculum platform usage data. The rate dips every time the agent repeats a suggestion that already exhausted local supplies or volunteer energy. The loop keeps producing output, but the output no longer compounds the institutional knowledge the denomination actually needs.

How discovery habits collapse when no one owns the context file

Torres taught teams to keep an updated opportunity solution tree that reflects real interviews and usage data. When the context file lives in a shared drive with no assigned owner, the tree stops growing. The agent continues to run on stale assumptions about what a typical volunteer can accomplish in one prep session.

You notice the pattern in the tickets that mention “this doesn’t match our current curriculum cycle.” Those tickets used to trigger updates to the context file. Now they sit in a backlog because the new mandate focuses on shipping visible agent improvements rather than maintaining the source material that makes those improvements relevant.

The result is a quiet reversal of Torres’s core practice. Instead of discovery feeding the loop, the loop starts feeding itself stale data. Over time the suggestions become generic enough that ministry leaders stop relying on them, which further reduces the signal available for any future correction.

Designing the org system that keeps the loop alive after the builder leaves

The handoff itself must become a tracked product artifact. That means documenting not just what the agent does, but which specific user contexts it draws from and who is responsible for refreshing each piece. Without that documentation, the next person inherits only the running code, not the discovery discipline that kept it useful.

One ministry I watched handled this by requiring every agent change to include an updated context section and an assigned reviewer. The reviewer was not the builder. Their job was to test the suggestion against three real volunteer workflows before the change went live. That single role kept the loop connected to current field conditions even after the original builder moved to another team.

The same principle applies to the curriculum resources side. When ownership of the context file moved from the builder to a rotating ministry lead, the volunteer completion rate stabilized. The agent still generated drafts, but the drafts now reflected what actual volunteers could finish in the time they had.

Your Turn: Apply This Today

• Identify the three agent loops already running in your org and list the current context files each one depends on.
• Assign one named owner to each context file with a required monthly refresh cadence and a visible change log.
• Write a one-page handoff artifact for the loop you inherited that includes the last three user contexts tested and the reviewer who signed off.
• Schedule a 30-minute review this week where the new owner walks through one recent agent output against actual volunteer feedback.
• Add a required field in your ticket system that blocks any agent update until the context owner has updated the supporting file.
• Run a two-week audit that measures whether volunteer completion rates improve after the context files receive their first assigned refresh.

The Agent That Kept Running the Schedule While No One Was Watching and The Ministry PM Who Handed Off Captain Duties Without the Handoff Log both trace the same pattern of loops that outlast their builders.

I consult with ministry product leaders on maintaining agent loops and institutional knowledge across team transitions. Let’s talk.