Blog

An agent loop that a ministry team rebuilds by hand every week is not a quality problem. It is coordinators protecting their right to say no after the system has already run.

Quick answer: Ministry teams keep rebuilding agent loops by hand because no one has written down who is allowed to say no, and when. Borrow John Wesley’s three simple rules—do no harm, do good, attend upon the ordinances—as three permission gates an agent loop must pass before it acts without a human signature.

That refusal sits at the center of every stalled deployment. The architecture itself moves fast enough. What coordinators withhold is the explicit grant of permission to act on a volunteer schedule, a follow-up list, or a content flag without a second human review. The agent loop keeps returning to the same desk because no one has drawn the boundary in advance.

This is the foundational misread that causes product teams to chase faster inference and cleaner prompts while the actual constraint remains untouched. The work does not slow down at the model layer. It slows at the signature layer.

John Wesley’s three rules—do no harm, do good, attend upon the ordinances—supply the missing lens. They are not abstract virtues. They are operational checkpoints that assign responsibility to the one human who bears the name of the congregation.

Permission boundaries that keep an agent loop from running unsupervised

Wesley’s first rule forces the boundary to be stated in negative terms before any loop begins. In practice this means writing the explicit list of actions an agent must never take on its own: never change a child’s small-group assignment without a named adult confirming the parent has already approved, never send a pastoral-care text that references a private prayer request, never alter the printed order of service once the bulletin has left the copier.

Teams that skip this step discover the failure only after the loop has acted. The damage is already done and the coordinator is left explaining why the system moved without cover. The rule survives Sunday morning only when it is written as a short, printed list that every volunteer can read in under a minute and that the agent is programmed to check before every external action.

The same list also tells the product team what data the agent must surface to a human within a fixed window. If the boundary is not legible to both the coordinator and the volunteer by Sunday morning, the agent loop will be rebuilt by hand the following week.

Accountability loops that still require a human signature

Wesley’s second rule shifts attention from prohibition to positive obligation. The agent must be able to show that it advanced a measurable good before any human is asked to sign. In children’s ministry this often means the agent proposes a volunteer placement only after it has verified three conditions: the volunteer completed the prior week’s lesson, the parent reply rate for that age group stayed above a documented threshold, and no conflicting event appears on the master calendar.

The signature is not a rubber stamp. It is the moment the coordinator accepts personal responsibility for the outcome. When the loop cannot produce the three data points in a single screen, the coordinator rightly withholds the signature and the loop returns to manual work. The architecture only earns the signature when the positive obligation is already met and visible.

Teams that treat the signature as optional discover that coordinators stop trusting the entire system. The loop may run overnight, but the human who must answer for it on Sunday morning will not delegate the authority again.

The rule that breaks when an agent loop runs overnight

Wesley’s third rule—attend upon the ordinances—names the element that cannot be automated: the recurring, embodied act of gathering that keeps a community accountable to one another. An overnight loop that reschedules volunteers or flags prayer requests without also surfacing the next physical gathering time quietly severs that connection.

The practical failure appears when the agent books a new volunteer for a slot that overlaps with the quarterly training meeting. The rule is broken not because the model erred but because no one encoded the ordinance of corporate learning as a hard constraint. The coordinator then spends Monday rebuilding the schedule by hand to restore the pattern of shared formation.

The three rules together convert vague concerns about “oversight” into three concrete gates. Any agent loop that cannot pass all three gates before it acts will be rebuilt manually the following week.

Your Turn: Apply This Today

• Pick one repeatable workflow—weekly volunteer placement for children’s small groups—and write the three Wesley rules as explicit gates the agent must satisfy before it proposes any change.
• Print the “do no harm” list on a single page and require the ministry coordinator to initial it before the agent receives production access.
• Build a one-screen summary that shows the three positive obligations the agent has already met and make that screen the only place the coordinator can add their digital signature.
• Set a hard stop so the agent cannot execute any overnight change that would affect a gathering scheduled within the next 72 hours.
• Run the loop once in a test environment with last week’s data and log every place a human signature would still be required.
• Schedule a 20-minute review with the two people who currently rebuild the schedule by hand and ask them to mark which of those signatures they are willing to delegate after the gates are in place.

