The general-purpose harness model from the LangGraph tutorials and OpenAI’s function-calling examples claims any workflow can be handled by a single agent equipped with a broad set of tools and a loose permission layer. The model treats ministry operations as just another set of tasks that an LLM can route through generic APIs. Ministry coordinators who tried this approach found the opposite: the agent would propose actions that violated child-protection policies, bypassed elder approval, or scheduled volunteers who had already declined. The harness never encoded the actual constraints, so every run required manual rollback.
Seneca wrote letters that responded to one correspondent’s precise circumstances rather than issuing universal rules. That correspondence rule exposes why the general harness collapses in church settings. A letter addressed the recipient’s actual limits; a treatise did not. The same distinction applies to product work. When the harness stays general, it cannot enforce the specific boundaries that keep ministry safe and accountable.
This is the foundational misread that causes product teams to ship agents that coordinators quietly disable after the first compliance incident.
Curriculum approval loops
A children’s ministry director at a mid-sized church once connected a general agent to their resource library. The agent could search, summarize, and suggest edits. Within a week it recommended a lesson that had been flagged for theological review two quarters earlier. The agent had no record of the flag because the harness treated every document as equally available.
Under Seneca’s rule the adapter would have opened by asking which elder held final sign-off for that quarter and which topics required a second reader. Only after those two checks passed would the agent surface the file. The narrow harness made the permission boundary visible before any generation step began.
Coordinators who kept the general harness eventually added a spreadsheet outside the agent to track the same flags. The extra table became the real system; the agent became a search box. The cost was duplicated data entry and eroded trust in the automation.
Child-checkin permission gates
Check-in systems already contain strict rules about who may release a child and under what conditions. A general-purpose agent given access to the check-in API quickly suggested moving a volunteer from one station to another without confirming that volunteer’s background-check status. The suggestion arrived in the coordinator’s inbox before anyone noticed the mismatch.
The narrow harness built for that church first queried the volunteer database for the exact clearance timestamp, then checked the current ratio of cleared adults to children in the room. Only when both conditions held did the agent offer the reassignment. The correspondence-style prompt made the safety constraint the first sentence of every run.
Teams that skipped this step reported that volunteers began ignoring agent suggestions altogether. They preferred the slower manual list because it had never placed a child at risk. The general harness had optimized for speed while the actual metric was zero policy violations.
Volunteer schedule overrides
Most scheduling tools allow an override when someone drops out. A general agent given that capability began reassigning people across campuses without confirming whether the new volunteer had completed the required training for that specific age group. The override succeeded in the software but failed the moment the volunteer arrived unprepared.
Seneca’s correspondence rule requires the writer to know the recipient’s exact obligations before offering advice. Translated to the adapter, this meant every override request first retrieved the volunteer’s training record, the campus policy on cross-training, and the elder who could grant an exception. The harness refused the change until all three returned true.
Coordinators who adopted the narrow version stopped receiving 11 p.m. texts from volunteers who had been assigned outside their comfort zone. The general harness had removed friction for the agent; the constrained harness removed friction for the people executing the schedule.
Your Turn: Apply This Today
- Choose the single ministry workflow that generates the most manual overrides this month and export its last thirty instances into a shared document.
- Interview the coordinator who owns that workflow and list every explicit permission rule they apply before approving an action; keep the list under twelve items.
- Write a one-page adapter spec that inserts those rules as the first conditional checks the agent must satisfy before calling any tool.
- Build a minimal custom harness in the language your team already uses—ten to fifteen lines of guardrail code is enough for a first version.
- Run the harness against the thirty exported instances and count how many now fail the encoded rules before any downstream action occurs.
- Present the failure count and the revised adapter to the coordinator within seven days; ask which single rule still needs tightening.
The Routing Step Ministry Teams Still Can’t Automate and The Children’s Check-In Desk That Suddenly Spoke Back both trace the same pattern of hidden permission boundaries that general agents never surface.
I consult with ministry product leaders on encoding permission constraints into AI agents and designing narrow harnesses for volunteer workflows. Let’s talk.