Month: August 2026

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.

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.

I once assumed that feeding ministry data into AI agents would naturally compound into better coordination over time, the way a shared spreadsheet evolves as more people touch it. I set loose permissions on a planning tool we used for volunteer curriculum distribution because the upside seemed obvious and the downside invisible. Within weeks the system had generated parallel versions of the same teaching calendar, each agent pulling from slightly different source material, and no one could tell which schedule the actual volunteers were following.

The cost showed up in missed handoffs and duplicated prep work. Ministry leaders started asking which version was authoritative, and the answer was none of them. The mistake was treating the AI layer as a simple accelerator rather than a new operating system that needed explicit boundaries before it started forking state.

This is the foundational misread that causes product teams to ship AI features that quietly erode institutional memory. Charlie Munger’s latticework of mental models forces the question: which models must intersect before any agent writes to a shared record? Second-order thinking, inversion, and the circle of competence all point to the same requirement—permission boundaries installed first, not added later.

The Shared Calendar That Split Overnight

One ministry team I worked with gave an agent read-write access to their master calendar so it could propose volunteer shifts. The agent optimized for coverage density and created two separate event streams that looked identical to different subgroups. Volunteers arrived on the wrong dates because the agent had silently branched the data model without triggering any conflict alert.

The latticework here is straightforward. Inversion asks what would guarantee the calendar stays single-source. The answer is a write boundary that requires human confirmation on any change that touches more than one volunteer record. Without that gate, the model compounds in opposite directions instead of converging.

Second-order effects appeared fast. Leaders stopped trusting the calendar altogether and reverted to private spreadsheets. The AI had technically succeeded at its narrow task while destroying the shared state the team actually needed.

When Volunteer History Stops Accumulating

Volunteer history is the one dataset that should get richer with every interaction. In another case an agent was allowed to log completion notes after each curriculum session. Because it lacked a boundary requiring source attribution, it began summarizing from its own prior outputs rather than the original volunteer reports. Within a quarter the history file no longer reflected what any real person had done.

Munger’s emphasis on circle of competence highlights the problem. The agent operated outside its competence once it started rewriting memory instead of appending to it. The fix is a boundary that tags every entry with its originating human or verified system and blocks any agent from editing those tags.

Teams that skip this boundary later discover they cannot answer basic questions about retention or engagement patterns. The data looks complete until someone tries to use it for actual planning.

The Hidden Cost of Letting Agents Write First

Most product roadmaps still treat AI output as draft material that a human will eventually review. In practice the first write often becomes the default version because review cycles are slow and the agent output looks plausible. One team discovered their agent had generated an entire quarter of children’s ministry outlines before anyone noticed the theological framing had drifted from the church’s stated positions.

Applying the latticework requires combining the model of opportunity cost with the model of path dependence. Once the agent writes first, later human edits fight against an already-compounded artifact rather than shaping clean source material. The boundary that prevents this is simple: agents may propose, but only verified humans may commit to the authoritative store.

Without that rule the organization pays compound interest in the form of corrective work and eroded trust. The calendar splits, the history flattens, and the first draft quietly becomes the operating reality.

Your Turn: Apply This Today

• Map every AI agent currently writing to a shared ministry record and list the exact fields it can touch without human approval.
• Define the three permission boundaries in writing: read-only for raw volunteer history, proposal-only for calendar changes, and attribution-required for any summary that will be stored as institutional memory.
• Implement a one-line commit gate in the tool you use most: any agent-generated change that affects more than one volunteer requires a named human to confirm before it saves.
• Audit the last thirty days of agent output in your volunteer or curriculum system and flag every entry that lacks a human source tag.
• Set a recurring monthly review where two leaders compare the current authoritative version against the last human-verified snapshot and note any drift.
• Document the three boundaries in the product requirements doc for the next AI feature so the engineering team cannot ship without them.

The same pattern shows up in the systems described in “The Prompt That Replaced the Engineer and Still Missed the Calendar” and “The OS No One Installed Because It Looked Like Extra Work.” Both pieces trace how missing boundaries turn helpful agents into sources of silent divergence.

I consult with product leaders and ministry technology teams on permission architecture for AI agents, protecting shared ministry state, and building verification layers that survive agent scale. Let’s talk.

The coordinator’s fingers paused above the keyboard as the first roster loaded on screen. Three clean columns appeared, each one assigning drivers, cooks, and setup leads for the weekend rural run. She scrolled to the bottom and already knew the second column would collapse once the actual availability texts arrived.

Her desk held a stack of printed sign-up sheets from the last trip, edges marked with handwritten notes about who could actually drive the truck with the medical supplies. The agent output ignored every one of those notes. She opened the group chat on her phone anyway, already drafting the follow-up questions that the prompt had never surfaced.

This pattern repeats whenever the visible task list becomes the only input. Solomon’s judgment exposed the same gap: the two women presented identical claims to the child, yet the true test lay in the unseen bond that would break under division. The prompt that replaced the engineer follows the same logic. It optimizes for visible coverage and treats every name as interchangeable until the first real conflict appears.

The spec that looked complete until real people moved

The missions coordinator had fed the agent a two-paragraph brief that listed dates, locations, and required roles. The output matched every stated requirement. Within an hour the first text arrived from the only driver licensed for the larger vehicle, reporting a family emergency that removed her from both the outbound and return legs.

No line in the original prompt had captured the single-person dependency on that license. The printed sheets from prior trips had carried that constraint in the margin notes, but those notes never entered the agent. The resulting schedule therefore satisfied the written spec while violating the actual operating condition.

Teams repeat this when they treat the prompt as a complete contract. The visible outputs look balanced until movement begins. Solomon’s test worked because it forced the hidden attachment into the open; the prompt test must do the same for ministry schedules.

Why agents surface the exact coordination problems teams had papered over

Agent outputs expose gaps that spreadsheets and email threads had previously hidden through repeated manual fixes. Once the three roster options appeared, the coordinator spent forty minutes rebuilding one by hand. Each adjustment revealed a dependency that had lived only in someone’s head or in a private message thread.

The papered-over problems were never malicious. They were simply the accumulated workarounds that kept last month’s trips running. When the agent removed the human buffer, those workarounds became visible failures in sequence. The schedule that looked complete on screen could not survive contact with the actual availability graph.

This is the core limitation of treating coordination as an optimization problem without first extracting the relational constraints. Solomon did not ask which woman had the stronger legal claim; he tested which claim would destroy the living connection. Ministry agents require the same test before any roster is treated as executable.

The rule that turns a prompt into something a ministry can actually run

The workable rule is to embed the hidden constraint directly into the prompt template rather than hoping the agent will infer it. In practice this means writing the single point of failure that would break the schedule if removed. For the rural run, that constraint was the licensed driver plus the backup who could cover both legs without double-booking the medical supply vehicle.

Once that constraint sits inside the prompt, the agent must generate options that survive its removal. The coordinator can then run the generated rosters against the actual conflicts from the previous month instead of discovering them after the fact. The test is concrete: if the schedule collapses when the named constraint is deleted, the prompt has not yet reached executable quality.

This rule keeps the definition of good tied to relationships rather than outputs alone. It also prevents the later stage where teams discover that their agent has optimized for a world that never existed outside the original two-paragraph description.

Your Turn: Apply This Today

• Take the volunteer schedule you shipped last month and list the three conflicts that required manual fixes after the fact.
• Write the single hidden constraint behind each conflict as a one-sentence rule that must survive in any new roster.
• Paste those three rules into your current agent prompt template and regenerate the schedule for the next event.
• Run the new output against the exact conflicts from last month and count how many still break.
• Adjust the constraint sentences until zero of last month’s conflicts reappear in the generated options.
• Save the revised prompt as the new baseline and apply it to the workflow you will run this week.

The Verification Layer No One Budgeted For and The Night the Voice Agent Forked Three Ministry Schedules at Once both trace the same pattern of surfaced constraints once agents replace manual coordination.

I consult with product leaders building agent tools for ministry coordination on defining executable success metrics and surfacing hidden relational constraints. Let’s talk.

Church leaders assume that giving AI agents access to past ministry data will create accumulating institutional memory on its own. The opposite holds: without fixed definitions of completion for recurring tasks, every new prompt resets the baseline and the system forgets what it already solved.

This reversal matters because most current deployments treat AI as a speed tool for isolated work rather than a carrier of team standards. The gap shows up in repeated cycles of prompt engineering that never stabilize.

John Wesley organized early Methodist societies around three rules that anyone could apply without constant oversight. Those rules created consistent behavior across thousands of scattered groups by stating what counted as finished before any activity began. The same discipline applies when AI becomes the carrier of ministry process.

The shared state that evaporates without explicit rules

Ministry teams already run the same workflows every week: children’s lesson preparation, volunteer assignment lists, follow-up sequences after events. Each cycle generates artifacts—notes, schedules, revisions—that could form a growing record. When agents receive only the current request plus whatever context fits in the prompt window, those artifacts stay outside the system.

The pattern appears in children’s ministry resource platforms where volunteers reuse lesson outlines. Without an enforced finish line, one volunteer marks a lesson complete after writing the main teaching point while another expects the full activity list, supply sheet, and parent email. The next agent starts over because no single definition of done travels with the task.

Shared state requires the definition to travel ahead of the work, not after it. Wesley’s groups posted their three rules at every meeting so participants knew the standard before they arrived. The equivalent move for AI is to publish the completion criteria for each recurring ministry task in a form agents and humans both read first.

Without that step, volume increases but retention does not. Each agent session becomes an independent event rather than an addition to an existing body of decisions.

How three constraints turn scattered prompts into retained knowledge

Wesley’s rules worked because they were few, memorable, and ordered every action. Translated to AI-assisted ministry work, three constraints achieve the same effect: state the harm to avoid, name the good to produce, and require the handoff that keeps the record intact.

The first constraint prevents agents from deleting or altering existing ministry records without explicit approval. The second requires every output to include the next required action and the person responsible. The third demands that the completed artifact be written back to the shared store before the task is marked finished.

These constraints convert individual prompts into additions to a single source of truth. When a children’s ministry coordinator asks an agent to update a lesson plan, the agent must first retrieve the last approved version, apply only changes that match the documented standard, list the remaining steps with owners, and store the new version before ending. The next request begins from the updated record rather than from scratch.

The constraints also surface disagreements early. When two agents or two humans produce conflicting outputs, the stored record shows which version met the three constraints and which did not. Resolution happens against an objective checkpoint instead of personal preference.

Teams that adopt the constraints report fewer re-prompts on the same task. The reduction occurs because the system now carries forward what counted as complete on prior runs.

The test that shows whether your team is actually compounding or just accelerating noise

Run the same recurring task three times in one week with different agents or different team members. After the third run, retrieve every stored artifact produced by that task. If the fourth run still requires the team to restate context that should already exist in the record, the system is accelerating noise rather than compounding knowledge.

The test fails when completion criteria remain implicit. One run may treat a schedule as finished once names are assigned; the next run treats it as finished only after confirmation emails are drafted and logged. The agents have no way to reconcile the two versions because no rule set governs what finished means.

The test passes when each run begins by loading the last stored artifact, applies the three constraints, and writes an updated artifact that the next run will load. Over successive weeks the record grows in precision rather than in volume of discarded drafts.

Product teams that pass the test treat the shared store as the primary deliverable and the agent session as a temporary lens. Teams that fail the test treat each session as the deliverable and the store as optional backup. The difference determines whether AI reduces coordination cost or simply multiplies it.

Your Turn: Apply This Today

• Pick one recurring workflow that runs at least weekly—lesson prep for children’s ministry or volunteer scheduling—and write its single-sentence definition of done on a shared page before any agent touches it.
• State the three constraints in that same document so every agent prompt and every human handoff must reference them before marking the task complete.
• Configure the first agent run this week to load the last stored artifact, apply only changes that meet the constraints, and write the new version back before ending the session.
• After the second run, check whether the stored record contains the exact next action and owner; if it does not, revise the done definition until the record always carries that information.
• Run the workflow a third time with a different agent or team member and confirm the new output begins from the updated record rather than from a fresh prompt.
• Document the reduction in restated context across the three runs and share the before-and-after record with the rest of the team by Friday.

The same pattern shows up in posts on how verification layers and contract replacements actually changed team behavior once the definition of done traveled with the work.

I consult with product leaders and ministry technology teams on defining completion states for recurring workflows, building shared memory systems with AI agents, and applying lightweight constraints that compound institutional knowledge over time. Let’s talk.

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.

A 2025 internal audit across 120 mission-driven AI teams showed that 71 percent now publish explicit value statements on their public sites. The same audit revealed that only nine of those teams had logged a single instance where a value statement blocked a planned feature release in the preceding twelve months.

The obvious reading is that values language has finally taken hold in faith-tech and nonprofit AI work. The data points the other direction. Most teams adopted the language after seeing it succeed elsewhere, then treated the statements as external-facing copy rather than hard limits on what ships. The result is a growing stack of polished principle pages that never touch the backlog.

John Wesley’s three simple rules worked because they functioned as live constraints on daily decisions, not as aspirational posters. “Do no harm,” “do good,” and “stay in love with God” were not discussion prompts; they were tests applied to specific choices about buildings, money, and travel. When the test failed, the activity stopped. That same test logic is what most current value statements lack.

Values as product constraints, not slogans

Most church-tech value statements read like they were written by a committee that never had to say no to revenue. They list words such as “stewardship,” “formation,” and “trust” without defining the observable behavior that would violate them. The absence of a violation test turns the statement into marketing.

When I worked on curriculum tools for volunteer teachers, the team adopted a rule that any new feature had to be completable in seven minutes or fewer on a printed page. The rule was not aspirational. It was checked against every prototype. Features that required more time or a screen were cut before they reached users. The constraint changed the product more than any vision slide ever did.

The same pattern appears in AI work. A value that cannot name the exact decision it would kill is not yet a constraint. It remains a slogan until the first time it removes scope or delays a launch.

How Anthropic’s approach differs from typical church tech culture copy

Anthropic’s constitution for Claude was written as a set of principles that raters and engineers must apply to concrete outputs. The principles are scored, not admired. When a generated response fails the test, the model is retrained or the prompt is rewritten. The constraint sits inside the release process, not beside it.

Most church-tech teams I see do the reverse. They publish a values page, then ask the product team to “keep the values in mind” while shipping. The values never enter the ticket template or the model evaluation rubric. The language travels; the test does not.

The difference is not size or funding. It is whether anyone on the team is paid to reject work that fails the stated rule. Without that role, the values remain external.

Where the constraint actually changes shipping decisions

One team building an agent for sermon preparation added a rule that the agent must surface the original source material for every generated illustration and must never produce an illustration that could not be verified in the pastor’s own library. The rule was applied at the prompt layer and again in the review queue. Two planned features were cut because they would have required the agent to generate unverifiable stories. The decision cost a quarter of planned scope, but it kept the product inside the constraint.

Another team working on volunteer scheduling software adopted the rule that no schedule change could be pushed without an explicit human confirmation step from the volunteer coordinator. The rule blocked an otherwise attractive automation that would have auto-swapped shifts based on predicted availability. The automation was never shipped. Retention among coordinators rose because the tool stopped making decisions they could not see or override.

In both cases the constraint was written before the feature was built, not reviewed after. That timing is what separates a working rule from a retrospective justification.

Your Turn: Apply This Today

• Pick one existing value statement your team has published and write the single sentence that would cause a feature to be rejected this quarter.
• Add that sentence to the definition-of-done checklist in your current AI project tracker before the next sprint planning meeting.
• Schedule a 30-minute review with the engineer or PM who owns the next model release and ask them to name the specific output that would fail the sentence.
• Remove or rewrite any value language on your public site that cannot produce a comparable rejection test within one hour of discussion.
• Log the first instance this month where the test removed scope, changed a prompt, or delayed a launch, then note the ticket number and the date.
• Repeat the exercise with one additional value statement next week and compare how many decisions each constraint actually touched.

The Ministry App That Chased Every Model Release and Lost Volunteer Trust shows what happens when copied language never becomes a live test. The Question Every PM Gets After the First Agent Ships tracks the moment teams realize the values they published never reached the release checklist.

I consult with product leaders at mission-driven AI teams on turning published values into enforceable shipping constraints and building review processes that survive model updates. Let’s talk.

A product leader asked me last month whether AI code generation meant their small team could finally skip the second human review on new features. The answer is no. Without that verification step, AI-assisted builds create ownership debt that surfaces exactly when schedules, volunteers, or users depend on the output.

Charlie Munger’s latticework of mental models makes the reason plain. Munger treated every new tool as one more model that must be cross-checked against several others rather than trusted on its own. AI generation supplies one model: statistical likelihood of correct syntax and logic. It supplies none of the models that matter in deployed systems—edge-case user behavior, downstream schedule impact, or the cost of a single wrong assumption reaching a real person. Teams that treat the generated code as the finished article are using only one model and calling the job done.

Verification as the new core engineering skill

The skill that now separates reliable teams from fragile ones is not prompt writing. It is the ability to hold generated output at arm’s length and run it through a second, slower mental model before it touches anything that affects live data.

In practice this looks like a short, repeatable checklist applied to every AI-produced function or workflow. The checklist asks three questions the model cannot answer: What assumption did the generation make about user intent? What happens if that assumption is off by one hour or one volunteer? Who owns the correction if the assumption fails on a Thursday night before a weekend event?

Teams that embed this checklist into the pull-request template see the same pattern. The first few times feel slow. After the third or fourth instance the verification step becomes faster than the original generation because the reviewer already knows the failure modes that matter in their context. The latticework grows stronger with each pass, exactly as Munger described.

Without the checklist the team ships faster for a short window, then spends the next quarter answering support tickets that trace back to one unexamined assumption in a generated script. The net velocity gain disappears once real users are involved.

Why ministry contexts expose the gap faster than startups

Startups can sometimes absorb a broken feature behind a feature flag or a small beta cohort. Ministry tools rarely have that buffer. A single incorrect schedule generated for children’s ministry volunteers reaches dozens of families who have already rearranged their weekend. The cost is paid in trust and in actual attendance the following Sunday.

The same pattern appears in resource platforms that serve volunteer teachers. When AI suggests a lesson outline that misreads the age range or the available materials, the volunteer standing in the classroom at 9:15 a.m. discovers the problem first. There is no second deployment cycle before the damage is done.

Ministry environments also concentrate the downstream effects. One schedule error does not affect a single user; it affects every family that volunteer was meant to serve. The latticework required here must include models of calendar friction, volunteer availability, and parental expectation. Statistical likelihood alone is not enough.

The cost of skipping the second human check

The most expensive failures I have watched did not come from bad prompts. They came from teams that accepted the first clean-looking output and moved it into production because the generation looked complete. One generated scheduling rule assumed volunteers could be reassigned with twenty-four hours’ notice. The assumption was statistically common in the training data. It was operationally false for the actual volunteer pool.

Recovering from that single rule required three weeks of manual overrides, personal phone calls, and rebuilt trust with the volunteer coordinators who had relied on the tool. The generation step had taken minutes. The verification debt took far longer to clear.

Munger’s point was never that new tools are suspect. It was that every new tool adds a model that must be tested against the others already in use. When the second human check is removed, the latticework stays incomplete and the first real-world collision reveals the missing pieces at the worst possible moment.

Your Turn: Apply This Today

• Choose the single AI-assisted workflow your team ships most often this month and write a three-question verification checklist that must be answered in the pull request before merge.
• Run the last three pieces of generated code through that checklist and log the one assumption each piece made that was not visible in the output itself.
• Assign the next generated feature to two people: one to accept the generation, one to run the verification questions and record the time required.
• Compare the verification time against the time spent fixing the last production incident that traced to an unchecked generation; use the comparison to set a minimum review duration for the next sprint.
• Document one concrete failure mode the checklist caught this week and add it to the shared list the team reviews before every new AI-assisted build.
• Schedule a thirty-minute retro in two weeks to drop any checklist item that never surfaces a problem and replace it with the next observed failure pattern.

The verification layer is the difference between shipping quickly and owning the result when real schedules and real volunteers are involved. Two earlier posts that explore the same tension are “The Night the Voice Agent Forked Three Ministry Schedules at Once” and “The Question Every PM Gets After the First Agent Ships.”

I consult with product leaders and ministry technology teams on verification discipline, AI-assisted workflow design, and downstream ownership costs. Let’s talk.

The printer spat out the third schedule while the denominational operations lead smoothed the pages flat on her kitchen table. Her eight-year-old leaned against the counter and asked why the church still used the old system that never matched what actually happened on Sunday. She pointed at one column and said the dates were already wrong.

That single mismatch sat at the center of her week. The new agent tools produced clean outputs, yet none of them carried forward the one correction that mattered most to her volunteers.

This scene shows the exact point where broad platforms lose. Teams keep adding features that look like the old system but faster. They miss the narrow, repeated regret that actually drives the switch.

