The Feature Roadmap That Quietly Became an Org Design Problem

Most AI product teams treat agent work as an exercise in feature velocity rather than an exercise in transferring judgment from one person to the next.

The result is systems that perform well when the original builder is in the room and stall the moment that person steps away. This pattern shows up whether the agent drafts volunteer schedules, summarizes teaching notes, or routes prayer requests. The first run succeeds because the builder still holds the mental model. The second and third runs fail because no one else holds the same model.

This is the foundational misread that causes product teams to optimize for launch metrics instead of handoff metrics. Teresa Torres’s continuous discovery framework makes the distinction sharp. Torres argues that discovery is not a phase but a set of small, repeating loops that keep the team in contact with the actual problem space. When those loops stay inside one person’s head, the team stops discovering as soon as that person moves on.

The same principle applies to agents. An agent is not a finished product until the discovery loop that created it can be run by someone else without the original builder present.

Stop shipping agents that only the builder can run

Children’s ministry platforms often see this first. A volunteer coordinator builds an agent that pulls curriculum themes and suggests age-appropriate activities. In testing it works cleanly because the coordinator knows which fields are reliable and which need manual override. Two weeks later a new volunteer tries the same flow and receives mismatched age groups because the override rule was never written down.

The agent itself is not the problem. The problem is that the builder treated the working demo as the end of the work rather than the start of a transfer process. Continuous discovery requires that the team document the questions the agent cannot yet answer, not just the ones it can. Without that documentation the next person inherits only the surface behavior.

Ministry teams feel the cost quickly. A single reliable volunteer leaves and the agent becomes shelfware. The team then concludes the technology failed when the real failure was the missing handoff step.

Make the handoff visible before the first demo

Teams that follow Torres’s approach insert a handoff checkpoint before any internal demo. They write the exact sequence another person must follow to reach the same result the builder reached. This sequence includes the data sources, the places where judgment is required, and the signals that mean the output should be rejected.

One platform team adopted this rule after an agent that routed small-group requests worked for its creator but produced inconsistent groupings once handed to the operations lead. The team added a one-page handoff document that listed the three judgment calls the agent could not yet make. The next iteration included those calls in the prompt, and the operations lead could run the loop without asking for clarification.

The checkpoint forces the builder to surface tacit knowledge before it is lost. It also surfaces gaps in the agent itself that would otherwise remain hidden until someone else tried to use it.

Measure the second and third person who can explain what just happened

Standard product metrics track time to first value or number of tasks completed. Those numbers stay high as long as the builder stays involved. The more useful metric tracks how many additional people can explain the agent’s decision without referring back to the builder.

In one case a teaching-notes agent was measured by how many staff members could describe why it flagged certain passages for review. After the handoff document was introduced, three staff members could give the same explanation the original product manager had given. Retention of the agent rose because the explanation no longer depended on one person remaining in the role.

Continuous discovery treats this transfer as observable behavior, not assumed goodwill. If the second and third people cannot restate the logic, the discovery loop has not yet left the builder’s head.

Your Turn: Apply This Today

• Pick one agent that shipped in the last quarter and list the three judgment calls it still requires.
• Write the exact sequence a new team member would follow to reach the same output without asking you for help.
• Run that sequence with a colleague who was not part of the original build and note every point where they hesitate.
• Add the missing judgment rules to the prompt or the supporting document before the next sprint planning meeting.
• Schedule a 30-minute review two weeks after the update and measure how many people can explain the agent’s output without your presence.
• Record the names of those people and treat that list as the real success metric for the agent.

The same transfer problem appears in schedule agents that keep running after the original owner leaves and in pod structures that still require an extra set of eyes to stay stable. Both cases show that the agent only becomes durable once the discovery loop moves beyond its first builder.

I consult with product leaders and ministry technology teams on building agent loops that transfer judgment and designing visible handoffs. Let’s talk.