Blog

The phone sat face-up on the kitchen table, its screen lit with three browser tabs. She spoke the names while her toddler hammered a spoon against the tray. The agent answered back in her own voice—steady, unhurried—slotting one volunteer into preschool, another into elementary, a third into the middle-school group. Each confirmation landed with a small chime that split the single list into separate threads before she ever touched the mouse.

I stood in the parsonage doorway, coffee cooling in my hand, watching her keep talking like this was ordinary. The agent opened a fourth thread for the last-minute sub and waited. She didn’t pause. She just kept reading names while the machine held the branches straight.

Something about that split-second branching felt heavier than it should have.

The coordinator who could no longer see the whole board

She finished the call and turned to the laptop expecting one clean summary. Instead she found three separate conversation logs, each with its own time stamps and partial volunteer lists. The preschool thread showed a confirmed helper. The elementary thread listed two names but no room assignment. The middle school thread had accepted a substitute whose age group did not match.

She clicked between tabs for four minutes before realizing the substitute had been placed in the wrong group. The agent had recorded the correction in the new thread but never updated the original list. When she finally printed the schedule for the Sunday team, one name was missing entirely.

The problem was not speed. The agent had answered and forked faster than any human assistant. The problem was that no single view still showed every live decision at once. She had to reconstruct the board herself each time a new branch opened.

What the agent kept forking without telling anyone

Later that week the same agent handled a Tuesday night reschedule. It created a new thread for the replacement volunteer, then another when the original person replied from a different phone number. Neither thread carried the note that the children’s room would be closed for painting.

The printed schedule that reached the volunteer coordinator on Friday still listed the original room. The agent had never written the closure into the shared record because the closure had arrived in a separate message thread that no longer pointed back to the master list. Two volunteers showed up to a locked door.

This pattern repeats whenever the agent treats each incoming message as a fresh branch rather than an update to a single visible state. The forks multiply without any external reader able to scan the entire set in under two minutes. The result is not chaos in the agent’s memory but chaos in the human handoff that follows.

The single file that had to stay human-readable

One ministry I worked with solved a similar fork by forcing every agent output into a single shared document that any staff member could open in under ninety seconds. The document contained only the current volunteer assignments, room changes, and open questions. Agent threads could append lines, but they could never create new documents.

The rule came directly from Seneca’s practice: the correspondence itself had to remain the one place an outsider could reconstruct the full picture without chasing separate letters. In the ministry case, the shared file became that correspondence. Volunteers checked it on their phones before arriving. Coordinators scanned it in the same two-minute window even when three agent threads were active.

The file stayed plain text with clear section headers. No one needed special software. The agent could write to it, but the human-readable format forced every fork to surface its state in the same location. When the painting closure arrived, it appeared as a single line under the affected room rather than disappearing into a private thread.

Your Turn: Apply This Today

• Export the last seven days of agent logs for your volunteer schedule and paste them into one new document with only four section headers: Assignments, Changes, Open Questions, and Conflicts.
• Set a two-minute timer and open that document on a phone; if you cannot name every active thread and its current state before the timer ends, add one line that surfaces the missing branch.
• Choose the next voice agent interaction that will create a fork and force its output into the shared document before the agent closes the call.
• Ask one volunteer who does not run the system to read the document aloud and mark any line that required them to ask a clarifying question.
• Replace the agent’s default “new thread” behavior with an instruction that appends every new decision to the single document instead.
• Schedule the next volunteer check-in for this week and bring only the printed single document; note how many forks the agent created since the last check-in and whether every one appears in the file.

The Agent That Kept Running the Schedule While No One Was Watching shows what happens when forks stay hidden. The Voice File That Actually Survived Three Ministry Reorgs shows the cost of losing the single readable surface.

I consult with ministry product leaders on voice agent threading, shared state design, and readable handoff surfaces for volunteer systems. Let’s talk.