Teresa Torres calls this continuous discovery. She argues that real product direction comes from repeated contact with the people who use the work, not from backlog grooming or roadmap votes. The operations lead already knew the gap. The tools simply never asked her about it.

The specific regret that made the switch inevitable

The old scheduling system failed every time a volunteer called in sick on Saturday night. The printed calendar showed the original name, the app showed the original name, and the email reminder still went to the original person. Someone had to stand at the door Sunday morning and fix it by hand.

That fix happened in every location the denominational lead oversaw. It took five to seven minutes each time, and it always fell to the same two or three people. The agent tools she tested could generate new schedules in seconds, yet none of them surfaced the previous correction as the starting point. They treated every week as clean.

The regret was not speed. It was continuity. Once she saw an agent that remembered the last manual override and asked whether it still applied, the old platform became unnecessary. Feature parity no longer mattered.

Why custom agents win when the pain is narrow and repeated

Broad platforms optimize for the average user across thousands of churches. That average hides the exact pattern this operations lead faced every weekend. A custom agent built for one workflow can store the correction history, the volunteer preferences, and the last-minute substitution rule in one place.

The agent does not need to do everything the old system did. It only needs to do the one task that previously required a human to intervene after the system finished. When the pain repeats at the same point in the week, the agent that owns that single loop pulls the rest of the workflow along with it.

Torres would recognize the pattern. The team stopped asking what the platform should include and started watching the moment the correction happened. That observation produced a narrow agent that replaced the contract.

How discovery changes once you own the workflow end-to-end

When the team controls the full sequence from schedule generation to Sunday morning printout, discovery becomes continuous by default. They see the eight-year-old question in real time. They hear the volunteer call on Saturday night. They measure whether the correction from last week carried forward.

Ownership also changes the metric. Instead of counting new features shipped, the team tracks how often the manual override still occurs. Each reduction in overrides becomes evidence that the agent now holds the institutional memory the old system never captured.

The operations lead no longer prints three versions. She prints one, checks the single highlighted change, and moves on. That shift only appeared after the team stopped trying to match the old platform and started tracking the regret that never left her kitchen table.

Your Turn: Apply This Today

• Pick one operational task your current tool forces a human to correct every single week and write down the exact correction that repeats.
• Shadow the person who makes that correction for two full cycles and note the moment they reach for the workaround.
• Build a one-page prompt that feeds the last correction back into the next run of the agent and test it with the same person.
• Measure only whether that specific override drops by half within four weeks; ignore every other feature.
• Remove the old platform’s export step for that single task and force the agent output to become the source of truth.
• Schedule a fifteen-minute weekly check-in with the same user for the next six weeks and log whether the regret has moved or simply changed shape.

The pattern shows up again in The Five-Year Roadmap the Agent Schedule Made Irrelevant and The Night the Voice Agent Forked Three Ministry Schedules at Once.

I consult with product leaders and ministry operations teams on continuous discovery loops, narrow agent design, and replacing broad platforms with workflow-specific tools. Let’s talk.

I was two paragraphs into updating my own five-year plan when the agent pinged me about a meeting pattern I’d kept for three years. It had already moved the block, updated three other calendars, and left a note explaining why the old rhythm no longer made sense for anyone involved.

I stared at the document on my screen—titles, timelines, the quiet assumption that progress still looked like the next role on the ladder—and felt the gap between what I’d written and what was actually happening in the work.

The plan kept treating time like something we still controlled. The agent had already started spending it differently.

The plan that assumed linear titles

Most career documents still list steps like associate product manager to product manager to senior product manager to director. Each step carries an implied increase in scope and a required demonstration of impact through visible deliverables. The assumption is that human managers will notice the progression and approve the next box on the chart.

In practice the agent handling schedule reconciliation already owns the data that determines whether a deliverable actually moved ministry outcomes. It logs every time a volunteer slot goes unfilled because the curriculum file arrived in the wrong format. That log sits outside any performance review cycle. The linear title plan has no column for the constraint the agent now owns.

Teams that treat the title sequence as the goal keep building artifacts that look good in the next planning meeting. They miss the moment the agent starts routing around a bottleneck that the next title was supposed to solve. The result is a roadmap that describes a career no one is actually living inside the current tooling.

How thread-forking exposed the actual constraint

The agent began forking its own follow-up threads after the third time the same volunteer cohort failed to receive updated materials. One thread handled the file conversion. Another thread checked the print queue status across three different church campuses. A third thread opened a lightweight ticket only when the conversion failed twice in a row. None of these threads required a human to request them.

What surfaced was not a skill gap in the product team but a handoff gap between the curriculum system and the volunteer management system. The five-year roadmap had listed “improve cross-team collaboration” as a senior-level competency. The agent made that competency visible as an automated rule set that already ran every Tuesday night. The constraint was never the absence of a title; it was the absence of a persistent loop that noticed repeated failure.

Cagan’s framework emphasizes that empowered teams define success by the problems they own rather than the features they ship. Thread-forking made the ownership question concrete. The agent did not wait for a promotion to start treating the repeated failure as its problem. The human roadmap still required a title change before anyone felt authorized to address it.

Writing the next role around what the agent already owns

The next useful move is not to invent a new title but to describe the boundary the agent now enforces. In one observed case a ministry product manager rewrote their own role description around the three constraints the agent had already made visible: file-format drift, campus print-queue latency, and volunteer confirmation lag. The description listed the agent as the first responder and the human as the owner of the rule changes when the agent logged a pattern.

This approach aligns with Cagan’s insistence that empowered teams receive problems, not solutions. The agent already receives the schedule data every day. The human role becomes the design of the feedback loop that turns agent logs into rule updates. The title on the org chart matters less than the documented agreement that the agent owns detection and the human owns intervention design.

Teams that make this shift stop measuring progress by the number of reports they review. They measure it by the number of agent-detected constraints that receive a permanent rule change within a week. The career path becomes a record of constraints owned rather than titles collected.

Your Turn: Apply This Today

• Pick the single agent thread that runs most often in your current workflow and export its last ten logs into a shared document before Friday.
• Write one sentence that names the constraint the agent surfaced most clearly in those logs, then send it to the two people whose work the constraint touches.
• Replace the next line item on your personal career doc with the name of the agent rule you will change if that constraint appears again in the next thirty days.
• Schedule a thirty-minute review with yourself next month where the only input is the agent’s log file rather than any title or promotion checklist.
• Identify one task you currently perform that the agent could fork tomorrow and document the exact condition under which you would let it own that task without review.
• Send the resulting three-sentence role description to your manager with the subject line “Constraint boundary update” and no additional context.

The pattern of rigid plans meeting live agent constraints shows up again in The Agent That Kept Running the Schedule While No One Was Watching and The Refactor That Finished in Two Days and Then Sat for a Week.

I consult with ministry product leaders on agent boundary design, constraint logging, and rewriting role definitions around owned problems rather than title sequences. Let’s talk.

Last night the ping came through at 11:17. The agent had booked a volunteer who’d already said no twice, then fired off the curriculum link to the entire wrong list. Three replies landed before I even opened my laptop.

I kept staring at the thread and wondering what I actually owned now. Not the clicks or the approvals—I’d already handed those off. Just the quiet gap between what the agent did and what should have happened.

That gap is where every PM ends up living once the first agent ships.

Where the regret actually showed up

In one children’s ministry tool rollout, the agent was given the narrow job of matching volunteer availability to upcoming events. It worked for the first two weeks. Then it started routing new volunteers to the same three sites because those sites had the cleanest data in the system. The other sites, with messier records, got zero new people. No one had written down what “fair distribution” actually meant when the agent had to choose.

The regret did not appear in the logs. It appeared three weeks later when two site leaders called the same week to say their teams were collapsing from lack of help. The PM had to stand in front of the directors and explain why the distribution looked the way it did. That conversation was the place the regret landed.

Schön would have called the moment the PM realized the data skew the “surprise.” The reflective move was not to add another approval step. It was to name, out loud and in the product spec, the exact outcome the team refused to accept even if the agent executed perfectly.

Shifting from gatekeeper to the person who names the failure mode

Most PMs still see their job as keeping bad things from shipping. After agents arrive, that posture becomes impossible to sustain. The agent will ship something unexpected because that is what agents do when they operate on live data. The PM’s new job is to name the failure mode that matters before the agent ever runs.

One team I watched tried to solve this by requiring every agent action to route through a human reviewer. Usage dropped to almost nothing within a month. Volunteers did not want to click through another screen. The PM eventually removed the gate and instead wrote a single sentence into the requirements: if the agent assigns a volunteer to a role they have never done before, the system must surface that fact to the site leader within twenty-four hours. That sentence became the owned regret point.

The shift is from “I approve this” to “If this goes wrong, here is the exact signal I will be measured against.” It is narrower and harder to hide behind.

Hiring senior ICs who already carry that regret

The strongest senior individual contributors I have seen in these environments are the ones who have already lived through an agent or automation decision that produced real damage. They do not need training on reflective practice. They already feel the weight when they look at a proposed handoff.

In interviews I now ask a single concrete question: tell me about a time an automated system you shipped created a problem you had not named in advance. The candidates who pause and then describe the exact person who had to clean it up are the ones who already carry the regret. The ones who pivot to process improvements or “lessons learned” slides usually do not.

Those ICs become the people who can sit with a product spec and point to the sentence that is still missing. They do not need permission to name the failure mode because they have already paid the cost of leaving it unnamed.

Your Turn: Apply This Today

• Pick the agent that has been running longest without daily human review and list the three outcomes the team has explicitly said it will not accept even if the agent executes its instructions perfectly.
• Write one sentence that names the single human who will be asked to explain the outcome if any of those three things happens, then add that sentence to the requirements doc this week.
• Schedule a thirty-minute meeting with the senior IC who has shipped the most agent work and ask them to mark the current handoff map with the exact place where regret would land if the agent ran for a full month unsupervised.
• Review the last three support tickets or ministry leader complaints that mentioned the agent and trace each one back to the missing failure-mode sentence rather than the missing approval step.
• Change the next hiring debrief to include the regret question above and score candidates on whether they describe the human cost or only the process fix.
• Identify the current handoff point in your largest agent flow that still carries no single name and attach one owner by the end of this sprint, even if the title on the org chart stays the same.

Two earlier posts on this blog walked through similar handoff problems: “The Agent That Kept Running the Schedule While No One Was Watching” and “The Three-Person Pod That Still Needed a Fourth Set of Eyes.”

I consult with product leaders and ministry technology teams on agent oversight, regret mapping, and handoff protocols. Let’s talk.

The phone sat face-up on the kitchen table, its screen lit with three browser tabs. She spoke the names while her toddler hammered a spoon against the tray. The agent answered back in her own voice—steady, unhurried—slotting one volunteer into preschool, another into elementary, a third into the middle-school group. Each confirmation landed with a small chime that split the single list into separate threads before she ever touched the mouse.

I stood in the parsonage doorway, coffee cooling in my hand, watching her keep talking like this was ordinary. The agent opened a fourth thread for the last-minute sub and waited. She didn’t pause. She just kept reading names while the machine held the branches straight.

Something about that split-second branching felt heavier than it should have.

The coordinator who could no longer see the whole board

She finished the call and turned to the laptop expecting one clean summary. Instead she found three separate conversation logs, each with its own time stamps and partial volunteer lists. The preschool thread showed a confirmed helper. The elementary thread listed two names but no room assignment. The middle school thread had accepted a substitute whose age group did not match.

She clicked between tabs for four minutes before realizing the substitute had been placed in the wrong group. The agent had recorded the correction in the new thread but never updated the original list. When she finally printed the schedule for the Sunday team, one name was missing entirely.

The problem was not speed. The agent had answered and forked faster than any human assistant. The problem was that no single view still showed every live decision at once. She had to reconstruct the board herself each time a new branch opened.

What the agent kept forking without telling anyone

Later that week the same agent handled a Tuesday night reschedule. It created a new thread for the replacement volunteer, then another when the original person replied from a different phone number. Neither thread carried the note that the children’s room would be closed for painting.

The printed schedule that reached the volunteer coordinator on Friday still listed the original room. The agent had never written the closure into the shared record because the closure had arrived in a separate message thread that no longer pointed back to the master list. Two volunteers showed up to a locked door.

This pattern repeats whenever the agent treats each incoming message as a fresh branch rather than an update to a single visible state. The forks multiply without any external reader able to scan the entire set in under two minutes. The result is not chaos in the agent’s memory but chaos in the human handoff that follows.

The single file that had to stay human-readable

One ministry I worked with solved a similar fork by forcing every agent output into a single shared document that any staff member could open in under ninety seconds. The document contained only the current volunteer assignments, room changes, and open questions. Agent threads could append lines, but they could never create new documents.

The rule came directly from Seneca’s practice: the correspondence itself had to remain the one place an outsider could reconstruct the full picture without chasing separate letters. In the ministry case, the shared file became that correspondence. Volunteers checked it on their phones before arriving. Coordinators scanned it in the same two-minute window even when three agent threads were active.

The file stayed plain text with clear section headers. No one needed special software. The agent could write to it, but the human-readable format forced every fork to surface its state in the same location. When the painting closure arrived, it appeared as a single line under the affected room rather than disappearing into a private thread.

Your Turn: Apply This Today

• Export the last seven days of agent logs for your volunteer schedule and paste them into one new document with only four section headers: Assignments, Changes, Open Questions, and Conflicts.
• Set a two-minute timer and open that document on a phone; if you cannot name every active thread and its current state before the timer ends, add one line that surfaces the missing branch.
• Choose the next voice agent interaction that will create a fork and force its output into the shared document before the agent closes the call.
• Ask one volunteer who does not run the system to read the document aloud and mark any line that required them to ask a clarifying question.
• Replace the agent’s default “new thread” behavior with an instruction that appends every new decision to the single document instead.
• Schedule the next volunteer check-in for this week and bring only the printed single document; note how many forks the agent created since the last check-in and whether every one appears in the file.

The Agent That Kept Running the Schedule While No One Was Watching shows what happens when forks stay hidden. The Voice File That Actually Survived Three Ministry Reorgs shows the cost of losing the single readable surface.

I consult with ministry product leaders on voice agent threading, shared state design, and readable handoff surfaces for volunteer systems. Let’s talk.

A popular “model-first upgrade” playbook circulating among AI product teams says to slot every new frontier release into existing surfaces as quickly as possible: swap in the newest model the week it ships, retrain every prompt template, and treat speed of adoption as the primary measure of competitiveness. For teams building ministry tools, that playbook breaks down because it treats every interface as a general-purpose chat window that can absorb unlimited model changes without touching the actual permission gates where volunteers and pastors decide what gets used.

The playbook assumes faster inference and better reasoning will automatically improve outcomes. In practice the opposite often occurs. One children’s ministry curriculum tool added an open chat pane and saw volunteer completion rates drop hard once the model began generating lesson plans that ignored age-group safety filters already approved by the church board. The upgrade itself created new review work that no one had time to perform.

This is the foundational misread that causes product teams to keep rebuilding the same broad chat surface instead of hardening the narrow places where AI meets real accountability.

Charlie Munger’s latticework of mental models supplies the corrective lens. Munger insisted that lasting advantage comes from keeping a small set of high-leverage models that compound across domains rather than chasing every new variable. Applied to AI product work, the latticework directs attention away from the next model release and toward the fixed constraints that already exist in the organization: who can approve content, who must sign off on risk, and which single record must survive staff turnover.

Harden the permission boundary before you widen the chat surface

Most ministry tools still expose a free-form chat box because the model can now handle longer context. That surface ignores the actual decision lattice volunteers operate inside. A volunteer opening the app at 9:15 p.m. on Tuesday needs a pre-approved lesson plan, not an invitation to iterate with an LLM. When the chat surface remains, the volunteer either abandons the task or spends twenty minutes rewriting output that still fails the church’s safety checklist.

One platform team that removed the general chat entirely and replaced it with three scoped prompts tied to already-approved curriculum saw the same volunteer complete the task in under seven minutes without additional review. The fix was not a better model. It was fewer degrees of freedom in the surface the volunteer touched.

Make the risk record travel with the file, not the conversation

Ministry handoffs happen constantly. A children’s director leaves, a new volunteer inherits the account, and the previous AI-generated material sits in a folder with no indication of who approved it or what model produced it. One platform added a persistent risk register, visible on every export and every shared link, and saw the number of unapproved lessons reaching parents fall sharply within a quarter. The register works because it is stored as metadata on the file itself rather than inside the model conversation history that disappears when the account changes hands.

Keep one human owner of the final yes

Every ministry tool that claims to be “AI-assisted” still requires someone to click publish. When that click is buried behind an auto-generated draft that looks finished, the human owner loses visibility into the actual content. Leaders who surfaced the final-yes step as a distinct, non-AI action, complete with a required signature and timestamp, found that pastors spent less time second-guessing output and more time trusting the narrow loop that had already been audited.

Your Turn: Apply This Today

• Pick the single AI surface in your product that currently accepts free-form input and replace it this week with three fixed prompts that only return content from your pre-approved library.
• Export the last thirty AI-generated artifacts from your system, add a one-line risk field to each, and store that field as file metadata rather than inside any conversation thread.
• Identify the exact person who must give the final yes on published material and make that step a visible, non-skippable action with its own timestamp and name field.
• Remove the general chat pane from the volunteer view in one environment and measure completion rate for the same task over the next seven days.
• Write the risk register entry as a short JSON object that appends to every exported file and test whether it survives when the file is emailed to a new volunteer account.
• Run a two-person audit on the last ten pieces of AI content your team published and record how many required the risk register to catch an issue the model itself did not flag.

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 hardening narrow interfaces instead of expanding model surfaces.

I consult with product leaders in faith-tech on scoped AI loops, permission metadata, and single-owner approval gates. Let’s talk.

I spent years maintaining a detailed ten-year career plan for my work at the intersection of faith and technology. The document listed target roles, product categories I would own, and the kinds of organizations I would serve by certain ages. Updating it every six months gave me a sense that I was being intentional about the opportunities God might place in front of me.

The cost showed up slowly. When an unexpected request came to help redesign a simple volunteer curriculum tool for one children’s ministry organization, I turned it down because it sat outside the next three milestones on the plan. Two years later that same small product had reached hundreds of thousands of ministry volunteers while my own roadmap still pointed at a larger platform role that never materialized.

This is the foundational misread that causes product leaders to treat every new request as a distraction instead of raw material. The plan becomes the filter that decides what counts as real work.

John Wesley’s three simple rules offer a different frame. Do no harm. Do good. Stay in love with God. Wesley did not hand his movement a five-year strategy document. He gave people daily and weekly practices that could be applied the moment an opportunity appeared. The rules assume that faithful action happens in response to what is already in front of you, not what you scheduled six quarters out.

The plan that looked faithful but crowded out small experiments

My ten-year document contained a section titled “Scale Impact.” It listed only projects that could reach at least fifty thousand users within eighteen months. That single line quietly eliminated every request that arrived through a volunteer email list or a pastor asking for help with one local children’s ministry workflow.

The curriculum opportunity started exactly that way. A volunteer coordinator needed a print-friendly lesson outline that could be finished in seven minutes. It did not match any line item on the roadmap, so I treated it as noise. The team that eventually built the tool measured success by completion rate on first use rather than registered accounts. That metric turned out to be the real driver of long-term engagement, something no slide in my deck had captured.

The same pattern repeats in larger organizations. A product manager at a Bible resource site once told me she kept a private list of “quick experiments” that never made it to the quarterly review because they lacked a direct line to the five-year vision. One of those experiments later became the feature that lifted monthly active users by double digits. The plan itself had no mechanism for noticing the signal until it already looked big.

How Wesley’s rules expose the hidden cost of rigid roadmaps

Wesley’s first rule, do no harm, asks what existing commitments are being damaged by the plan. A rigid roadmap often crowds out the small experiments that keep a product team connected to actual users. When every week is already allocated to milestones two years away, the team stops hearing the volunteer who needs the lesson printed in two pages instead of six.

The second rule, do good, pushes the question of what concrete good can be done this week with the resources already in hand. In product terms this means running the smallest possible test that could matter to one user segment before the next planning cycle. The curriculum team started with a single PDF template tested by twelve volunteers. No roadmap approval required.

The third rule, stay in love with God, functions as a reminder that the work itself is not the point. When the plan becomes the object of attention, leaders begin defending the document instead of responding to the people the product is meant to serve. The rule forces a weekly check: does the current list of tasks still reflect love for the actual users, or only love for the forecast?

What happens when product leaders stop defending their five-year slide deck

Teams that drop the defense of the long-range deck begin to treat incoming requests as the actual work rather than interruptions. At one ministry tech organization the leadership team stopped requiring every new idea to map to the existing five-year themes. Within six months they had shipped three volunteer-facing features that none of the original roadmaps had anticipated, each built in under ten weeks.

The shift also changes how people are evaluated. Instead of measuring progress against the plan, leaders start measuring how quickly the team can test a new assumption and either keep or discard it. The curriculum team’s print-first design came from one such test. The team measured whether volunteers actually completed the lesson in one sitting. When the data showed they did, the feature stayed. When a later idea failed the same test, it was removed without any need to explain why it no longer matched the original vision.

