Blog

You open the dashboard on a Tuesday and the prayer request from the single mom is already marked “routine follow-up.” No one on the team touched it. The agent read the tone, pulled the history, and routed it before you finished your first coffee.

That’s the moment ownership slips. Not in a dramatic handoff meeting, but in the quiet second when a model decides what counts as urgent and what can wait.

The question isn’t whether to use agents. It’s whether every decision they make still travels through the same messy loop you already use for volunteers and pastoral care—where real people keep seeing the raw request before anything gets closed.

That single filter step looks like efficiency. In practice it removes the volunteer from the loop that used to shape how care decisions were made. Over weeks the coordinator stops asking the volunteer what they would have done. The model’s threshold becomes the de facto policy.

Teams that track every handoff notice the pattern within two weeks. The agent begins to carry institutional memory the volunteer never had access to. When the volunteer rotates out, the knowledge does not transfer back to the next person; it stays inside the agent.

Resilience Language That Masks Ownership Erosion

Small teams often describe the agent as “building resilience” because it keeps basic tasks moving when volunteers are absent. The phrase hides the fact that the team has stopped practicing the handoff itself. Resilience that depends on a model is not the same as resilience built through repeated human handoffs.

In one mid-size church the prayer request inbox agent started summarizing needs before they reached the care pastor. The language used in updates shifted from the pastor’s phrasing to the agent’s summaries. Six months later the pastor could no longer explain how certain families had been triaged, because the decision criteria lived only in the agent’s prompt history.

Continuous discovery treats this as a signal, not a feature. The team asks who still owns the definition of an urgent request. When the answer points to the model rather than a named person, the ownership has already moved.

Discovery Meetings That Surface the Hidden Cost

Teresa Torres’s continuous discovery requires regular conversations with the people who will be affected by the change. Applied to agents, those conversations must include the exact moment the agent will make a choice previously made by a volunteer or pastor. The meeting does not discuss model capabilities; it walks through one real request and names who loses the decision right.

Teams that run these meetings before any code is written catch the shift while it can still be reversed. They ask what the volunteer would have done differently and whether that difference matters. The answer usually reveals a judgment the agent cannot safely replicate without the volunteer’s ongoing input.

After deployment the same questions are repeated monthly. The goal is not to measure accuracy but to detect when the human side of the loop has stopped practicing the original handoff. When participation drops, the agent is scaled back before the team forgets how the work was done.

Your Turn: Apply This Today

• Pick one daily workflow an agent could touch, such as triaging new prayer requests, and write the exact handoff steps a volunteer currently follows.
• Run that workflow through your existing discovery questions with the two people who usually perform the handoff and note every judgment they make that the agent would now own.
• Document the ownership shift in one paragraph that names the person who loses the decision right and the date the change would take effect.
• Schedule a 30-minute continuous discovery conversation with those same two people within the next five days to review the paragraph.
• Before any prompt is written, decide what weekly signal will tell you the human handoff is no longer being practiced.
• Write the rollback trigger that returns the workflow to the original human loop if that signal appears.

Embedding agents into existing ministry workflows beats building separate AI tools and To the Product Manager Handed an AI Agent Mandate Last Quarter both explore how teams keep control when models arrive inside daily work.

I consult with product leaders and ministry leaders on embedding agents through continuous discovery and preserving ownership in volunteer and pastoral workflows. Let’s talk.

It’s 11:40 p.m. and the laptop fan is the only sound in the kitchen. She pastes the last batch of prayer requests into the new tool, adds a short prompt about warmth and brevity, and watches three drafted replies appear. They read clean enough to send.

She queues them for morning, shuts the screen, and heads to bed. The system handled the volume; the rest, she figures, is just logistics.

By Thursday the first reply had already reached someone whose request was resolved weeks ago, and another landed with a small-group suggestion that made no relational sense. The AI had done exactly what it was asked. It just had no way to know what it was missing.

Solomon’s judgment supplies the missing lens. When two women claimed the same child, Solomon did not optimize for speed or volume. He forced the real criterion into view: which outcome would actually preserve life. The sword test revealed the difference between a claim that sounded right and the relationship that mattered. Faith-tech pilots skip this step when they treat the first generated message as the deliverable.

The Clean Output That Breaks on Contact

The first agent response always flatters the builder. Sentences land in the right tone. The structure looks complete. Yet the output contains no trace of the ministry’s actual decision rules about who owns which relationship or when a request moves from one leader to another.

I watched this play out with a mid-size church that fed six months of pastoral care notes into an early agent. The drafts looked pastoral. Two of the first five messages went to the wrong volunteer because the model had no way to know that one leader had stepped back for health reasons three weeks earlier. The data existed in a different system. The prompt never asked for it.

The surface match creates the illusion of progress. Real ministry work depends on context that lives outside the text the agent sees. Without an explicit rule for surfacing that context, the output routes people to the wrong place while still sounding correct.

The Pre-PMF Gate I Now Require

Before any pilot expands past the single volunteer who built it, I ask for one artifact. A single sentence that states the exact outcome the ministry owner will measure after the tool runs. Not accuracy. Not time saved. The concrete result for the person on the other end of the message.

Most teams resist this step because it feels slow. They have already seen the agent produce something usable in a demo. The sentence forces them to name what changes in the real workflow once the output leaves the screen. If the owner cannot edit the sentence into something they can verify in their own system, the pilot stops.

This requirement comes from watching too many promising workflows collapse at the first handoff. The sentence acts as the test Solomon applied. It reveals whether the automation targets the relationship that actually needs preserving or merely the text that happens to be easy to generate.

Which Problems Become Tools and Which Stay Human

Once the judgment step is explicit, the list of candidate automations shrinks. Tasks that only require matching visible data to a template survive. Tasks that require knowing which relationships have changed in the last month or which requests were already closed do not.

The prayer-request database that became a living record stayed human at the point of assignment. The agent now drafts language and surfaces possible matches, but the final owner still confirms the routing against the current small-group map. The judgment step sits with the ministry owner, not the model.

This split changes how teams staff pilots. Instead of handing a volunteer a new workflow and measuring output volume, the owner first writes the one-sentence definition of success. Only then does prompt work begin. The result is fewer tools that reach production, but those that do survive first contact with real people.

Your Turn: Apply This Today

• Take the next AI pilot idea you have written down and reduce it to one sentence that names the exact outcome a ministry owner will verify after the tool runs.
• Send that sentence to the actual ministry owner who would receive the output and ask them to edit it in their own words before any prompt is written.
• If the owner cannot name a verifiable result in one sentence, archive the pilot idea for thirty days and pick a narrower problem.
• Document the edited sentence in the same place you store the prompt history so the success criterion stays visible when the first clean output appears.
• Run the pilot only with the single volunteer who owns that sentence, and stop expansion until they confirm the outcome matched the definition on their own system.
• Repeat the one-sentence definition step for every new workflow before any code or prompt work begins this quarter.

The same pattern showed up in how the living prayer-request database evolved and in the decision to embed agents rather than build separate tools. Both cases required the judgment step before any automation moved forward.

I consult with product leaders and ministry owners on defining success criteria for AI pilots and embedding agents into existing workflows. Let’s talk.