Blog

Most product teams assume the agent request is the difficult step. They negotiate scope, define inputs, and celebrate when the first output lands on time. The real constraint appears only after the agent meets the brief without complaint: the original request no longer represents the outcome the team actually needs.

Teresa Torres built continuous discovery on the premise that teams must keep testing their assumptions against real users even after a solution ships. When agents absorb the execution layer, that same discipline shifts from validating features to repeatedly raising the target outcome itself. The scarce skill becomes the ability to notice that the delivered result is still too modest and to press for a harder one.

This is the foundational misread that causes product teams to treat agent workflows as simple delegation exercises. They hand off a task, measure completion speed, and stop. Torres’s practice shows why that pattern collapses once the agent stops being the bottleneck.

The first time the agent finished the roster update early

A children’s ministry platform team had built a volunteer scheduling agent for mid-size churches. The initial request was straightforward: pull availability from the existing database, assign names to slots, and flag conflicts. The agent returned a complete roster in four minutes instead of the two hours a volunteer coordinator usually spent.

The first reaction inside the team was relief. Metrics looked strong. Completion rate jumped. Yet the coordinator who received the output still spent the next morning making phone calls because the assignments ignored which volunteers had led the same age group before. The agent had solved the stated problem. It had not touched the actual retention problem the church cared about.

The gap was not in the agent’s code. It was in the outcome the team had named. They had asked for a filled schedule. The church needed a schedule that kept volunteers returning quarter after quarter. Torres’s continuous discovery loop forces exactly this distinction before the next cycle begins.

What happened when the next request stayed small

The team shipped the agent and moved on. Two weeks later the same coordinator returned with a follow-up ask: add a text reminder two days before each shift. The request stayed inside the original frame. It treated the roster as a one-time output rather than a recurring relationship.

Because the agent could now generate reminders without new human input, the team could have paused to test whether the deeper need had changed. Instead they implemented the reminder and measured open rates. Open rates looked fine. Volunteer return rates did not move.

The pattern repeated across other workflows. Each new request arrived already scoped to what the agent could execute quickly. Continuous discovery, applied after the agent existed, would have required the team to re-interview the coordinator about what success looked like once execution cost dropped to near zero. No one ran that interview.

The weekly practice that forced the ambition upward

The team instituted a standing thirty-minute review every Friday. One person owned the current agent workflow. Their only job in the meeting was to state the original outcome in one sentence, then say what outcome would matter if the agent handled every mechanical step without oversight. The rule was simple: the new outcome had to be harder to measure and further from the current data.

The first time they applied it to the roster agent, the coordinator said the real goal was not filled slots but “volunteers who choose this church over three other serving options each quarter.” That single sentence changed the next three agent iterations. The team stopped adding reminder features and started surfacing historical serving patterns so coordinators could see who had quietly stopped returning.

The practice worked because it made the elevation of ambition a repeatable step rather than an occasional insight. Torres’s method requires ongoing contact with the user; here the user was the ministry leader whose definition of success had to keep expanding as the agent’s capacity grew.

Your Turn: Apply This Today

• Pick the person who owns the next agent workflow and book a 25-minute call for this week; open by reading their original request out loud and ask what outcome would be worth measuring if the agent removed all current manual steps.
• Write the new outcome as a single sentence that cannot be answered by the data the agent already produces, then share it back to them for confirmation before the call ends.
• Identify the one metric that would prove the harder outcome is moving and add it to the agent’s weekly report even if the current agent cannot influence it yet.
• Run the same 25-minute conversation with a second workflow owner inside the same product area before the end of next week.
• Document the two new outcomes in the same place the original requests live so the next person who opens the ticket sees the raised bar immediately.
• Schedule the same review for four weeks from now and treat it as recurring rather than a one-time exercise.

This pattern shows up again in The PM Who Inherited the Agent Schedule and The PM Role That Still Needs Human Judgment After Agents Ship.

I consult with product leaders on agent workflow design, continuous discovery after execution is automated, and raising outcome ambition inside mission-driven teams. Let’s talk.

