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.