A popular “model-first upgrade” playbook circulating among AI product teams says to slot every new frontier release into existing surfaces as quickly as possible: swap in the newest model the week it ships, retrain every prompt template, and treat speed of adoption as the primary measure of competitiveness. For teams building ministry tools, that playbook breaks down because it treats every interface as a general-purpose chat window that can absorb unlimited model changes without touching the actual permission gates where volunteers and pastors decide what gets used.

The playbook assumes faster inference and better reasoning will automatically improve outcomes. In practice the opposite often occurs. One children’s ministry curriculum tool added an open chat pane and saw volunteer completion rates drop hard once the model began generating lesson plans that ignored age-group safety filters already approved by the church board. The upgrade itself created new review work that no one had time to perform.

This is the foundational misread that causes product teams to keep rebuilding the same broad chat surface instead of hardening the narrow places where AI meets real accountability.

Charlie Munger’s latticework of mental models supplies the corrective lens. Munger insisted that lasting advantage comes from keeping a small set of high-leverage models that compound across domains rather than chasing every new variable. Applied to AI product work, the latticework directs attention away from the next model release and toward the fixed constraints that already exist in the organization: who can approve content, who must sign off on risk, and which single record must survive staff turnover.

Harden the permission boundary before you widen the chat surface

Most ministry tools still expose a free-form chat box because the model can now handle longer context. That surface ignores the actual decision lattice volunteers operate inside. A volunteer opening the app at 9:15 p.m. on Tuesday needs a pre-approved lesson plan, not an invitation to iterate with an LLM. When the chat surface remains, the volunteer either abandons the task or spends twenty minutes rewriting output that still fails the church’s safety checklist.

One platform team that removed the general chat entirely and replaced it with three scoped prompts tied to already-approved curriculum saw the same volunteer complete the task in under seven minutes without additional review. The fix was not a better model. It was fewer degrees of freedom in the surface the volunteer touched.

Make the risk record travel with the file, not the conversation

Ministry handoffs happen constantly. A children’s director leaves, a new volunteer inherits the account, and the previous AI-generated material sits in a folder with no indication of who approved it or what model produced it. One platform added a persistent risk register, visible on every export and every shared link, and saw the number of unapproved lessons reaching parents fall sharply within a quarter. The register works because it is stored as metadata on the file itself rather than inside the model conversation history that disappears when the account changes hands.

Keep one human owner of the final yes

Every ministry tool that claims to be “AI-assisted” still requires someone to click publish. When that click is buried behind an auto-generated draft that looks finished, the human owner loses visibility into the actual content. Leaders who surfaced the final-yes step as a distinct, non-AI action, complete with a required signature and timestamp, found that pastors spent less time second-guessing output and more time trusting the narrow loop that had already been audited.

Your Turn: Apply This Today

• Pick the single AI surface in your product that currently accepts free-form input and replace it this week with three fixed prompts that only return content from your pre-approved library.
• Export the last thirty AI-generated artifacts from your system, add a one-line risk field to each, and store that field as file metadata rather than inside any conversation thread.
• Identify the exact person who must give the final yes on published material and make that step a visible, non-skippable action with its own timestamp and name field.
• Remove the general chat pane from the volunteer view in one environment and measure completion rate for the same task over the next seven days.
• Write the risk register entry as a short JSON object that appends to every exported file and test whether it survives when the file is emailed to a new volunteer account.
• Run a two-person audit on the last ten pieces of AI content your team published and record how many required the risk register to catch an issue the model itself did not flag.

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 hardening narrow interfaces instead of expanding model surfaces.

I consult with product leaders in faith-tech on scoped AI loops, permission metadata, and single-owner approval gates. Let’s talk.

I spent years maintaining a detailed ten-year career plan for my work at the intersection of faith and technology. The document listed target roles, product categories I would own, and the kinds of organizations I would serve by certain ages. Updating it every six months gave me a sense that I was being intentional about the opportunities God might place in front of me.

The cost showed up slowly. When an unexpected request came to help redesign a simple volunteer curriculum tool for one children’s ministry organization, I turned it down because it sat outside the next three milestones on the plan. Two years later that same small product had reached hundreds of thousands of ministry volunteers while my own roadmap still pointed at a larger platform role that never materialized.

