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.