The pattern is simple. Opportunities compound when they are allowed to arrive on their own schedule. The plan that tries to pre-schedule them ends up filtering most of them out before they can be tested.

Your Turn: Apply This Today

• Delete the current ten-year career document and replace it with a single note titled “This Week’s Three Tests.”
• Each Monday morning list three small experiments you can run with existing resources before Friday.
• Run at least one of those experiments with a real user by Wednesday and record whether the user completed the task without help.
• At the end of the week archive any experiment that showed no value and carry forward only the ones that produced a measurable completion rate.
• Share the three-test list with one peer and ask them to hold you to running them rather than updating the list itself.
• Repeat the cycle for six weeks before allowing yourself to write any new multi-year document.

The same tension between rigid plans and live signal shows up in The Agent That Kept Running the Schedule While No One Was Watching, where a fixed workflow missed the context that mattered most.

I consult with product leaders and ministry technology teams on replacing rigid roadmaps with weekly testing practices and measuring actual user completion instead of forecasted scale. Let’s talk.

The pattern shows up across AI product teams often enough to be a rule of thumb: the bigger the product team gets, the harder it becomes to say who actually owns a given model’s behavior once it starts making decisions in production. Larger teams launch more pilots. They also let more of those pilots quietly change shape or get replaced within six months, because no single person feels required to own the fix or the rollback.

The surface reading suggests bigger teams handle complexity better. The actual pattern runs the opposite direction: added headcount spreads the cost of a bad agent outcome across so many people that no one feels required to own the fix or the rollback.

This is the foundational misread that causes product teams to treat team size as a proxy for readiness. Solomon’s judgment between the two mothers exposes it cleanly. One woman was willing to divide the child to settle the claim; the other refused because the living outcome mattered more than preserving her portion of the arrangement. The test was not how many people stood around the throne. It was who would accept a smaller claim to keep the real thing intact.

Why adding more PMs masks the places where ownership is missing

When a team grows past five or six product managers, the first thing that disappears is a single point of accountability for any one model behavior. Someone owns the prompt layer, another owns the retrieval pipeline, a third owns the evaluation dashboard. Each can point to their slice when the agent produces a wrong recommendation or drifts on a key metric.

The result is a steady increase in meetings that review outputs without changing the underlying decision logic. In one children’s ministry curriculum platform I watched, the team added four product managers after an initial AI summarization feature went live. Within eight weeks the feature was generating summaries that flattened the theological tone volunteers relied on. No single person had the authority to pause the model while the retrieval set was rebuilt, so the feature stayed on for another two months while the group negotiated scope.

Solomon’s test still applies. The teams willing to shrink their own headcount or cut a feature entirely are the ones that keep the outcome alive. Everyone else negotiates around the damage.

The inference cost that forces real tradeoffs no headcount chart can hide

Inference spend does not scale with team size. It scales with the number of decisions the model is allowed to make without human review. A team of twelve can approve ten times the volume of experiments, but each additional experiment still consumes tokens at the same rate once it reaches users.

I have seen mid-size product groups run out of budget on low-stakes queries because no one held the mandate to turn the temperature down or restrict the context window. The headcount chart looked healthy. The actual constraint was a monthly inference bill that no single owner could defend or reduce. The smaller teams I have worked with hit the same cost wall earlier and therefore made the tradeoff sooner, usually by narrowing the agent’s scope rather than adding another reviewer.

The mother who would not let the child be divided understood that half a living outcome is not an outcome worth preserving. Larger teams rarely face that same clarity because the cost is distributed across multiple budgets and multiple roadmaps.

How minimal teams learn faster because every person feels the full weight of a bad agent decision

A three-person product team shipping an agent that recommends volunteer curriculum cannot hide from the result. When the model suggests the wrong passage or the wrong age range, the same three people see the support tickets, the churn data, and the angry emails the next morning. There is no layer of analysts or coordinators between the decision and its consequence.

That direct exposure accelerates two kinds of learning. First, the team stops shipping marginal improvements that add inference cost without measurable outcome lift. Second, they develop sharper instincts for when to keep the model out of the loop entirely. Larger teams can staff an entire workstream around monitoring drift without ever feeling the same pressure to change the model or remove it.

The pattern shows up consistently: teams under five product managers who ship live agents tend to revise their decision boundaries within a week or two of a measurable regression, while larger teams often take much longer and usually add another reviewer instead of tightening the original logic.

Your Turn: Apply This Today

• List every model decision that reached production in the last 30 days and name the single person who can pause it without a meeting.
• Calculate the inference cost per active user for each agent you shipped this quarter and mark which ones exceed the original estimate by more than 30 percent.
• Identify the last three agent regressions that produced user-visible errors and note how many product managers were involved in the fix versus how many were involved in the original launch.
• Remove one recurring review meeting that exists only because multiple people own adjacent parts of the same model behavior.
• Run a one-week test where the smallest possible team (three or fewer) owns the next agent change from prompt to production without additional reviewers.
• Write down the specific outcome metric that would cause you to turn the model off entirely rather than add another person to monitor it.

The same ownership gap shows up in The Agent That Kept Running the Schedule While No One Was Watching, where distributed responsibility let a bad outcome run unchecked.

I consult with product leaders on AI shipping decisions, team ownership structures, and inference tradeoffs that surface only after models reach production. Let’s talk.

The cursor on the screen paused mid-sentence as the founder typed out yet another requirement for the senior product role. Across the open office, the three engineers who had already started building the internal workflow tool sat at their desks, trading pull requests in the quiet that followed the afternoon standup. One of them pushed a commit that solved the exact coordination problem the job post still described as a future deliverable.

That afternoon the founder sent the draft to three recruiters. None of the engineers in the room knew a posting existed.

The pattern repeats across faith-tech teams that treat hiring as a search for an external solution rather than a scan of existing capability. The six weeks spent refining language could have been spent mapping who already carried the right combination of constraints, incentives, and mental models for the work. Posting first assumes the right person arrives from outside; mapping first reveals whether the right person is already inside and simply lacks the invitation to own the problem.

Charlie Munger’s latticework of mental models supplies the lens. Munger argued that real judgment comes from holding multiple models at once, opportunity cost, inversion, circle of competence, and second-order effects, rather than relying on any single framework. Applied to talent, the latticework turns a job description into a filter that often excludes the people whose existing models already match the constraints of mission-driven work.

The map that made the posting unnecessary

In one case the internal tools team had already shipped a lightweight volunteer scheduling system that reduced administrative load by half. The system addressed the exact friction the senior PM role was meant to solve. The engineers had built it on nights and weekends because they saw the gap every Sunday. When leadership finally posted the role, two of those engineers applied internally and were told they lacked “enterprise-scale experience.”

The latticework reveals the mistake. Inversion asks what would have to be true for the current team to already hold the solution. Opportunity cost asks what six weeks of posting and interviewing actually consumed. Circle of competence asks whether the posted requirements matched the narrow domain the engineers already navigated daily. The answers pointed to an existing operator rather than an external hire.

How Munger’s models reveal hidden operators

Munger’s second-order effects model surfaces people who anticipate downstream consequences others miss. In one children’s ministry platform project, one engineer consistently flagged that new features would increase volunteer prep time on Saturday nights. That single observation shaped the entire release cadence more than any product requirement document. The engineer never held a PM title, yet the model lived in his work.

The latticework also surfaces people who apply inversion naturally. Another engineer started every planning conversation by asking what would break if the feature shipped tomorrow. That habit exposed edge cases in global rollout that later became the difference between a tool used in three countries and one used in forty. These operators already carried the mental models the role was meant to import.

Turning the same practice toward regulated industries

The same mapping approach travels to regulated spaces where compliance and mission constraints intersect. One health-tech team mapping internal talent found a data analyst who had already built audit trails that satisfied both HIPAA and the ministry’s reporting needs. The analyst had done the work quietly because the existing vendor tools created reporting gaps every quarter. Posting a compliance PM role would have repeated the six-week cycle while the solution already sat inside the team.

Regulated environments reward people whose models already account for constraint density. Munger’s circle of competence model makes this visible: the analyst’s competence was not in writing job descriptions but in operating inside overlapping rule sets. Mapping surfaces that competence before a posting buries it under generic requirements.

Your Turn: Apply This Today

• List every current project that lacks an owner and note which three people have touched the work in the last month even without a title.
• For each person, write the two mental models they already demonstrate in their existing output rather than the skills they list on a resume.
• Run a ten-minute conversation with those people asking what constraint they would remove first if they owned the problem tomorrow.
• Compare that answer against the last job description you posted and strike every requirement that does not match an observed model.
• Invite the strongest internal match to scope the role for thirty days before any external search begins.
• Document the second-order effects they already track and use that list as the actual success criteria for the work.

The same latticework that exposed the engineers also explains why internal mapping consistently outperforms external posting in mission-driven settings. Related posts cover how inversion changes product roadmaps and why mental models matter more than titles when teams scale.

I consult with faith-tech product leaders on talent mapping, mission-constrained hiring, and applying mental models to team structure. Let’s talk.

The children’s ministry coordinator stood at her kitchen island, phone propped against a mixing bowl, three voice agents already open in separate tabs. One agent suggested reassigning the early service volunteers based on last month’s no-shows. Another pulled from a different calendar and offered nursery coverage that overlapped with the worship rehearsal. Her four-year-old kept reaching for the device while the third agent read back conflicting confirmation times.

She answered each one in turn, trying to keep the threads straight without writing anything down. The kitchen timer went off for the casserole. She silenced it with her elbow and kept typing.

This scene shows what happens when parallel tools arrive before anyone has settled the actual order of importance. Ministry leaders already juggle multiple calendars, last-minute absences, and family interruptions. Adding more agents does not reduce that load. It simply splits the same decisions across more channels that never talk to each other.

Seneca wrote his letters to Lucilius with one clear rule: correspondence should clarify a single line of thought, not multiply open questions. He answered one matter at a time and expected the recipient to do the same. When agents run side by side without that discipline, they recreate the exact problem Seneca tried to avoid—scattered attention that never lands on what matters most.

What the phone scene revealed about how ministry leaders already manage overload

The coordinator already tracked volunteer commitments in her head, on a paper list taped to the fridge, and in a shared spreadsheet someone updated twice a week. None of those systems spoke to each other, yet she had built workarounds over years of Sunday mornings. The agents did not replace those workarounds. They added three new ones that still required her to decide which answer counted.

Most ministry leaders operate the same way. They absorb interruptions, reconcile conflicting data, and protect the one or two outcomes that cannot slip. When a new tool appears without first asking which outcome owns priority, it simply increases the number of places the leader must reconcile the same facts.

The real cost shows up in completion rate. Volunteers who receive three different messages about the same shift stop responding. The leader then spends the next evening manually fixing the confusion the agents created. The metric that matters—whether the volunteer actually shows up—drops even as activity in the agents rises.

The guardrail that turns parallel agents from noise into clarity

Seneca’s practice gives the guardrail: designate one owner and one outcome before any agent starts work. The coordinator needed to decide first which service or role mattered most that weekend. Only after that decision could an agent act without creating new conflicts.

In practice this means the product sets a single visible owner for the workflow. That owner states the priority in plain language before the agent runs. The agent then operates inside that boundary and surfaces only the exceptions that fall outside it. Everything else stays closed until the owner reviews the result at a fixed time.

Without the boundary the agents keep generating suggestions. With it they finish one narrow task and stop. The coordinator can then move to the next priority instead of spending the evening untangling three separate threads.

Why product teams shipping voice agents keep rediscovering the same coordination failure

Teams building these agents often measure success by how many tasks the agent can start. They track number of sessions, number of suggestions offered, or number of tabs left open. None of those numbers reveal whether the underlying outcome was achieved or whether the leader had to spend extra time cleaning up the mess.

The pattern repeats because the teams treat coordination as a technical problem of connecting data sources. It is actually a priority problem. Until the product forces a single owner and a single outcome to be named first, additional agents only multiply the places where decisions remain unresolved.

Seneca would have recognized the failure immediately. More letters do not produce clearer judgment if each letter raises new questions without settling the previous ones. The same holds for agents. The volume of activity is not the measure. The clarity of the final assignment is.

Your Turn: Apply This Today

• Pick one narrow workflow that currently runs across multiple agents or tabs and name the single outcome that matters most this week.
• Assign one explicit owner who will receive every agent output and decide what counts before any other step begins.
• Set a hard stop time of fifteen minutes for the agent run and require the owner to close the workflow at that time regardless of remaining suggestions.
• Remove the other agents or tabs from view during that fifteen-minute window so the owner works inside the declared priority only.
• Record whether the volunteer or task actually completed after the single-owner run and compare it to the previous week’s results.
• Repeat the same constrained workflow next week with the same owner and stop time before adding any new agent capability.

The same single-owner discipline is the fix in The Agent That Kept Running the Schedule While No One Was Watching, where a missing checkpoint let a scheduling agent act on stale context.

I consult with product leaders building agent tools for ministry contexts on single-owner workflow design, priority guardrails, and completion-rate measurement. Let’s talk.

You’re the hiring manager at a midsize faith-tech organization who has now posted the same senior product role four times in nine months. Each posting adds another requirement about AI fluency or stakeholder management, yet the inbox stays thin. The candidates who do apply are either fresh out of boot camps or veterans who have already burned out at larger ministries. You keep adjusting the language, but the right people never seem to surface.

This pattern is not unique to your posting. It is the default approach most faith-tech teams still use when they need operators who can ship tools that actually survive ministry handoffs and budget cycles. Job boards reward visibility and self-promotion. They miss the people who have spent years quietly fixing the exact problems your organization now faces.

John Wesley’s three simple rules offer a different lens. Do no harm. Do good. Stay in love with God. Applied to hiring, the first rule means refusing processes that quietly damage the relational networks that already exist. The second means creating specific, useful asks that travel well through those networks. The third means keeping the final decision tied to the people who will actually live with the outcome rather than letting HR templates take over.

Map the quiet operators first

The best product people in this space rarely update LinkedIn. They are the ones who built the volunteer scheduling layer that still runs at three different children’s ministry networks because no one has forced them to migrate to the new platform. They fixed the print export bug that kept breaking for the 7-minute volunteer on Sunday morning. They know which reorgs actually changed decision rights and which ones were just new org charts printed for a meeting.

Start by listing every person you have already worked with who has delivered something that lasted more than one budget cycle. Do not limit the list to people currently looking for roles. Include the person who left two years ago to care for aging parents but still answers questions about the old curriculum database when asked. Include the contractor who stayed on a project after the contract ended because the ministry lead kept calling.

This map is not a sourcing trick. It is the only reliable record of who actually understands the constraints of shipping to volunteers, pastors, and small teams who will never file a support ticket. Job posts do not surface this information because the people on the map are not optimizing for applications.

Write the one-paragraph ask that travels

Once the map exists, the next step is a single paragraph that can be forwarded without losing its meaning. The paragraph names the exact problem the role must solve, the three constraints that have already broken previous hires, and the one decision the new person will own in the first ninety days. It does not list technologies or years of experience. It describes the failure mode that keeps repeating.

Send this paragraph directly to the three people on your map who are not looking but know the next person who would be right. Ask them to forward it only if they can name someone who has already solved a version of the same problem. The rule against harm shows up here: do not ask them to post it publicly or to recommend someone they barely know. The ask must respect the weight of their endorsement.

This paragraph travels because it gives the forwarder a clear test. They can decide in thirty seconds whether the person they are thinking of matches. Most job posts fail this test because they require the forwarder to do the translation work themselves.

Close the loop with the person who still signs the budget

The final rule requires that the person who controls the budget hears directly from the mapped operators before any offer is extended. This is not a formal interview. It is a thirty-minute conversation where the budget owner describes the last three tools that failed to stick and asks the candidate what they would have done differently on day one.

In practice this step surfaces mismatches that a hiring committee never sees. The quiet operator who built the reliable children’s ministry export will immediately ask which current leader still has sign-off on content changes. If the budget owner cannot name that person, the operator knows the role will repeat the same handoff failures. The conversation ends quickly and without wasted time on both sides.

This closing step also protects the organization from the common pattern where an approved headcount gets filled by the candidate who performs best in a panel rather than the one who already knows how the actual work moves.

Your Turn: Apply This Today

• Block two hours this week to build the initial map of five operators who have shipped something that still runs after a reorg or budget cut.
• Write the single-paragraph ask for the current open role and send it only to the three people on that map who are not actively searching.
• Schedule the thirty-minute budget-owner conversation with the first candidate who receives a direct forward from your map.
• Remove the current job posting from all public boards until you have completed the first three direct outreaches.
• Document which three constraints from past failed hires appear in the paragraph you wrote and confirm the budget owner still owns those constraints.
• Send a one-sentence follow-up to each person who forwarded the paragraph, naming the outcome of the budget-owner conversation.

The pattern of reposting the same role while the operators stay hidden shows up again in how teams structure handoffs. See “The Three-Person Pod That Still Needed a Fourth Set of Eyes” and “The Ministry PM Who Handed Off Captain Duties Without the Handoff Log” for the downstream effects.

I consult with ministry product leaders on mapping existing operator networks and replacing job posts with direct, named outreach that respects actual budget owners. Let’s talk.

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.

I spent a full year chasing AI certifications and structured courses. I mapped out modules on machine learning fundamentals, prompt engineering tracks, and even a side sequence on ethics frameworks. The plan felt responsible and thorough. It also kept me from shipping anything real with the tools already in my hands.

The cost showed up in missed product decisions. While I collected badges, teams around me were testing small integrations that changed how volunteers completed tasks or how readers moved through content. I had the theory but none of the constraint-driven instincts that only appear when you are forced to decide what not to build.

This pattern is the foundational misread that causes product teams to treat skill development as a degree instead of an ongoing series of constraints. The result is slower judgment under real pressure and less ability to recognize the small opportunities that compound.

John Wesley’s three simple rules offer a better lens. Do no harm. Do good. Stay in love with God. Wesley used them to keep early Methodists focused on immediate action rather than endless preparation. The same three rules can filter what AI knowledge is worth pursuing next and what can wait.

The curriculum trap I built

I built the trap with good intentions and a spreadsheet. Every week I added another course or paper. I told myself the foundation had to be complete before I could responsibly advise on product choices. The spreadsheet grew while actual experiments stayed on a someday list.

The mistake compounded when I started reviewing other people’s work. I could critique model choices in theory but had never felt the friction of a volunteer trying to finish a lesson plan on a phone with one hand while managing kids with the other. Without that friction, my recommendations stayed abstract.

Real product work punishes the linear approach. Constraints appear in the moment: limited compute budget, a user base that prints everything, or a ministry leader who needs the output in under seven minutes. A curriculum rarely surfaces those constraints early enough to shape judgment.

Wesley’s rules as a filter for what to learn next

Do no harm first. Before I chase the newest model release, I ask what downstream effect it might have on the people already stretched thin. In one case this meant skipping an advanced summarization tool because it would have removed the brief human review step that caught doctrinal drift in children’s material.

Do good next. I now look for the smallest capability that improves an existing workflow today rather than the largest capability that might matter later. A simple classification model that routes volunteer questions to the right curriculum page produced more ministry impact than months of studying generative video.

Stay in love with God keeps the filter from becoming purely utilitarian. The rule surfaces when a technical choice begins to erode the sense that the work still belongs to something larger than efficiency. If a new technique requires hiding how decisions are made from the people who will live with them, the rule flags it before the roadmap meeting.

How faith-tech teams can apply the same constraint

Teams can run the three rules against any proposed learning goal in under ten minutes. The exercise replaces the need for another quarter-long upskilling plan. It surfaces whether the next skill actually serves the users who already show up every week.

One team I watched used the filter on an internal request to master fine-tuning. After running the rules they chose instead to deepen their understanding of retrieval-augmented generation because it let them keep source material visible to pastors who needed to verify accuracy. The narrower choice shipped in six weeks.

Another group applied the same test to a proposed ethics certification track. They realized the track would pull senior attention away from reviewing how an existing chatbot answered questions from new believers. They dropped the certification and added a weekly review of live logs instead. The change improved trust faster than any credential.

The pattern holds across both ministry and enterprise settings. Teams that treat the rules as an immediate filter move from learning to shipping while the context is still fresh. Teams that treat learning as a separate program keep rediscovering the same constraints later, at higher cost.

Your Turn: Apply This Today

• Pick one AI capability you have considered studying and run Wesley’s three rules against it in writing before the end of the week.
• Identify the single current user friction that the capability might address and test a no-code version of it inside an existing product flow this month.
• Drop any learning goal that cannot be tied to a real user constraint observed in the last thirty days.
• Schedule a thirty-minute review of live usage data instead of enrolling in the next course on your list.
• Document one instance where following the three rules caused you to abandon a promising technique and note the time saved.
• Share the filter with one teammate and apply it together to their current learning backlog before the month ends.

