Month: August 2026

I opened the review doc on Tuesday and saw the same three constraints written out in full, again. Not because anyone forgot. Because the thread from Friday had already been cut.

We’d hit 82 generations the week before. Clean count on the dashboard. Then we swapped the general chat for a harness that carried the actual rules. Output fell to 61. The surprise wasn’t the drop. It was that every single one of those 61 still made sense on Wednesday morning.

The 50-generation score that flipped when the harness locked the calendar

We ran a controlled test on children’s ministry scheduling. The general agent produced 50 usable drafts across four weeks. Each draft still required the coordinator to paste the current date range, the room list, and the volunteer availability back into the thread because the model had already forgotten them.

After the harness added a persistent calendar object that updated only through a single approved tool call, the same team reached the same 50-generation mark in nine days. The difference was not speed of generation. It was that no draft after the first one needed the coordinator to restate the constraints.

The reset count fell from 3.2 per completed schedule to 0.4. Most of those remaining resets came from external changes, not from the agent losing its place. Munger would call this the difference between a system that compounds and one that restarts.

How tool adapters replaced three separate Slack threads

Before the harness, a volunteer confirmation workflow lived in three channels: one for the initial ask, one for room confirmation, and one for last-minute swaps. The general agent could generate the text for any single channel, but it could not carry the decision from one channel into the next without a human pasting the outcome.

The harness added three small adapters. One read the room calendar API, one wrote to the volunteer database, and one posted the final confirmation. The agent now moved the decision across all three without new context. The coordinator stopped opening Slack to reconcile the threads.

The same pattern appeared in curriculum assignment for SermonCentral-style resources. The harness kept the volunteer skill tags and the print deadline in one object. Output volume stayed roughly flat, but the number of follow-up messages dropped by more than half.

The repeatable job that finally stayed inside the 11 p.m. boundary

One coordinator ran volunteer scheduling every Tuesday night. The general agent often produced a first draft by 9:30, yet the back-and-forth over missing constraints pushed the final sign-off past 11:00 on six of the last eight weeks. The extra time came from repeated explanations of blackout dates and age-group rules.

Once the harness stored those rules in a locked object and required the agent to call an update tool rather than restate them, the Tuesday workflow closed by 10:10 in seven of the next eight weeks. The coordinator reported sleeping through the night for the first time in months.

The measurable change was not the agent’s intelligence. It was the removal of the context tax that had been invisible in the generation count.

Your Turn: Apply This Today

• Choose one ministry task that repeats at least weekly, such as volunteer scheduling or print-ready lesson assignment, and write down its three fixed constraints in a single document.
• Build a one-page harness that stores those constraints as a persistent object and exposes only a single update tool call instead of free chat.
• Run the task through both the general chat agent and the new harness for two cycles, counting every message that restates a constraint already given earlier in the thread.
• Log the reset count and the clock time from start to final approval for each cycle in a simple spreadsheet.
• Compare the two sets of numbers and note which column, resets or raw generations, moved more.
• Keep the harness version for the next four weeks and record whether the reset count stays below one per cycle before deciding to expand it.

The Year I Chased General Tools Before Building the One Harness That Stuck shows the cost of measuring only volume. The Context Window That Only Closed When a Real Coordinator Sat Down tracks what happens when the harness finally holds the variables that matter.

I consult with ministry product leaders on custom harness design for repeatable workflows, context reset measurement in AI agents, and volunteer-facing product constraints. Let’s talk.

You’re staring at the calendar invite that landed at 6:42 a.m. “AI agents – Q3 ship.” No agenda, just the title and a note that the VP wants a demo ready before the next leadership offsite. You haven’t even finished your first coffee and already the thing feels heavier than it should.

You know what they’re really asking. They want loops that keep running when the usual person is out, when the form is missing a signature, when three people need to sign off and two of them haven’t answered an email since Easter. The tech part is the easy part. The hard part is that nobody has drawn the actual map of who still has to say yes.

So you sit there wondering how many times the agent is going to knock before it finally gives up and the original request just sits there again, unanswered.

