Letter to the PM Who Just Inherited the Ministry Agent Schedule

I got the handoff on a Tuesday afternoon. Three folders, a half-broken prompt chain, and a Slack thread already full of people asking why the same six volunteers kept getting double-booked for nursery.

By Thursday the children’s director had already texted twice. The model kept assigning people who had never once shown up on a Wednesday night, and nobody had told it that the retired couple who always say yes actually mean “only if it’s before six.” I stared at the availability sheet and realized the real schedule lived in people’s heads and in ten years of unspoken patterns, not in the columns I could actually feed it.

That’s the part that breaks these agents. Not the prompt engineering. The part where the church’s actual life never made it into the data.

That is the foundational misread of a ministry agent schedule: it pushes product teams to chase model upgrades instead of taking ownership of the update loop. The schedule agent already has enough capability. What it lacks is a reliable way to absorb the recurring changes that volunteers experience and that no static form ever records.

Start by mapping every recurring volunteer state change

Begin with the states that repeat across every quarter. A volunteer moves from “available” to “unavailable” when a child starts sports. Another shifts from “willing to lead” to “willing to assist only” after a health change. These are not edge cases; they are the normal rhythm of ministry life.

Document each state with the exact trigger that flips it. Do not rely on the agent’s current form fields. Walk through the last three scheduling cycles with the actual coordinators who sent the correction emails. Capture the language they used in those corrections, not the language the form asked for.

Once the states are listed, turn each one into a short context file the agent can read on every run. Keep the files plain text and versioned. The goal is not richer data models. The goal is a living record that matches how the volunteers actually describe their constraints.

Instrument the feedback loop that actually updates context

Most agents receive feedback only after the schedule is already published. That timing is too late. Build the loop so that any correction a coordinator makes in the shared spreadsheet or group thread writes directly back to the relevant context file before the next scheduling cycle begins.

Test the loop with the smallest possible set of volunteers first. Choose one age group and one service time. Measure how many corrections still require a human to intervene after the agent has run. If the number does not drop within two cycles, the feedback path is still missing a state change.

The architecture matters more than the model. A smaller model that receives accurate, timely context files will outperform a larger model that continues to guess from outdated availability data. Ownership of that update path belongs to the product manager, not the engineering team that owns the model endpoint.

Protect the non-delegable judgment calls at schedule boundaries

Some decisions cannot be handed to the agent even with perfect context. A last-minute funeral, a sudden pastoral crisis, or a family emergency that surfaces only hours before the service all require human judgment that sits outside any file. Identify those boundary conditions now.

Create a simple rule: the agent may propose, but it never publishes without an explicit human confirmation step at those boundaries. The confirmation does not need to be elaborate. A single Slack reaction or a checkbox in the same thread where the correction arrived is enough.

Keep a short log of every overridden proposal. Review the log monthly. The overrides reveal the next set of state changes that belong in the context files. Over time the boundary shrinks, but it never disappears.

Your Turn: Apply This Today

• List the three most common state changes in your current volunteer coordination and write each one into its own plain-text context file the agent can read on the next run.
• Pick one volunteer coordinator and ask them to send their next correction directly into the shared file instead of the group chat, then confirm the agent incorporated it before the following schedule.
• Mark the three schedule boundaries where a human must still approve publication and add that approval step to the agent’s current workflow this week.
• Review the last month’s override log with the team that actually publishes the schedule and add any missing triggers to the context files before Friday.
• Run the agent on a single service time using only the new context files and count how many manual corrections still appear.
• Schedule a thirty-minute review with the same coordinator next week to adjust the files based on what the run revealed.

The same pattern shows up in The Night the New Career Tool Asked the Wrong Job and The PM Role That Still Needs Human Judgment After Agents Ship. Both posts trace what happens when teams treat agents as finished rather than as correspondents that need ongoing, owned updates.

I consult with product leaders building agent systems for ministry teams on context file architecture, volunteer state mapping, and protection of non-delegable judgment calls at schedule boundaries. Let’s talk.