The Product Leader Who Inherited an Agent Loop With No Owner

You inherited the agent loop last quarter when the previous PM moved on to a startup. The denomination needed someone who understood both the tech and the field realities of churches running on volunteers, and they handed you the keys without a map. The loop still runs—generating weekly curriculum outlines, flagging volunteer availability gaps, and pushing draft emails to small group leaders—but no one can explain why certain suggestions land well one month and miss entirely the next.

That absence of ownership is the real problem. Teresa Torres’s continuous discovery framework assumes someone stays close enough to the users to keep refreshing the context that feeds the system. Without that person, the loop drifts. It starts optimizing for yesterday’s patterns instead of today’s actual ministry constraints.

The missing owner in every agent loop

The agent that suggests children’s ministry stories still pulls from a context file last updated in March. It recommends the same Moses craft for the fourth time this year because the file never recorded that three regions ran it already and volunteers pushed back. You see the duplicates in the feedback tickets, but the system has no signal that the suggestion needs updating.

This happens because the builder treated the agent as a feature release rather than an ongoing product. Once the initial integration shipped, attention moved to the next sprint. The context file became an artifact no one touched, exactly the opposite of Torres’s insistence that discovery is continuous work, not a handoff deliverable.

In practice this shows up in the volunteer completion rate metric you track from the old curriculum platform usage data. The rate dips every time the agent repeats a suggestion that already exhausted local supplies or volunteer energy. The loop keeps producing output, but the output no longer compounds the institutional knowledge the denomination actually needs.

How discovery habits collapse when no one owns the context file

Torres taught teams to keep an updated opportunity solution tree that reflects real interviews and usage data. When the context file lives in a shared drive with no assigned owner, the tree stops growing. The agent continues to run on stale assumptions about what a typical volunteer can accomplish in one prep session.

You notice the pattern in the tickets that mention “this doesn’t match our current curriculum cycle.” Those tickets used to trigger updates to the context file. Now they sit in a backlog because the new mandate focuses on shipping visible agent improvements rather than maintaining the source material that makes those improvements relevant.

The result is a quiet reversal of Torres’s core practice. Instead of discovery feeding the loop, the loop starts feeding itself stale data. Over time the suggestions become generic enough that ministry leaders stop relying on them, which further reduces the signal available for any future correction.

Designing the org system that keeps the loop alive after the builder leaves

The handoff itself must become a tracked product artifact. That means documenting not just what the agent does, but which specific user contexts it draws from and who is responsible for refreshing each piece. Without that documentation, the next person inherits only the running code, not the discovery discipline that kept it useful.

One ministry I watched handled this by requiring every agent change to include an updated context section and an assigned reviewer. The reviewer was not the builder. Their job was to test the suggestion against three real volunteer workflows before the change went live. That single role kept the loop connected to current field conditions even after the original builder moved to another team.

The same principle applies to the curriculum resources side. When ownership of the context file moved from the builder to a rotating ministry lead, the volunteer completion rate stabilized. The agent still generated drafts, but the drafts now reflected what actual volunteers could finish in the time they had.

Your Turn: Apply This Today

• Identify the three agent loops already running in your org and list the current context files each one depends on.
• Assign one named owner to each context file with a required monthly refresh cadence and a visible change log.
• Write a one-page handoff artifact for the loop you inherited that includes the last three user contexts tested and the reviewer who signed off.
• Schedule a 30-minute review this week where the new owner walks through one recent agent output against actual volunteer feedback.
• Add a required field in your ticket system that blocks any agent update until the context owner has updated the supporting file.
• Run a two-week audit that measures whether volunteer completion rates improve after the context files receive their first assigned refresh.

The Agent That Kept Running the Schedule While No One Was Watching and The Ministry PM Who Handed Off Captain Duties Without the Handoff Log both trace the same pattern of loops that outlast their builders.

I consult with ministry product leaders on maintaining agent loops and institutional knowledge across team transitions. Let’s talk.