Blog

You’re the product manager who opened your inbox in March and found yourself responsible for an agent schedule that now books, cancels, and reschedules volunteer shifts at a denomination whose regions you have never seen in person. The previous owner left for a startup, the handoff doc is three bullet points, and the agents have already started changing assignments based on rules nobody documented.

This is the foundational misread that causes product teams to treat agent execution as a prompt problem instead of a state-change problem. Teresa Torres’s continuous discovery insists on ongoing contact with users and evidence before every decision. When agents own the loops, that contact must move from the initial request to the exact moments the system alters ministry reality.

Map the handoff points where agents fork ministry state

In the children’s ministry tool I helped shape, the real boundary was never the lesson request. It was the moment the system marked a volunteer as confirmed and removed them from the open list. Agents now do that step without a human seeing the calendar conflict that only surfaces on Sunday morning.

The fork happens at three places: when an agent accepts a last-minute swap, when it drops a recurring commitment, and when it notifies the small-group leader instead of the volunteer coordinator. Each fork changes the shared record that later humans treat as truth. Torres’s method would require sitting with the actual coordinator while the agent proposes the change, watching which field they check first and which notification they ignore.

Without that map, teams keep adding guardrails to the prompt. The guardrails never reach the record that actually drives attendance reporting and background-check reminders.

Build discovery into the rollback surface, not the prompt

Continuous discovery loses its power when the only place to test an assumption is before the agent runs. The useful test happens after the change exists. In one region, an agent moved twenty volunteers from a midweek program to a weekend event based on attendance trends. The rollback required three separate systems to be edited by hand because no one had built an undo path that preserved the original notification chain.

Discovery therefore belongs on the rollback surface. That means every agent action must leave a reversible record that the coordinator can inspect in under thirty seconds. The question becomes: what evidence would make this coordinator choose to revert rather than repair? You learn that by watching the revert happen, not by asking about preferences in a workshop.

Measure coordination debt the way you once measured velocity

Velocity once tracked story points closed per sprint. Coordination debt tracks the number of manual corrections required after an agent schedule runs for one week. In the volunteer system, that number started at four corrections per hundred assignments and climbed to thirty-eight once agents began handling recurring conflicts without human review.

The debt shows up as duplicate background-check requests, leaders receiving two different volunteer names for the same slot, and printed rosters that no longer match the app. Torres would treat each correction as a signal that the current permission boundary is wrong. The team that measures debt this way stops optimizing for agent speed and starts optimizing for the speed of human repair.

Your Turn: Apply This Today

• Pick the single live agent workflow that books or reassigns people this week and list every state change it can make without human approval.
• Instrument one rollback action so the coordinator sees the before-and-after record in the same screen they already use for manual edits.
• Run the agent for seven days, then count every manual correction required and write the exact reason given for each one.
• Choose one handoff point from your list and add a required human confirmation only when that specific field changes.
• Meet with the person who performs the most corrections and watch them fix one live example without offering any suggestions.
• Update the permission boundary so the agent cannot touch recurring assignments longer than four weeks without an explicit approval step.

The post “The PM Role That Broke When Agents Took the Wheel” shows what happens when those boundaries stay undefined. “The Verification Layer No One Budgeted For” walks through the cost of discovering the need for reversibility only after the first schedule collision.

I consult with product leaders running agent workflows in ministry tools on permission boundaries, rollback design, and coordination debt tracking. Let’s talk.

Ministry platforms that track a high volume of internal messages often assume more logged data means a stronger moat. The teams pulling ahead, though, are the ones ignoring most of those messages for model training and instead guarding the handful of exchanges that reveal how decisions actually move between people.

The obvious reading says more logged data equals a stronger moat. That reading collapses once you watch what happens inside small teams. The data that compounds is the data that records who spoke to whom, when a handoff occurred, and which constraint surfaced only in the moment of coordination. Everything else adds noise that models happily optimize while the real advantage slips away.

This is the foundational misread that causes product teams to chase model performance instead of protecting coordination. They stockpile tokens and lose the map of how work actually travels through their group.

John Wesley’s three rules offer a different lens. Do no harm by removing the friction that already exists. Do good by creating the next useful connection. Attend to the means of grace by keeping the shared memory alive so the next person can act on yesterday’s context without starting over. Applied to internal data, the rules shift focus from volume to the threads that let a small team function as one mind.

The Slack History No One Tagged

