You’re the product manager who received an AI agent mandate at a denomination you still don’t fully understand. The directive landed in Q4 with a slide deck full of capability claims and a timeline that assumed your existing roadmaps would simply stretch. No one named the actual ministry staff whose daily friction would determine whether the agent helped or harmed.
That assignment puts you in a position most faith-tech product leaders never chose. You now decide what the agent sees, what it surfaces, and what it is allowed to change before any user experiences the result.
This is the foundational misread that causes product teams to build agents that optimize the wrong things. They treat the model as a solver rather than a forced listener. Teresa Torres’s continuous discovery framework makes the distinction clear: the product improves only when teams repeatedly expose it to the live moments where users struggle, not when they let the model infer needs from aggregated data.
The First Interview You Must Run With the Agent Watching
Pick one children’s ministry volunteer who still prints the lesson on Thursday night because the digital flow breaks at step three. Schedule a thirty-minute call and share the screen with your agent open in a separate pane that records every prompt you feed it.
Do not brief the agent beforehand. Let it watch the volunteer describe how they adapt the material for a child who arrives late and disruptive. Note the exact sentence where the volunteer says they skip the discussion question because it never fits the remaining time. That sentence is the signal.
The agent will immediately suggest a rephrased question or a shorter activity. Your job in that moment is to pause and ask the volunteer whether the suggestion would have worked last week. Record the answer verbatim. The first interview succeeds when the agent is forced to hold its optimization until a named person has rejected or accepted the change.
Repeat this pattern with two more volunteers before the week ends. The pattern matters more than volume. Each session reveals friction the model cannot see in usage logs.
How to Make Every Output Traceable to a Named Person Who Can Say No
Build a simple log that ties every agent suggestion to the exact user who would experience it. The log must include the person’s role, the ministry context they named, and their direct response. Store it where the engineering team cannot delete rows without a pull request that surfaces the original name.
At Sermons4Kids we learned that volunteer completion rate only moved when we stopped accepting any edit that lacked a named volunteer’s veto. The same rule applies to agents. If the suggestion cannot be traced to someone who could have said no in real time, it does not ship.
This requirement slows the first two weeks. It also prevents the agent from quietly rewriting curriculum language that carries theological weight for a specific congregation. Traceability is not paperwork; it is the mechanism that keeps the model from becoming an unaccountable editor of lived ministry practice.
The Discovery Loop That Keeps Agents From Becoming Invisible Infrastructure
Continuous discovery requires the agent to participate in the loop rather than sit outside it. After each interview, feed the volunteer’s exact words back into the agent with one added instruction: surface the next question you would ask this person if you could book a follow-up call.
Review the agent’s proposed question before you send it. The review step is where you catch when the model has drifted into generic best practices instead of the particular constraint the volunteer described. Over time the agent learns the difference because you have made the correction visible and attributable.
Run this loop on the same three volunteers for four weeks. The repetition surfaces whether the agent’s suggestions are actually reducing the friction or simply layering new steps. Only after the loop shows measurable reduction in the original pain point do you widen the set of users.
The loop also protects against the quiet failure mode where the agent becomes infrastructure that no one questions because it no longer interrupts anyone. When the agent stops generating questions that require a named person’s answer, the loop is broken and discovery has ended.
Your Turn: Apply This Today
- Block thirty minutes on Thursday to interview one volunteer with the agent watching and record the session.
- Create the traceability log in the same document where you already track user stories and require every agent output to carry a name before it moves to engineering.
- Write the agent’s follow-up question after the interview and send it to the volunteer only after you have reviewed it for drift.
- Schedule the second and third interviews for next week with the same volunteers so the loop begins before any broader rollout.
- Tag the original friction sentence from the first call in your backlog and measure whether the agent’s later suggestions reduce that exact sentence’s frequency.
- Share the traceability log excerpt with one ministry leader who can say no and ask them to mark the row that would have failed their test.
Embedding Agents Into Existing Ministry Workflows Beats Building Separate AI Tools showed how agents gain traction only when they inherit the constraints of current volunteer flows. Trust Signals Can’t Be Faked—Why Faith-Tech Products Must Build Verifiable Ministry Outcomes made the same point about outcomes that must remain attributable to real people.
I consult with product leaders building AI agents for ministry contexts on continuous discovery loops, traceable agent outputs, and surfacing ministry friction before optimization. Let’s talk.