Blog

You open the spreadsheet on a Tuesday morning and the number stares back like it already made the decision. Ten months of runway, a headcount line, and a blank “use case” field that everyone expects you to fill before the next steering call.

The demo you watched last week produced clean, safe copy in under a minute. It just didn’t sound like anyone who has ever had to stand in front of real people on a Sunday and own what was said.

That single choice exposed the real constraint. The denomination’s surface area is not compute. It is the distance between an output and the moment a volunteer decides whether to use it or rewrite it by hand. Sovereign control over routing would have sent that task to a smaller, fine-tuned model trained on actual volunteer feedback instead of routing everything through the frontier model for marginal coherence gains.

Zone-based coordination replaced feature ownership once the team stopped assigning agents to single product areas. Instead they mapped three zones: preparation, delivery, and follow-up. Each zone carried its own data residency rule and latency budget. Preparation agents could use heavier models because they ran overnight. Delivery agents stayed on lighter, on-premise inference so a last-minute children’s lesson change did not depend on an external queue. Follow-up agents lived inside the existing volunteer workflow tool so completion data stayed inside the same system that already measured whether the lesson was actually taught.

The shift removed the old feature-owner meetings where one person defended their agent’s scope. Decisions moved to routing tables reviewed every two weeks. The tables listed model, residency, maximum cost per task, and the single human checkpoint required before the output reached a volunteer. Ownership became maintenance of the table rather than defense of a feature.

The routing rule that protected Sunday validation emerged from the same table process. Any agent output intended for direct use in a worship service had to route through the on-premise model first. Only if that model returned a low score did the task escalate to the larger hosted model, and even then the output carried a required human review tag before it could be scheduled. The rule looked conservative on paper. In practice it cut the number of unusable drafts that reached the Sunday morning test by more than half. The cost per validated item dropped because the expensive model was invoked only after the cheaper one had already filtered obvious mismatches.

The rule also surfaced a second pattern. Volunteer completion rate, not generation volume, became the metric that determined whether a routing change stayed in the table. When completion dipped, the team adjusted residency or model size before touching prompt language. The routing table turned into the place where taste was enforced rather than hoped for.

The first decision that revealed the taste gap

The vendor demo surfaced the gap because no one had defined what “good enough for a seven-minute volunteer” actually meant in tokens or latency. The team measured against public leaderboards instead of against the printed sheet that gets left on a kitchen table. Sovereign routing starts by writing that definition down before any agent is turned on.

How zone-based coordination replaced feature ownership

Feature ownership rewarded the person who shipped the most agents. Zone coordination rewarded the person who kept the routing table accurate when volunteer data changed. The difference showed up in the first month the new table ran: three agents were retired because their residency rule no longer matched the actual data sources used on Sunday.

The routing rule that protected Sunday validation

The rule required on-premise inference for any worship-facing output and a human checkpoint for anything that escalated. It did not eliminate the frontier model. It made the frontier model the exception rather than the default path. That single constraint preserved the judgment that lives in the room on Sunday morning.

Your Turn: Apply This Today

• Write one explicit routing rule this week that names the model, the residency location, and the maximum cost allowed for any task that reaches a volunteer.
• Map the three zones your current agents touch and assign each zone its own residency requirement before the next sprint planning meeting.
• Pick the single human checkpoint that must occur before any escalated output reaches Sunday materials and add it to the routing table as a required field.
• Run last week’s highest-volume agent task through the new rule and record the change in cost and volunteer completion signal.
• Remove any agent whose routing table entry cannot be defended with a real volunteer metric by Friday.
• Schedule the first two-week review of the routing table with the people who actually print and use the outputs.

The same tension between default scale and retained judgment shows up in both Letter to the PM Who Now Arbitrates Taste and Why Top PMs Still Route Specs Through Sunday Validation. The posts walk through parallel cases where control over the path mattered more than model size.

I consult with product leaders at faith-based organizations on inference routing, data residency choices, and Sunday validation loops. Let’s talk.

I watched a PM hand off an AI-built prototype last month and call it done by lunch. The flow looked clean on his screen. Then the first user tried it on a train with one hand and no signal, and the whole thing stopped making sense after the second tap.

That gap never shows up in the deck. It only appears once someone actually needs the thing to work without you in the room.

I stopped writing specs after that.

Explore: Making the Delivery Medium Part of the Prototype

The explore prototype that surfaced the print step problem began with a single prompt to generate a children’s ministry lesson builder. The first version rendered cleanly on screen and passed internal review. When the same flow was printed for a volunteer who only had the sheet in front of her, the required checkbox sequence disappeared and the activity list ran past the bottom margin. That single failure forced the next three iterations to treat print as a first-class output instead of an afterthought. The lesson was not that the agent was wrong; it was that the explore step had not yet included the actual delivery medium.

Expand: Testing the Narrow Loop Under Real Use

How expand changed the volunteer scheduling loop came next. After the print issue was visible, the team expanded the prototype to include a weekly availability calendar that updated in real time. Early versions assumed every volunteer would check the app daily. Real use showed that most only opened it once on Thursday night. The expanded version therefore added an SMS reminder that carried the same state as the calendar, and the completion rate for sign-ups rose without any increase in push notifications. The expansion phase succeeded because it kept testing against the same narrow user action rather than adding features.

Extract: Locking In the Rule

The extract protocol that now lives in every new agent was written only after the expanded version had run for three live events. It consists of four checks that must pass before any generated code moves into the main repository: the flow must complete on paper, the flow must complete on a shared device without login, the error states must be reachable in under two taps, and the success metric must be recorded without an additional screen. The protocol is short because it was pulled directly from the failures observed in the earlier stages, not from a general style guide.