Frequently Asked Questions

What is an “agent loop” in ministry AI workflows?

An agent loop is a recurring automated process, such as volunteer scheduling or follow-up messaging, that an AI system runs on its own on a set cadence. When the loop lacks clear permission boundaries, coordinators end up rebuilding its output by hand each week to catch what it got wrong.

Why do ministry teams keep rebuilding agent loops by hand?

Because no one has written down, in advance, exactly what the agent is never allowed to do, what good it must prove before a human signs off, and which recurring human gatherings its schedule changes must respect. Without those three gates, coordinators do not trust the loop enough to let it run unsupervised.

How do Wesley’s three rules apply to AI governance?

Do no harm becomes a written list of actions the agent loop must never take alone. Do good becomes a requirement that the agent prove measurable benefit before a human signs off. Attend upon the ordinances becomes a hard rule that no automated change can override the community’s recurring, in-person gatherings.

The same pattern appears in the volunteer who tried the new voice agent on a baptism outline and in the caching shortcut that quietly broke three ministry agents. Both cases turned on whether permission and accountability had been written down before the loop ran.

I consult with ministry product leaders and church tech teams on mapping permission gates, designing human-signature checkpoints, and applying Wesley’s rules to overnight agent workflows. Let’s talk.

A narrow harness, not a general-purpose AI agent, is what keeps ministry coordination work safe. The “general-purpose AI agent” recommendation that circulates through product strategy sessions and frameworks like the one in Marty Cagan’s books falls apart the moment it meets ministry coordination work. That approach pushes teams to ship a single model that handles intake, routing, formatting, and handoff for every role. It promises lower maintenance and broader adoption. In practice the model erases the exact checkpoints that keep a coordinator from sending a child to the wrong room or printing a curriculum page with the wrong date.

Quick answer: Skip the general-purpose AI agent for ministry coordination work. Build a narrow harness instead: one that locks child-protection fields, kiosk name formatting, and curriculum export gates so the model can propose changes but never silently overwrite the details that matter.

Coordinators do not need another flexible assistant. They need outputs they can audit in under two minutes without opening a second screen. When the general agent varies a single field on its own, the coordinator loses the signal that something went wrong. Trust does not recover after the first incident.

This is the foundational misread that causes product teams to ship agents that look complete in demos yet create silent failure loops in the field. The agents optimize for coverage instead of exposing the three constraints that actually determine whether a workflow stays safe. Teresa Torres’s continuous discovery work supplies the corrective lens. Torres insists teams maintain direct, repeated contact with users to surface the jobs that matter most. When applied here, the practice reveals that the jobs are not broad categories like “manage events” but narrow, non-negotiable gates: deterministic child-protection fields, fixed kiosk outputs, and coordinator-controlled curriculum exports. Discovery does not end when the first prototype ships; it continues by watching whether those gates remain visible after every model update.

Child-protection fields a narrow harness must keep deterministic

Ministry coordinators who manage children’s programming treat certain data points as fixed once entered. A child’s allergy flag, custody note, or room assignment cannot be reinterpreted by a model. When a general agent rewrites or softens one of those fields to “improve readability,” the change travels downstream before anyone notices.

Teams that tested broad agents on volunteer scheduling saw the model swap a documented peanut allergy for a generic “dietary preference” label in two separate test runs. The coordinator caught it only because she printed the list herself. Continuous discovery sessions with four different coordinators showed the same pattern: the moment the agent treats a protected field as editable text, the entire output requires manual re-verification that defeats the supposed time savings.

The narrow harness keeps those fields in a locked schema. Any generation attempt that touches the field triggers an explicit flag rather than a silent rewrite. Coordinators report they now scan only the flagged lines instead of rereading every record.

Kiosk check-in outputs that cannot vary by even one name

Check-in kiosks at larger campuses print name tags and parent receipts in a single pass. A one-character difference in a child’s printed name creates immediate line confusion and erodes parent confidence. General agents trained on varied datasets introduce small formatting shifts—middle initial placement, nickname expansion, suffix handling—on roughly one in twelve prints during observed sessions.