By the fourth iteration the same unavailable volunteer appeared again because the list had not been deduplicated after the last quarter’s updates. The loop logged each attempt as a new action. The children’s director received six notifications about the same missing slot and assumed the system was broken. In reality the loop had never been required to check whether the contact record still matched a living, local, willing person before placing the next call.

The pattern repeated across three separate churches using the same shared tooling. Each time the agent treated the contact database as a static truth rather than a record that required a human to confirm currency. The cost was not compute. It was coordinator time spent deleting duplicate alerts and manually marking records inactive.

What the 7-minute window revealed about goal definition

Ministry volunteers rarely have more than seven contiguous minutes between the end of one task and the start of the next. Any agent loop that requires a volunteer to read a multi-paragraph request, check a calendar, and reply inside that window will fail more often than it succeeds. The teams that measured success by loop completion rate missed this entirely. They recorded high retry counts as evidence the system was working hard.

When the same loops were forced to surface after the first failed contact and wait for a coordinator to approve the next attempt, the retry count dropped sharply. The goal shifted from “secure coverage through repeated outreach” to “present one clean request that a real person can answer inside their existing seven-minute slot.” The difference was not the agent code. It was the insertion of a single human review before the second and third iterations could fire.

Solomon’s test did not need to run multiple times. One clear proposal exposed the mismatch between claim and reality. Loops that never surface for that kind of review keep claiming they are close to success while the actual coverage problem remains untouched.

The harness that turned repeated calls into a single accountable step

The teams that eventually reduced wasted loops built a simple harness around the first three iterations. After the initial contact attempt, the agent wrote a one-sentence summary and routed it to the person already responsible for that ministry area. Only after that person confirmed the contact record was current and the request wording fit the seven-minute constraint could the agent proceed to a second attempt. The third attempt required the same gate plus a short note explaining why the first two had not worked.

The harness did not slow the overall process. It eliminated the loops that had been running into the same dead ends. One church reported that the average time from request to confirmed volunteer dropped from four days of silent retries to one day with two human touches. The coordinator no longer spent evenings clearing duplicate voicemails. The agent still handled the dialing and logging, but every path now terminated at an accountable decision rather than an endless queue.

This matches the judgment principle. The test does not replace the decision maker. It creates the condition under which the decision maker must act or the false path ends.

Your Turn: Apply This Today

• Pick the single agent loop you are being asked to ship this quarter and list the first three iterations it would run if left unconstrained.
• Identify the one existing human role that already holds permission to approve or reject that specific request today.
• Build a one-screen summary that surfaces after the first failed contact and routes only to that role, then instrument whether the summary is read within four hours.
• Log the number of iterations that occur before the human gate is hit and require that number to stay at one for the first two weeks after launch.
• Remove any retry logic that bypasses the gate and replace it with a clear “request closed pending human review” state.
• Review the logs after seven days and adjust the summary wording so the human can decide in under two minutes rather than asking for more data.

The same pattern appears in the volunteer coordination failures described in 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 posts trace how loops without an early human checkpoint simply multiplied existing friction.

I consult with product leaders shipping agent systems into ministry and nonprofit coordination workflows on permission gate design, seven-minute volunteer UX constraints, and loop iteration limits that preserve accountability. Let’s talk.

The extended-context-window playbook that swept product teams in 2024 promised that feeding agents hundreds of thousands of tokens of prior conversation would remove continuity breaks in multi-step workflows. Ministry teams adopted the same logic for volunteer scheduling agents and curriculum distribution bots. They loaded every policy update, past email thread, and volunteer preference into the prompt and expected the agent to carry the thread forward without dropping details.

That approach breaks in practice because ministry handoffs rarely stay inside a single digital thread. The coordinator who receives the agent’s output still prints a one-page summary, walks it to the children’s area, and hands it to a volunteer who has never opened the app. The extra tokens never reach that second person. The framework treats the agent as the sole carrier of state when the actual state lives in printed sheets, shared Google Drives that volunteers ignore, and verbal confirmations at the door.

