Blog

I assumed the labs shipping these agents would treat agent safety oversight as a non-negotiable baseline rather than an optional add-on. The models we integrated into our volunteer scheduling system came with the usual promises of alignment research and red-teaming summaries. I took those at face value and moved on to the integration work.

That assumption cost us. An early deployment routed a counseling note to the wrong volunteer coordinator because the agent interpreted a time-stamp mismatch as an update rather than a correction. The note contained details that should never have left the original small group. We caught it before it spread further, but the near-miss exposed how thin the guardrails actually were once the agent left the lab environment.

This is the foundational misread that causes ministry product teams to ship agents without building their own oversight layer. The labs optimize for broad capability and public benchmarks. They do not optimize for the handoff moments where a decision touches a real person’s schedule, story, or role in a local church.

John Wesley’s three simple rules offer a clearer lens than most modern safety frameworks. Do no harm. Do good. Stay in love with God. Wesley wrote them for small groups of ordinary believers who needed a way to check their daily actions against the gospel. The rules work because they force a person to examine concrete decisions rather than abstract intentions. Applied to agent logs, they turn vague alignment claims into specific audit questions.

The first rule, do no harm, maps directly to the audit gap we discovered. After the counseling note incident we pulled every agent decision that touched private data for the prior thirty days. The logs showed repeated cases where the agent had merged records across different individuals because the similarity score exceeded a threshold the lab had set for general use. None of those merges had triggered an internal flag. The harm was small in each case, yet the pattern was consistent. Wesley’s rule forced us to treat every instance as a potential injury rather than a statistical outlier.

The second rule, do good, exposed a different problem in how we measured success. Our initial dashboard tracked task completion rate and latency. After mapping the rule to the decision logs we added a new column: number of decisions that required a human to step in and improve the outcome. The number started high and stayed high. Agents were completing tasks, but they were not surfacing the moments where a volunteer assignment could have been handled with more care or context. The rule made the metric visible because it asked whether the action produced actual benefit for the people involved.

The third rule, stay in love with God, is harder to translate but necessary. It pushed us to ask whether the agent’s pattern of decisions aligned with the long-term formation of the community rather than short-term efficiency. In practice this meant reviewing logs for any recurring choice that quietly reduced face-to-face contact between leaders and volunteers. The pattern showed up in how the agent preferred to send automated reminders instead of prompting a quick call. The rule did not reject automation; it required us to justify when automation served formation and when it replaced it.

The audit gap appeared immediately after the first production deployment. We had instrumented the usual performance metrics but had no routine for reading the actual decision traces. Days in, a volunteer received two conflicting assignments for the same evening. The agent had resolved the conflict by picking the higher-priority label without checking whether the volunteer had already accepted the first assignment. The gap was not in the model’s reasoning; it was in our lack of a standing process to review the traces before they affected real schedules.

Wesley’s rules applied to the logs gave us language to describe what we were looking for. We began printing the decision traces for any action that touched schedules, counseling notes, or volunteer assignments. Two people read them each morning. The exercise took about twenty minutes. It surfaced the counseling note error within days and prevented several similar merges in the following week.

After the near-miss we added a reporting protocol that required human sign-off before any agent change reached the live system. The protocol is simple. Every agent action that touches the three categories generates a ticket. The ticket includes the decision trace, the data involved, and a one-sentence description of the intended outcome. A designated reviewer must approve or override within a few hours during business days. The rule has slowed some workflows, yet it has also caught repeated attempts by the agent to infer missing data from patterns that did not apply to the specific person.

The audit gap that appeared after the first agent deployment

We instrumented performance but skipped decision review. The first conflicting volunteer assignment surfaced because a coordinator happened to notice the double booking in a weekly email digest. No automated alert existed. The gap widened over the following days as more agents were added to handle counseling intake forms. Each form carried implicit context about personal circumstances that the agent treated as interchangeable fields.

Wesley’s rules applied to agent oversight of decision logs

Do no harm required us to flag every merge of records that crossed individuals. Do good required us to count the number of decisions a human later improved rather than the number the agent completed. Stay in love with God required us to notice when the agent reduced direct human contact in favor of automated reminders. The three questions turned a pile of logs into a usable review process that two people could finish in about twenty minutes each morning.

The reporting protocol we added after the first near-miss

Any agent action touching schedules, counseling notes, or volunteer assignments now creates a ticket with the full decision trace. A named reviewer must approve or override within a set response window. The protocol has not eliminated agent errors, but it has moved the first detection from the volunteer to the review queue. The cost is predictable time rather than unpredictable harm.

Your Turn: Apply This Today