One children’s ministry tool team kept every thread about volunteer availability. The history contained repeated notes on which leaders preferred printed copies over app links and which ones needed a reminder two days before Sunday. No one labeled those threads as training data. The product kept shipping updates that assumed digital-first usage until a new hire read the old exchanges and adjusted the print export flow. Completion rates rose without any new model.

The three rules show why this worked. The team had already done no harm by leaving the raw conversation intact instead of summarizing it into a ticket. They did good when the new hire could act on the actual pattern rather than a cleaned-up metric. The shared memory became the means of grace because it carried the constraint forward without requiring anyone to remember it.

Most platforms delete or compress these threads once a ticket closes. The coordination cost reappears the next quarter when a new person hits the same wall. The data moat shrinks because the team optimized for cleanliness instead of continuity.

Why Routing Alone Won’t Save Coordination

Many small teams now route every request through an agent or triage bot. The logs look clean and the model scores improve. What disappears is the moment when two people realized a volunteer needed a different curriculum level and adjusted the assignment in one sentence. That adjustment never entered the routing system because it happened outside the ticket.

Wesley’s rules expose the gap. Routing can avoid harm by preventing duplicate work. It rarely does good because it removes the space where the next useful connection forms. Without the habit of recording the adjustment, the team loses the means of grace that would let the next coordinator inherit the right decision.

The durable moat sits in the un-routed exchange. Teams that treat those exchanges as protected memory rather than noise keep the actual operating logic inside the group instead of leaking it into generic model weights that every competitor can fine-tune.

The Habit That Turns Raw Data Into Shared Memory

One team began ending each week by naming the three exchanges that changed how work would happen next week. They pasted the short excerpts into a single running note. No automation. No tagging taxonomy. The note grew into the only place a new hire could see why the print-first flow existed or why certain volunteers received a phone call instead of an email.

The practice follows the rules directly. It avoids harm by refusing to overwrite context with summaries. It does good by surfacing the next connection for whoever opens the note. It attends to the means of grace by turning scattered messages into a living record the whole team can reference without asking the original participants again.

Over six months the note became the difference between onboarding that took two weeks and onboarding that took two days. The model performance stayed flat. The coordination speed did not.

Your Turn: Apply This Today

• Pick the last three Slack or email threads where a handoff changed because of a volunteer constraint and paste the key lines into one running note before Friday.
• Label that note “Coordination Memory” and share the link only with current team members so the raw exchanges stay inside the group.
• At the end of next week, add the single sentence that describes the adjustment someone made outside any ticket system.
• Review the note with the newest team member and ask what constraint they now see that the model would have missed.
• Delete or archive any routing bot log that duplicated the same adjustment already captured in the note.
• Repeat the three-exchange capture every Friday for the next four weeks and count how many times the note prevented a repeated question.

The Prompt That Replaced the Engineer and Still Missed the Calendar shows what happens when teams protect only the visible output. The OS No One Installed Because It Looked Like Extra Work tracks the quiet habit that actually preserved coordination across handoffs.

I consult with small ministry product teams on mapping coordination threads, protecting internal shared memory, and turning raw exchanges into durable operating context. Let’s talk.

A growing “Agent-First Product Management” playbook circulating among product leaders tells teams to hand discovery, prioritization, and even outcome measurement to autonomous agents so the human PM can focus on “higher-order bets.” The model assumes agents will surface the right problems, run the experiments, and flag only the decisions that truly require taste or authority. In faith-tech work, that assumption breaks immediately because the cost of a wrong call lands on real people whose spiritual formation, not just their engagement metrics, is at stake.

The framework treats verification as a residual task that gets smaller as models improve. It does not account for contexts where the signal is relational and the downside is not a lost quarter but a broken trust that takes years to repair. When the product shapes how volunteers teach children Scripture or how users encounter the Bible in crisis, an agent that optimizes for completion rate can ratify the wrong outcome without ever knowing it missed.

This is the foundational misread that causes product teams to strip the verification layer out of their operating model. They optimize for speed of iteration and treat human review as an expensive add-on rather than the non-delegable core. The result is clean dashboards that hide the moments when an agent quietly chose the expedient over the faithful.

Solomon’s judgment offers the clearest lens here. Two women claimed the same child. Solomon did not ask for more data or run another test. He created a forced choice that revealed which claimant bore the actual cost of the outcome. The test worked because only the true mother would refuse the split. Agents can simulate preferences and optimize for stated goals, but they carry none of the relational stake that makes the refusal meaningful. In ministry products, that stake is the difference between a feature that serves formation and one that merely moves a number.

