Blog

She sat at the kitchen table after the house had gone quiet, one hand on her phone and the other keeping her toddler from sliding off her lap. Three new schedules waited on the screen. Every one of them put volunteers back into rooms she had already closed, at times that would force her to start calling parents again.

The agents had moved fast. They just hadn’t moved inside the actual constraints—the ones that only show up after you’ve done the work for years and know which names can’t be used and which spaces are already spoken for.

That gap is where most tools break.

Solomon’s judgment offers the clearest lens here. Two women claimed the same living child. Solomon proposed dividing the child in half. The true mother immediately refused the proposal and surrendered her claim rather than see the child destroyed. The false mother accepted the division. Solomon identified authority by who possessed the right to say no to the wrong solution.

When Embedded Thinking Meets Ministry Reality

The same pattern appears in every agent-assisted scheduling system I have watched roll out. Engineering teams embed preference rules, capacity limits, and volunteer history into the model. The model produces a clean table. The person who actually runs the ministry then spends the next evening correcting names, locations, and conflicts the model never saw.

The problem is not the quality of the code. The problem is that the final authority still sits with the person who must live with the result, yet the system treats that person as a reviewer rather than a decider. In one children’s ministry rollout I observed, the volunteer coordinator received a schedule that reassigned three teachers who had already told her they were unavailable for the entire quarter. She had entered that information herself. The agent had overwritten it because the optimization score improved when those names were included.

The director at the kitchen table faced the identical situation. She could accept the schedules and create confusion for families, or she could reject them and lose the evening she had planned for other work. Either path left the real decision in her hands after the agents had finished.

The Authority That Cannot Be Automated

Solomon did not ask the women to negotiate a compromise. He tested which one held the actual claim by offering an outcome neither would accept if they were the true parent. The test worked because authority was defined by the willingness to stop the process rather than by the ability to generate options.

In agent systems the equivalent test is simple. Can the person responsible for the outcome delete or rewrite an entire agent result without needing approval from another system or another role? Most current setups fail this test. The agent output moves into a review queue. Suggested edits require the original prompter to re-run the agent. The human who must execute the schedule has no direct way to mark the output as invalid and move on.

I have seen this in curriculum planning tools as well. A volunteer ministry director receives a lesson plan that references a story the church no longer uses. She knows the replacement story and the reason for the change. The system offers her a comment box. It does not offer her a button that says “this output is rejected; generate nothing further until I approve a new constraint.” The difference matters on a Tuesday night when the toddler needs to go to bed.

Keeping the Human Who Can Still Say No

The practical requirement is therefore not better prompts or cleaner data. The requirement is an explicit handoff of final authority to one named person who can veto the entire agent output in one action. That person must be outside the engineering or product team that built the agent. Their veto cannot be overridden by score thresholds or escalation workflows.

In the churches where this has worked, the rule is written down. One volunteer coordinator owns Tuesday night schedules. One children’s director owns room assignments. Their names sit in the system record next to the constraint “agent output requires this person’s explicit approval before distribution.” When they reject an output, the agent stops. It does not suggest alternatives until they release it.

This matches the Solomon test. The person who can stop the division holds the real authority. Everyone else is negotiating after the fact.

Your Turn: Apply This Today

• Pick one recurring agent output in your current workflow and assign a single named person outside the build team the right to reject it in full with one click.
• Update the system record so that rejection halts any further agent runs on that task until the named person clears it.
• Write the rejection rule in one sentence and place it in the shared project doc by Friday.
• Test the rule this week by having the named person reject one live agent output and confirm the system does not generate replacements without their release.
• Review the last three agent outputs you accepted and identify which one the named person would have rejected if given the chance.
• Schedule a ten-minute check-in with that person next week to hear what the rejected output would have broken for them.

The same authority question shows up again in the agent that kept running the schedule while no one was watching and in the three-person pod that still needed a fourth set of eyes.

I consult with ministry product leaders on agentic scheduling systems, explicit veto rights, and volunteer workflow ownership. Let’s talk.

I still have the notebook. The 2018 plan sits on page 47, each role written in the same blue pen, connected by straight lines like train stops. No erasures, no extra space.