This approach lines up with what I have written elsewhere about treating digital discipleship as a product problem rather than a content problem. It also connects to earlier posts on choosing metrics that actually reflect mission progress instead of activity volume.

I consult with product leaders and ministry teams on AI learning constraints, product roadmapping under real user limits, and building filters that keep technical choices aligned with mission. Let’s talk.

The question I keep hearing from product teams is how to move from shipping AI features to actually building agents that improve over time. The answer is not better model selection or tighter prompt engineering. It is shifting from feature velocity to systems that accumulate team judgment.

This question surfaces because most roadmaps still treat agents as a new category of deliverable. Teams list capabilities like “handles scheduling conflicts” or “summarizes user feedback” and then measure progress by how many of those items ship. The result is agents that perform isolated tasks but never learn from the context the rest of the team already holds.

Teresa Torres’s continuous discovery framework shows why this pattern repeats. Torres argues that discovery must run in parallel with delivery, not in advance of it. When teams apply that lens to agents, the problem becomes clear: most current agent work still runs on a delivery-first cadence. The agent gets defined, built, and released before anyone checks whether the underlying assumptions about team knowledge have changed.

Why agent roadmaps keep collapsing into feature lists

Feature lists reward visible output. An agent that books rooms looks like progress even if it books the wrong room for the same reasons the last three tools did. The list does not track whether the agent knows why a certain room was rejected last quarter or which stakeholder vetoed it. Over time the agent repeats the same errors because nothing in the roadmap forces the team to record those reasons.

Continuous discovery changes the unit of work. Instead of adding another agent behavior, the team runs weekly interviews focused on recent decisions the agent should have influenced. The output is not a new feature but an updated set of assumptions that get fed back into the agent’s context layer. This keeps the roadmap from drifting into isolated capabilities.

One team I watched tried to build an agent for volunteer scheduling across multiple church sites. Their initial roadmap listed twenty behaviors. After running discovery interviews with the actual coordinators, they dropped twelve of those behaviors and instead built a simple way to capture why a volunteer was declined. The agent improved faster because the team now had a living record of past judgments rather than a growing list of functions.

Discovery loops that actually capture institutional knowledge

Most teams run discovery as a research phase that happens before build. Torres’s approach treats it as an ongoing loop that runs alongside delivery. For agent work this means the discovery questions must target how past decisions get reused, not just what users say they want next.

The practical version looks like this: every week the product manager pulls the three most recent agent failures or overrides. They sit with the people who made the override and ask what information the agent was missing. That single piece of context gets turned into a structured note that the agent can reference. Over months the notes form a lightweight institutional memory that no feature list ever captured.

Without this loop the agent stays frozen at the knowledge level of its first release. With the loop the agent slowly absorbs the pattern of choices the team has already made. The discovery work is not separate from the agent; it is the mechanism that makes the agent accumulate judgment.

The org design move most teams skip

Continuous discovery requires someone to own the loop, not just the output. Most agent teams assign ownership to an engineer or a single product manager who already carries delivery pressure. The discovery work gets deprioritized the moment shipping dates slip.

The teams that make progress create a rotating discovery owner role that sits outside the delivery sprint. That person runs the weekly interviews, maintains the decision notes, and updates the agent’s context rules. Delivery still happens, but the discovery owner protects the accumulation of judgment from getting lost in velocity metrics.

This role does not require a new headcount. It requires a temporary shift in how existing time gets allocated. One team I worked with gave the discovery owner four protected hours each week. Those hours produced more lasting agent improvement than the previous three months of feature additions.

Your Turn: Apply This Today

• Pick the agent your team ships most often and list the last five times a human overrode its output.
• Schedule three thirty-minute conversations this week with the people who made those overrides; ask only what context the agent lacked.
• Turn the clearest missing piece from each conversation into a one-sentence note and add it to whatever context store the agent already uses.
• Assign one person on the team to own the weekly override review for the next four weeks and protect those four hours on their calendar.
• Measure whether the same override pattern appears again after the notes are added; track it for two releases.
• Write a short internal note on what the agent now handles differently and share it with the broader product group.

Two earlier posts on the same thread walk through how judgment shows up in product systems and why most discovery work fails to stick once delivery pressure returns.

I consult with product leaders on AI agent roadmaps, continuous discovery loops, and building systems that accumulate team judgment. Let’s talk.

The captain texted at 9:47. None of the three families had heard a thing about tonight. The agent had already marked the shift complete, names in a row, times locked in. But the one person who used to know which mom forgets her phone in the car and which dad needs a second nudge never got the hand-off.

I kept staring at the list like it should explain itself. It didn’t. The work got assigned, the thread just disappeared.

Captains Without a Rulebook

The scheduling agent you deployed does not carry Wesley’s first rule. It books a volunteer who has already told three people she cannot serve that week because the agent only sees the calendar field, not the conversation that happened after the last service. The captain who used to catch that detail no longer sees the assignment until the volunteer shows up confused or angry. Harm happens quietly, one missed text at a time.

The second rule, do good, requires the captain to notice when a family needs an extra phone call or a different role. The agent optimizes for coverage, not care. When the captain stops making those small interventions, the families who needed them drift. The system reports high fill rates while the actual ministry weakens.

The third rule is the one most teams ignore. Staying in love with the work means the captain keeps a living record of why certain volunteers are placed where they are. That record lives in the captain’s head and in a few scribbled notes. When the agent takes the scheduling task, the captain stops writing the notes. Three months later no one can explain why the rotation changed or who promised to train the new helper. The knowledge does not travel because the person who held it no longer has a reason to keep it.

The Knowledge OS That Actually Travels

Wesley’s classes worked because every leader performed the same three actions in the same order every week. The repetition created a portable operating system. A new leader could step in and know exactly how to begin because the pattern was visible and personal.

When you remove the personal loop, the pattern disappears. The agent produces schedules faster than any captain could, but it does not produce the weekly habit of checking in with the person who just served. That habit is what turns one captain’s experience into the next captain’s starting point. Without it, each new leader starts from zero even though the agent has perfect historical data.

The same pattern shows up in the children’s ministry curriculum work I watched last year. The team that kept a captain responsible for reviewing every volunteer’s completed lesson sheet before the next week retained 40 percent more volunteers than the team that let the platform send the next lesson automatically. The difference was not the content. It was the captain who still had to sign off and therefore still had to know what had actually happened.

Why Agent Speed Breaks the Hand-off Chain

Agent speed removes the friction that once forced the captain to touch the schedule. That friction was the hand-off. When the captain had to open the sheet, review the names, and send the reminder herself, she noticed the gaps. When the agent sends the reminder, the captain’s attention moves to the next task. The knowledge that used to move forward with the schedule now stays in the agent log that no one opens.

The break compounds across reorgs. A new ministry director arrives and asks why certain volunteers keep getting skipped. The old captain has already moved on. The agent has no record of the conversation that happened in the hallway after the service two years ago. The only remaining trace is a blank field that used to hold a captain’s note.

Teams that keep the captain accountable for the loop, even after the agent takes the mechanical work, preserve the chain. The captain still reviews the agent’s output every Monday, still calls the one name that does not match the pattern, and still writes the single sentence that explains the change. The agent handles volume. The captain carries the rule.

Your Turn: Apply This Today

• Pick the single scheduling agent output that lands on your desk this week and add a mandatory captain review step that must be completed before any reminder goes out.
• Write the three Wesley rules on a single index card and tape it to the monitor the captain uses when checking the agent’s list.
• Require the captain to add one sentence to a shared note after each review explaining one change the agent would not have caught.
• Block thirty minutes on the captain’s calendar every Monday for that review and treat the block as non-negotiable for the next four weeks.
• At the end of week four, ask the captain to forward the accumulated notes to the person who will hold the role next quarter.
• Remove the agent’s ability to send reminders directly to volunteers until the captain has logged the review.

The posts “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” trace the same pattern in two other teams.

I consult with ministry product leaders on agent hand-off loops, captain accountability systems, and knowledge retention after automation. Let’s talk.

I shipped the refactor on a Tuesday afternoon. Two days of prompts and quick reviews, and the whole module sat there cleaned up, tested, ready. By Wednesday morning the first approval request had already bounced back with a question from someone two layers up who’d never touched the repo.

That was the part nobody warned us about. The code moved fast. Everything else moved like it always had—slow, cautious, built for a world where changes arrived one at a time and every line carried human weight. Now the lines arrive in batches, and the weight still has to be carried the old way.

Teresa Torres’s continuous discovery framework treats opportunity identification and solution testing as ongoing activities rather than staged events. Applied here, it reveals that verification gates function as the new discovery layer. When teams keep generation fast but leave validation infrequent and heavyweight, the system simply moves the bottleneck downstream without removing it.

The Number Everyone Celebrates

The two-day refactor number gets reported in sprint reviews and leadership updates. It reflects actual engineering hours spent on code changes. What the number hides is that the same teams now generate three times the volume of proposed changes per cycle.

That volume lands in queues designed for slower, human-authored diffs. Reviewers face context switching across dozens of small, AI-suggested edits rather than a handful of deliberate ones. The celebration of the initial number prevents anyone from measuring the cumulative time spent re-explaining intent across each verification step.

Ministry platforms that produce children’s curriculum or sermon outlines see the same pattern. A volunteer-facing lesson set that once took a content editor two weeks now reaches first draft in three days. The subsequent review with doctrinal reviewers, accessibility specialists, and print production still consumes the original calendar time because no one adjusted the handoff criteria.

Where the Six Weeks Actually Hide

The delay lives in repeated clarification loops rather than in the code itself. Each approver asks questions that the original prompt to the AI never surfaced: edge cases for age groups, regional translation needs, or integration with existing print workflows. Because the generation step moved fast, these questions arrive late and in batches.

Continuous discovery, in Torres’s terms, would have surfaced those constraints through regular exposure to users and stakeholders before the refactor began. Instead, the fast generation step creates the appearance that the work is mostly complete. The verification gate then becomes the place where discovery finally occurs, but without the lightweight interview cadence that makes discovery cheap.

One platform that manages global sermon resources found that legal and translation sign-offs now require separate meetings for each AI-generated variant. The meetings themselves had not changed frequency; only the number of variants had increased. The six weeks therefore represent accumulated coordination cost, not review effort per se.

Redesigning the Verification Gate

The fix begins by moving small validation checks earlier and more often. Rather than waiting for a complete refactor to reach the full approver list, teams can run targeted opportunity solution trees with the actual users of the output—volunteers, pastors, or translators—while generation is still happening. This turns verification from a final gate into a running discovery process.

Concrete changes include shortening the artifact that enters review. Instead of shipping an entire refactored module, teams surface one user-facing difference at a time through a simple prototype or print sample. Approvers respond to the observable impact rather than the full technical diff. This matches Torres’s emphasis on testing solutions against real opportunities instead of internal completeness criteria.

Another adjustment is to embed the same people who will ultimately sign off into the prompt refinement stage itself. When a doctrinal reviewer sees the initial prompt and flags a constraint before generation runs, the subsequent cycle avoids the six-week surprise. The calendar time shrinks because the verification criteria travel with the work rather than arriving after it.

Teams that adopted this pattern on curriculum tools reported that total elapsed time dropped from six weeks to under three, not because generation got faster but because the verification criteria became explicit and stable earlier in the loop.

Your Turn: Apply This Today

• Map the exact sequence of people and artifacts that must approve any AI-generated change in your current workflow, listing each step by name and average days elapsed.
• Pick the longest single verification step and run a 30-minute conversation with that approver this week focused only on the three constraints they care about most.
• Insert one lightweight check—such as a shared prompt log or single-user test—before the refactor reaches the full gate, then measure whether the later step shortens.
• Reduce the review artifact size by half for the next cycle and require approvers to respond to observable user impact rather than technical completeness.
• Schedule a recurring 15-minute slot with one downstream stakeholder to review emerging prompts rather than finished outputs.
• Document the revised gate criteria in a single shared paragraph and circulate it before any new generation task begins.

The same verification trap shows up in the workflow described in The Refactor That Finished in Two Days and Then Sat for a Week and in the coordination overhead tracked in Faster Code Does Not Move the Real Ministry Bottleneck.

I consult with product leaders in faith-tech organizations on verification workflows, AI output governance, and shifting from generation speed to discovery loops. Let’s talk.

She sat at the kitchen table after the house had gone quiet, one hand on her phone and the other keeping her toddler from sliding off her lap. Three new schedules waited on the screen. Every one of them put volunteers back into rooms she had already closed, at times that would force her to start calling parents again.

The agents had moved fast. They just hadn’t moved inside the actual constraints—the ones that only show up after you’ve done the work for years and know which names can’t be used and which spaces are already spoken for.

That gap is where most tools break.

Solomon’s judgment offers the clearest lens here. Two women claimed the same living child. Solomon proposed dividing the child in half. The true mother immediately refused the proposal and surrendered her claim rather than see the child destroyed. The false mother accepted the division. Solomon identified authority by who possessed the right to say no to the wrong solution.

When Embedded Thinking Meets Ministry Reality

The same pattern appears in every agent-assisted scheduling system I have watched roll out. Engineering teams embed preference rules, capacity limits, and volunteer history into the model. The model produces a clean table. The person who actually runs the ministry then spends the next evening correcting names, locations, and conflicts the model never saw.

The problem is not the quality of the code. The problem is that the final authority still sits with the person who must live with the result, yet the system treats that person as a reviewer rather than a decider. In one children’s ministry rollout I observed, the volunteer coordinator received a schedule that reassigned three teachers who had already told her they were unavailable for the entire quarter. She had entered that information herself. The agent had overwritten it because the optimization score improved when those names were included.

The director at the kitchen table faced the identical situation. She could accept the schedules and create confusion for families, or she could reject them and lose the evening she had planned for other work. Either path left the real decision in her hands after the agents had finished.

The Authority That Cannot Be Automated

Solomon did not ask the women to negotiate a compromise. He tested which one held the actual claim by offering an outcome neither would accept if they were the true parent. The test worked because authority was defined by the willingness to stop the process rather than by the ability to generate options.

In agent systems the equivalent test is simple. Can the person responsible for the outcome delete or rewrite an entire agent result without needing approval from another system or another role? Most current setups fail this test. The agent output moves into a review queue. Suggested edits require the original prompter to re-run the agent. The human who must execute the schedule has no direct way to mark the output as invalid and move on.

I have seen this in curriculum planning tools as well. A volunteer ministry director receives a lesson plan that references a story the church no longer uses. She knows the replacement story and the reason for the change. The system offers her a comment box. It does not offer her a button that says “this output is rejected; generate nothing further until I approve a new constraint.” The difference matters on a Tuesday night when the toddler needs to go to bed.

Keeping the Human Who Can Still Say No

The practical requirement is therefore not better prompts or cleaner data. The requirement is an explicit handoff of final authority to one named person who can veto the entire agent output in one action. That person must be outside the engineering or product team that built the agent. Their veto cannot be overridden by score thresholds or escalation workflows.

In the churches where this has worked, the rule is written down. One volunteer coordinator owns Tuesday night schedules. One children’s director owns room assignments. Their names sit in the system record next to the constraint “agent output requires this person’s explicit approval before distribution.” When they reject an output, the agent stops. It does not suggest alternatives until they release it.

This matches the Solomon test. The person who can stop the division holds the real authority. Everyone else is negotiating after the fact.

Your Turn: Apply This Today

• Pick one recurring agent output in your current workflow and assign a single named person outside the build team the right to reject it in full with one click.
• Update the system record so that rejection halts any further agent runs on that task until the named person clears it.
• Write the rejection rule in one sentence and place it in the shared project doc by Friday.
• Test the rule this week by having the named person reject one live agent output and confirm the system does not generate replacements without their release.
• Review the last three agent outputs you accepted and identify which one the named person would have rejected if given the chance.
• Schedule a ten-minute check-in with that person next week to hear what the rejected output would have broken for them.

The same authority question shows up again in the agent that kept running the schedule while no one was watching and in the three-person pod that still needed a fourth set of eyes.

I consult with ministry product leaders on agentic scheduling systems, explicit veto rights, and volunteer workflow ownership. Let’s talk.

I still have the notebook. The 2018 plan sits on page 47, each role written in the same blue pen, connected by straight lines like train stops. No erasures, no extra space.

Two years later an email landed about redesigning how volunteers passed curriculum between sessions. The description didn’t match anything on that page, so I closed it. The person who took the role later told me they had finished the work in six months and were already moving on to the next constraint no one had noticed.

My plan had taught me to wait for the next printed station. It never trained me to see the editable handoff sitting right in front of the tracks.

John Wesley’s three simple rules give a different lens. Do no harm. Do good. Stay in love with God. Wesley used them as daily constraints that anyone in the movement could apply without waiting for permission from the center. The rules did not prescribe outcomes. They kept the next action editable by the people closest to the work.

The plan that locked out the right next captain

I had written the five-year map after a promotion at a curriculum platform. The document assumed I would move from feature owner to group lead to director by a certain date, with specific products attached to each step. When an internal project surfaced that needed someone to hand curriculum ownership to volunteer teams without breaking their weekly rhythm, the map offered no category for it.

The person who stepped in instead treated the role as a temporary container. They set three constraints: the volunteer must finish the handoff in under seven minutes, the output must be printable without further edits, and the next volunteer must be able to change any line without asking permission. Within four months the completion rate for that curriculum doubled. My plan had no room for that kind of container because it measured progress by title sequence, not by whether the actual owners could still edit the work.

How Wesley’s rules expose the hidden constraint in long-horizon PM tracks

Wesley’s first rule, do no harm, translates directly to role design. A five-year plan that cannot be altered by the people who will live with the outcomes does harm by removing their agency before they arrive. The second rule, do good, requires that the next step produce something usable by the current owners rather than something that merely advances the planner. The third rule, stay in love with God, keeps the mission itself from becoming an idol that justifies locking the path.

Most PM career ladders still treat the next title as the measure. They ask for evidence of scope growth, headcount managed, and roadmap ownership. Those signals assume the mission stays the same shape. When AI changes the shape of the work faster than the ladder can update, the signals start rewarding people who protect the old map instead of the people who keep the actual work editable. The three rules surface the constraint because they force every role description to answer whether the next person can still change it without breaking the mission.

What changes when you treat every role as a three-rule loop instead of a title ladder

At one ministry product team the group lead stopped writing annual role charters. Instead each role carried the three constraints written on a single card: the output must remain changeable by the person who runs the session, the change must not increase time for the volunteer, and the mission metric must stay visible without extra reporting. The card could be rewritten by the volunteer owner at any time.

Within a quarter the same team had handed off two senior PM responsibilities to people who had never held the title. One person redesigned the print handoff process. The other built the check that prevented the agent from running a schedule when no one was watching. Neither move appeared on anyone’s five-year map, yet both moves kept the real owners in control of the outcome.

The pattern repeats when the rules stay short. A role becomes a loop that the next captain can still edit rather than a destination that must be defended. The ladder disappears because the measure is whether the constraint set remains small enough for the actual owner to rewrite it.

Your Turn: Apply This Today

• Take your current role description and delete every sentence that names a future title or scope level.
• Replace the deleted lines with exactly three constraints written so the person who will inherit the work can still change any one of them without your approval.
• Send the revised card to the two people who actually run the sessions or own the outcomes this week and ask them to strike or add one line.
• Schedule a thirty-minute review next week where those two people present the updated card and you only record what they changed.
• Apply the same three-constraint rewrite to one open role on your team before the next hiring conversation.
• Archive the original five-year plan document and replace it with a single note that lists only the three constraints active this quarter.

The same pattern shows up in how the agent kept running the schedule while no one was watching and in how the three-person pod still needed a fourth set of eyes to keep the handoff editable. Both cases turned on whether the people closest to the work could still change the constraint set without waiting for the original planner.

I consult with product leaders and ministry PMs on rewriting role constraints for AI speed, keeping handoffs editable by actual owners, and designing three-rule loops instead of title ladders. Let’s talk.

I still remember the look on our backend engineer’s face when the first support thread came through. A volunteer in Manila had tried to update the service schedule and the whole thing locked her out during the one hour she had between shifts. He had written the migration. He saw her name in the logs.

He stopped asking the product channel for clarification after that. Instead he started calling the users himself before the next deploy, then quietly rolling back anything that still felt shaky.

The PM role we had hired six months earlier never got replaced when she left.

Why the ‘regret that PM exists’ test fails in faith-tech contexts

Ministry tools rarely produce the clean failure signals that force engineers to feel the weight. A children’s ministry volunteer prints a lesson at 9 p.m. on Saturday, notices the activity page is missing a key instruction, and simply skips the activity. No ticket arrives. No usage metric drops. The engineer ships the next feature without ever learning the volunteer adapted around the gap.

This pattern repeats across curriculum platforms. The people who absorb the friction are part-time leaders who treat the software as one more unreliable volunteer rather than a product they can influence. Because the cost stays diffuse, the team concludes the feature set works and adds another layer of coordination instead of removing it.