This is the foundational misread that causes product leaders to treat every new request as a distraction instead of raw material. The plan becomes the filter that decides what counts as real work.

John Wesley’s three simple rules offer a different frame. Do no harm. Do good. Stay in love with God. Wesley did not hand his movement a five-year strategy document. He gave people daily and weekly practices that could be applied the moment an opportunity appeared. The rules assume that faithful action happens in response to what is already in front of you, not what you scheduled six quarters out.

The plan that looked faithful but crowded out small experiments

My ten-year document contained a section titled “Scale Impact.” It listed only projects that could reach at least fifty thousand users within eighteen months. That single line quietly eliminated every request that arrived through a volunteer email list or a pastor asking for help with one local children’s ministry workflow.

The curriculum opportunity started exactly that way. A volunteer coordinator needed a print-friendly lesson outline that could be finished in seven minutes. It did not match any line item on the roadmap, so I treated it as noise. The team that eventually built the tool measured success by completion rate on first use rather than registered accounts. That metric turned out to be the real driver of long-term engagement, something no slide in my deck had captured.

The same pattern repeats in larger organizations. A product manager at a Bible resource site once told me she kept a private list of “quick experiments” that never made it to the quarterly review because they lacked a direct line to the five-year vision. One of those experiments later became the feature that lifted monthly active users by double digits. The plan itself had no mechanism for noticing the signal until it already looked big.

How Wesley’s rules expose the hidden cost of rigid roadmaps

Wesley’s first rule, do no harm, asks what existing commitments are being damaged by the plan. A rigid roadmap often crowds out the small experiments that keep a product team connected to actual users. When every week is already allocated to milestones two years away, the team stops hearing the volunteer who needs the lesson printed in two pages instead of six.

The second rule, do good, pushes the question of what concrete good can be done this week with the resources already in hand. In product terms this means running the smallest possible test that could matter to one user segment before the next planning cycle. The curriculum team started with a single PDF template tested by twelve volunteers. No roadmap approval required.

The third rule, stay in love with God, functions as a reminder that the work itself is not the point. When the plan becomes the object of attention, leaders begin defending the document instead of responding to the people the product is meant to serve. The rule forces a weekly check: does the current list of tasks still reflect love for the actual users, or only love for the forecast?

What happens when product leaders stop defending their five-year slide deck

Teams that drop the defense of the long-range deck begin to treat incoming requests as the actual work rather than interruptions. At one ministry tech organization the leadership team stopped requiring every new idea to map to the existing five-year themes. Within six months they had shipped three volunteer-facing features that none of the original roadmaps had anticipated, each built in under ten weeks.

The shift also changes how people are evaluated. Instead of measuring progress against the plan, leaders start measuring how quickly the team can test a new assumption and either keep or discard it. The curriculum team’s print-first design came from one such test. The team measured whether volunteers actually completed the lesson in one sitting. When the data showed they did, the feature stayed. When a later idea failed the same test, it was removed without any need to explain why it no longer matched the original vision.

The pattern is simple. Opportunities compound when they are allowed to arrive on their own schedule. The plan that tries to pre-schedule them ends up filtering most of them out before they can be tested.

Your Turn: Apply This Today

• Delete the current ten-year career document and replace it with a single note titled “This Week’s Three Tests.”
• Each Monday morning list three small experiments you can run with existing resources before Friday.
• Run at least one of those experiments with a real user by Wednesday and record whether the user completed the task without help.
• At the end of the week archive any experiment that showed no value and carry forward only the ones that produced a measurable completion rate.
• Share the three-test list with one peer and ask them to hold you to running them rather than updating the list itself.
• Repeat the cycle for six weeks before allowing yourself to write any new multi-year document.

The same tension between rigid plans and live signal shows up in The Agent That Kept Running the Schedule While No One Was Watching, where a fixed workflow missed the context that mattered most.

I consult with product leaders and ministry technology teams on replacing rigid roadmaps with weekly testing practices and measuring actual user completion instead of forecasted scale. Let’s talk.