church techFrom the builder

Pastors Asked for This Feature. I Will Not Build It.

By Michael Tribett · July 15, 2026 · 12 min read

Pastors have asked me, more than once, for the same feature. And every time, the ask sounds completely reasonable.

Here it is. Collie, the sheepdog inside FlockConnect, notices that two people in your church would probably hit it off. Ryan and John are both into rock climbing. Both have Tuesday mornings free at 8am. So the request goes: when Collie spots a match like that, have her text them both an introduction on the pastor's behalf.

No.

I keep saying no, and I owe the pastors who asked a real explanation. Because on paper this looks like exactly what FlockConnect is for. We exist to help people get connected. This is a feature that connects people. Why would the guy who built connection software refuse to build the connection feature?

To be frank, it comes down to the question I ask before every AI feature. Not "what can the AI do here?" The better question is "what don't I want the AI to do?" It is easy to make something agentic that does everything for you. It is also how ministry becomes robotic.

A text message from a system is generic. An organic relationship will not form that way. But when Collie tells the pastor, and the pastor walks up to Ryan on Sunday and says, "Hey, have you met John? He's super into rock climbing. I'd love to connect you two," something different happens. The pastor stewarded that moment. The introduction cost somebody something. That is the human element relationships actually need.

So this post is the full list of what Collie will never do, and why that boundary is the product. It starts with the feature everyone wants.

The question I ask before every AI feature

Most AI product work starts with a capability list. What can the model do now? What did it learn this month? Start there and you will ship everything that demos well, because almost everything demos well.

I start at the other end. Before I build any AI feature, I write down what I do not want the AI to do inside it. That list comes first, and the feature has to live inside it. My whole approach to integrating AI is less "what can AI do?" and more "what don't I want the AI to do?" Because it is very easy to make something agentic to where it just does everything for you, and it becomes robotic.

That is the default direction of this technology. Every model release hands you a little more it could take over. Nobody has to decide to make ministry software robotic. You just have to never decide against it. So I decide against it, on purpose, at the start of every feature, and the refusals get written down before the first line of code.

Why the reasonable ask gets a no

Run the auto-intro text through that question and it fails in the first minute.

What don't I want the AI to do? I do not want it standing in a moment that belongs to a person. And an introduction is exactly that kind of moment.

When pastors asked me for this feature, I told them I am fundamentally against the idea. A system-sent text is too generic, and I do not think an organic relationship will form well that way. Ryan gets a message from a piece of software telling him a stranger shares his hobby. There is no relationship behind that message, no history, nobody who knows them both. It reads like what it is: a database noticing an overlap.

I want it to be as organic as possible. I want to give the pastor that information so the next time they see that person, they can introduce them.

The same information lands completely differently that way. The pastor walks up to Ryan on Sunday. "Hey Ryan, have you met John yet? He's super into rock climbing." That introduction carries weight because it cost the pastor something. He had to notice, remember, and spend part of his Sunday on these two men. And Ryan learns something bigger than John's name. He learns his pastor knows him.

Building the text instead would just be lazy, and it takes away the human element that is necessary for forming relationships. That is the whole refusal. The feature is buildable. It would demo beautifully. And it removes the exact thing FlockConnect exists to protect.

What Collie will never do

Here is the list, then. These are not gaps waiting on a roadmap or technical limits. Every one of them is buildable today. They are refusals, written into how Collie is designed.

Collie will never reach out to a church member on her own. No text, no email, no nudge. She is specifically designed to never contact a church member on behalf of the pastor.
Collie will never send anything a person has not approved. She can draft a note, an email, a next step. Then she stops and waits. A person reviews and approves every action before it goes anywhere.
Collie will never introduce two members to each other. There is no member-introduction generator in FlockConnect, and there never will be. Connections get surfaced to the pastor, and the pastor does the introducing.
Collie will never change anyone's care on her own. No writing to a care record, no closing a follow-up, no reassigning a person without a human deciding it.
Collie will never simulate pastoral care. She is not a chaplain and not a counselor, and no church member will ever mistake a message from a bot for care from their pastor, because Collie does not message members at all.
Collie will never make the pastoral decision. Her job ends where the pastor's job begins. She brings the information so the pastor can make the call.

If a future feature cannot live inside that list, the feature loses. The list does not.

What Collie does instead

The alternative is not less capability. It is capability pointed at sight instead of action. I do not believe the answer is more automation standing between a pastor and their people. I believe it is better sight.

So Collie alerts the pastor to issues and concerns within the church. Low engagement. A giving pattern that stopped. A check-in that stopped. A note a small-group leader left. Then it is the pastor's job to do with that information what that pastor will do.

You can see the same restraint in surfaces that have already shipped. Connection health in FlockConnect shows a plain status word, never a percentage, because a percentage invites ranking and a congregation is not a leaderboard. I wrote up how that works in what is a connection health score. And when the connection-suggestion surface that started this essay does ship, it will obey the same rule as everything else here: the suggestion goes to the pastor, and "Hey Ryan, have you met John?" stays a sentence only a human being says.

That is what a Church Relationship Manager is for: helping a church see its own relationships clearly, so the people responsible for those relationships can act.

The boundary is the product

I made the fuller argument for all of this in AI should be a sheepdog, not a shepherd, and I will not re-argue it here. The short version: the pastor is the shepherd, Collie is the sheepdog. AI can bark. The shepherd still has to shepherd.

What I hope anyone building with AI takes from the refused feature is the method underneath it. Ask what you don't want the AI to do before you ask what it can do. Write the refusals down. Let them cost you a feature that would have demoed well. A person reviews and approves every action Collie proposes, and that boundary is the product, not a limitation we are apologizing for.

This boundary is personal before it is product. I talk to AI all day, and I have written about what it does and does not feed.

I want AI to be seen as a tool and not as a replacement. It should not interfere with what makes us human.

About the author

I am Michael Tribett, the founder of FlockConnect. I hold a Master of Divinity from Southeastern Baptist Theological Seminary (2022), I have led a small group at my church since 2018, and I spent three years inside a major ChMS company before building the relational layer I kept looking for and never found. When I am not building, I am a full-time dad to two little girls.