The Ministry Director Who Watched Three Agents Draft Schedules She Could Not Edit

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.