This is the foundational misread that causes product teams to overinvest in prompt length while the real constraint sits outside the model. Larger windows improve recall inside the chat but leave the physical transfer points untouched. The agent generates a perfect schedule. The coordinator still rewrites it on paper because the permission log lives in a separate system that the agent cannot update.

Teresa Torres’s continuous discovery process offers the corrective lens. Torres insists teams run weekly interviews with the people who actually touch the output, not just the users who request the feature. In ministry agent work that means sitting with the coordinator who prints the sheet, not just the pastor who approved the budget. The method surfaces the exact moment the digital state stops traveling with the task.

The coordinator who printed the policy sheet anyway

One children’s ministry coordinator in a mid-size church received a clean agent-generated volunteer roster on Monday. The agent had pulled attendance history, skill tags, and room assignments from the last six months. She opened the message, read it, then printed a condensed version that fit on half a page. She carried that half-page to the supply closet and taped it to the door.

The printed version omitted the agent’s notes on background check expiration dates. Those notes sat in the full context window but never made it onto the paper. Two volunteers showed up the next Saturday without current checks. The coordinator later said she printed because the volunteers expected a physical list they could cross off with a pen. The extra tokens in the agent’s window did not change that expectation.

The same pattern appears when agents generate curriculum outlines. The outline arrives with linked resources and timing suggestions. The volunteer still writes the three main points on an index card before class because the tablet is charging in another room. Continuous discovery would have caught this behavior in the first interview round rather than after launch.

How fixed context still collides with permission logs

Permission systems in most churches remain split between the planning software and a paper sign-off sheet kept in the church office. An agent can hold the full history of who is cleared to drive the van, but it cannot write to the clipboard that the insurance company requires. When a last-minute substitute appears, the coordinator checks the clipboard, not the agent.

Teams that tried to solve this by expanding the context window simply moved the collision earlier. The agent now refuses to output a name until it confirms the log entry, yet the log entry only happens after a human signs the paper. The loop stalls. Torres’s method would require the product team to observe the clipboard step in real time rather than assume the digital record is authoritative.

The collision repeats in budget approvals. The agent can track line items inside its window, but the treasurer still needs a printed requisition form with two signatures before releasing funds. Adding more context about past budgets does not remove the signature requirement. The constraint lives in the physical gate, not the token count.

The discovery loop that actually surfaces the real constraint

Torres recommends a weekly cadence of customer interviews focused on recent decisions, not hypothetical preferences. For ministry agents this means asking the coordinator to walk through the last handoff that happened that week. The question is not “Would you use an agent?” but “Show me the paper you used yesterday.”

One team ran three consecutive weeks of these interviews and found the same pattern: every successful schedule change involved a verbal confirmation at the Wednesday staff meeting. The agent output arrived after that meeting, so it was already stale. The discovery loop revealed that the real redesign target was not the context length but the timing of when the agent ran relative to the in-person meeting.

Another loop exposed that volunteers only trusted outputs they could annotate. They wanted margins for handwritten notes. The agent produced clean PDFs with no white space. Adjusting the output format took one afternoon once the interview data arrived. The context window size never came up as the blocker.

Your Turn: Apply This Today

• Pick one ministry workflow that currently uses an agent for scheduling or resource distribution and list every physical object that leaves a person’s hand during that workflow this week.
• Schedule two 20-minute interviews with the actual coordinator or volunteer who receives the agent’s output and ask them to show the paper or screen they used the last time the task ran.
• Map the exact timestamp when the agent’s output becomes irrelevant because a permission log or verbal confirmation happens outside the system.
• Reduce the agent’s context by half and test whether the output still fails at the same physical handoff point you observed in the interviews.
• Change the run time of the agent so it executes immediately after the weekly in-person meeting rather than before it, then measure whether the printed sheet still appears.
• Document the single permission gate or annotation step that the agent cannot touch and bring that item to the next product review instead of another token budget request.

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 trace the same pattern of digital state stopping at physical boundaries.

I consult with ministry product leaders on agent handoff redesign, continuous discovery interviews, and permission log integration. Let’s talk.