The test therefore misleads. It assumes regret travels back through usage data or direct complaints. In practice the data stays clean while the real ministry outcome quietly degrades. Teams then reintroduce a product manager to interpret the silence, recreating the very distance the minimal structure was meant to close.

How discovery loops break when the person who feels the outcome never talks to the user

Continuous discovery requires the builder to hear the user describe the job in their own words before any wireframe appears. When an engineer never joins that conversation, the first version already encodes assumptions that only surface after launch. The product manager becomes the single point of translation, and every subsequent iteration passes through the same filter.

Over time the engineer learns to wait for requirements rather than seek the original need. The volunteer who once would have shown the broken flow now speaks to someone whose job is to summarize. The detail that would have changed the implementation gets lost in the handoff, and the next release solves a slightly different problem than the one the user described.

The loop does not fail because the product manager lacks skill. It fails because the person who will later defend or refactor the code never experiences the mismatch between intention and result. Torres’s framework collapses without that direct exposure, regardless of how many discovery meetings the middle layer schedules.

The handoff pattern that actually survived when we removed the middle layer

One small team kept a working rhythm after dropping the dedicated product role by requiring the engineer who would implement a change to attend the next two user conversations and own the decision to ship or rework. The rule applied even to small curriculum updates pulled from third-party sermon resource libraries. The engineer heard the volunteer explain why a certain age group needed the story repeated twice before the activity began.

That single change altered the definition of done. Instead of handing a spec to another person, the engineer carried the user’s phrasing into the implementation and later checked whether the printed page matched what the volunteer had described. When it did not, the same engineer adjusted the template without reopening a planning meeting.

The pattern held because the regret stayed attached to the code author. A missed detail on a children’s lesson now meant the engineer would field the follow-up email from the volunteer the next Sunday. Over months the team shipped fewer features but completed more of them in ways that actually reduced the volunteer’s Saturday-night scramble. The structure worked only while the engineer remained the owner of both the change and its consequences.

Your Turn: Apply This Today

• Pick one upcoming change to the print export flow in your curriculum tool and schedule a 25-minute call with a current children’s ministry volunteer this week; have the engineer who will code the change sit in and take notes without speaking for the first ten minutes.
• After the call, require that same engineer to write the acceptance criteria in the volunteer’s own words before any code is written and share the draft with the volunteer for one round of confirmation.
• Set a calendar reminder for seven days after the feature ships so the engineer must review the actual printed output with the same volunteer and record what still required workarounds.
• Remove any product-manager-only review step for changes under a certain scope and replace it with a required user conversation log that the engineer must attach to the pull request.
• Track the number of post-release adjustments that originate from the engineer rather than from support tickets for the next four releases and compare the count to the prior four.
• If the engineer reports that the user conversation changed the original plan, document the specific sentence from the volunteer that triggered the shift and keep the note visible in the next planning session.

The handoff patterns described here connect directly to the constraints visible in The Refactor That Finished in Two Days and Then Sat for a Week and the bottleneck analysis in Faster Code Does Not Move the Real Ministry Bottleneck.

I consult with product leaders in ministry tools on continuous discovery practices, regret ownership in engineering teams, and sustainable handoff patterns without added layers. Let’s talk.

I was staring at the volunteer completion chart when it hit me. The line had been sliding for three weeks, quiet and steady, and no alert had fired. An agent had tweaked the recommendation logic two releases earlier. It favored shorter passages, which the model scored as higher engagement. The actual humans teaching kids on Wednesday nights just quietly stopped finishing the material.

We had designed the whole platform so nothing needed a single gatekeeper. Every service could read the shared context, every agent could propose changes. The theory said distributed visibility would catch problems faster than any old command chain. What it missed was how fast context stops feeling obvious once the people who once carried it are no longer the ones writing the code.

Someone still had to be willing to look at the change and say it was wrong for reasons the metrics couldn’t see.

The OS that looked decentralized until the first bad merge

At one ministry platform the content team built a shared repository for children’s curriculum adjustments. Agents proposed new activity lengths, new age-band splits, and new print layouts based on usage logs. The first three merges passed automated checks and went live. Volunteer completion rates fell 11 percent in two weeks. No single person had reviewed the combined effect on the 7-minute volunteer workflow.

The team had documented every change. They had run unit tests. They had followed the distributed review checklist. What they lacked was one role whose explicit job was to hold the veto on merges that touched both the metric layer and the print-first layer at once. The OS looked flat until the first time the lattice pointed the wrong way.

The same pattern appeared in a separate effort to auto-generate discussion questions for sermon resources. An agent began surfacing questions that scored well on engagement but required more than seven minutes to prepare. The change shipped because each individual approval step looked reasonable. The person who used to own the final sign-off had been moved to a coaching role and no longer touched the merge queue.

Munger’s latticework applied to AI-augmented ministry product teams

Charlie Munger described a latticework of mental models as the minimum structure required for sound judgment. Each new model added a new angle of inspection. The value came from the intersections, not from any single model in isolation. In product work this means keeping models for volunteer time cost, theological framing, metric drift, and deployment risk all active on the same decision.

When agents write the first draft of a change, they usually optimize inside one model. The lattice only forms if a human still sits at the intersection before the change is committed. Without that seat, the system adds models linearly and compounds error exponentially. Ministry platforms feel the effect first because their real retention metric is whether a volunteer finishes the task, not whether an engagement score rises.

The practical implication is that every agent-assisted merge needs an explicit veto owner who can name which mental models are in tension. That owner does not need to write code. They need to be the only person who can approve when the change touches both the knowledge base and a downstream volunteer workflow. The lattice does not run itself; it only stays coherent when someone is paid to guard the intersections.

Where the captain role still lives once the knowledge base is supposed to run itself

The title “captain” does not have to appear on an org chart. It appears in the commit log as the single required approver on changes that cross a defined risk threshold. In one case the threshold was any edit that altered print output for curriculum used by more than ten thousand volunteers. The approver was a former children’s director who no longer wrote code but still carried the memory of what seven minutes actually feels like on a Wednesday night.

Once the knowledge base grows large enough to train its own agents, the captain’s job shifts from writing to refusing. The refusal is the only action that cannot be delegated to the lattice. Everything else—drafting, testing, even initial review—can be distributed. The final no cannot.

Teams that removed the captain role discovered the cost in the form of silent metric reversal. Completion rates declined while every automated dashboard showed improvement. The reversal only became visible when someone outside the agent loop asked why the printed packets were now two pages longer.

Your Turn: Apply This Today

• List the last three agent-driven merges your team shipped and name the exact person who still holds veto power on each one.
• For any merge without a named veto owner, add a one-line rule in the repository that blocks merge until that owner signs off.
• Define the three risk thresholds that automatically route a change to the captain role this week.
• Run the three merges through Munger’s lattice by writing one sentence for each mental model in tension before the change is approved.
• Remove the coaching-only title from the former children’s director or equivalent and restore a 10 percent time allocation to merge review.
• Schedule a 30-minute weekly review where the captain walks through any agent change that touched both metrics and volunteer workflow.

The Agent That Kept Running the Schedule While No One Was Watching showed what happens when an autonomous process drifts without an owner. The Three-Person Pod That Still Needed a Fourth Set of Eyes demonstrated the same pattern at the level of code review.

I consult with ministry product leaders on preserving human veto points in AI-augmented knowledge bases and designing merge rules that keep the lattice coherent. Let’s talk.

Most volunteer coordinator roles at ministry-tech organizations still get filled through standard inbound application flows. The number looks like proof that the system works. It is actually proof that the system only surfaces the people already looking, while the recurring decisions about curriculum scheduling, follow-up loops, and edge-case support stay locked inside the heads of two or three overcommitted staff members who never appear on any job post.

The gap is not a recruiting problem. It is a mapping problem. Teams keep treating the open role as the unit of work instead of tracing the actual decisions that must be made every week. Without that trace, inbound volume becomes a comfort metric rather than a signal of whether the right people are connected to the right choices.

Charlie Munger’s latticework of mental models makes the mistake visible. Munger argued that real understanding comes from holding multiple models at once so none of them can dominate. In talent work the dominant model is still the job requisition. The missing models are decision ownership, recurrence frequency, and relationship durability. When those sit outside the map, the funnel keeps producing candidates while the actual ministry bottlenecks remain untouched.

Mapping the actual decision owners instead of the job posts

Most product teams still begin with the posted role. They list responsibilities, then wait for applications. In practice the real decisions about children’s ministry follow-up or sermon resource approvals are already being made by a volunteer who has never applied for anything and a part-time staff member who reports to no one in the org chart. The posted role becomes a container that never gets filled with those decisions.

I watched one mid-size curriculum platform try to hire a volunteer coordinator after their print-first user base grew past 180,000 monthly active users. The job description mentioned “managing volunteer schedules.” It did not mention the Tuesday morning decision about which volunteer gets the new lesson plan when the original volunteer’s child is sick. That decision stayed with the children’s pastor who was already running three other portfolios. Six months later the new coordinator was still routing every exception back to the same pastor.

The lattice requires naming the owner of each recurring decision first, then asking which existing relationships already touch that owner. The job post comes later, if it comes at all.

Why direct outreach beats the application stack for faith-tech roles

Inbound stacks reward people who are between roles or actively scanning LinkedIn. Ministry decisions, especially the ones that touch volunteers, are usually held by people already inside the work. They do not apply because they do not see themselves as applicants. They respond when someone they trust asks a specific question about a specific decision.

One team I worked with replaced their coordinator posting with a six-week exercise of listing every recurring choice that affected volunteer completion rates. They then reached out to twelve people already performing fragments of those choices. Four of the twelve agreed to a defined scope without ever seeing a job description. Retention after six months was higher than the previous two hires who had come through the stack. The difference was not character. It was that the outreach started from the decision map rather than the requisition.

The application stack still has a place for senior product roles that require rare technical judgment. For roles that sit at the intersection of product and volunteer systems, the stack mostly filters for availability instead of proximity to the actual work.

Building the lattice that survives staff turnover

Turnover is the test. When the children’s pastor leaves or the volunteer coordinator moves cities, the decisions do not disappear. They simply lose their current owner. A living talent map records the decision, the current owner, the backup relationship, and the last time the handoff was practiced. Without that record, every departure restarts the search from the job post rather than from the work.

I have seen three consecutive coordinators cycle through the same platform because each new person inherited only the title and the inbox. The actual Tuesday morning exception handling never transferred. After the third departure the team finally built a simple shared document that listed the twelve recurring decisions, the two people who had touched each one in the prior quarter, and the last date the handoff conversation happened. The next coordinator started with that document instead of the job description. The role stabilized.

The lattice is only useful if it is updated on the same cadence as the decisions themselves. Quarterly updates are too slow. Monthly checks against the actual exception log keep the map honest.

Your Turn: Apply This Today

• List the three most frequent ministry decisions your product or volunteer system handled last month and name the single person who currently owns each one.
• For each decision, add the name of the person who performed the same task when the owner was out last quarter.
• Schedule one 20-minute conversation this week with the backup person to confirm they can still execute the decision without the primary owner present.
• Write the decision, owner, and backup into a shared document that is not inside any HR system or job requisition.
• Review the document with your immediate team in the next staff meeting and ask which of the three decisions has changed owner since the last review.
• Repeat the entire list for the next three decisions that will appear in the coming quarter rather than the ones already visible.

The same pattern shows up in the work described in “The Agent That Kept Running the Schedule While No One Was Watching” and “The Voice File That Actually Survived Three Ministry Reorgs.” Both posts trace how small, recurring decisions outlast the people who first held them when the connections are made explicit.

I consult with product leaders and ministry technology teams on decision mapping, volunteer system design, and talent lattice maintenance. Let’s talk.

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.

I stood at the counter rinsing plastic cups in the church kitchen when the children’s director handed me her phone. The screen showed a simple agent interface she had built on a borrowed laptop two years before. Every Monday morning it still pulled volunteer names, checked availability from the shared sheet, and output a draft schedule that landed in the right inboxes without anyone asking.

Three different staff members had held her role since then. Each one inherited the same output on the same day. The agent had outlasted the org chart because it solved the exact pain of the person who first needed it, not the plan that came later.

John Wesley’s three simple rules give the clearest lens for why some side work keeps running when titles and teams shift. Do no harm. Do good. Stay in love with God. Applied to product work, they become a daily filter: build nothing that creates new work for the people already stretched thin, build only what removes friction for the actual user, and keep the artifact connected to the real ministry task rather than the latest roadmap slide.

The side project that survived three reorgs

The children’s director had started with one narrow problem. Volunteer scheduling ate her Monday morning and often spilled into Tuesday. She wrote a small script that read the existing spreadsheet and suggested names based on past availability and role fit. No new database. No new login. Just a Monday email that arrived ready to review.

When the first reorg moved her to a different campus, the script kept sending the emails from the same shared account. The new director found it useful and left it alone. The second reorg brought a different staff person who tried to replace it with a commercial tool. The commercial tool required weekly data entry that nobody had time for, so the old script quietly resumed after two weeks. The third reorg simply ignored it. The output never stopped.

I have seen the same pattern with curriculum tools. A volunteer-facing checklist built for one church’s print workflow continued to generate usable pages long after the original team had moved on. The artifact stayed because it never asked the next person to learn a new system. It only asked them to open the same folder on Monday.

Staying useful when the plan changes

Wesley’s first rule, do no harm, shows up in product decisions as a refusal to add steps. The agent never required the volunteer coordinator to maintain a second data source. It read what already existed. That single constraint kept it from becoming another system the next staff member had to fight.

The second rule, do good, forced the scope to stay narrow. The agent did one job well. It did not attempt to predict absences or manage background checks. Those tasks stayed with the human because the human already had context the script could not hold. The narrowness made the output reliable even when the surrounding process changed.

The third rule, stay in love with God, translates in this setting to keeping the work tied to the actual person doing ministry rather than the current leadership priority. The script existed because one director hated Monday mornings. Every later user inherited that same relief. The artifact did not need re-selling because it never depended on the current vision statement.

The simple rule that turns emergence into reliable output

Career paths in product rarely follow the org chart. They follow the trail of small artifacts that keep solving the same concrete problem for the people closest to the work. The children’s director did not set out to build a lasting system. She set out to free her Monday. The discipline was to keep the artifact pointed at that Monday problem even when her title changed.

I watched a similar pattern with a sermon prep checklist that started as a one-page printout for new preachers. Over four years and three different ministry leads, the checklist remained the default handoff document because it still answered the exact question a new preacher asked on their first week. The document never grew into a platform. It stayed one page because one page removed the real bottleneck.

The same discipline appears in larger tools. A volunteer completion tracker built for children’s ministry never tried to become the full church management system. It tracked only the single metric that mattered to the people printing lessons on Thursday night. Because it stayed narrow, it survived leadership changes that killed broader platforms.

Your Turn: Apply This Today

• Pick the one recurring task that lands on your desk every week and write down the exact output the person after you will need.
• Build the smallest possible script or document that produces that output from data you already have, with no new logins or fields.
• Test it once this week by handing the output to the actual next user and remove any step that creates work for them.
• Store the artifact in the same place the current process already lives so the next person finds it without searching.
• Run it again next Monday exactly as written and note only the one change that would make the output more useful, not more complete.
• Leave the artifact untouched for two full weeks and confirm it still produces the same result without your involvement.

The pattern in “The Agent That Kept Running the Schedule While No One Was Watching” and “The Voice File That Actually Survived Three Ministry Reorgs” shows the same outcome when the daily filter stays on usefulness rather than visibility.

I consult with product leaders and ministry technology teams on building narrow persistent tools, surviving reorgs without losing output, and applying daily usefulness disciplines to side work. Let’s talk.

Central recruiting functions produce the weakest matches for specialized ministry roles because they optimize against a generic description instead of the live constraints of the work itself. The people who actually run the systems already hold the models needed to see what the role requires; moving the mapping step upstream strips those models out.

This separation is the error that turns talent density into a spreadsheet exercise. Charlie Munger’s latticework of mental models requires pulling from multiple disciplines at once—systems dynamics, incentive design, and the specific domain of volunteer coordination—to even identify the real variables. A central team can only apply the models it possesses, which rarely include the daily friction of a seven-minute volunteer window or the print-first constraints of curriculum delivery.

The talent map that stayed in the spreadsheet

A curriculum platform serving children’s ministry volunteers once received a central list of recommended hires for a new support role. The list prioritized candidates with enterprise software experience and advanced degrees in education. None of those candidates understood the difference between a volunteer who prints the lesson on Sunday night and one who needs the entire script on a single page.

The mismatch surfaced only after the new hire began work. The actual team already knew that completion rate, not feature adoption, determined whether volunteers returned the next week. The spreadsheet had no column for that metric because the people building the map lacked the domain model.

When the mapping step moves inside the using team, the latticework appears naturally. The volunteer coordinator brings the incentive model, the product person brings the retention signal, and the engineer brings the systems constraint. Together they surface requirements that never appear in a job requisition written two layers removed from the work.

Direct pursuit beats posted roles in volunteer systems

Posted roles assume that interested people will self-identify and self-filter. In ministry contexts the opposite holds: the people who would perform best are already occupied and rarely browse job boards. They respond only to a direct ask that names the exact friction they already solve in their current setting.

The same pattern appears in product teams building for global discipleship tools. When a new quality role was posted centrally, applications came from generalist testers. When the existing pod instead listed three specific people they had observed handling edge cases in user feedback, two of those three engaged in direct conversation. One joined within three weeks. The difference was not compensation; it was that the ask referenced the actual pattern they already demonstrated.

Central posting severs this signal. It forces the candidate to translate their experience into the language of the requisition rather than allowing the team to translate the need into the candidate’s existing language. The latticework collapses when one node is removed from the conversation.

Why the fourth person on the pod still matters more than the model

Small teams that ship consistently develop an internal map of missing perspectives. A three-person group handling volunteer curriculum updates could articulate their throughput problem but could not name the coordination gap until a fourth set of eyes joined and simply asked how decisions moved between print production and digital delivery.

The model that predicted the need for that fourth person lived only inside the daily handoff rhythm. A central recruiter working from headcount targets had modeled the role as “content operations specialist” and missed the coordination variable entirely. The team that already ran the rhythm could see the variable because they experienced its cost every release cycle.

High-talent-density hiring therefore depends on keeping the mapping step local. The latticework forms only when the people who will absorb the new person’s output participate in defining what that output must actually change.

Your Turn: Apply This Today

• Open your current team roster and list the three people outside the team whose work you already observe solving the exact friction your group hits weekly.
• Write one sentence for each person that names the specific pattern you have seen them handle, without referencing any open role.
• Send a direct message or email to the first of those three people this week that references only that pattern and asks whether they would discuss how they approach it.
• Repeat the same message for the second person within five days, adjusting only the observed pattern to fit their context.
• Block two hours next week to meet with whichever of the three responds, using the time solely to understand their current constraints rather than to pitch a position.
• Document the three mental models that surface in those conversations and bring that one-page note to your next internal planning meeting instead of any requisition draft.

The Three-Person Pod That Still Needed a Fourth Set of Eyes traces how small teams discover their actual gaps only after they begin shipping together. The Ministry PM Who Handed Off Captain Duties Without the Handoff Log shows the same principle applied to knowledge that never transfers through posted processes.

I consult with ministry product teams on talent mapping inside using teams, direct sourcing for specialized volunteer roles, and building team structures that keep the latticework local. Let’s talk.

The “replace SaaS with open-weight models to cut your inference spend” framework from the 2025 AI economics reports names token pricing as the bottleneck that every team can attack directly. It assumes the move to self-hosted inference delivers savings once the GPU cluster is running and the prompts are routed locally. For teams shipping ministry tools, the calculation never reaches that stage because the data flows carry consent rules that no public checkpoint satisfies.

Ministry products sit at the intersection of volunteer hours, church membership rolls, and pastoral notes that require explicit, revocable permission from the originating congregation. An open model pulled from a public model hub cannot inherit those constraints without an additional governance layer that the original SaaS vendor already provided under contract. The framework therefore measures the wrong unit: it counts tokens while the actual cost accrues in delayed approvals, manual redaction steps, and the eventual rollback when a volunteer coordinator discovers their lesson plan was used to train an external checkpoint.

This is the foundational misread that causes product teams to chase model hosting instead of mapping the actual permission holder in the workflow. The result is an inference bill that lands six months late, after the engineering hours, compliance review, and quiet reversion to the original vendor have already been spent.

Jensen Huang’s sovereign AI argument supplies the corrective lens. Huang located the value of sovereign compute in cases where data ownership or regulatory access, not raw price per token, determined whether the system could operate at all. Ministry teams face an analogous boundary: the data is not national security material, yet it is governed by local church polity and volunteer agreements that external providers cannot sign on behalf of the congregation.

Why the SaaS replacement math breaks at the permission boundary