Two years later an email landed about redesigning how volunteers passed curriculum between sessions. The description didn’t match anything on that page, so I closed it. The person who took the role later told me they had finished the work in six months and were already moving on to the next constraint no one had noticed.

My plan had taught me to wait for the next printed station. It never trained me to see the editable handoff sitting right in front of the tracks.

John Wesley’s three simple rules give a different lens. Do no harm. Do good. Stay in love with God. Wesley used them as daily constraints that anyone in the movement could apply without waiting for permission from the center. The rules did not prescribe outcomes. They kept the next action editable by the people closest to the work.

The plan that locked out the right next captain

I had written the five-year map after a promotion at a curriculum platform. The document assumed I would move from feature owner to group lead to director by a certain date, with specific products attached to each step. When an internal project surfaced that needed someone to hand curriculum ownership to volunteer teams without breaking their weekly rhythm, the map offered no category for it.

The person who stepped in instead treated the role as a temporary container. They set three constraints: the volunteer must finish the handoff in under seven minutes, the output must be printable without further edits, and the next volunteer must be able to change any line without asking permission. Within four months the completion rate for that curriculum doubled. My plan had no room for that kind of container because it measured progress by title sequence, not by whether the actual owners could still edit the work.

How Wesley’s rules expose the hidden constraint in long-horizon PM tracks

Wesley’s first rule, do no harm, translates directly to role design. A five-year plan that cannot be altered by the people who will live with the outcomes does harm by removing their agency before they arrive. The second rule, do good, requires that the next step produce something usable by the current owners rather than something that merely advances the planner. The third rule, stay in love with God, keeps the mission itself from becoming an idol that justifies locking the path.

Most PM career ladders still treat the next title as the measure. They ask for evidence of scope growth, headcount managed, and roadmap ownership. Those signals assume the mission stays the same shape. When AI changes the shape of the work faster than the ladder can update, the signals start rewarding people who protect the old map instead of the people who keep the actual work editable. The three rules surface the constraint because they force every role description to answer whether the next person can still change it without breaking the mission.

What changes when you treat every role as a three-rule loop instead of a title ladder

At one ministry product team the group lead stopped writing annual role charters. Instead each role carried the three constraints written on a single card: the output must remain changeable by the person who runs the session, the change must not increase time for the volunteer, and the mission metric must stay visible without extra reporting. The card could be rewritten by the volunteer owner at any time.

Within a quarter the same team had handed off two senior PM responsibilities to people who had never held the title. One person redesigned the print handoff process. The other built the check that prevented the agent from running a schedule when no one was watching. Neither move appeared on anyone’s five-year map, yet both moves kept the real owners in control of the outcome.

The pattern repeats when the rules stay short. A role becomes a loop that the next captain can still edit rather than a destination that must be defended. The ladder disappears because the measure is whether the constraint set remains small enough for the actual owner to rewrite it.

Your Turn: Apply This Today

• Take your current role description and delete every sentence that names a future title or scope level.
• Replace the deleted lines with exactly three constraints written so the person who will inherit the work can still change any one of them without your approval.
• Send the revised card to the two people who actually run the sessions or own the outcomes this week and ask them to strike or add one line.
• Schedule a thirty-minute review next week where those two people present the updated card and you only record what they changed.
• Apply the same three-constraint rewrite to one open role on your team before the next hiring conversation.
• Archive the original five-year plan document and replace it with a single note that lists only the three constraints active this quarter.

The same pattern shows up in how the agent kept running the schedule while no one was watching and in how the three-person pod still needed a fourth set of eyes to keep the handoff editable. Both cases turned on whether the people closest to the work could still change the constraint set without waiting for the original planner.

I consult with product leaders and ministry PMs on rewriting role constraints for AI speed, keeping handoffs editable by actual owners, and designing three-rule loops instead of title ladders. Let’s talk.

I still remember the look on our backend engineer’s face when the first support thread came through. A volunteer in Manila had tried to update the service schedule and the whole thing locked her out during the one hour she had between shifts. He had written the migration. He saw her name in the logs.