The cursor blinked on the “add another skill” field while the missions director’s coffee cooled beside her laptop. Slack messages stacked up from the three short-term volunteers waiting on placement answers, each one tagged with a different timezone. The career tool had already cycled through its quarterly goals screen twice, refusing to move forward until she picked from the dropdown.

She typed one entry, then deleted it. The volunteers needed decisions before their flights, yet the screen kept framing the problem as her personal resume growth.

This is the same pattern that breaks jobs-to-be-done work when the team’s real job is keeping a shared state intact across handoffs. Individual outcome questions pull attention away from the coordination constraints that actually determine whether placements survive the next season.

John Wesley’s three simple rules give a different lens. Do no harm. Do good. Stay in love with God. Applied to product interviews, the first rule means the script must not damage the fragile continuity a ministry team already carries. The second means it must actively strengthen that continuity. The third keeps the conversation anchored in the actual relationships rather than abstracted career ladders.

Replace title-chasing prompts with state-preservation questions

Most placement tools open by asking what title or skill set the user wants next quarter. That question assumes the user’s primary task is personal advancement. In the missions director’s case, her primary task was making sure none of the three volunteers arrived without a clear partner on the field.

When the script instead starts with “What state must this team hold steady for the next six months?” the answers surface constraints the tool had ignored. The director listed “one local contact who already knows the language for each arriving volunteer” before she listed any skill of her own. The tool now had to treat that contact as a non-negotiable resource rather than an afterthought.

The shift also changes what counts as progress. Completion is no longer “user filled out five fields.” Completion is “the handoff conditions for the next volunteer are recorded and visible to the people who will act on them.” Metrics move from individual profile completeness to team state continuity.

Interview the handoff, not the person

Traditional interviews treat the missions director as the unit of analysis. They ask about her experience, her goals, her bandwidth. The real unit is the handoff moment when a volunteer steps off a plane and meets the local contact.

Observing that moment in three different regions showed the same pattern. The volunteer who had a named contact waiting with a printed schedule stayed. The volunteer who only had an email address and a general “someone will meet you” message did not. The difference was not the volunteer’s skills but whether the handoff state had been preserved.

A revised interview therefore asks the director to walk through the last successful handoff out loud, step by step, naming every person who touched the volunteer between airport and first assignment. The questions stay on those touch points rather than on the director’s title or aspirations. The resulting data describes the actual coordination surface the tool must support.

Let the oldest volunteer story set the outcome frame

The missions director had one story she told without being asked. A volunteer from eight years earlier still wrote every Christmas because a local pastor had met him at the airport with the exact right bus schedule and a spare key to a spare room. That single preserved state had created eight years of relationship.

When the interview script opens with that story instead of a skills matrix, the outcome frame changes. The director is no longer optimizing for her own next role. She is optimizing for the conditions that let an eight-year relationship begin. The tool must now record and surface the elements that made that handoff durable: the named contact, the printed schedule, the spare key protocol.

This ordering also prevents the tool from treating every placement as a fresh start. It forces the system to inherit the durable states already operating in the field.

Your Turn: Apply This Today

• Open the current placement interview script and move the first three questions to the bottom; replace them with “Name the person who will meet the volunteer at the airport and what they already know about the arrival date.”
• Pick one recent placement that succeeded and one that did not; list every handoff step that differed between them and add those steps as required fields in the next version of the form.
• Schedule a 20-minute call with the oldest volunteer from the last two years and ask only what single action by a local contact made the difference; turn that action into a state-preservation prompt.
• Remove every title or skill dropdown from the first screen and replace it with a single open field: “What must stay the same for the next volunteer after this one?”
• Run the revised script with one missions director this week and count how many coordination constraints appear before any personal career goal is mentioned.
• Update the completion metric in the tool from “profile 80% complete” to “next handoff state recorded and visible to at least two other people.”

The post on prompt replacement shows what happens when tools optimize for the wrong actor. The post on the culture export that actually stuck shows how durable states travel when the handoff is designed first.