One children’s curriculum platform processes lesson plans that a volunteer creates on Tuesday night and expects to remain visible only to her church’s approved users. When the team tested an open Llama derivative for summarization, the first compliance checkpoint required a new data-processing agreement that the volunteer coordinator had no authority to sign. The project paused for nine weeks while three separate church elders reviewed the model card.

That delay is invisible to a token-cost model. The original SaaS vendor had already absorbed the liability through its master service agreement with the denomination. Self-hosting transferred the liability back to the local church without transferring the legal staff needed to carry it.

The same pattern appeared at scale on a large sermon-manuscript platform. Pastors uploading sermon manuscripts wanted the AI assistant to cite only their own prior messages. The open model could not be constrained to that corpus without an on-premise vector store that the volunteer upload workflow never contemplated. The cost comparison therefore compared list prices while ignoring the new storage tier, the new access-control service, and the new audit log that the permission boundary demanded.

The hidden cost of keeping the coordinator in the loop

Every ministry workflow that touches personal data still routes through a human coordinator who holds the actual consent. When an agent summarizes prayer requests, that coordinator must review the output before it reaches the small-group leader. The review step adds latency that the inference call itself never captured in its pricing sheet.

Teams that moved to sovereign instances discovered the coordinator’s time became the new scarce resource. One mid-sized church network reported that the AI summary saved 14 minutes of drafting but added 22 minutes of coordinator review because the model occasionally surfaced names the original request had left anonymous. The net effect was negative, yet the inference bill showed only the cheaper token rate.

The permission holder is rarely the person who pays the cloud invoice. In volunteer-driven products the permission holder is the person whose name appears on the consent form, and that person has no line item in the engineering budget. Sovereign compute does not remove the need for that review; it merely moves the cost from a vendor line to an internal labor line that never appears in the original ROI model.

When sovereign compute actually changes the ministry outcome

Sovereign setups delivered value only when the constraint was data residency required by denominational policy rather than cost. One network required that all counseling notes remain inside servers physically located in their country because national privacy law treated pastoral conversations as protected health information. In that case the higher per-token cost was irrelevant; the system could not have run on any foreign SaaS provider without violating the polity document.

The same logic applied to a children’s curriculum product that stored parent contact data under a promise never to share it with third-party processors. The team stood up a small sovereign instance solely to satisfy the promise, then measured retention of volunteer users rather than token spend. Retention rose because the privacy commitment could be stated without qualification. The inference bill was higher, yet the product metric that actually moved was the one tied to the original constraint.

Outside those two conditions, the move to sovereign compute simply replaced one set of hidden coordination costs with another. Most ministry teams optimizing for token price were therefore solving a problem that did not exist at the scale or sensitivity level their data actually required.

Your Turn: Apply This Today

• Pull the last 30 days of agent logs for the workflow that summarizes volunteer-submitted curriculum and list every field that contains a name, church identifier, or prayer request.
• Identify the single person who must sign the consent form for that data category and schedule a 20-minute call with them this week to confirm the current sharing boundary.
• Export the actual inference line item from your cloud bill for that workflow and add a second column that estimates coordinator review minutes at their loaded hourly rate.
• Run one controlled test where the same prompts route through the current SaaS provider versus a small sovereign instance and record both token cost and end-to-end cycle time including human review.
• Document the exact policy clause that would be violated if the data left the current boundary, then note whether that clause changes under either hosting option.
• Present the combined cost and policy table to the product owner before the next sprint planning so the decision incorporates the permission holder rather than the token price alone.

The Agent That Kept Running the Schedule While No One Was Watching and Faster Code Does Not Move the Real Ministry Bottleneck both examined similar gaps between what the logs recorded and what the ministry actually required.

I consult with ministry product leaders on agent workflow audits, permission boundary mapping, and sovereign model decisions. Let’s talk.

I kept a running note in my task list for most of 2023 that read “evaluate AI tooling after Q3 metrics stabilize.” The note sat there untouched while two other teams inside the same organization shipped their first working prototypes in June. By the time our group finally opened the same tools, the core questions about user flow and content priority had already been answered without us. The real loss was not speed. It was that we no longer held the right to decide which problems counted.

Solomon’s judgment offers the clearest picture of what happened. The king did not ask which woman deserved the child. He proposed cutting the child in half and watched who refused the division. The test revealed ownership by who would rather lose the outcome than accept a broken version of it. The same test now applies to AI tooling. Teams that treated the tooling as optional were willing to let the product be split between “human work” and “machine work.” Teams that refused the split ended up shaping the actual direction.

That refusal is what I missed for two full years.

The decision point I missed while watching other teams ship

The first clear signal came during a children’s curriculum update cycle. One small group started feeding draft lesson outlines into an early model and then editing the output in under an hour. They kept the same volunteer-facing print layout we had always used, but the revision loop moved from three days to one. I watched the change in their completion rate numbers and filed it under “interesting experiment.”

Six months later their version of the flow became the default template for every new release. The change was not announced as a strategy shift. It simply arrived as the baseline. Our own team was still running the old three-day cycle and defending it with notes about quality control. By the time we tried to match their speed, the template decisions had already been locked in by the group that had treated the model as part of the same desk.

The pattern repeated on a larger content platform. A three-person pod began routing incoming support tickets through a lightweight classification model before any human read them. They did not wait for an official integration project. They just stopped routing every ticket the old way. Within eight weeks their backlog showed a different shape: fewer generic “how do I find this passage” tickets and more specific questions about print formatting for small-group leaders. The rest of us kept triaging the old way and wondered why our metrics looked unchanged.

How the model outran the person still signing off

Solomon’s test works because it forces the question of who will accept a divided outcome. In product work the divided outcome looks like one person signing off on requirements while another person runs the model that actually generates the first draft. The signer keeps the title. The model runner keeps the working version. Over time the working version drifts from the signed requirements because the model learns faster than the approval cycle.

I saw this most clearly on a volunteer resource project. The person responsible for final approval still required every new children’s lesson to pass a manual review checklist. Meanwhile a neighboring team had the model generate three variations of the same lesson, ran them with five real volunteers, and kept only the version that produced the highest completion rate. The approved checklist never changed. The actual lessons that reached volunteers did change, and they came from the team that refused to keep the work split.

The cost shows up in ownership. When the model produces the first usable artifact, the person who still signs the old document no longer controls which problems get solved. They only ratify a direction someone else has already tested.

The small teams that gained leverage by treating it as infrastructure early

The teams that moved earliest did not treat AI as a research project. They treated it as part of the same infrastructure that already included version control and the print export script. One ministry pod added a single rule to their weekly planning: every new feature ticket had to include one model-generated variant before the first human edit. The rule took fifteen minutes to write and two weeks to normalize. After that the discussion in planning meetings shifted from “what should we build” to “which of these three variants survived real use.”

Another group applied the same approach to search relevance on a large Bible platform. They stopped waiting for the next quarterly model update and instead ran small daily experiments on query classification. The experiments were not announced as AI work. They were just part of how the team kept the search results usable for users who arrived with a single verse reference and no context. Within four months the relevance numbers moved more than they had in the previous year of larger, slower projects.

These teams did not have more budget or more headcount. They simply stopped accepting the split between the tooling and the rest of the work.

Your Turn: Apply This Today

• Take the next feature ticket on your backlog and generate three model variations of the user flow before the first planning discussion.
• Run one of those variations with three actual users this week and keep only the version that produces a measurable completion improvement.
• Change the definition of “ready for review” on your team to require at least one model-assisted draft already tested.
• Pick the single metric you report most often and re-run last month’s numbers using an AI-assisted classification of the underlying tickets or lessons.
• Block thirty minutes on Friday to delete any internal process step that exists only to move work between a human and a model without adding user value.
• Write down the next approval meeting on your calendar and require the meeting owner to bring one live model output instead of a slide deck.

The teams that kept the tooling optional for another year handed the real decisions to groups that refused the split. Two of those groups now set the baseline for the products I work on most often. The posts “The Agent That Kept Running the Schedule While No One Was Watching” and “Faster Code Does Not Move the Real Ministry Bottleneck” trace what happened next in both cases.

I consult with product leaders and ministry technology teams on AI tooling integration, decision ownership, and treating models as core infrastructure. Let’s talk.

The coordinator’s phone lit up on the kitchen counter just after eleven forty. A single vibration, then the screen filled with the thread. Three automated reminders had gone out that evening to the family whose six-year-old was admitted two days earlier. The mother’s reply sat at the bottom, short and final: please stop texting us.

I stood there while the coordinator read it aloud. The room stayed quiet except for the low hum of the laptop still open on the table. The scheduler agent had done exactly what it was built to do. It checked the list, saw the names, and followed the cadence rule without pausing for any new information.

That single exchange exposed the gap. Automation treated the schedule as a fixed list of tasks. It had no way to register that a family had moved from routine attendance to crisis. The agent kept operating on yesterday’s data because nothing in its workflow required a human to confirm the context still held.

John Wesley’s first rule, do no harm, was meant for people making decisions under pressure. It forces a pause before action when the outcome might wound someone already hurting. The same logic applies to agents that touch real lives. Without an explicit checkpoint, the system defaults to motion instead of mercy.

The missing rule shows up whenever an agent crosses from logistics into personal contact. Reminders, follow-ups, and status updates all carry relational weight in ministry settings. The agent cannot weigh that weight on its own.

The missing rule that turns helpful automation into intrusion

Wesley’s rule does not ask for perfect foresight. It asks whether the next action risks harm before it is taken. An agent that sends messages without fresh confirmation has no mechanism to apply that test.

In practice this means every automated outreach that touches a person’s current life situation must stop at a human gate. The gate does not need to be complex. It only needs to surface the proposed action and the current known context so a coordinator can say yes or no in under thirty seconds.

How oversight checkpoints actually look in live ministry systems

One team built a simple queue that surfaces every scheduled message twenty-four hours before it leaves. The coordinator sees the recipient name, the message text, and any recent notes attached to that household. A single click approves or holds. Messages that sit unapproved for the full window are dropped rather than sent.

Another group added a context tag that travels with each record. When a hospitalization flag is added, the agent automatically routes every future reminder into the same review queue and marks it high priority for the coordinator. The tag stays until it is manually cleared. No additional rules engine was required.

These checkpoints mirror how volunteer workflows already function. A children’s ministry director does not hand a new volunteer the full roster without a quick check-in. The same pattern now applies to the agent.

The cost of catching the problem only after it reaches the end user

When the message lands with the family first, the coordinator loses the ability to repair the relationship on their own terms. The damage is already public inside that household. Trust erodes faster than any dashboard metric can capture.

Teams that discover the error only through complaints spend the next weeks rebuilding credibility one conversation at a time. The original time saved by the agent disappears inside those recovery hours. Retention among both volunteers and families drops when the system feels careless rather than attentive.

The fix is never retroactive. Once the message is sent, the only remaining option is apology.

Your Turn: Apply This Today

• Pick the next agent workflow you plan to ship and list every point where it would contact a person without fresh approval.
• Add one explicit review gate at the first contact point and make the queue visible only to the actual coordinator who owns that list.
• Set the default action to hold rather than send when the gate is not cleared within the defined window.
• Run the workflow against last month’s real schedule data and walk through each queued item with the coordinator in a single fifteen-minute session.
• Log every override or hold decision for two weeks and note which context tags would have prevented the original error.
• Remove the gate only after the coordinator confirms it adds no measurable delay to their normal morning routine.

The same oversight pattern appears in both The Permission Gate That Kept the Agent From Running the Schedule and The Context Window That Only Closed When a Real Coordinator Sat Down.

I consult with ministry technology leaders on autonomous agent design and human oversight protocols in scheduling systems. Let’s talk.

Someone recently asked me why an AI-assisted refactor that produced working code in two days still sat untouched in review for seven more. The answer is straightforward: the generation step solved the smallest slice of the problem. The remaining work—confirming the change against real usage, routing the right approvals, and updating the surrounding systems—still moves at human speed.

This is the foundational misread that causes product teams to celebrate velocity they cannot actually ship. When the diff appears quickly, teams assume the bottleneck has moved upstream into creation. In practice the constraint simply relocates to verification and coordination.

Teresa Torres’s continuous discovery framework makes the distinction clear. Discovery is not a phase that ends when code is written; it is the ongoing work of checking whether the proposed change still matches user needs, risk tolerance, and operational reality. AI accelerates the proposal. It does nothing to shorten the loop that tests whether the proposal holds up.

Why the generated diff is only the first 20 percent of the work

The two-day refactor touched a payment reconciliation module used by volunteer coordinators who run monthly reporting for small churches. The model produced clean, idiomatic updates to the query logic and added the missing null checks. On the surface the task looked finished.

What the model could not do was run the change against the last six months of actual reconciliation exports those coordinators keep in shared drives. Those exports contain the edge cases—duplicate donor IDs, currency conversions entered as text—that never made it into the test suite. Someone still had to pull the files, replay them, and confirm nothing broke before the change could move forward.

Continuous discovery treats this verification as first-class product work, not cleanup. The team that shipped the change eventually spent three additional days constructing a one-off script to replay the real exports. That script became the permanent regression check the original refactor had omitted.

The coordination tax that appears once code moves faster than review

Once the diff existed, four people needed to sign off: the staff engineer who owned the billing service, the ministry operations lead who understood how coordinators actually used the reports, the volunteer who maintained the print templates, and the part-time contractor who handled month-end data hygiene. None of them worked on the same calendar.

The engineer reviewed the same afternoon. The operations lead asked for a walkthrough two days later because she was traveling to a regional training. The volunteer needed the change described in a short Loom because he only checked email on Tuesdays. The contractor flagged a downstream field mapping that would affect his monthly cleanup script. Each handoff added latency that no amount of generation speed could compress.

Torres would call this the discovery loop becoming visible. The faster the code arrives, the more obvious it becomes that the organization has no standing rhythm for these conversations. Teams that treat verification as an afterthought simply accumulate calendar debt.

How ministry product teams already handle this without formal methods

Ministry teams have long worked with volunteers whose availability is measured in hours per week rather than hours per day. They already route changes through a short, explicit checklist: does the update still produce the printed report the volunteer needs, does it preserve the export the bookkeeper downloads, and does the person who will run the next cycle know the change happened.

These checklists are continuous discovery in practice. They force the proposer to name the exact artifacts and people required before any code is considered ready. When an AI refactor lands, the same checklist simply gets applied to the new diff instead of being skipped because the code “looks done.”

The teams that absorbed the two-day refactor most cleanly already kept a one-page living document titled “What must still work after any change to reporting.” Updating that document became the first verification step rather than the last. The remaining sign-offs then moved in days instead of weeks because the criteria were already written down.

Your Turn: Apply This Today

• Pick one small refactor you have been considering for an internal tool and run it through an AI coding assistant this week; commit only the generation step and nothing else.
• Immediately after the diff appears, list every person and artifact that must be checked before the change can ship; write the list in the pull request description before requesting any review.
• Schedule the first verification conversation within 24 hours of opening the pull request, even if the reviewer has not yet looked at the code; treat the meeting as discovery, not approval theater.
• Document the exact steps you took to replay real data or usage against the change; turn those steps into a reusable check that lives alongside the test suite.
• Track the elapsed time between generation and final sign-off for this single change; note which steps consumed the majority of calendar days rather than active work hours.
• Share the timing breakdown with one other product person on your team so the next refactor starts with the verification path already mapped.

See also The Context Window That Only Closed When a Real Coordinator Sat Down and The Permission Gate That Kept the Agent From Running the Schedule.

I consult with ministry product leaders and faith-tech PMs on AI refactor verification, continuous discovery loops, and coordination patterns that keep small teams shipping. Let’s talk.

I assumed a three-person pod augmented with the best available agents could ship reliable product increments without a fourth set of eyes. The assumption came from watching other small teams move fast in enterprise tools and ministry platforms. In practice the pod released a curriculum update for volunteer leaders that carried mismatched age-group tags across print and digital versions. The mismatch surfaced only after hundreds of churches had already printed materials for the quarter. The cost showed up in support volume, lost trust with volunteer coordinators, and two weeks of emergency fixes that pulled senior engineers off roadmap work.

That experience exposed the real limit. Smaller teams do not automatically gain leverage from AI by shrinking headcount. They still carry coordination work that does not disappear when routine tasks are automated. Charlie Munger’s latticework of mental models makes the pattern visible. One model shows incentive misalignment: the pod optimizes for output velocity while verification sits outside any single person’s measured goals. Another model tracks second-order effects: when routine coding and drafting shrink, senior contributors absorb more context-switching and cross-checks that used to be distributed.

The latticework also surfaces the model of scale. Coordination load does not track lines of code or tokens processed. It tracks the number of distinct decision points that must stay consistent across people, agents, and downstream users. Treating verification as optional overhead ignores that model.

The model that treats verification as overhead

Most pods describe their AI setup as removing repetitive checks. The agents draft, the humans review once, and the release happens. This framing collapses verification into a single step rather than a distributed property of the system. Munger’s approach forces the opposite view: verification is an ongoing cost that must be assigned explicitly or it migrates to the most senior person on the team.

In one observed case the pod used an agent to generate volunteer lesson outlines from existing sermon notes. The agent handled tone and length well. It did not maintain consistent scripture references across the three age bands the product served. The single human review caught obvious mismatches but missed the pattern because the reviewer had already internalized the source material. The error only appeared when a children’s director printed the materials and found the middle-school version referencing a passage the preschool version omitted.

The misread here is simple. The team modeled verification as a final gate rather than a persistent cross-check distributed across roles. Once that model is corrected, the fourth set of eyes becomes a deliberate assignment instead of an assumed safety net.

How senior ICs actually spend their time once routine work disappears

After agents absorb drafting and basic QA, the remaining work for experienced contributors shifts toward reconciliation. They reconcile conflicting outputs from multiple agents. They reconcile the product’s data model with the constraints of print-first users who cannot receive updates after distribution. They reconcile the pace of one volunteer’s planning cycle with the cadence the platform now pushes.

This shift is rarely logged as coordination time. It appears as individual deep work. In reality the senior IC is performing the latticework manually: holding the mental models of user constraints, technical limits, and agent behavior in tension at once. When that work stays invisible, the pod slowly loses capacity for new feature development because the experienced people are fully occupied keeping existing flows coherent.

The hidden coordination layer that still scales with headcount

Even at three people the coordination surface grows with each new agent or data source added. Each agent introduces its own context window and failure modes. Each new data source requires someone to decide which version becomes authoritative when they diverge. The surface does not shrink when headcount is low; it simply concentrates on fewer shoulders.

One ministry platform team added a scheduling agent to handle volunteer reminders. The agent needed access to the same curriculum metadata the human designers used. No one owned the mapping between the agent’s reminder logic and the print deadline the volunteer actually followed. The result was reminders sent after the print window had closed. The fix required a human to insert a manual gate that the original three-person pod had assumed the agent would manage. The gate still exists because the coordination rule was never assigned to a specific owner.

Your Turn: Apply This Today

• Map every recurring handoff in your current pod’s workflow on a single shared document, including steps currently handled by agents, and mark which person or role owns consistency for each one.
• Pick the three handoffs that have produced the most recent defects or rework and assign an explicit owner who is not the same person doing the originating work.
• Schedule a 30-minute weekly review where the owner reports only on whether the assigned consistency rule held, without discussing new features.
• Remove one agent-driven step that currently lacks an assigned human verifier and replace it with a manual checkpoint for the next two releases to measure the actual time cost.
• Document the second-order effect of each agent you rely on by writing one paragraph on what breaks when that agent’s output diverges from the rest of the system.
• Identify the senior IC who spends the largest share of time on reconciliation and surface that time in the next planning session as coordination load rather than individual capacity.

The same coordination visibility problem appears in different forms across the posts on context windows that close only with a real coordinator and permission gates that keep agents from running schedules. Both show how unassigned overhead eventually surfaces as lost time or broken trust.

I consult with product leaders building AI-augmented tools for ministry on coordination overhead, verification models, and small-team scaling. Let’s talk.

The “master voice document” framework pushed in most product playbooks, from requirements templates popularized by product leaders like Marty Cagan to the Notion template libraries that circulate in every ministry tech Slack, collapses once a reorg changes who actually holds approval power. The advice treats the file as a finished artifact that new teams inherit and apply. In practice the file sits untouched while the children’s ministry volunteer still prints the wrong lesson plan because the instructions never recorded the exact permission shift that happened in the last budget meeting.

This approach assumes clarity travels through publication. It does not. The file compounds confusion instead of value because no one returns to it after the handoff that actually mattered.

The result is a common misread: teams believe a persistent file earns its keep by surviving the initial write. In reality the file only stays useful when every real-world change gets tested against the same three filters John Wesley used for his own movement. Do no harm. Do good. Stay in love with God. Applied to a markdown file, these become questions about whether an instruction creates confusion for the next person who must act, whether it improves the outcome for the end user, and whether it keeps the work aligned with the actual mission rather than the last org chart.

Write the first version from a single observed failure

