Named Specialists Beat the General Ministry Agent Every Time

I watched a volunteer delete an entire morning’s work after the general agent we’d pointed at everything—prayer requests, donor notes, facility bookings—decided to “help” with a counseling ticket. It had pulled a real name from an old database and offered the person a tidy paragraph of advice that was neither asked for nor accurate. The volunteer sat there refreshing the sent folder, realizing she now had to call someone and explain that a machine spoke on behalf of the church.

That single reply cost more time than the agent had ever saved us. The problem wasn’t malice. It was that nothing inside the system told it where its job stopped. What we needed instead were named specialist agents, each built around one job and nothing else.

Solomon didn’t split the difference between two mothers. He named the one thing that actually mattered and refused every other claim. Every specialist agent that has worked for us since has followed the same logic: name one job, and refuse everything outside it.

The named specialist agent that only handled roster updates

One team replaced a broad scheduling agent with a single specialist whose only job was to propose roster changes and nothing else. The specialist could read availability data, suggest swaps, and flag conflicts, but it had no ability to send notifications or update the calendar. Every proposal landed in a human queue.

The restriction forced the model to stay precise about dates and roles instead of guessing at downstream effects. Volunteers noticed the difference immediately. They stopped receiving messages that assumed they could cover a shift they had already declined. Acceptance of the suggestions rose because they arrived already vetted for basic accuracy.

The same team had previously tried to give the general agent more context and better prompting. Those changes reduced errors only marginally. The hard boundary around roster updates cut the error rate roughly in half without any increase in model size.

The approval gate that saved the finance team from three bad decisions

A different group added an explicit approval step before any agent could move budgeted funds between categories. The agent could draft the transfer, calculate the impact on remaining line items, and write the justification, but the actual ledger change required a named human to approve.

In the first month the gate caught three separate proposals that would have left a children’s event underfunded because the agent had pulled stale enrollment numbers. Each case was small enough that a human reviewer might have missed it under time pressure. The gate made the mismatch visible before the transfer executed.

The finance lead later said the real value was not the catches themselves but the change in how the team talked about the agent. Instead of treating it as an autonomous decision maker, they treated it as a drafter whose work required sign-off. That shift removed the background anxiety that had accompanied every automated suggestion.

How multi-account support actually worked when each agent stayed narrow

A ministry platform supporting several hundred small churches tried one agent for all account questions and watched response quality collapse. The agent mixed data between accounts, offered features that belonged to a different pricing tier, and occasionally referenced another church’s custom fields.

They split the work into three named specialists: one that only read public plan details, one that only handled data export requests, and one that only opened tickets for human review. Each specialist carried its own job title and its own approval gate for any action that touched account data.

Support staff reported that the volume of follow-up corrections dropped sharply. When a user asked about exporting attendance records, only the export specialist responded, and it refused to touch any other data type. The narrow scope made the handoff to a human reviewer obvious rather than hidden inside a long, plausible-sounding reply.

Your Turn: Apply This Today

• Open your current agent list and rename the broadest one with a single, real job title such as “Roster Change Drafter” instead of “Ministry Assistant.”
• Pick one meaningful action that agent currently performs and route it through an explicit human approval step this week.
• Write the refusal message the agent will show when a user asks it to do anything outside its new title.
• Test the renamed agent against the last three requests it handled incorrectly and confirm it now declines the ones that fall outside its lane.
• Share the job title and approval rule with the two people who review its output most often and ask them to flag any drift.
• Schedule a thirty-minute review next Friday to decide whether the second agent on your list also needs its own title and gate.

The same pattern of narrow titles and visible gates appears in both “The PM Who Just Shipped an Agent and Now Needs an Evaluation Layer” and “The Evaluation Layer That Broke When We Trusted the Model Alone.”

I consult with product leaders building AI agents for ministry contexts on specialist design, approval workflows, and trust boundaries in multi-agent systems. Let’s talk.