The call came while I was still clearing breakfast dishes. A pastor in western Pennsylvania had one question: the AI tool that could write his entire children’s ministry curriculum in ten minutes had already been built, so why was his volunteer team still printing last year’s worksheets at the kitchen table? Reaching the smallest churches, it turned out, had nothing to do with how fast the feature was built.
He wasn’t asking about prompts or pricing. He wanted to know how the file was supposed to reach the three other volunteers who only ever showed up on Sunday morning, none of them checking product stores or reading release notes. The tool had done its part. Everything after that stayed exactly the same.
That single gap between “we shipped it” and “it actually reached the smallest room” is the part no one has fixed yet, and reaching the smallest churches lives entirely inside it.
Print-first constraints remain the real filter. A volunteer who prints the lesson at home on Thursday night does not care that the underlying model ran on a rented GPU cluster. If the output still requires reformatting to fit an 8.5-by-11 sheet and a three-ring binder, the adoption path is identical to the one that existed before the agent existed.
Completion rate inside that binder is the only metric that travels back to the builder. Every other telemetry—sign-ups, demo requests, feature usage—stops at the church office door. The cost reduction therefore changes the speed of iteration for the builder while leaving the observable result for the smallest churches unchanged. Reaching the smallest churches means winning that binder, not the dashboard.
The two distribution paths that decide reaching the smallest churches
Ministry tools travel either through denominational or regional trust nodes or through direct volunteer-to-volunteer referrals. The first path requires explicit endorsement from a person already trusted by multiple congregations; the second requires the tool to survive one successful handoff between two people who already know each other.
App-store or website discovery plays almost no role. A pastor searching for “AI children’s lesson” will still ask the children’s director at the next association meeting whether anyone has tried the new thing. That meeting is the actual product review cycle. Builders who optimize only for the website conversion funnel never reach the table where the decision is made.
Both paths are slow by design. They exist to reduce risk for volunteers who have limited time and zero tolerance for tools that fail on Sunday. Speeding up the build phase does not compress the trust verification phase that follows.
Munger’s Inversion Test Applied to an Agent Rollout
Charlie Munger’s latticework requires asking what would have to be true for the opposite outcome to occur. Instead of asking how to get the agent adopted, the useful question is what would have to be true for the smallest churches to never install it even after it is free and technically perfect.
The answer points to missing handoff artifacts. No printed one-page instruction that fits inside the existing binder. No verbal script the director can repeat in thirty seconds to a volunteer. No version that survives a lost internet connection on Saturday night. Each missing artifact is a reason the tool stays on the drive.
Inversion also reveals the second-order effect. When the agent is easy to build, teams ship more versions. Each new version increases the cognitive load on the person who must decide whether to reprint the lesson packet. The proliferation itself becomes a distribution tax rather than a distribution benefit.
Your Turn: Apply This Today
- Pick one current AI feature already in pilot and write the exact three-sentence script a children’s director would say to a volunteer at the end of a planning meeting.
- Print that script on the same sheet as the generated lesson and test whether the volunteer can complete the activity without opening a second tab or device.
- Map the next two people who must physically receive the printed sheet after the director approves it and note how many days typically pass between each handoff.
- Remove every UI element that requires the volunteer to log in or download an app; replace it with a single QR code that prints at the bottom of the page and opens the content in a browser.
- Run the inversion question with the actual volunteer: “What would have to be true for you to throw this page away and use last week’s lesson instead?” Capture the first answer verbatim.
- Schedule the next iteration of the agent only after the printed artifact survives one full Sunday with the volunteer who originally gave the answer above.
Distribution Moats Still Decide Which Ministry Tools Actually Reach Churches laid out the trust-node mechanics in more detail. The 1997 Lesson AI Product Teams Keep Missing showed how earlier technology shifts produced the same pattern when builders ignored the final handoff layer.
I consult with AI product leaders and ministry tool builders on distribution path mapping, trust-node verification, and agent rollout constraints. Let’s talk.