One site replaced the general agent with a harness that ingests the exact kiosk template and emits only the permitted string lengths and capitalizations. The model still suggests room assignments, yet the name block passes through a deterministic formatter before printing. Coordinators now treat the kiosk print step as a verification gate rather than a source of surprises. They keep the harness version pinned and reject any model update that would loosen the formatter.

Curriculum export steps that still need the coordinator’s final gate

Sermons4Kids-style exports move from planning screen to printed packet in three clicks for hundreds of volunteers each week. When a general agent was allowed to reorder or condense lesson pages, coordinators lost the ability to confirm that every page carried the correct copyright line and the week’s date. Two teams reported volunteers arriving with incomplete packets because the agent had dropped the final page during generation.

The replacement harness enforces a fixed export sequence and surfaces a single confirmation screen that lists page count, date, and copyright status before the file is released. The coordinator must click “approve” on that screen; the model cannot bypass it. Continuous discovery showed that coordinators accepted the extra click once they saw the failure rate drop.

The harness therefore preserves the human gate without forcing the coordinator to open the full document again. The model proposes, the harness constrains, and the coordinator retains final authority on the artifact that reaches volunteers.

Your Turn: Apply This Today

• Pick the single workflow your current general agent touches most often and list its three hardest constraints in writing before touching any code.
• Replace the general agent call in that workflow with a narrow harness that hard-codes the first constraint as a schema rule rather than a prompt instruction.
• Run the harness on last week’s real data set and count every silent change it prevents; share the count with the coordinator who owns the workflow.
• Pin the harness version and add an explicit rejection rule that blocks any future model update from loosening the second constraint.
• Schedule one 20-minute discovery call this week with the coordinator to watch them use the harness output and note the exact moment they decide to trust it.
• Document the third constraint as a required human gate in the harness and remove the model’s ability to generate the final artifact without that gate.

Frequently Asked Questions

What is a “narrow harness” in an AI ministry workflow?

A narrow harness is a constrained layer that sits between a general AI model and a ministry task. It locks specific fields, formats, and approval gates so the model cannot silently alter protected data like allergy flags, printed names, or curriculum exports.

Why not just use a general-purpose AI agent for everything?

A general-purpose agent optimizes for broad coverage, not for the narrow constraints that keep coordination work safe. It can quietly reformat a custody note or drop a curriculum page, and coordinators often do not discover the change until a volunteer or parent is already affected.

How do I start replacing a general agent with a narrow harness?

Pick the single workflow the general agent touches most, write down its three hardest constraints, and hard-code the first one as a schema rule instead of a prompt instruction. Then run the harness against a week of real data and count every silent change it prevents.

The pattern in “The Volunteer Who Tried the New Voice Agent on a Baptism Outline” and “The Caching Shortcut That Quietly Broke Three Ministry Agents” shows the same erosion when general tools hide failure points instead of surfacing them.

I consult with ministry product leaders and church tech teams on baking deterministic constraints into agent harnesses and running continuous discovery that keeps those gates visible. Let’s talk.

Dear ministry product lead at the mid-sized denomination, the one whose calendar now carries an AI scheduling agent that was supposed to free up the children’s ministry coordinators but instead opened a burnout split between them by week three.

Quick answer: A burnout split happens when an AI rollout quietly rewards the coordinators who already know how to steer it and quietly punishes the ones still doing the work by hand. You close the gap with a standing fifteen-minute, red-pen check-in that forces every agent-generated correction to be named and counted before it disappears into “the agent handles it.”

You see the split forming in real time. One group finishes their Friday tasks by three and leaves notes about how the agent handled the rotation. The other group stays until seven because the same agent keeps routing volunteers to the wrong campuses or printing the wrong lesson counts. You did not ask for this division. It arrived with the rollout.

Charlie Munger’s latticework of mental models makes the split visible before the org chart does. You apply the incentive model to the coordinators who now protect their new free hours. You apply the feedback-loop model to the print-first volunteers whose corrections never reach the agent. When those two models intersect with the small-team constraint that no one can be spared for extra review, the burnout line hardens into something permanent.

