I spent eighteen months treating every new AI framework as the missing piece that would finally let our team move faster without breaking the trust we had built with ministry leaders. Each week brought a new paper, a new prompting technique, or a new agent pattern that promised to compress weeks of work into days. I cleared calendar space, ran internal demos, and rewrote team processes around whatever had just landed on arXiv or in a Discord thread.
The real cost showed up in the work that quietly stopped happening. We deferred hard questions about how children’s ministry volunteers actually finish a lesson plan on a phone during the seven minutes between services. We stopped measuring whether the output helped a pastor prepare without creating new review loops. The frameworks kept our attention on model performance while the product quietly drifted from the people who used it every week.
This is the foundational misread that causes product teams to treat AI tooling as an end rather than a constraint. John Wesley’s three simple rules, written for Methodist societies in the eighteenth century, offer a clearer lens than any current tutorial: do no harm, do good, and stay in love with God. Applied to faith-tech, they force attention on the human cost before any prompt is written.
Do No Harm When Every Prompt Promises Speed
Most AI workflows begin with the assumption that faster output is neutral. In ministry settings that assumption breaks quickly. When a children’s curriculum generator produces a lesson in four minutes, the volunteer still has to judge whether the story is theologically sound, age-appropriate, and printable on the church copier. The speed creates the appearance of progress while shifting the verification burden onto the least-resourced user.
Teams I have watched adopt this pattern usually discover the damage later, when a parent emails about an inaccurate Bible story or a volunteer quietly stops using the tool. The framework that promised acceleration never accounted for the downstream correction work. Wesley’s first rule requires asking what harm is introduced before the first line of code is changed or the first prompt is saved to the shared library.
The practical test is simple. Before shipping any new AI-assisted workflow, the team must be able to name the exact person who will absorb the error if the model is wrong and confirm that person has both the time and the expertise to catch it. If that person is a volunteer with a seven-minute window, the workflow fails the rule.
Preventing Evil by Refusing to Outsource Verification
The second rule presses further. Doing good requires refusing to let the model become the final reviewer of its own output. In practice this means keeping a human in the loop at the point where ministry outcomes are decided, not merely where content is generated. Many current agent patterns collapse this distinction by treating verification as another task the model can handle.
One team I observed built an agent that drafted weekly prayer requests from church email inboxes. The initial version looked impressive in the demo because it summarized tone and urgency. After two weeks the pastoral staff noticed the summaries flattened the actual language people used when they were desperate. The correction work fell back on the same staff who had hoped to be freed up. The evil here was not malice but the quiet replacement of real pastoral attention with a plausible proxy.
Staying inside the rule means the verification step is designed first and the generation step is designed second. The team that kept the inbox summaries under direct human review before any automation ran found the real time savings came from better search inside the existing database, not from the model itself.
Staying in Love with the Work That Cannot Be Automated
Wesley’s final rule is the one most easily ignored under tooling pressure. Staying in love with God, translated into product terms, means continuing to value the parts of the work that resist automation. For faith-tech this often includes the slow judgment calls that determine whether a resource actually forms people rather than simply informing them. Those calls require attention that current frameworks treat as overhead.
Teams that chase framework after framework eventually notice they have less time for the judgment work and more time managing prompt libraries. The love for the actual outcome fades because the daily craft has been replaced by maintenance of the tooling layer. The rule does not forbid new tools. It requires that the tools serve the irreplaceable work rather than displace it.
In one case a sermon resource platform stopped adding new AI features for six months and instead rebuilt the print workflow so volunteers could finish a lesson on a single printed page. Usage and completion rates rose without any model being called. The decision looked slow to outsiders but kept the team connected to the outcome that actually mattered.
Your Turn: Apply This Today
- Pick one current AI learning habit you repeat weekly and replace it this week with a single chapter from a pre-2015 product book applied directly to your live workflow.
- Before the next prompt you write for ministry content, name the exact user who will catch errors and confirm they have seven minutes or less to do so.
- Design the verification step for your next AI-assisted feature before you design the generation step, then document who owns the final sign-off.
- Remove one automated output that currently reaches a volunteer or pastor without a human review gate and measure the change in completion rate over two weeks.
- Schedule a two-hour session this month to map which parts of your product still require slow pastoral or volunteer judgment and protect those steps from further automation.
- Choose one pre-2015 book on product or operations and require the next three framework evaluations to cite a specific principle from that book before any new tooling is adopted.
Embedding Agents Into Existing Ministry Workflows Beats Building Separate AI Tools and Trust Signals Can’t Be Faked—Why Faith-Tech Products Must Build Verifiable Ministry Outcomes both explore how durable constraints outperform rapid tooling cycles when the users are ministry leaders rather than engineers.
I consult with faith-tech product leaders on applying historical product constraints to AI decisions and protecting ministry outcomes from automation shortcuts. Let’s talk.