Your Turn: Apply This Today

• Choose one three-step task inside your current product that volunteers or end users complete without training and prompt an AI coding agent to generate a working prototype of just those three steps.
• Print the resulting screen or flow, hand it to one person who matches your target user, and time how long it takes them to finish without asking questions.
• Note the exact point where the prototype broke or required explanation, then write a single-sentence adjustment before you generate the next version.
• Run the revised prototype through the same print-and-time test with a different user the next day and record whether the completion time dropped.
• Extract the one rule that would have prevented the first failure and add it to a short checklist you apply to every new agent-generated file this month.
• At the end of the week, compare the original prototype against the version that passed two real-user tests and delete any code that did not survive the cycle.

The same explore-expand-extract discipline appears in both “The Trust Step Kent Beck Made Non-Negotiable” and “Why Top PMs Still Route Specs Through Sunday Validation”, where the cost of skipping the first stage shows up in later rework rather than in initial velocity.

I consult with product leaders building ministry tools on prototyping workflows, volunteer adoption metrics, and agent-assisted development. Let’s talk.

I still remember the night the curriculum agent died. A volunteer in our kids ministry pulled it up on her phone in the church basement, stared at the clean, tested output, then set the phone down and reached for the dog-eared binder she’d used for three years. Nothing in our sandbox had prepared us for that moment.

Three different pilots later, the pattern was the same. The agent handled the hard cases. The metrics looked strong. But the handoff to real calendars and real people never cleared the gap between what we built and where ministry actually happens.

The bias wasn’t in the model. It was in the quiet belief that if it worked inside our walls, it would find its way to theirs.

Where the quality metric hid the handoff failure

The first pilot scored 96 percent on accuracy for lesson-plan generation. Volunteers tested the agent in a two-week lab and finished every task. We declared success and moved to live use. What the metric never captured was the moment a volunteer had to print the output, carry it across a church parking lot, and explain it to a substitute teacher who had never seen the system.

That single transfer broke the chain. The substitute opened the printout, saw unfamiliar formatting, and defaulted to the paper curriculum already in the bin. Completion rate dropped from 94 percent in the lab to 11 percent on the actual Wednesday night. The quality score stayed untouched because we never measured the transfer itself.

The second pilot used an agent that summarized weekly sermon content into small-group questions. Internal review praised the theological tone and length. The failure point arrived when the pastor needed to route those questions to a volunteer coordinator who only checked email once a week. The coordinator never opened the file. Again the internal metric offered no warning because the handoff lived outside the product surface.

Both cases followed the same pattern: we treated the agent as a self-contained deliverable. Munger’s latticework would have required us to model the actual sequence of human movements before claiming readiness.

How distribution actually worked in the three pilots

Distribution in these settings rarely runs through app stores or dashboards. It runs through people who already carry paper, text threads, and verbal briefings on Sunday morning. The curriculum agent never reached its intended users because the only person who knew how to trigger it sat in the children’s director’s office and left at 8 p.m. on Wednesdays. No one else had both the login and the physical print step in their normal routine.

The sermon-prep pilot collapsed for a different distribution reason. Pastors liked the output when they tested it alone, but the small-group leaders who actually taught the material received it only if the pastor remembered to forward an email. That single extra step had no owner and no reminder system. The pilot recorded high usage from the pastor and zero usage from the people who needed the content most.

The third pilot required a laptop connected to a specific projector model that existed in only one classroom. Volunteers scheduled for other rooms could not run the agent at all. The distribution constraint was physical equipment, not software quality. Once we mapped the actual rooms and devices in use, the 95-percent accuracy number became irrelevant.

Each failure traced back to an unmodeled distribution path rather than a defect in the agent. The latticework approach would have flagged these paths before any code was written.

The model I now run before any new agent ships

I now force three additional models alongside the quality model before shipping. The first is a literal map of every human who must touch the output between generation and use. The second is a timing model that records when each of those humans is actually available. The third is an incentive model that asks what each person gains or loses by completing their step.

Running the map on a new agent takes less than an hour but changes the definition of done. If the map shows more than two handoffs or a timing gap longer than forty-eight hours, the pilot does not ship until the handoff is either removed or instrumented. The incentive check often reveals that one volunteer gains nothing from the extra step; that person becomes the redesign target, not the agent itself.

This process has already stopped two agents that would have repeated the earlier pattern. One required a second volunteer to re-enter data that the first volunteer had already typed. The map made the duplication visible. The other needed a Sunday-morning printer that no volunteer was willing to operate; the incentive model showed zero benefit for that role, so the feature was cut before development began.

The latticework does not slow delivery. It prevents the expensive restart that follows every silent failure on Sunday.

Your Turn: Apply This Today

• Draw the exact sequence of people who must receive output from your current AI workflow and mark the last person who actually uses it on Sunday.
• Time-stamp each handoff in that sequence against the real availability windows of the people involved, not the ideal schedule.
• Identify the single handoff with the longest gap and either automate it or assign an explicit owner this week.
• Run the incentive check on the last person in the chain: list what they gain or lose by completing their step and adjust the workflow if the gain is zero.
• Remove any step that requires equipment or access only one person possesses; redesign or drop the feature if removal is impossible.
• Re-test the revised workflow with the actual volunteers or pastors who will run it, not the internal team, before declaring the pilot ready.

The same distribution blind spot appears in “The Trust Step Kent Beck Made Non-Negotiable” and “Why Top PMs Still Route Specs Through Sunday Validation.”

I consult with faith-tech product leaders on distribution audits, pilot handoff design, and latticework application to AI workflows. Let’s talk.