He stopped asking the product channel for clarification after that. Instead he started calling the users himself before the next deploy, then quietly rolling back anything that still felt shaky.

The PM role we had hired six months earlier never got replaced when she left.

Why the ‘regret that PM exists’ test fails in faith-tech contexts

Ministry tools rarely produce the clean failure signals that force engineers to feel the weight. A children’s ministry volunteer prints a lesson at 9 p.m. on Saturday, notices the activity page is missing a key instruction, and simply skips the activity. No ticket arrives. No usage metric drops. The engineer ships the next feature without ever learning the volunteer adapted around the gap.

This pattern repeats across curriculum platforms. The people who absorb the friction are part-time leaders who treat the software as one more unreliable volunteer rather than a product they can influence. Because the cost stays diffuse, the team concludes the feature set works and adds another layer of coordination instead of removing it.

The test therefore misleads. It assumes regret travels back through usage data or direct complaints. In practice the data stays clean while the real ministry outcome quietly degrades. Teams then reintroduce a product manager to interpret the silence, recreating the very distance the minimal structure was meant to close.

How discovery loops break when the person who feels the outcome never talks to the user

Continuous discovery requires the builder to hear the user describe the job in their own words before any wireframe appears. When an engineer never joins that conversation, the first version already encodes assumptions that only surface after launch. The product manager becomes the single point of translation, and every subsequent iteration passes through the same filter.

Over time the engineer learns to wait for requirements rather than seek the original need. The volunteer who once would have shown the broken flow now speaks to someone whose job is to summarize. The detail that would have changed the implementation gets lost in the handoff, and the next release solves a slightly different problem than the one the user described.

The loop does not fail because the product manager lacks skill. It fails because the person who will later defend or refactor the code never experiences the mismatch between intention and result. Torres’s framework collapses without that direct exposure, regardless of how many discovery meetings the middle layer schedules.

The handoff pattern that actually survived when we removed the middle layer

One small team kept a working rhythm after dropping the dedicated product role by requiring the engineer who would implement a change to attend the next two user conversations and own the decision to ship or rework. The rule applied even to small curriculum updates pulled from third-party sermon resource libraries. The engineer heard the volunteer explain why a certain age group needed the story repeated twice before the activity began.

That single change altered the definition of done. Instead of handing a spec to another person, the engineer carried the user’s phrasing into the implementation and later checked whether the printed page matched what the volunteer had described. When it did not, the same engineer adjusted the template without reopening a planning meeting.

The pattern held because the regret stayed attached to the code author. A missed detail on a children’s lesson now meant the engineer would field the follow-up email from the volunteer the next Sunday. Over months the team shipped fewer features but completed more of them in ways that actually reduced the volunteer’s Saturday-night scramble. The structure worked only while the engineer remained the owner of both the change and its consequences.

Your Turn: Apply This Today

• Pick one upcoming change to the print export flow in your curriculum tool and schedule a 25-minute call with a current children’s ministry volunteer this week; have the engineer who will code the change sit in and take notes without speaking for the first ten minutes.
• After the call, require that same engineer to write the acceptance criteria in the volunteer’s own words before any code is written and share the draft with the volunteer for one round of confirmation.
• Set a calendar reminder for seven days after the feature ships so the engineer must review the actual printed output with the same volunteer and record what still required workarounds.
• Remove any product-manager-only review step for changes under a certain scope and replace it with a required user conversation log that the engineer must attach to the pull request.
• Track the number of post-release adjustments that originate from the engineer rather than from support tickets for the next four releases and compare the count to the prior four.
• If the engineer reports that the user conversation changed the original plan, document the specific sentence from the volunteer that triggered the shift and keep the note visible in the next planning session.

The handoff patterns described here connect directly to the constraints visible in The Refactor That Finished in Two Days and Then Sat for a Week and the bottleneck analysis in Faster Code Does Not Move the Real Ministry Bottleneck.

I consult with product leaders in ministry tools on continuous discovery practices, regret ownership in engineering teams, and sustainable handoff patterns without added layers. Let’s talk.