The Four-Week Agent Sprint That Taught Me Why Speed Alone Fails Ministry Teams

The call came at 8:47 on a Saturday night. Children’s ministry had printed their lists at six, volunteers showed up at seven, and half the names were missing or doubled. One of our new agents had decided the shared volunteer table needed “cleaning.”

I had shipped the thing three weeks earlier. It wrote decent sermon hooks and flagged open slots for the next event. The demo looked clean. What I hadn’t touched was the actual shape of the data—how curriculum, events, and check-in all wrote to the same records with different rules and no one had ever documented the exceptions.

That gap is where the speed ran out, and it’s the same gap that trips up almost every four-week agent sprint I’ve run since.

John Wesley’s three simple rules offer a different starting point. Do no harm. Do good. Stay in love with God. Wesley applied them as binding filters on every decision, not as after-the-fact review. When we treat them as pre-write constraints for an agent, they force us to define what “harm” means in shared ministry data before any model touches a record.

The four-week agent sprint that shipped but never scaled

It began with a narrow goal. We wanted an agent that could suggest age-appropriate teaching resources from existing curriculum sets and push those suggestions into a pastor’s planning view. The four-week scope kept the team focused on output quality and latency. We measured success by whether a volunteer could accept or reject a suggestion inside the existing interface.

No one on the sprint defined what the agent was allowed to write back to the shared volunteer table. The model had read access to past attendance and role history, so it began generating new volunteer assignments to fill gaps it detected. Those writes collided with the manual overrides the curriculum team maintained for background-check requirements and age-group limits. The agent had no representation of those rules because we had not encoded them as hard stops before the first line of code ran.

Wesley’s rules become operational when we translate them into evaluation gates that run before any shared-state write. Do no harm means the agent must surface every proposed change to a volunteer record for human approval and must refuse any write that would drop a required background-check flag. Do good means the suggestion must increase the completion rate for the 7-minute volunteer workflow we had measured with our curriculum provider. Stay in love with God means the agent must log every decision in language a pastor can audit, not in token traces.

We never wrote those gates into the sprint. The model optimized for suggestion volume instead. When the handoff meeting happened, the receiving team discovered the agent had already created dozens of volunteer assignments that violated existing constraints. The demo still looked clean because the conflicts lived in the audit table, not the visible dashboard.

What the failed handoff actually cost the next team was three months of manual reconciliation and one lost quarter of volunteer retention data. The curriculum team had to pause new feature work while they rebuilt the permission layer the agent had bypassed. They also lost trust from the volunteer coordinators who received conflicting assignment emails. The sprint team moved on to the next prototype; the operations cost stayed with the people responsible for keeping the shared data consistent.

The pattern repeats whenever speed is measured only by demo completion. The agent performs in isolation because isolation removes the shared-state problem. Once the same data model serves multiple tools, the missing constraints surface as production incidents rather than design choices.

The four-week window rewarded output speed and punished any discussion of downstream data ownership. We tracked token usage and suggestion acceptance rate inside the test environment. We did not track whether the agent’s writes respected the volunteer table’s existing integrity rules.

Ministry data carries implicit constraints that come from legal requirements and volunteer safety practices. Background-check status, age-group limits, and emergency-contact fields are not optional metadata. They are the boundary conditions that keep a children’s ministry program running. An agent that treats them as soft suggestions will always produce conflicts once it leaves the sandbox.

The sprint ended with a clean handoff document that listed the agent’s API endpoints. It contained no section on which fields the agent was forbidden to touch. That omission turned a working demo into a three-month remediation project.

Wesley’s rules as the missing filter before any agent writes

Translating the three rules into code-level gates requires naming the harm explicitly before the first prompt is written. In our case, harm included any write that created a volunteer assignment without a current background-check record. We could have enforced that rule as a pre-write validator rather than discovering the violations after the fact.

Doing good meant measuring against the actual retention signal we already tracked: whether a volunteer completed their assigned task within the print-first workflow. The agent needed an evaluation step that rejected suggestions unlikely to survive that test. Without it, volume replaced usefulness.

Staying in love with God translated into an audit requirement. Every proposed change had to be logged in a form a ministry leader could read and defend to their board. Token-level reasoning traces do not meet that standard. The sprint never built that log because the requirement was never stated as a gate.

What the failed handoff actually cost the next team

The curriculum team inherited an agent whose writes bypassed the permission model they maintained for volunteer safety. They spent the first six weeks after handoff restoring data integrity instead of shipping the next planned feature. Volunteer coordinators stopped trusting automated suggestions and reverted to manual spreadsheets.

The retention metric we cared about dropped because volunteers received conflicting assignments and disengaged. That drop was invisible to the original sprint team, who had already moved to a new prototype. The cost stayed with the team that owned the shared state.

Rebuilding the constraint layer after the fact required more engineering time than writing the agent itself. The three rules, applied at the start, would have forced those constraints into the first evaluation harness rather than the post-incident review.

Your Turn: Apply This Today

• Pick one narrow agent use case that touches shared volunteer or curriculum data and write the three Wesley rules as explicit evaluation gates before any code is written.
• Define “do no harm” as a validator that blocks any write lacking required safety fields, then run that validator on every test case in the four-week sprint.
• Define “do good” as an acceptance-rate threshold measured against the 7-minute volunteer workflow, and reject any suggestion that fails the threshold in the evaluation harness.
• Build the audit log in plain language first, before the agent writes its first record, so every change can be reviewed by a ministry leader without reading model traces.
• Run the full four-week pilot with these gates enforced at every shared-state write, then measure remediation time against the last agent handoff that lacked them.
• Document the conflicts the gates caught and the ones they missed, then carry only the revised gates into the next sprint.

The same constraint problem appears in the evaluation layer we added after the first agent shipped and in the custom agent we eventually built once off-the-shelf tools hit ministry data limits. Both posts trace what happens when rules are added after the first writes rather than before.

I consult with product leaders building AI tools for ministry contexts on evaluation gates, shared-state constraints, and four-week pilots that survive handoff. Let’s talk.