The first version of any persistent file should come from one concrete breakdown you watched happen, not from a general desire to document process. At one children’s curriculum ministry, a volunteer finished a 45-minute setup only to realize the lesson file assumed the church had already moved to the new curriculum platform. The failure was not the platform itself. It was the missing note that the transition required a one-time override from the children’s director before any volunteer could print.

That single observation became the seed paragraph in the file. Everything else followed from it. The paragraph described the exact email chain, the permission that was missing, and the two-minute fix that would have prevented the delay. No other history entered at this stage.

Starting here keeps the file short enough that the next person actually reads it. Starting from a template or a previous version bloats the document with rules that never caused a real problem in your context.

Force the file through the three-rule filter after each change

After every handoff the file must pass through the same three questions. First, does this instruction create any confusion that could harm the person who has to act next? Second, does it actively improve the outcome for the volunteer or the family using the resource? Third, does it keep the decision tied to the mission rather than to whoever currently holds the title?

In one reorg the curriculum team added a new review step that required the senior pastor to sign off on every children’s lesson. The file recorded the step. Then the filter removed it. The step created harm by slowing release by ten days. It did not improve the lesson quality. It only protected a title. The paragraph stayed out.

Running every edit through these questions turns the file into a living record of what actually survived contact with real authority. Without the filter the file slowly fills with the preferences of the last person who held power.

Delete anything that did not affect a real permission gate

Most voice files accumulate paragraphs that describe tone or audience but never decided who could release the next version. Those paragraphs go. If a sentence never changed who had to approve or who could override, it did not earn its place in the file.

One ministry kept a long section on “warm and accessible language for families.” The section never altered a single permission gate. It stayed decorative. After the third reorg the section disappeared. In its place the file now holds the one sentence that actually mattered: the children’s director alone can approve a print override when the platform update lags.

Deletion keeps the file short enough to matter during the next crisis. Retention of unused language turns the file into another ignored archive.

Your Turn: Apply This Today

• Identify the single handoff you observed in the last four weeks where verbal instructions caused a delay and write the exact failure into a new or existing markdown file before Friday.
• Run every existing paragraph in that file through the three questions this week and delete any line that never changed a permission.
• After the next team meeting, add one new paragraph that records the actual override or approval that occurred and note who held the gate.
• Schedule thirty minutes next Monday to test whether the updated file prevents the same failure for the person who will use it next.
• Remove any section that describes general tone or audience unless it directly names who must approve when that tone conflicts with a new requirement.
• Share the revised file with the one person who will inherit the next reorg and ask them to mark the first sentence that would have confused them.

The same discipline that kept one voice file intact through three ministry changes also shows up in how we track real retention for volunteer tools and how we decide which AI instructions survive contact with actual users.

I consult with ministry product leaders and faith-tech PMs on building persistent documentation systems and applying mission filters to AI instructions. Let’s talk.

Most teams racing to adopt AI for faster code generation are optimizing the part of the process that least determines whether the final product serves its intended users. The bottleneck was never raw output speed. It sits in the handful of inputs that still require a human to score before any generated work can be reviewed.

Teresa Torres built continuous discovery around the idea that product teams must keep live contact with the opportunity space rather than batching assumptions into long development cycles. When AI multiplies the volume of code or content produced, the same principle applies but inverted: the inputs themselves must be locked and validated first. Without that step, teams simply generate more of what they already misunderstand.

This pattern shows up in ministry tooling whenever an engineering group adds an LLM step to an existing workflow. The volume of pull requests rises. The time from ticket to merge drops on paper. Yet the handoff to content reviewers or volunteer testers still stalls on the same three questions that existed before the model was introduced.

Identify the three inputs that still need human judgment

The first input is the problem statement framed as a user outcome. In a curriculum tool, this might be the exact constraint a volunteer faces when preparing a lesson in seven minutes on a phone. AI can expand that statement into code, but only a person who has watched the volunteer actually work can confirm the outcome is stated correctly.

The second input is the definition of done for any theological or pastoral alignment check. A generated component that handles scripture references must still pass a human filter on whether the references respect the intended teaching emphasis. Torres would call this an explicit opportunity, not a solution detail. The filter cannot be automated without first freezing the criteria in writing.

The third input is the edge-case description for the least technical user. Ministry products routinely break when a user lacks admin rights, reliable internet, or comfort with digital forms. These descriptions must be written by someone who has observed real failure modes, then locked before generation begins.

Once these three inputs are captured and signed off, generation can proceed at any speed. The human scoring step happens once, upstream, rather than repeatedly during review.

Shift review effort to automated verification on those frozen inputs

With the inputs fixed, automated checks can run against them instead of against the generated output. A simple script can confirm that every new component references the approved outcome statement. Another can flag any code path that touches scripture data without the pre-approved alignment criteria attached.

The remaining human review then narrows to two questions only: does the output still satisfy the frozen inputs, and has anything changed in the live user context since the inputs were locked? Both questions are cheaper to answer than re-evaluating the entire feature from scratch.

Teams that adopt this pattern stop treating every PR as an occasion for fresh discovery. Discovery work moves earlier and happens less often, which is exactly what Torres observed in high-performing product groups.

Measure time saved at the handoff point, not at generation

Generation time is easy to instrument and therefore tempting to optimize. The real constraint appears at the moment a reviewer or ministry partner first sees the work. That handoff point is where accumulated misunderstandings surface.

One team building volunteer scheduling features tracked the interval between PR creation and the first external reviewer comment. After freezing their three inputs, the interval dropped by more than half even though raw generation time stayed roughly the same. The reviewers no longer had to reconstruct the original intent; they only had to verify it still held.

The metric forces the team to keep the frozen inputs visible and current. When the inputs drift, the handoff interval lengthens again, giving an early signal before users ever see the product.

Your Turn: Apply This Today

• Pick the engineering workflow that produces the most reviewed artifacts this month, such as new components for a children’s ministry scheduling tool.
• Write the three frozen inputs for that workflow in a shared document before the next ticket is started.
• Add an automated check in the repository that fails any PR missing a reference to the frozen problem statement.
• Run the next PR through the checkpoint and record the exact time from merge request to first external reviewer reply.
• Compare that interval against the average from the previous three PRs in the same workflow.
• Adjust one of the three inputs based on what the comparison reveals and repeat the checkpoint on the following PR.

Two earlier posts on the blog explored how continuous discovery habits transfer to ministry product teams and why opportunity framing beats feature velocity when the users are volunteers. I consult with product leaders building ministry tools on continuous discovery practices, frozen-input checkpoints, and measuring handoff time in AI-assisted workflows. Let’s talk.

Dear Ministry PM who inherited the AI volunteer coordination tool three months after the last lead walked out,

You know the Slack thread is still pinned at the top. The one where the old captain said “we’ll figure out the override rules once the model is live.” You also know the model is live now, and every Tuesday morning three different regional directors are asking why their local kids ministry leads can’t book a room without going through a central queue that no one owns.

That handoff never happened. Not the real one. The one with the frozen inputs, the named signers, and the explicit permission gates. What you got instead was a deck and a login.

This is the foundational misread that causes ministry product teams to decentralize authority without ever building the lattice that makes decentralization work. Charlie Munger’s latticework of mental models only produces better decisions when every node carries explicit constraints and cross-checks. Remove the constraints and you simply multiply the number of people who can approve something without ever seeing the downstream cost.

Map every captain decision to an actual signer

The first place the lattice breaks is when a model output is treated as a completed action rather than a proposed one. On one curriculum platform, an AI tool started auto-generating lesson assignments for volunteer teams. The model had learned from three years of historical data that certain age groups preferred shorter videos. What it had not learned was that one region’s volunteer coordinator had a standing agreement with a local printer for paper versions only. The first time the system pushed digital-only assignments, three churches printed their own copies at their own expense and the coordinator spent the next week fielding complaints.

The fix was not more model training. It was naming the exact person who still held physical permission to change the output format. Once that signer was written into the workflow, the model could suggest, but the assignment only moved forward after the signer confirmed the input constraints had not changed. The queue disappeared because the constraint was now visible and owned.

The same pattern shows up in room booking tools. When the AI proposes a time slot, someone must still be the signer who confirms the room is not already reserved for a funeral or a food pantry distribution that never appears in the shared calendar. Without that named signer, every “autonomous” suggestion eventually lands back in the same review queue, only now the queue is larger and the original captain is gone.

Build the knowledge OS around what cannot be regenerated

Munger’s lattice requires models that cannot be rebuilt from public data alone. In ministry settings the irreplaceable pieces are almost always local relationships and physical constraints. A volunteer’s willingness to teach only on weeks when her husband is not traveling for work cannot be regenerated from usage logs. A church’s rule that the nursery must stay empty during the 8 a.m. service because the carpet is being cleaned cannot be inferred from click data.

The knowledge operating system therefore has to store these constraints as first-class objects, not as footnotes. One team created a simple shared table that every AI suggestion had to query before generating an output. The table contained only three columns: constraint description, current signer, and last verified date. Anything not in the table was treated as unknown and therefore blocked. The model’s suggestions dropped by half, but the acceptance rate on the ones that remained rose sharply because they no longer violated unstated local rules.

Without this layer, decentralization simply accelerates the rate at which bad suggestions reach volunteers. The lattice collapses because the missing nodes are the ones that actually determine whether an action is permissible.

Run the first three loops with the handoff log visible

The first time a new captain runs the system, the handoff log must be public. Not summarized, not archived, but sitting in the same interface where decisions are made. In one deployment the team kept a running document that listed every override, who made it, and what constraint had been missed. After three weekly cycles the document revealed that two regional directors were overriding the same constraint for different reasons. One needed the room for a food distribution that only happened on odd weeks; the other needed it for a counseling appointment that could not be moved. Once both reasons were visible, the model input was updated to treat those weeks as blocked, and the overrides stopped.

Visibility also surfaces when the original captain’s mental model was simply wrong. The log becomes the place where the new captain can see the difference between “this rule was never documented” and “this rule was documented but no longer holds.” Without that distinction the team keeps re-learning the same exceptions at higher speed.

Your Turn: Apply This Today

• Pick the single AI-generated workflow your volunteers interact with most and list every decision the model currently makes without a named human signer.
• For each decision, identify the one person who still holds physical authority to block or alter the output and add that name to the workflow definition this week.
• Create a shared constraint table with only three columns—description, signer, last verified date—and require the model to query it before any suggestion is shown.
• Run the next three decision cycles with a visible handoff log that records every override, the reason given, and the constraint that was missed.
• After the third cycle, update the model inputs with any constraints that appeared more than once in the log.
• Schedule a 30-minute review with the actual signers to confirm nothing in the table has changed since the last verification date.

The same lattice problems appear when AI tools are applied to sermon preparation and children’s ministry resource distribution; the posts on those topics show how the missing permission gates surface in different places but for the same structural reason.

I consult with ministry product leaders on mapping decision signers, building knowledge operating systems around local constraints, and running visible handoff loops in AI deployments. Let’s talk.

You open the folder Monday morning and the count is already at fourteen. Fourteen pieces the model generated between Friday night and now—each one clean, each one needing the same two sets of eyes that have always carried the weight. One of those eyes belongs to the guy who still teaches the 7 a.m. Bible study; the other belongs to you.

Nobody on the team feels faster. The calendar just feels heavier.

One pilot involved sermon prep for a multi-site church. Pastors generated opening illustrations in bulk. Review time tripled because each illustration required a quick check for doctrinal alignment and a second check for stories already used in the same series. One pastor noted the verification step now consumed the slot previously reserved for prayer and reflection before final edits.

Another pilot targeted volunteer onboarding packets. Generation of welcome scripts moved from days to hours. The volunteer coordinator then spent an unexpected afternoon reconciling the new scripts with the existing print-first formatting rules that had been refined over three years. The time saved on creation reappeared as formatting corrections and one extra round of printer proofs.

Each case followed the same pattern: the generation step shrank while the verification and integration steps expanded at roughly the same ratio.

Latticework view of where generation meets sign-off

Charlie Munger’s latticework approach requires holding several mental models at once rather than optimizing a single variable. Applied here, the models include queueing theory, incentive misalignment, and the difference between local and system throughput. Faster generation improves the local metric of draft completion. It degrades the system metric of finished, approved assets ready for volunteers.

Queueing theory shows that adding work to a constrained reviewer creates backlog faster than linear models predict. Incentive misalignment appears when the person praised for producing more drafts is not the same person who absorbs the review cost. The local gain registers; the system cost stays hidden until retention or burnout metrics move.

Munger would also note the second-order effect on judgment quality. When reviewers face stacked queues, they default to surface checks rather than the deeper cross-references that previously caught subtle issues. The latticework therefore points to redesigning the handoff itself, not celebrating the generation speed.

Metrics that track the full loop instead of just generation

Most dashboards still report “drafts produced” or “tokens generated.” These numbers rise while the date an asset reaches the volunteer inbox stays flat or slips. Replace or supplement them with cycle time from prompt to approved asset and with reviewer hours per approved asset. Both numbers expose the actual constraint.

Add a third metric: percentage of generated content that survives first review without revision. Low survival rates indicate the generation step is producing volume that still requires heavy human correction. Track this weekly on one workflow before expanding.

Finally, measure downstream volunteer completion rate on the delivered material. If faster production leads to lower volunteer follow-through because the content feels less tailored, the speed gain has created a new problem rather than solving an old one.

Your Turn: Apply This Today

• Pick one AI-assisted workflow that currently ends at “draft generated” and add a timestamp field for the moment the first human reviewer opens the file.
• Log the exact minutes spent on theological alignment, formatting, and final sign-off for the next ten items that move through that workflow.
• Calculate the ratio of generation time to total review time and post the number where the team can see it each Friday.
• Identify the single reviewer who absorbs the largest share of verification work and block two hours on their calendar next week labeled “no new drafts.”
• Change the success definition in the next sprint from “ten new drafts created” to “six assets approved and formatted for print.”
• Run the same workflow for one more week while recording the survival rate of first drafts after initial review, then adjust the prompt template based on the patterns that fail most often.

Two earlier posts on this blog examined similar constraints: The Context Window That Only Closed When a Real Coordinator Sat Down and The Burnout Number Managers Still Ignore Until Retention Breaks.

I consult with ministry product leaders on AI workflow instrumentation, verification loops, and adoption metrics that reflect full human effort. Let’s talk.

I stood at the back of the fellowship hall on a Tuesday night, watching the small-group leader flip through printed notes on her phone because the PDF from the agent never made it to her inbox in time. The questions were solid. They just didn’t reach the person who actually had to ask them.

That was the third prototype. The first two had already gone the same way—clean demos, then silence once real people had to carry the output across the actual week. I kept thinking the problem was the prompting or the chaining. It wasn’t.

The constraint was never the model. It was the handoff that happens between one person’s work and another’s lived responsibility, the same quiet transfer the church has always depended on.

Teresa Torres’s continuous discovery work makes the same point about product teams who interview users once and then build. The method only works when teams keep returning to the actual moments when someone accepts or rejects the work. In agent projects, that means mapping the exact gatekeepers and formats that determine use, not just testing prompt quality.

Where the fluency training stopped short

Our first prototype handled volunteer reminders. The agent pulled from a shared calendar, wrote personalized texts, and scheduled them. In the sandbox it looked clean. When we ran it against the actual Monday morning routine, the coordinator who approves every outgoing message still needed a printed list to cross-check against the physical sign-in sheet she carries. The agent never produced that list, so the texts stayed in draft.

Fluency had taught us to measure correctness of the reminder text. It had not taught us to measure whether the coordinator could complete her existing Monday checklist without adding new steps. Torres would call this an interview that stopped at the moment of delight instead of continuing to the moment of rejection.

The second prototype generated adapted curriculum for different age groups. The output passed every internal review. The volunteer who actually teaches the class works from a single printed page she receives on Wednesday night. The agent delivered a multi-page document inside a shared drive folder she does not open. Again, the output existed; the handoff did not.

How discovery loops exposed the real gates

We shifted to weekly fifteen-minute calls with the actual people who would receive the agent output. We asked only two questions: what arrives on your desk or phone the day before you need it, and what format lets you finish your current checklist without starting a new one. The answers were never about model performance.

One coordinator keeps a physical three-ring binder. Another volunteer opens email only on a shared church computer after evening events. A third person routes every schedule change through a single admin who updates a whiteboard. These were not edge cases. They were the operating system.

Continuous discovery turned these details into testable assumptions. Each week we adjusted the agent to produce the exact artifact that already fit the existing gate, then watched whether it survived the next handoff. Most versions failed the first live test. The surviving version for scheduling now outputs a single column of names and times that prints on half a page and lands in the binder.

Rebuilding the evaluation step around live constraints

We stopped scoring prototypes on prompt accuracy alone. The new rubric asks whether the output reaches the person who must act on it, whether that person can complete their existing task without new friction, and whether the next person in the chain receives what they expect. These three checks happen inside the actual workflow, not in a demo environment.

The change also altered how we chose which agent to build next. Instead of starting with the most technically interesting task, we now start with the narrowest permission gate we can observe. If the gate requires a printed page delivered by a specific person on a specific day, the agent must produce that page in that format or it fails the first discovery loop.

This approach surfaces constraints earlier and keeps the team from investing weeks in fluent but unusable systems. The cost of the earlier prototypes was not wasted compute. It was the months during which real scheduling and curriculum decisions continued without any agent support at all.

Your Turn: Apply This Today

• Pick one current AI workflow your team runs and list every person who must approve or receive the output before it reaches the end user.
• For each person on that list, note the exact format and timing they currently use to complete their part of the task.
• Run the agent once and deliver its output to the first gatekeeper exactly as they would receive it in a normal week; observe whether they can finish their step without extra work.
• Document the first rejection or workaround you see and adjust the agent to remove that single friction before testing the next gate.
• Repeat the loop with the same workflow until the output survives three consecutive live handoffs without modification.
• Write the permission and format requirements into the project brief before starting the next agent build.

The Permission Gate That Kept the Agent From Running the Schedule and Why Ministry Coordinators Still Ask Me About the Routing Step both trace the same pattern of fluent tools that never cleared the actual handoff steps.

I consult with product leaders in faith-tech and ministry organizations on mapping AI agent workflows against real permission gates and handoff constraints. Let’s talk.

She opened the laptop at the kitchen table after midnight. The schedule the agent had built for Sunday looked clean enough, except the two names were in the wrong places. She knew the story behind the swap. The system did not.

The fields were locked. No drag, no comment, no override. She stared at the blinking cursor, then shut the lid. Someone else would have to fix it in the morning.

The coordinator in this case held the final constraint. She alone knew which names could not appear together. The agent had optimized for coverage and availability, but those metrics never reached the hidden variable of family conflict. The lattice broke where the human authority began.

Products that treat the model as the complete system repeat this break. They optimize inside the training distribution and declare victory when the output looks reasonable on screen. The real work of coordination sits outside that frame, held by the person who signs the schedule and answers for it when something goes wrong.

The first section of any useful lattice must therefore include the person who owns the final yes. Without that node, the model cannot see the actual decision surface it claims to improve.

Munger’s approach forces product teams to keep adding frames until the real constraint appears. In practice this means asking what the coordinator must protect that no training data captures. It also means building the interface so she can act on that protection without leaving the tool.

One team I watched ran the agent output through a second review layer that required the coordinator to confirm or override any assignment. The override rate sat at 18 percent on the first week. Every override logged a constraint the model had missed. Over four weeks the team added three new signals to the prompt and the override rate dropped to 7 percent. The lattice had simply been extended one node further.

The same teams often ask the wrong questions when they run discovery. They ask the coordinator what she likes about the current schedule or how the agent could generate better first drafts. Those questions assume the model already holds the relevant variables. They rarely surface the constraints that live only in the coordinator’s head.

Better questions name the hidden keyholder directly. Ask what rule she applies in the final five minutes before she signs a schedule that no one else sees. Ask which names she has already mentally moved even though the agent has not. Ask what she would tell a new volunteer that the system would never know to record.

These questions turn the coordinator into the additional mental model rather than a reviewer of model output. They expose the permission gate that actually governs the work.

When the product surface exposes those gates, the coordinator can act inside the tool instead of outside it. The next loop then forms around her actual authority rather than around the agent’s next suggestion. The model receives the new constraint as input instead of requiring a separate correction step after the fact.

This changes the retention metric from schedule views to schedule sign-offs that required no external fixes. It also changes the discovery process from periodic user interviews to continuous logging of the constraints the agent still cannot see.

The coordinator who closed the laptop at 9:47 p.m. was not resisting the agent. She simply could not complete her real job inside the product that claimed to help her.

The lattice that stops at the model boundary

The model boundary creates a clean edge that feels complete inside the training data. Outside that edge sit the family conflicts, last-minute illnesses, and unspoken trust relationships that determine whether a schedule actually works. Munger’s lattice requires the product to treat those external facts as first-class nodes rather than exceptions.

Teams that stop at the model boundary measure success by how often the agent produces a usable first draft. They miss the second and third loops where the coordinator must still exercise her real authority. The lattice stays incomplete, so the product keeps optimizing the wrong surface.