The two emotional curves behind every ministry burnout split

The first curve belongs to the coordinators who already worked in spreadsheets. Their output graph rises fast for ten days, then flattens as they learn which prompts keep the agent from hallucinating volunteer names. Their language changes. They start saying the agent “handles it” instead of describing the actual task.

The second curve belongs to the coordinators who still print every schedule and walk it to the volunteer table themselves. Their graph drops for three weeks while they absorb the new failure modes. They absorb the extra thirty minutes per event correcting the agent’s output. Their language changes too. They start saying the agent “adds work” and they mean it literally.

These curves are not personality differences. They are the predictable result of unequal access to the agent’s actual error surface. The first group controls the prompts. The second group only sees the consequences. Munger would call this an unexamined feedback loop that the lattice should have caught at the design stage, and it is the exact mechanism behind every ministry burnout split we have measured.

Why the coordinator’s time-on-task metric predicts the burnout split

Most teams track completion rate or volunteer sign-up numbers. Those metrics stay flat even while the split forms. The sharper signal sits inside the time-on-task number for the single coordinator who owns the agent output each week.

When that number drops below the pre-agent baseline, the early-adopter group gains capacity and begins protecting it. When the same number rises above baseline, the remaining coordinators absorb the delta and begin resenting both the agent and the colleagues who no longer share the load. The metric does not lie about who carries the hidden tax.

At SermonCentral we watched this exact pattern when the print-first curriculum flow met an automated lesson generator. The time-on-task line for the volunteer manager told us within fourteen days which side of the eventual split each person would occupy. We ignored it because the aggregate completion numbers looked fine. That mirrors what Gallup has found in its research on burnout: unclear expectations and unmanageable workload quietly divide teams long before anyone names the problem out loud.

The one intervention that still moves the needle

Managers remain the only control point that can keep the split from becoming structural. The intervention is not another prompt improvement or a new dashboard. It is a standing fifteen-minute check-in that forces the agent output to be named as an added task before it is treated as a removed task.

The check-in works because it surfaces the exact moment the second curve begins to climb. The manager asks one coordinator to walk through the last three agent-generated schedules and mark every manual correction in red ink. The red marks become the only data the room is allowed to discuss for that week.

Teams that run this check-in weekly keep both curves from diverging past the point of repair. Teams that skip it discover six weeks later that the early adopters have been promoted or reassigned and the remaining coordinators have updated their résumés.

Your Turn: Apply This Today

• Block the next fifteen minutes on Thursday morning with the single coordinator who owns the agent output and ask them to print the last three schedules.
• Hand them a red pen and tell them to mark every correction that took more than two minutes of their time.
• Count the red marks out loud and write the total on a sticky note that stays on your monitor until the next check-in.
• Ask the coordinator which one of those corrections could have been prevented by a change in the prompt or the input data.
• Make that one change before the following check-in and bring the new output to the same person for comparison.
• Repeat the entire fifteen-minute exercise next week with the same coordinator and the same red pen, then compare the two sticky notes.

Frequently Asked Questions

What is a “burnout split” in a ministry AI rollout?

A burnout split is the divide that forms between the coordinators who quickly learn to steer a new AI agent and the coordinators left doing manual corrections by hand. One group’s workload shrinks while the other’s grows, even though leadership rolled out the same tool to everyone.

How do I know if my team already has a burnout split?

Compare time-on-task for the coordinator who owns the agent’s output against the coordinators still working manually. If one number is falling while the other is rising, the split has already started, regardless of what the aggregate completion metrics show.

What is the fastest way to close a burnout split?

Run a standing fifteen-minute, red-pen check-in every week. Ask one coordinator to mark every manual correction the agent required, count the marks out loud, and change one input or prompt before the next check-in. The habit surfaces the hidden tax before it hardens into resentment or turnover.

The Burnout Line That Split My Last Ministry Product Team and Letter to the PM Now Asked to Run a Three-Person Generalist Pod both trace the same pattern from different starting points.

I consult with ministry product leads on AI rollout diagnostics and preventing burnout splits in small teams. Let’s talk.