I consult with product leaders building placement and assignment tools for mission teams on coordination constraints, state-preservation questions, and handoff interviews. Let’s talk.

Someone keeps asking me the same question about internal ministry data: how do we make our own records worth more than the generic training sets everyone else has access to? The answer is to stop treating coordination history as raw logs and start treating it as a first-class product asset that agents can read and act on.

That shift turns scattered volunteer schedules, room assignments, and follow-up notes into something agents cannot replicate from public sources. Most teams still feed agents only the surface data—names, dates, attendance counts—while the real signal sits buried in the sequence of changes and handoffs that produced those numbers.

This is the foundational misread that causes product teams to overvalue volume and undervalue sequence. They collect more tables without noticing that the history of how those tables changed is what gives an agent context for its next move.

Charlie Munger built his latticework of mental models by forcing every new piece of information to sit next to the models he already carried. The same discipline applies here. Internal coordination data only compounds when it connects to models of state, cost, and handoff rather than sitting in isolation.

Stop treating volunteer rosters as ephemeral

Volunteer rosters change every week, so teams delete the old version and load the new one. That deletion erases the record of who accepted, who declined, who got swapped at the last minute, and which leader made the call. An agent that only sees the current list has no way to know whether a particular person is reliable under pressure or whether a certain time slot keeps producing conflicts.

The fix is to keep every version of the roster as a distinct state object with timestamps and author fields. When an agent later needs to suggest a substitute, it can check the last three times that slot was filled and see which people actually showed. The data cost is low; the coordination value compounds.

I watched one children’s ministry platform lose six months of useful history because they overwrote the roster table each Monday. The agent they built could generate names but could not avoid the same three volunteers who always said yes and then burned out.

Route every agent decision through a visible state log

When an agent books a room or sends a reminder, the action needs to land in a log that both humans and future agents can read. The log should record the decision, the data it used, and the person or rule that approved it. Without that record, the next agent starts from a blank slate and repeats the same coordination mistakes.

A visible state log also lets ministry staff see what the agent changed and why. That visibility turns the system from a black box into something people trust enough to give it more authority over time.

One platform I worked with added a simple decision log to their scheduling agent. Within two weeks the volunteer coordinator was using the log to spot patterns she had never noticed before, such as which age groups consistently needed last-minute swaps. The agent became more useful because its history was now legible.

Price the cost of forked schedules in hours, not tokens

Every time two agents or two humans maintain separate calendars for the same event, someone eventually spends real time reconciling them. That cost is measured in hours of staff attention and volunteer frustration, not in API calls. Internal data becomes a moat only when the system surfaces those forked schedules before they require manual cleanup.

Teams that track the actual hours spent on reconciliation quickly see which datasets are worth maintaining and which ones can be retired. The numbers also give product leaders a concrete way to argue for better logging instead of relying on vague promises about future AI gains.

I have seen ministry tools where the same event existed in three different systems for months. The only reason anyone noticed was a volunteer who showed up at the wrong building. The hours spent fixing that single conflict exceeded the entire development budget for the agent that created it.

Your Turn: Apply This Today

• Pick the single dataset your team already stores that contains the most coordination events—rosters, room bookings, or follow-up assignments—and export the last ninety days of changes with timestamps and authors.
• Write a one-page description of what each change record actually means to the next person or agent who needs to act on it.
• Build a minimal log table that captures decision, source data, and approver for every new agent action this week.
• Measure the hours your team spent reconciling duplicate schedules in the past month and write that number next to the dataset that produced the duplicates.
• Choose one recurring coordination task and require the agent to read the visible state log before it proposes any change.
• Review the results in seven days and keep only the log fields that directly reduced reconciliation time.

The Prompt That Replaced the Engineer and Still Missed the Calendar shows what happens when agents operate without state history. The PM Role That Broke When Agents Took the Wheel traces how coordination costs surface only after the logs are missing.

I consult with product leaders building AI features for churches and ministry organizations on coordination data, agent decision logs, and scheduling cost tracking. Let’s talk.