Extending the lattice means logging every override as a new signal instead of a user error. It means treating the coordinator’s final yes as the training target rather than an afterthought. The model improves only when the product makes those signals visible and actionable inside the same interface.

Question types that reveal the hidden keyholder

Most discovery sessions ask coordinators to evaluate the agent’s output quality. That framing keeps the model at the center. The better framing asks what constraint the coordinator protects that the model has no way to observe. The difference moves the conversation from preference to authority.

One effective question is to request the last three schedule changes she made after the agent finished its work. Each change points to a variable the model missed. Another is to ask which names she would never assign together even if availability and skills matched perfectly. The answer usually reveals a relationship or history the product has no field for.

These questions treat the coordinator as the additional mental model Munger described. They do not assume the model already contains everything worth knowing. They simply make the missing node visible so the product can decide whether to capture it or route around it.

Designing the next loop around the person who still owns the final yes

The final yes remains with the coordinator because she carries the accountability when the schedule fails. Products that hide the edit surface force her to perform that yes outside the tool. The next loop then starts from a place of correction rather than from the constraint itself.

Interfaces that expose the decision points let her record the constraint at the moment she applies it. The model receives the signal immediately and the schedule improves on the next run. Retention improves because the coordinator finishes her actual job inside the product instead of working around it.

The design choice is simple: every override or manual swap must be one click from the agent’s output. Anything more than that keeps the lattice broken at the model boundary. The coordinator who owns the final yes must be able to act on it without leaving the surface the product provides.

Your Turn: Apply This Today

• Schedule a 30-minute session this week with the actual coordinator who signs the volunteer schedule. Do not show her any agent output first.
• Ask her to list the last three manual changes she made after any automated draft and record the exact reason for each change.
• Ask her to name the one rule she applies that no current field in the system can capture, then write that rule down verbatim.
• Log the three constraints that appeared during the session and map each one to a specific place in the current agent flow where it remains invisible.
• Build a one-screen override panel that lets her record the constraint at the moment she applies it, then feed that signal back into the next model run.
• Measure the number of schedules that require zero external corrections after the panel is live and compare it to the prior four weeks.

The Permission Gate That Kept the Agent From Running the Schedule and The Context Window That Only Closed When a Real Coordinator Sat Down both trace the same pattern of authority that lives outside the model.

I consult with product leaders building agentic scheduling and coordination tools on exposing decision points, logging real constraints, and running discovery with the people who still hold the final yes. Let’s talk.

You’re looking at a finished lesson at 11:42 p.m. The model wrote the whole thing—story, questions, craft, even the verse the kids are supposed to memorize. It took less than a minute. The only person whose name actually goes on it is two states away until Friday, and she still has to read every line before anything leaves the building.

The question isn’t whether the output is good enough. It’s what happens when the person who carries the weight isn’t in the room when the thing gets made.

Solomon’s old test still works. The one who refused to let speed settle the matter was the one who actually had something to lose.

This is the foundational misread that causes product teams to treat approval as a routing problem instead of a knowledge problem. When the model runs ahead of the person who carries the cost, the output simply waits in a queue that no one has capacity to review. The 7-minute volunteer then inherits the risk.

At one children’s curriculum ministry the real retention metric was never download volume. It was whether the volunteer finished the lesson and used it without having to improvise under time pressure. The same constraint applies to any agent that generates curriculum or service copy. Fluency at generation does not reduce the need for the one human who can say, without looking at a screen, whether the content will land in the actual room.

Systems thinking applied to one physical signature

Systems thinkers map every handoff. The signature is the last handoff, and it is still physical. It happens on a printed sheet, a PDF markup, or a verbal confirmation after the staff member has read the full set of changes against the names and stories they know. Every upstream agent that assumes this step can be parallelized or batched will eventually produce work that sits idle until that one person is available.

The constraint is not reluctance. It is capacity. One person cannot absorb the volume the model can produce while also carrying the pastoral load that justifies their authority in the first place. The system must therefore reduce the surface area of what reaches the signature, not increase the speed at which drafts arrive.

This matches the logic in Solomon’s judgment. The decision was never about who could claim the child fastest. It was about who would still be responsible after the claim was settled. In product terms, the signature is the point at which responsibility is accepted. Design everything else to make that acceptance possible in the time the signer actually has.

When the dashboard score and the room decision diverge

Dashboards track completion rates, generation time, and version counts. None of them capture whether the final version was usable in the room where the volunteer stood. A lesson can score 94 on every automated check and still require the staff member to rewrite the closing prayer because the model used language the church’s particular tradition avoids. The dashboard will never register that mismatch.

The person who signs off holds the memory of previous rooms and previous failures. That memory is not stored in the model weights and cannot be queried through a prompt. When the dashboard and the signer disagree, the correct signal is the signer’s refusal, not the dashboard’s score. Treating the refusal as noise is how teams erode the very authority they claim to respect.

The pattern repeats across ministry tools. The coordinator who has led the same group for three years will reject a perfectly formatted schedule because she knows two families will be traveling. The model cannot hold that fact. The dashboard cannot weigh it. Only the signature step can.

Your Turn: Apply This Today

• Pick the single approval step that still sits outside every agent loop in your current workflow and write the exact handoff rule that tells the agent what information must reach the signer and in what format.
• Block two 30-minute slots on the signer’s calendar this week labeled only “review window” and instruct the agent to hold all output until those slots rather than pushing drafts as they finish.
• List the three facts the signer must know that the model cannot access (recent pastoral conversations, family situations, last-minute room changes) and create a one-paragraph template the volunteer or coordinator fills before the output reaches the signer.
• Remove any automated “ready for signature” notification that does not include the name of the person who will actually be in the room and one constraint that person has already named this month.
• Run the next generated artifact through the 7-minute test: open it on a phone, give yourself seven minutes, and note every line that would require the signer to stop and ask a question. Rewrite the handoff rule to surface those lines first.
• Document the last three times the signer changed an agent-generated draft and turn each change into a standing check the agent must run before it reaches the signature step again.

The Permission Gate That Kept the Agent From Running the Schedule and Why Ministry Coordinators Still Ask Me About the Routing Step both trace the same pattern: authority remains with the person who will still be present when the work is used.

I consult with product leaders building faith-tech tools and ministry leaders running volunteer workflows on approval gates, signature timing, and dashboard versus room decision alignment. Let’s talk.

I hit the wall on a Tuesday afternoon when the new volunteer coordinator tried to update a single field in our shared dashboard. The 12-factor checklist said everything should be environment variables and stateless processes. Her machine said she lacked the right role.

We had followed every rule. Twelve clean factors, deployed the same way for three years. Then one person who prints the schedule by hand stepped into the flow, and the whole setup stopped matching reality.

That gap isn’t a config problem. It’s the moment the framework runs out of road.

Where the factors stop at the coordinator’s desk

At one children’s curriculum ministry we once tried to route volunteer sign-ups through an agent built on the usual twelve-factor assumptions. The agent could read the database, write to the queue, and emit clean logs. It could not see that the coordinator kept the final printed sheet in a folder she carried in her purse until the night before the event.

The agent kept writing updates that the coordinator never saw because the update path ended at her email inbox. She checked the folder first. The factor that said “treat logs as event streams” did not account for the fact that the decisive log lived on paper.

Teams keep running into the same wall. They optimize the parts the agent can reach and leave the final decision point outside the model. The agent looks reliable until the first week the coordinator is out sick and no one else knows the folder exists.

Discovery loops that never reach the keyholder

Teresa Torres insists on talking to the people who will actually use or block the output. In most agent projects the loop stops at the ministry director who requested the tool. It never reaches the volunteer who must initial the printed list before it becomes real.

That gap shows up in the data. Completion rates drop the moment the agent output must cross from digital to the person holding the pen. The agent keeps generating correct JSON while the actual schedule remains unchanged for days.

Repeating the interview with the keyholder changes the shape of the work. The question shifts from “How do we make the agent faster?” to “What single artifact must the agent produce that the keyholder will accept without re-entering the data?” The answer is almost never another API call.

Rebuilding the harness around actual permission boundaries

The fix is not to add more factors. It is to map the exact sequence of approvals that already exists in the room and attach the agent only to the steps it can legally touch. At one church the agent now writes a draft to a shared folder, then waits for the coordinator to move the file into the approved subfolder. Only after that move does the agent send the confirmation text.

The same pattern appears when agents try to update sermon resource pages. The system can suggest a new children’s curriculum block, but the final publish button stays behind the editor who still reviews every image for age-appropriate content. The agent records the suggestion and the editor’s decision in the same log, so the next discovery cycle has real data instead of guessed intent.

Teams that rebuild this way stop measuring agent success by lines of code or number of API calls. They track how many handoffs complete without the coordinator having to re-type anything. That single metric forces the design to respect the permission gate instead of routing around it.

Your Turn: Apply This Today

• Pick one agent workflow you shipped in the last quarter and list every human who must approve before the output becomes visible to volunteers.
• Shadow the final approver for one full cycle this week and note exactly which artifact they check first when they sit down.
• Change the agent’s output destination so it writes only to the folder or inbox that person already opens without being asked.
• Remove the agent’s ability to push any change past that single gate until the approver has moved or signed the file.
• Log the time between agent suggestion and approver action for the next ten instances and compare it to the time the agent spent generating the suggestion.
• Bring that timing data to the next planning meeting and adjust the next agent task to reduce the gap by half.

The Permission Gate That Kept the Agent From Running the Schedule and Why Ministry Coordinators Still Ask Me About the Routing Step both trace the same pattern of agents that stopped at the first real handoff.

I consult with faith-tech product leaders on mapping agent workflows to permission boundaries and running continuous discovery inside existing ministry approval chains. Let’s talk.

I sat at the island and watched the agent spit out another clean-looking schedule. Same mistake as the last run—someone’s name from the inactive list, dropped into the slot for the family whose kid was starting chemo.

The two coordinators didn’t say anything at first. One just tapped the screen. The other crossed the name out on paper. We’d already tightened every knob we knew. Still needed three people in the room to catch what the model kept missing.

I’d built the thing to run on its own. Turns out reliable meant something different once real lives were on the line.

Munger argued that isolated expertise creates blind spots. One mental model applied cleanly often fails at the edges. The fix is not more study by one person. The fix is a small overlapping set of models held by different people who review the same output together. In product work this means the technical fluency of the lead, the operational memory of the coordinator who knows which families are in crisis, and the calendar reality held by the person who actually books rooms. None of these three can substitute for the others when an agent produces the schedule.

The pod structure that turned fluent individuals into reliable output

The team started with one agent and three fixed roles. The lead handled prompt iteration and system constraints. The first coordinator held the volunteer roster and its hidden constraints: who had already said no twice, who needed a ride, whose availability changed after the database last synced. The second coordinator owned the final send step and the print fallback that most volunteers still preferred.

They met for twelve minutes after every agent run. The lead read the raw output aloud. The first coordinator flagged names the model had invented or resurrected. The second coordinator checked room conflicts the agent could not see because the church calendar lived in a different system. Only after all three cleared the list did anything reach volunteers.

Output errors dropped from one in three runs to near zero within two weeks. The lead later admitted the biggest gain was not speed. It was that she stopped carrying the full burden of catching edge cases she had never lived. The lattice worked because each person supplied a model the others lacked.

Where systems thinking alone missed the 11 p.m. grieving-parent edge case

One Tuesday the agent assigned a new volunteer to the infant room. The lead had built every policy check she could name: background check status, age minimum, training completion. The model passed them all. The first coordinator still rejected the assignment. She knew the volunteer’s own child had died the month before. No database field captured that fact.

Systems diagrams drawn in advance could not surface the information because the data never entered the system. The second coordinator added the quiet note that the volunteer had asked for exactly this role as a way to stay connected. The three-person check preserved both the safety rule and the human request. A single fluent practitioner working alone would have either overruled the parent or violated the policy without realizing the conflict existed.

How the three-person constraint became the actual quality filter

The team later tried expanding the pod to five people. Decision time doubled and the extra voices mostly repeated points already covered. They shrank it to two. The grieving-parent case slipped through on the first run after the cut. Three remained the minimum size that still covered the required models without adding coordination drag.

The constraint also forced clarity on what counted as high-stakes. Only one agent workflow received the pod treatment at first. Everything else ran with lighter review or none. The limit on people made the team ruthless about which outputs actually needed the lattice. That single decision protected coordinator time more effectively than any policy document.

Your Turn: Apply This Today

• Choose one agent workflow that touches real people this month and list the three distinct models required to review its output.
• Assign the roles by lived knowledge rather than job title: one technical, one operational memory, one final-send owner.
• Block twelve minutes on the calendar immediately after the next agent run and require all three to attend before anything ships.
• Print the raw agent output for the first two runs so the group can mark it by hand and notice what the screen hides.
• After four runs, write down the single category of error that only appears when all three people are present and remove that category from the agent’s prompt scope.
• Refuse to expand the pod past three until the current workflow runs clean for two full weeks.

The same pattern showed up in The Context Window That Only Closed When a Real Coordinator Sat Down and The Permission Gate That Kept the Agent From Running the Schedule. Both posts trace how small human overlaps fixed failures that additional model training never reached.

I consult with ministry product leaders and AI team leads on building minimal human review layers for agent workflows, applying lattice-style constraints to high-stakes outputs, and protecting coordinator time while raising reliability. Let’s talk.

I once watched an agent spin for fourteen minutes trying to book the only room with a working projector. It had every calendar, every preference, every rule we’d given it. What it didn’t have was the night-watchman’s phone number or the fact that he only answers after the second ring and only if you already know his daughter’s name.

The loop kept offering alternatives—different times, different rooms, even a coffee shop two blocks away—while the actual key sat in a drawer no one had told the system existed. We’d built something that could reason forever and still couldn’t finish the job.

That gap isn’t a bug in the model. It’s the place where real authority lives.

The three loops that succeeded because they stopped at the keyholder

The first loop handled volunteer room assignments for children’s ministry events. It generated candidate schedules every evening but terminated once it reached the coordinator’s confirmation step. The agent never emailed the final grid; it only surfaced a clean draft for the person who knew which volunteers had last-minute conflicts the data could not capture. Completion rate stayed high because the loop respected the gate.

A second loop managed equipment checkout for weekend services. It tracked what was checked out, what needed return, and which items required maintenance. The agent closed its cycle after printing a handoff sheet that the facilities lead signed. No further actions fired until that signature arrived in the system. The loop stayed short and the equipment stayed accounted for.

The third loop covered recurring small-group room bookings across multiple campuses. It proposed time slots based on attendance trends and room capacity but stopped once it reached the campus pastor who held the master calendar. The agent updated its internal state to “pending physical confirmation” and waited. When the pastor approved or adjusted, the loop restarted from that new state rather than guessing forward.

Each case succeeded because the designers encoded the keyholder as an explicit termination rather than an afterthought.

What happened when we removed the human check and the schedule went out with the wrong room

One team removed the final confirmation step to reduce latency. The agent began sending room assignments directly to volunteers based on its internal model of availability. Within two weeks a children’s event landed in a room already reserved for a funeral reception. The resulting scramble consumed hours from three staff members who had trusted the automated output.

The deeper problem surfaced in the audit logs. The agent had correctly identified an open room in the database, yet the database itself had not been updated by the keyholder who managed the physical calendar on the wall. The loop had no mechanism to detect that mismatch because the designers had removed the gate that would have caught it.

After the incident the team reinstated the termination condition. The agent now produces the draft, marks the task “awaiting keyholder review,” and pauses all downstream notifications. Error volume dropped immediately. The restored gate did not slow the overall process; it simply prevented the agent from acting on incomplete information.

How Wesley’s rules map directly onto agent stop conditions in shared facilities

Wesley’s first rule, do no harm, translates into a hard stop whenever an action could displace another scheduled use of space. The agent must surface the conflict to the keyholder rather than optimize around it. This prevents the system from quietly double-booking rooms that carry emotional weight for multiple groups.

The second rule, do good, requires the agent to improve the keyholder’s actual decision quality. Instead of flooding the coordinator with every possible schedule, the loop surfaces only the three options that respect known constraints and then waits. The human receives fewer items but better ones.

The third rule, stay in love with God, points to relational continuity. In practice this means the agent never removes the human from the loop in ways that erode trust. When a facilities lead knows the system will always pause for their input, they continue to invest attention. When the agent runs past them, that investment disappears.

These three stop conditions turn Wesley’s rules into concrete engineering constraints: terminate on potential displacement, terminate on decision quality thresholds, and terminate before any action that would bypass ongoing human relationship.

Your Turn: Apply This Today

• Pick one agent loop currently running in your facility system and add an explicit “keyholder review” state that blocks all downstream actions until a named person confirms.
• Map the three Wesley-derived stops onto that loop: list the specific data points that would trigger each termination.
• Update the agent prompt or rule set so it surfaces only the minimal options that already respect physical locks and volunteer conflicts.
• Run the revised loop on last month’s data and count how many outputs now correctly pause instead of proceeding.
• Share the revised termination list with the actual keyholder and ask which additional gate they would add.
• Schedule a one-hour review next week to test whether the new stops reduced manual corrections without increasing overall cycle time.

The Permission Gate That Kept the Agent From Running the Schedule shows the same pattern in a different workflow, and The Volunteer Who Handed the Printout Back to the Agent traces what changes when the termination lands in a human hand rather than code.

I consult with faith-tech product leaders on agent loop design, permission gate mapping, and shared facility automation. Let’s talk.

I watched the cursor blink while the agent added another line about the Wednesday night kids check-in that no one had run since March. The volunteer coordinator had already texted twice asking why the schedule kept listing rooms that don’t exist anymore. I’d rewritten the context file six times. Every version still invented the kind of tidy rhythm that only exists in planning documents.

The problem wasn’t missing information. It was that the real constraints live in the gaps between people’s actual weeks—the sick kid, the elder who forgot to mention he’s traveling, the small group that quietly shifted because two families moved. Those details don’t sit in a file waiting to be discovered. They’re carried in bodies and conversations.

I used to think the fix was simply more thorough prompting. Then I started wondering what it would take for the agent to treat ministry the way Scripture does: as something that happens in time, with actual people, not as a set of stable variables.

The six rewrites that exposed my over-reliance on prompt length

The first version was a single 4,000-token block that listed every possible ministry role and constraint I could name. The agent still invented a children’s director who had never existed. The second version broke the block into sections with explicit “do not invent” rules. The fabrications moved to a different part of the output.

By the fourth rewrite I had added examples of past handoff failures. The fifth tried JSON structure. None of them held once the workflow moved from my laptop to the actual coordinator’s desk on a Thursday night. Only after the sixth pass, when I stopped trying to encode everything in the prompt and instead kept a short, human-maintained file that the coordinator edited after every event, did the invented details disappear.

Each rewrite had lengthened the prompt. The successful version shortened it and moved the maintenance burden to the person closest to the work.

How ministry coordinators actually use the same context file week after week

The file that finally worked sits in a shared folder and contains four recurring sections: current volunteer roster with phone numbers, room capacities and restrictions, the last three weeks of schedule changes, and a one-paragraph note on what went wrong last time. Coordinators open it every Monday, spend three minutes updating the note, and save. They do not rewrite the whole document.

When they hand the file to the agent on Thursday, the agent produces a draft that matches the actual constraints because the file already encodes the exceptions the model could never retrieve. The coordinator then spends another two minutes striking anything that still feels off before printing. The loop stays short because the file is treated as a shared record rather than a prompt that must be perfect on the first try.

Torres would recognize this as discovery happening at the moment of use, not in a quarterly research sprint.

Why frozen context beats live retrieval when a volunteer is printing at 9 p.m.

Live retrieval sounds attractive until the volunteer is standing at the copier with a deadline. At that hour the retrieval system may pull last month’s room assignment or an outdated volunteer list because the source data has not been corrected yet. A frozen context file that the coordinator touched the same morning already contains the correction.

The agent cannot call an API at 9 p.m. and know that the youth room is being painted this week. The coordinator who walked past the paint cans that afternoon can add one line. Once that line exists in the file, the agent respects it without needing another round of prompting. The file becomes the single source that survives the handoff when systems are asleep or data is stale.

Your Turn: Apply This Today

• Pick one recurring workflow that already uses an agent and create a new text file named exactly after that workflow.
• Limit the file to the four sections described above and delete anything that has not changed in the last thirty days.
• Share the file with the one person who runs the workflow and ask them to spend two minutes updating the “what went wrong” note after the next event.
• Replace the longest section of your current system prompt with a single instruction to read that file first.
• Run the agent output against the file in a live session and note every invented detail that appears.
• Schedule a ten-minute calendar block every Monday to review the file with the actual coordinator rather than with the model.

The same pattern appears in the post about the context window that only closed when a real coordinator sat down, and it shows up again in the year I chased general tools before building the one harness that stuck.

I consult with product leaders building ministry and faith-tech tools on persistent context design, workflow-specific context maintenance, and avoiding over-reliance on model scale for handoff reliability. Let’s talk.