The Waymo Parallel That Doesn’t Travel to Ministry

Waymo’s autonomous vehicles succeeded because the environment is bounded, the failure modes are physical and observable, and the cost of error falls on insurance models that can price the risk. The same logic does not transfer to products that shape how a children’s ministry volunteer prepares a lesson at 9:30 p.m. on a Tuesday. The variables are not lane markings and traffic signals; they are the volunteer’s attention span, the child’s home situation, and the theological weight of the story being told.

Teams that import the Waymo pattern assume that once the agent handles content selection and personalization, human oversight can drop to quarterly reviews. In practice, the agent begins to favor lessons that score high on the proxy metrics it was given—completion time, visual appeal, repeat usage—while quietly dropping stories that require more context or that surface harder questions. The volunteer still prints the material, but the formation goal has already drifted.

The verification step that remains is not another prompt. It is a human who carries responsibility for the actual child in the room and who will notice when the content no longer fits. That person cannot be replaced by higher model accuracy because the signal lives outside the data the agent sees.

What Breaks When Discovery Gets Automated

Automated discovery promises to replace the slow work of talking to users with continuous agent-driven interviews and synthesis. The pitch is that the agent can run hundreds of lightweight conversations, cluster themes, and surface opportunities faster than any human PM. In faith contexts the method produces plausible themes that still miss the constraint that matters most: the user is often serving under time pressure and emotional weight that no interview transcript captures.

A children’s ministry coordinator may say in a recorded session that she wants shorter lessons. The agent logs the preference. What it cannot register is that the same coordinator will accept a longer lesson if it reduces her Sunday morning panic, because the real job is not efficiency but survival until the service ends. The agent optimizes for the stated preference. The PM who still talks to coordinators in person learns the unstated one.

When discovery is fully automated, the team loses the ability to notice which problems users will tolerate and which ones they will quietly route around. That distinction only appears when someone with skin in the outcome is in the loop. Without it, the roadmap fills with features that solve clean problems and ignore the messy ones that actually determine whether the product stays in use.

The Decision Point No Agent Can Hold

Every week, a product decision arrives that cannot be reduced to trade-offs the agent has been trained to weigh. A new agent-generated curriculum track scores well on engagement but quietly under-emphasizes a core doctrine the ministry has taught for decades. The data does not flag the gap because the doctrine was never encoded as a metric. The human PM must decide whether to ship the track, rewrite it, or kill it.

Solomon’s test applies directly. Only the person who will answer for the outcome in front of the actual ministry leaders will pause to ask whether the doctrine matters more than the engagement lift. An agent can surface the trade-off, but it will not carry the cost of choosing poorly. That cost sits with the PM whose name is attached to the product in the eyes of the churches using it.

Rebuilt operating models that remove this layer do not become faster; they become brittle. The first time an agent makes a call that contradicts the ministry’s actual convictions, the entire trust relationship must be rebuilt from the beginning. The verification step that looked like overhead turns out to be the only part of the system that could have prevented the breach.

Your Turn: Apply This Today

• Pick one agent workflow currently running in your product and add a single human verification checkpoint this week that requires the PM to review the output against the ministry’s stated convictions before it reaches users.
• Write down the exact decision the agent is making today that carries relational risk, then schedule 30 minutes on Friday to test whether the current prompt would have caught the mismatch in a past incident you still remember.
• Run the verification test on the oldest active agent flow in your stack by Friday and log whether the human reviewer changed the output or accepted it unchanged.
• Identify the one proxy metric the agent is optimizing that has no direct counterpart in your ministry’s actual success criteria, then replace it with a qualitative check that only a person carrying outcome responsibility can perform.
• Document the last three times an agent surfaced a “ready to ship” recommendation and note which one required a Solomon-style judgment call that the model could not have resolved.
• Schedule a 45-minute session with the ministry leader who owns the outcome for your highest-volume feature and ask them to name the single failure mode an agent would never flag on its own.

The same pattern appears in “The Verification Layer No One Budgeted For” and “The PM Role That Broke When Agents Took the Wheel,” where the missing human step turned clean agent output into downstream trust problems that took quarters to repair.

I consult with product leaders building AI tools for ministry on agent verification workflows, discovery automation limits, and the decision points that still require human ownership. Let’s talk.