Blog

The general-purpose harness model from the LangGraph tutorials and OpenAI’s function-calling examples claims any workflow can be handled by a single agent equipped with a broad set of tools and a loose permission layer. The model treats ministry operations as just another set of tasks that an LLM can route through generic APIs. Ministry coordinators who tried this approach found the opposite: the agent would propose actions that violated child-protection policies, bypassed elder approval, or scheduled volunteers who had already declined. The harness never encoded the actual constraints, so every run required manual rollback.

Seneca wrote letters that responded to one correspondent’s precise circumstances rather than issuing universal rules. That correspondence rule exposes why the general harness collapses in church settings. A letter addressed the recipient’s actual limits; a treatise did not. The same distinction applies to product work. When the harness stays general, it cannot enforce the specific boundaries that keep ministry safe and accountable.

This is the foundational misread that causes product teams to ship agents that coordinators quietly disable after the first compliance incident.

Curriculum approval loops

A children’s ministry director at a mid-sized church once connected a general agent to their resource library. The agent could search, summarize, and suggest edits. Within a week it recommended a lesson that had been flagged for theological review two quarters earlier. The agent had no record of the flag because the harness treated every document as equally available.

Under Seneca’s rule the adapter would have opened by asking which elder held final sign-off for that quarter and which topics required a second reader. Only after those two checks passed would the agent surface the file. The narrow harness made the permission boundary visible before any generation step began.

Coordinators who kept the general harness eventually added a spreadsheet outside the agent to track the same flags. The extra table became the real system; the agent became a search box. The cost was duplicated data entry and eroded trust in the automation.

Child-checkin permission gates

Check-in systems already contain strict rules about who may release a child and under what conditions. A general-purpose agent given access to the check-in API quickly suggested moving a volunteer from one station to another without confirming that volunteer’s background-check status. The suggestion arrived in the coordinator’s inbox before anyone noticed the mismatch.

The narrow harness built for that church first queried the volunteer database for the exact clearance timestamp, then checked the current ratio of cleared adults to children in the room. Only when both conditions held did the agent offer the reassignment. The correspondence-style prompt made the safety constraint the first sentence of every run.

Teams that skipped this step reported that volunteers began ignoring agent suggestions altogether. They preferred the slower manual list because it had never placed a child at risk. The general harness had optimized for speed while the actual metric was zero policy violations.

Volunteer schedule overrides

Most scheduling tools allow an override when someone drops out. A general agent given that capability began reassigning people across campuses without confirming whether the new volunteer had completed the required training for that specific age group. The override succeeded in the software but failed the moment the volunteer arrived unprepared.

Seneca’s correspondence rule requires the writer to know the recipient’s exact obligations before offering advice. Translated to the adapter, this meant every override request first retrieved the volunteer’s training record, the campus policy on cross-training, and the elder who could grant an exception. The harness refused the change until all three returned true.

Coordinators who adopted the narrow version stopped receiving 11 p.m. texts from volunteers who had been assigned outside their comfort zone. The general harness had removed friction for the agent; the constrained harness removed friction for the people executing the schedule.

Your Turn: Apply This Today

• Choose the single ministry workflow that generates the most manual overrides this month and export its last thirty instances into a shared document.
• Interview the coordinator who owns that workflow and list every explicit permission rule they apply before approving an action; keep the list under twelve items.
• Write a one-page adapter spec that inserts those rules as the first conditional checks the agent must satisfy before calling any tool.
• Build a minimal custom harness in the language your team already uses—ten to fifteen lines of guardrail code is enough for a first version.
• Run the harness against the thirty exported instances and count how many now fail the encoded rules before any downstream action occurs.
• Present the failure count and the revised adapter to the coordinator within seven days; ask which single rule still needs tightening.

The Routing Step Ministry Teams Still Can’t Automate and The Children’s Check-In Desk That Suddenly Spoke Back both trace the same pattern of hidden permission boundaries that general agents never surface.