• Identify the three categories of agent action that touch schedules, counseling notes, or volunteer assignments in your current system and list every one that currently runs without a human gate.
• Build a daily ticket queue that pulls the decision trace for each of those actions and assign a single reviewer who checks it before the change reaches production.
• Add a one-sentence “outcome justification” field to the ticket that forces the reviewer to state why the agent decision produces benefit for the actual person involved.
• Set a same-day response window during business hours and a next-morning window outside those hours so the protocol stays enforceable.
• Run the first thirty decision traces through Wesley’s three rules and note which rule surfaces the largest number of required changes.
• Schedule a weekly thirty-minute meeting where the reviewer shares the two most useful overrides with the rest of the product team so the pattern becomes shared knowledge.

The same pattern of skipped context appears in The Context Layer Ministry Teams Skipped When Agents Arrived. The question of what happens after the first agent ships is addressed directly in Letter to the PM Who Just Inherited the Ministry Agent Schedule.

I consult with ministry product leaders and church technology teams on agent oversight protocols, decision log review processes, and human review triggers for scheduling and pastoral data. Let’s talk.

Ministry PMs keep asking how to show users that a real human will step in at certain points in an AI agent, without the promise of human in the loop oversight reading like defensive copy. The answer is to declare the exact decision point, name the role that owns it, and surface that declaration in the product flow itself.

This approach draws directly from Solomon’s judgment in the biblical account. Two women claim the same child. Solomon does not simply assert authority or promise fairness. He states the test in public, names the consequence, and lets the true mother reveal herself through her response. The power lies in the visible rule, not in later reassurance that “someone is watching.”

Generic human-in-the-loop language collapses for the same reason vague royal promises would have failed in that story. Teams wrote “a human reviews sensitive cases” into their help pages and onboarding modals. Users learned to ignore it because the statement carried no observable consequence. When the agent produced an error on a children’s ministry curriculum recommendation or a volunteer schedule conflict, the promise offered no route to correction and no person to hold accountable. The phrase became wallpaper.

The same pattern appears in faith-tech pilots I have watched. One platform added a banner that read “human oversight active.” Within a couple of weeks the banner stopped registering with users because nothing changed in the actual output when the banner was present versus absent. Another team routed every prayer request through an agent and then claimed human review for anything marked “crisis.” The filter itself stayed opaque, so volunteers never knew whether their input would reach the named pastor or simply disappear into the model again.

Why generic “human in the loop” claims failed

The failure starts with the decision to treat the human step as a safety net rather than a product feature. Safety-net language stays in the terms of service or a settings footnote. Product features appear in the interface where the user is working. When the human step remains invisible until something breaks, users experience the break as the system’s normal behavior rather than an exception that should have been caught.

Teams also avoided naming the actual person or role because they feared it would highlight headcount costs. The result is a claim that cannot be tested. Solomon did not say “someone wise will decide.” He named the action and the outcome in the same sentence. Ministry users need the same clarity. They need to know that the children’s ministry director, not an unnamed reviewer, will approve any curriculum that references specific family situations.

The deeper issue is that generic claims remove the possibility of feedback. If no one knows where the handoff occurs, no one can improve the handoff. I have seen agent logs where an escalation sat unclaimed for days because the system never surfaced the assigned human to the user or to the human themselves. The generic language created the illusion of coverage while the actual workflow stayed broken.

The specific places we now declare a real person will decide

We have narrowed the declarations to three recurring moments that matter most in ministry products. The first is any recommendation that will be printed and handed to a volunteer with little prep time. The agent may generate the lesson outline, but the final version that reaches the volunteer must carry the name of the staff member who approved the print-ready file.

The second moment is any scheduling change that affects more than a few volunteers on the same weekend. The agent can propose the swap, yet the interface must show the ministry coordinator who will confirm availability before the change is published. This rule emerged after one church lost several volunteers because an agent moved a shift without checking travel conflicts that only the local coordinator knew.

The third moment is any output that references a user’s personal data, such as prayer requests or giving history used to tailor follow-up. The declaration here names the exact staff role that will review the output before it is sent. In each case the product surfaces the name at the moment the user triggers the agent, not after the fact.

The cost of keeping that declaration current

Maintaining these declarations requires a small but non-negotiable review cycle. Each quarter the product team must list every agent step that currently carries a human name and verify that the named role still exists and still owns the decision. When a staff member leaves, the declaration must be updated within one sprint or the agent step is paused until a replacement is assigned.

The cost also shows up in interface real estate. Adding a line that reads “Approved for print by Sarah T., Children’s Director” takes space that could have held another suggestion. Teams resist the space until they measure what happens when the line is absent. Completion rates for volunteer tasks noticeably drop when users cannot trace the source of the material they are asked to teach.

Finally, the cost includes logging the actual handoff. Every time the named human accepts or rejects the agent’s output, the system records the choice and the reason. These logs become the only reliable way to know whether the declared human step is functioning or has quietly atrophied into another automated path.

Your Turn: Apply This Today

