The Custom Agent We Had to Build After Off-the-Shelf Tools Hit Ministry Data Limits

I was watching the volunteer schedule bot suggest the same three people for nursery again when one of them had just texted that her kid’s chemo started that week. The model had pulled the public calendar clean. It just didn’t know what the calendar never says out loud.

That’s where every off-the-shelf agent we tried eventually ran out of road. Ministry data isn’t sitting in tidy tables. It lives in the half-finished Slack threads, the voice memos from the hospital parking lot, and the things only three elders know to keep quiet.

We kept hitting the same wall until we stopped trying to bolt their framework onto our reality and started building one that could actually carry it.

The assumption that general agents will just plug in

Most teams start by connecting a commercial agent to whatever calendar or messaging system already exists. The connection works for surface events. It fails the moment the agent needs to read the private note that says “do not assign this family to the 9 a.m. service because of the ongoing custody situation.” That note exists in a shared document the public agent cannot reach without violating the ministry’s own access policy.

The gap is not technical ignorance. It is policy. The public agent has no representation of the rule “pastoral staff only” that lives in the team’s actual practice. When the agent guesses, it either over-shares or under-serves. Either outcome erodes trust faster than the productivity gain can recover.

Teams that persist with the plug-in approach end up writing longer prompt instructions. The instructions grow brittle. One change in volunteer policy requires rewriting the prompt across every agent instance. The maintenance burden quickly exceeds the original time savings.

What sovereign control actually changes in practice

Sovereign control begins with the data layer, not the model. The custom agent we built only ever saw data that had already passed through the ministry’s existing permission checks. Volunteer phone numbers stayed inside the private directory. Schedule conflicts stayed inside the internal ticket system. The agent received only the minimal subset required for the task and returned output that the same permission system then routed.

That boundary altered daily work in three concrete ways. First, the agent could safely propose schedule swaps because it never proposed a swap that violated an elder’s private availability note. Second, the output carried an audit trail that matched the ministry’s existing record-keeping, so staff could trace every suggestion back to the source data without additional logging. Third, the agent refused tasks when the required data sat outside its boundary, surfacing the refusal to a human instead of hallucinating a workaround.

The change also shifted metrics. We stopped tracking “agent tasks completed” and started tracking “volunteer completion rate on the revised schedule.” The latter number moved because the agent respected the real coordination patterns rather than the public calendar approximation.

Where the boundary sits between buy and build

The decision rule we now use is simple. If the workflow only touches data that already appears in a public API and carries no private coordination rules, a commercial agent is acceptable. If the workflow touches any data that the ministry treats as internal—availability notes, pastoral handoffs, child-protection flags—the agent must be built or heavily forked inside the sovereign boundary.

That rule eliminated two common vendor proposals. One suggested routing all volunteer texts through a shared LLM endpoint. The endpoint would have required exporting the private notes. Another offered a calendar-sync agent that could read the full shared drive. Both were rejected because they crossed the boundary we had already drawn for human staff.

The build path is narrower than it first appears. We reused open models for the language work and kept the routing logic inside code we already maintained for the ministry’s internal tools. The new agent became an additional consumer of the same permission service rather than a separate system. That reuse kept the scope small and the security posture consistent.

Your Turn: Apply This Today

• Pick one recurring workflow that currently routes through a shared calendar or messaging tool and list every private note or access rule that human coordinators already apply before they act.
• Trace the exact data fields an agent would need to read in order to propose the next action in that workflow, then mark which fields sit behind an existing permission check that no public API exposes.
• Write the refusal message the agent should return when it encounters a data request that crosses the permission boundary, and test it against the last three real schedule changes your team handled manually.
• Identify the single internal system that already enforces the permission rules for that workflow and confirm the agent can call it without exporting raw records.
• Run a one-week audit where you log every instance a human overrode or corrected an off-the-shelf agent suggestion, then tag each override with the private rule the agent missed.
• Schedule a 30-minute review with the two staff members who handle the most handoffs in that workflow and ask them to name the one data access rule they would never want surfaced to a general model.

The Night the New Career Tool Asked the Wrong Job and The Data Moat That Actually Matters for Small Ministry Teams both explore the same tension between public tooling and private coordination rules.

I consult with ministry product leaders on defining sovereign data boundaries for agents and auditing workflows that cross public and private coordination layers. Let’s talk.