The PM Role That Broke When Agents Took the Wheel

You’re the product manager who walked into a Monday standup and learned the denomination’s new agent would now own volunteer routing, curriculum reminders, and follow-up texts for parents who miss check-in. No one asked how the agent would know which family just moved or which small group leader quit without notice. They just handed you the mandate and the dashboard.

You know the tool will generate schedules faster than the old spreadsheet ever could. You also know the first time it books two overlapping events on the same night, the phone calls will come to you, not the vendor.

This is the foundational misread that causes product teams to treat agent deployment as a handoff rather than a permanent increase in surface area they must personally monitor. Teresa Torres’s continuous discovery framework makes the cost visible: opportunity and regret both compound when the people closest to the work stop talking to the people who experience the work every week.

The handoff that never stayed handed off

The first agent your team shipped handled basic reminder texts for children’s ministry volunteers. Engineering owned the integration, data owned the success metrics, and you moved on to the next initiative. Within six weeks the agent began texting the wrong shift leaders because a children’s director had updated the volunteer roster in the church management system rather than the spreadsheet the model was trained on.

The failure landed in your inbox because the director knew your name from the original requirements meeting. No one else on the team had that relationship. The handoff had never actually left your desk; it had only left the meeting room.

Continuous discovery insists that the same person who decides what the agent should optimize must also sit with the person whose week gets wrecked when the optimization is wrong. In ministry settings that person is usually a volunteer coordinator working two jobs, not a salaried staff member who can absorb the coordination cost.

Discovery loops that must run on live schedules

Torres’s interview cadence assumes weekly customer contact. When the product is an agent that books rooms and sends texts, the relevant signal arrives on Tuesday at 4:17 p.m. when the youth pastor texts you directly because three families showed up to an event that no longer exists on the calendar.

You cannot batch those moments into a quarterly research sprint. The loop has to close the same day the agent creates the mismatch, or the next week’s schedule will repeat the same error with different families.

Teams that delegate the loop to an analyst or an LLM summary lose the texture. The analyst sees a drop in response rate. You hear that the volunteer who always covers last-minute nursery shifts stopped checking her phone because the agent kept asking her to cover events she had already declined three times. That distinction changes the next prompt and the next guardrail.

The boundary that keeps agents from forking real work

One church ran an agent that could propose small group meeting times based on member availability pulled from multiple calendars. The model suggested a Tuesday night slot that worked for the majority. It did not know the associate pastor’s standing counseling commitment or that the host home had just lost internet. Two groups met anyway and one dissolved after the confusion.

The boundary is not a technical constraint on the model. It is an explicit rule that certain categories of schedule change must route through a human before the agent sends any message. The product manager owns the definition of that category because only the product manager sees both the model’s output volume and the downstream coordination cost when the output is accepted without review.

Continuous discovery treats that boundary as a living artifact. Every time an agent creates a fork that requires manual cleanup, the boundary gets one line tighter or one exception wider. The work is never finished because the agent’s context window keeps expanding.

Your Turn: Apply This Today

• Pick the single agent your team shipped most recently and list every coordination failure reported in the last fourteen days; schedule thirty-minute calls with the two people who felt the impact most directly before Friday.
• Write the exact sentence you will send the next time the agent books overlapping events and save it as a template so you are not composing under pressure at 6 p.m.
• Define one category of change the agent may never execute without human review and add it to the prompt and the monitoring dashboard this week.
• Block two hours on your calendar every Tuesday for the next month labeled only “agent regret review” and refuse to move them for internal meetings.
• Ask the volunteer coordinator at the largest site using the agent what single piece of information the model still lacks and ship the smallest possible data fix that week.
• Document the last three times you personally had to intervene after the agent acted and turn each instance into one new discovery question for the following week’s interviews.

The same pattern appears in both “The Question Every PM Gets After the First Agent Ships” and “The Night the Voice Agent Forked Three Ministry Schedules at Once.” The difference is whether the product manager treats the agent’s output as someone else’s problem to clean up.

I consult with product leaders shipping agents into ministry and nonprofit workflows on continuous discovery loops, regret surface ownership, and live coordination boundaries. Let’s talk.