Blog

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.