• Pick the agent workflow that generates volunteer lesson plans and add a visible line at the final export step that reads “This file waits for approval from [role name] before it is sent to print.”
• Open the agent configuration for weekend scheduling and insert a required checkpoint that names the single coordinator who must confirm any change affecting more than three people.
• Update the prayer-request agent so that any message containing a user’s name or specific situation shows the exact staff role that will review it before delivery.
• Review the last thirty days of agent logs for the three workflows above and confirm that each named human actually received and acted on the handoff notice.
• Remove any banner or footer that says “human oversight active” and replace it with the three specific declarations above if they are not already in the flow.
• Schedule a thirty-minute calendar block next week to walk through one agent trace with the actual named human and adjust the interface text based on what that person says is missing.

Two recent posts explore related questions about agent handoffs and evaluation layers: Graph Engineering: Stop Waiting on Agents That Don’t Need Each Other and Letter to the PM Who Just Inherited the Ministry Agent Schedule.

I consult with ministry product leaders on declaring human decision points in agent workflows, maintaining current ownership declarations, and measuring whether those handoffs actually occur. Let’s talk.

I still remember the email that came in on a Tuesday morning. The agent had booked a call with a woman whose husband had died six weeks earlier. The model saw a recent gift, a clean CRM field, and an open slot on the calendar. It did exactly what we asked it to do.

She wrote back asking how we had known to reach her right then, and whether someone on staff had been watching the obituary pages. I had no good answer for her. The prompt never told the model to pause for a death in the family.

That was the week I stopped trusting volume as a proxy for care, and the week we started designing the agent roster rule that eventually stopped it from happening again.

The agent that booked the wrong donor call three times

The first run pulled a retired pastor who had served on the denomination’s finance committee years earlier. The model saw the title, the past gift size, and the open calendar slot. It booked the call for Tuesday at 10 a.m. The executive assistant who received the invite replied that her boss had passed away the year before.

The second run found a current major donor whose assistant had already asked multiple times that year to route all requests through the foundation office. The agent ignored the note in the CRM because the note sat in a free-text field the model treated as secondary. The call was booked anyway. The donor’s office canceled and asked to be removed from future outreach.

The third run surfaced a board member’s spouse who had served on the development committee until a quiet conflict over grant priorities. The model had no signal for that conflict. The invite went out, the board member called the CEO directly, and the project paused for two weeks while leadership decided whether the agent should continue at all.

Each failure looked like a data-quality problem on the surface. It was not. It was a refusal problem.

Why the agent roster rule had to live in the prompt and the calendar

We built the roster as a single shared document the agent had to check before any calendar action. The document contained three columns: name, explicit refusal reason, and the human owner who last confirmed the refusal. The agent prompt required it to query that document first and surface any match before generating an invite.

The calendar itself carried the same rule. Every proposed meeting block carried a hidden tag that the agent could not override. If the tag matched a roster entry, the block stayed blocked even if the model found an opening. The human owner received a daily digest of attempted bookings that hit the roster, not a list of successful bookings.

The rule moved from a nice-to-have note in the brief to a hard gate because the first three runs showed that volume incentives always outrun soft instructions. Once the roster lived in both the prompt and the calendar system, the agent stopped treating every open slot as an opportunity.

The measurable drop in wasted follow-up hours once the roster rule was explicit

After the roster rule went live, the booked calls that later required apology or removal dropped from a weekly occurrence to essentially none across a six-week test. The agent still surfaced the same volume of potential names, but it now routed the roster matches to a human queue instead of sending invites.

The follow-up work shifted from reactive damage control to proactive list maintenance. One PM had spent several hours a week cleaning up after bad bookings before the rule. After the rule, that time dropped to a short weekly pass on roster updates. The saved hours went into tightening the criteria the human owner applied, which in turn improved the quality of the names the agent was allowed to touch.

The same pattern appeared when we applied the roster approach to volunteer recruitment for a children’s ministry resource platform. The agent stopped inviting people who had already declined multiple times, and the volunteer completion rate for the first session rose because the remaining contacts had not been burned by repeated outreach.

Your Turn: Apply This Today

• Export the last thirty days of agent-proposed outreach and mark every name that produced a refusal or complaint; turn that list into the first version of your roster document.
• Add a single required query step in the agent prompt that checks the roster before any calendar action and surfaces matches to a human instead of booking.
• Tag every calendar block the agent can use with a hidden refusal flag that the model cannot override without human approval.
• Set a daily digest that shows only the roster hits, not the successful bookings, so the human owner sees refusal patterns before they compound.
• Run the next agent test with a hard stop after ten proposed actions; require the human owner to review roster matches before the agent continues.
• Measure the hours spent on post-booking cleanup this week and again after the roster lives in both prompt and calendar; treat the difference as the real retention metric for the agent.

The same refusal logic shows up when an evaluation layer has to decide what an agent is allowed to touch at all, which is why the post on shipping an agent and then needing that layer is worth reading next. The custom work we had to do after off-the-shelf tools hit ministry data limits also traces back to the same roster problem.

I consult with product leaders shipping autonomous agents in ministry contexts on refusal criteria, evaluation layers, and roster design. Let’s talk.