I consult with ministry product leaders on encoding permission constraints into AI agents and designing narrow harnesses for volunteer workflows. Let’s talk.

A ministry product team logged 91% accuracy on their latest model after swapping it into a frozen set of 200 ministry workflow tasks. The number looked decisive on the dashboard, yet the same swap triggered overrides on 67% of live Sunday morning runs because the benchmark tasks had frozen the inputs months earlier and erased the pastor’s real-time adjustments for grief, local news, or volunteer absences.

The obvious reading says the model improved. The actual pattern shows the benchmark rewarded answers that no longer fit the room. Teams treat the score as evidence of progress when it mostly measures how well the model learned to mimic a snapshot that the congregation has already moved past.

Solomon’s judgment makes the mechanism visible. Two women claimed the same child. The king did not ask for higher accuracy on a pre-written list of facts about the infant. He proposed a cut that forced the real claim to surface through the response that could not be scripted in advance. The frozen benchmark plays the role of the first woman’s confident assertion. The human override is the second woman’s refusal to let the child be divided. Only the override reveals which output belongs in the actual household.

Baptism outline review

One children’s ministry platform froze a set of 40 baptism outline tasks in January. The tasks asked the model to generate age-appropriate language for the ceremony, including a standard welcome for parents and a short prayer. The benchmark scored completions on keyword presence and sentence length. After the March model update the score reached 93%.

Volunteers began overriding the output the first Sunday it went live. The generated prayer thanked God for “smooth transitions” while the actual family had just lost a grandparent two days earlier. The benchmark had no slot for that variable. The override rate climbed to 71% within three weeks because the frozen tasks rewarded generic warmth instead of the specific mercy the room required.

The pattern repeated across three other churches using the same curriculum tool. Each team kept the high benchmark number on the slide deck for leadership while the actual printouts carried handwritten corrections. The score measured fidelity to January’s template, not fidelity to the child standing in the water.

Event registration validation

A midsize church built an internal agent to validate event registrations against capacity, age requirements, and volunteer background checks. They created a frozen benchmark of 150 past registrations with clear right answers. The model passed at 88% after the June swap.

When the agent ran against new summer camp sign-ups, it rejected three siblings whose parents had submitted a handwritten note about a custody schedule change. The benchmark contained no example of handwritten notes. The override came from the children’s director who recognized the family and approved the forms in four minutes. The benchmark score stayed high while the live process required a human to restore the correct outcome.

Teams noticed the same gap on medical form updates and carpool changes. The frozen tasks rewarded strict rule application. The ministry process rewarded judgment that could absorb exceptions without breaking the child or the parent.

Giving statement accuracy

An operations team froze 75 giving statement tasks that tested whether the model could match donor names, dates, and amounts to the correct quarter. After the latest model the score hit 95%. Leadership celebrated the reduction in staff hours.

The first statements sent in July contained correct numbers but used language that listed a recent gift as “recurring” when the donor had made a one-time memorial gift after a funeral. The benchmark had never included memorial gifts. The override came from the finance volunteer who caught the phrasing before the statements mailed. The score remained high; the trust cost appeared in follow-up emails and one donor who called the church office confused.

Solomon’s test works because it does not measure how cleanly the model repeats the known facts. It measures whether the output can survive contact with the person who actually holds the stake.

Your Turn: Apply This Today

• Pick one ministry process that runs every Sunday, such as baptism follow-up emails, and write exactly ten tasks that include the last three real exceptions your team handled manually.
• Freeze those ten tasks with their original inputs and the human-approved outputs, then store them in a single shared document no one can edit after today.
• Run the next model swap against the frozen set and record both the automated score and the exact sentences that required overrides.
• Run the model after the following swap on the same ten tasks and note which overrides changed or disappeared.
• Run it a third time after the next major update and mark any task where the new output now matches the frozen human version without changes.
• Present the three-run table to your team with the single sentence that names the process and the override rate, then decide whether the benchmark still earns the right to gate the next deployment.

