The most dangerous sentence a church AI can say is not a wrong answer about the Trinity. It is not even a made-up Bible verse, though those are bad. The most dangerous sentence a church AI can say is this one:
"I've passed that along to the pastor."
Because that sentence is either true, or it is a lie the software tells to a person who just did something brave.
Think about who hears it
Nobody asks a church's assistant to have someone call them because life is going well. The person typing "can someone from the church call me this week" at 11pm is a new widow, a dad whose marriage is coming apart, a teenager working up the nerve to talk to an adult. Reaching out cost them something. When the assistant answers warmly and says the pastor will be in touch, that person stops looking for help. They have been helped, as far as they know.
If the request never actually reached a human, the software did not fail a feature test. It told a vulnerable person that the church heard them when the church did not. That is a different category of bug. I would call it what it is: a broken promise, made at scale, by a machine wearing the church's name.
We have caught this in our own system. Twice.
I want to be specific here, because this article is worthless if it reads like a vendor pointing at everyone else.
Earlier this year we discovered that in one of our demo configurations, the assistant was confirming "prayer request saved" while the save had been quietly short-circuited. The conversation looked perfect. The visitor was thanked. No row was written anywhere a human would ever look. We fixed it, wrote the reason into the code in capital letters, and carved prayer requests, benevolence requests, and safety flags out of every shortcut path permanently: those writes are load-bearing, and nothing is allowed to fake them.
Then, just this month, an adversarial audit of our own platform caught the same disease in a different limb. On our public demo, a visitor who asked for a callback about a painful family situation was told a pastor would reach out within two business days. The callback request went nowhere. The prayer requests were landing; the callbacks were not. Same promise, same warmth, no record.
We fixed that the same day, and it forced us to write down the principle underneath both bugs.
A promise is a write
Here is the engineering rule we now hold ourselves to, and it is simple enough to put on a sticky note: if the assistant made a promise, there must be a record a human can see. No row, no promise. The sentence "I've passed that along" is only allowed to exist as a description of something that already happened in the database, never as a pleasant noise the model makes.
That sounds obvious. It is not how most conversational AI is built. Language models are optimized to produce satisfying conversation, and "your request has been submitted" is a deeply satisfying sentence. It ends the interaction on a warm note whether or not anything was submitted. Every layer between the model and the database, and there are more of those layers than anyone admits, is a place where the words and the reality can quietly come apart. When they do, the failure is invisible by design: the person who was dropped believes they were caught, so nobody complains, so nobody looks.
Jesus had a standard for speech that I think about more as an engineer than I ever expected to:
"All you need to say is simply 'Yes' or 'No'; anything beyond this comes from the evil one." (Matthew 5:37, NIV)
Let your yes be yes. A church's software speaks with the church's voice, and the standard does not relax because the speaker is made of code. If the machine says yes, the yes must be real.
What we changed, concretely
Three things, and I would encourage you to hold any vendor, including us, to all of them.
Every pastoral promise writes an observable record. Prayer requests, callback requests, benevolence needs, safety concerns: each one lands in a table the church's dashboard actually reads, at the moment the assistant claims it did. The confirmation language is generated from the outcome of the write, not alongside it.
Demo and test modes are not allowed to fake load-bearing writes. The whole point of a shortcut path is that nobody looks at it closely. So the writes that carry a person's cry for help are exempt from shortcuts, everywhere, including on our own sales demos. If you try our demo and ask for a callback, a real row lands somewhere a human can audit.
When something does fail, the assistant says so. A stream that dies mid-answer now produces an honest "I'm having trouble right now, please use the contact options on this page" instead of silence. An error the visitor can see is recoverable. A failure dressed up as success is not.
The question to ask any church AI vendor
You do not need to read anyone's source code. Ask one question: "When your assistant tells a visitor their prayer request was passed along, show me where I can see that request." Then submit one from the public-facing tool yourself and watch for it.
If the answer involves a dashboard with your request sitting in it, timestamped, you are dealing with people who understood the assignment. If the answer is a pause, you have learned something more important than any feature list, because everything else the assistant says rests on whether its yes means yes.
We publish how we handle this, including what our AI will not promise, on our AI safety page, and the assistant you can try on our chatbot page runs the exact same load-bearing writes as a paying church's does. That last part is the whole point.
The machine is allowed to sound warm. It is not allowed to be wrong about whether the church heard you.
Sources
- Matthew 5:37, New International Version. biblegateway.com
- Our earlier post on why the same system refuses to promise confidentiality: Why Our Church AI Will Never Promise to Keep Your Secrets
Frequently asked questions
How do I know if my church's chatbot actually delivers prayer requests?
Submit one yourself from the public page and then look for it in the admin dashboard, or ask whoever manages the tool to show you the record. A trustworthy system produces a visible, timestamped entry for every request the assistant claims to have passed along. If nobody can point to where the requests land, treat every confirmation the assistant gives as unverified.
What should a church AI say when something goes wrong?
It should say that something went wrong, plainly, and give the visitor a human path: a phone number, a contact form, an email. The unacceptable behavior is silence or a cheerful confirmation of an action that failed. An honest error keeps the person looking for help; a false success stops them.
Is it wrong for a church to use AI for prayer requests at all?
Taking a prayer request is a fine job for AI, with one condition: the AI is a bridge, not the destination. Its work is to capture the request accurately and put it in front of a real person who will pray and follow up. The moment the machine becomes the last stop, either by design or by a silent bug, it has taken on a role it cannot fulfill.