The Routing Step Ministry Teams Still Can’t Automate and The Benchmark Number That Still Needed a Human Gate both trace the same pattern of scores that hide the real cost of automation.

I consult with product leaders and ministry operations teams on frozen benchmark design, live override tracking, and model swap evaluation for Sunday workflows. Let’s talk.

The volunteer coordinator opened the agent dashboard on the first laptop and watched suggested task routes fill the screen. One volunteer leaned forward, clicked through the options, and began reassigning children’s ministry prep items without asking anyone else. On the laptop inches away, the second volunteer read the first line of output, closed the tab, and returned to the paper checklist she had printed the night before.

That split happened in under ninety seconds. The same tool, the same set of inputs, and two different responses that would shape how each person spent their next several hours.

The difference was not technical skill. It was whether anyone had first decided what the agent was allowed to touch and what it was required to leave alone.

John Wesley’s three rules give a usable frame for this moment. Do no harm. Do good. Stay in love with God. When managers skip the first two rules and treat AI rollout as a tooling question, they create exactly the split I keep seeing: one camp that gains capacity and another that quietly steps back.

Permission mapping before rollout

Permission mapping is the concrete version of “do no harm.” It means naming the data fields, the decision types, and the communication channels an agent may never touch before any volunteer opens the dashboard.

I sat with one children’s ministry team that spent two hours listing every task that touched a child’s medical note or a parent’s custody arrangement. They drew a hard line: the agent could suggest craft supplies and room assignments, but it could never generate or store anything that included a child’s name alongside a health detail. That single boundary kept three volunteers from walking away from the tool.

Without the map, the first volunteer to try the agent will either over-trust it or over-correct by rejecting the whole system. The split begins the moment someone has to decide in real time what counts as safe.

Protection rules for edge cases

Protection rules turn “do good” into daily practice. They are short, written statements that tell the agent what to do when the input falls outside normal patterns.

One team wrote three sentences that lived in the prompt itself: if the suggested task involves a child under three, always flag it for a human; if the parent contact is marked confidential, route to the coordinator only; if the time estimate exceeds fifteen minutes, do not auto-assign. These rules were not buried in a settings menu. They appeared every time the agent returned a suggestion.

The result was not slower output. It was output that the volunteer who had closed the tab could actually use without creating new risk. The volunteer who had leaned in still moved faster because the guardrails removed the mental tax of second-guessing every suggestion.

Weekly check-in on actual time saved

Wesley’s third rule, stay in love with God, translates here into staying in honest relationship with the work and the people doing it. That requires looking at real time saved rather than dashboard metrics.

I watched a coordinator run a ten-minute Friday check-in where each volunteer answered two questions only: what task did the agent handle this week, and how many minutes did it actually free? After four weeks the numbers showed the agent saved nine minutes on average for one role and created seven minutes of new review work for another. They adjusted the permission map on the spot.

Teams that skip this check-in keep running on the assumption that adoption equals progress. The split widens because one group experiences real relief while the other absorbs hidden cost.

Your Turn: Apply This Today

• Pick one high-stakes ministry process that currently uses an agent and write the three explicit rules it must obey before the next volunteer opens the dashboard.
• Schedule a single forty-minute session with the exact team that owns the process and walk through every data field the agent may never touch.
• Add the protection rules directly into the agent prompt so they appear with every new suggestion this week.
• Run a ten-minute Friday check-in for the next four weeks that records only minutes saved and minutes added, then adjust one permission based on the numbers.
• Document the final permission map and protection rules in the same document the volunteers already use for that process so no one has to hunt for them.
• Share the updated map with the second volunteer who previously closed the tab and ask what would make the tool trustworthy enough to try again.

Two related posts that explore similar ground are The Routing Step Ministry Teams Still Can’t Automate and Letter to the PM Who Inherited the Agent Pilot.

I consult with product leaders and ministry technology teams on AI agent permission mapping, protection rule design, and weekly time-saved reviews. Let’s talk.