I hit the wall on a Tuesday afternoon when the new volunteer coordinator tried to update a single field in our shared dashboard. The 12-factor checklist said everything should be environment variables and stateless processes. Her machine said she lacked the right role.
We had followed every rule. Twelve clean factors, deployed the same way for three years. Then one person who prints the schedule by hand stepped into the flow, and the whole setup stopped matching reality.
That gap isn’t a config problem. It’s the moment the framework runs out of road.
Where the factors stop at the coordinator’s desk
At one children’s curriculum ministry we once tried to route volunteer sign-ups through an agent built on the usual twelve-factor assumptions. The agent could read the database, write to the queue, and emit clean logs. It could not see that the coordinator kept the final printed sheet in a folder she carried in her purse until the night before the event.
The agent kept writing updates that the coordinator never saw because the update path ended at her email inbox. She checked the folder first. The factor that said “treat logs as event streams” did not account for the fact that the decisive log lived on paper.
Teams keep running into the same wall. They optimize the parts the agent can reach and leave the final decision point outside the model. The agent looks reliable until the first week the coordinator is out sick and no one else knows the folder exists.
Discovery loops that never reach the keyholder
Teresa Torres insists on talking to the people who will actually use or block the output. In most agent projects the loop stops at the ministry director who requested the tool. It never reaches the volunteer who must initial the printed list before it becomes real.
That gap shows up in the data. Completion rates drop the moment the agent output must cross from digital to the person holding the pen. The agent keeps generating correct JSON while the actual schedule remains unchanged for days.
Repeating the interview with the keyholder changes the shape of the work. The question shifts from “How do we make the agent faster?” to “What single artifact must the agent produce that the keyholder will accept without re-entering the data?” The answer is almost never another API call.
Rebuilding the harness around actual permission boundaries
The fix is not to add more factors. It is to map the exact sequence of approvals that already exists in the room and attach the agent only to the steps it can legally touch. At one church the agent now writes a draft to a shared folder, then waits for the coordinator to move the file into the approved subfolder. Only after that move does the agent send the confirmation text.
The same pattern appears when agents try to update sermon resource pages. The system can suggest a new children’s curriculum block, but the final publish button stays behind the editor who still reviews every image for age-appropriate content. The agent records the suggestion and the editor’s decision in the same log, so the next discovery cycle has real data instead of guessed intent.
Teams that rebuild this way stop measuring agent success by lines of code or number of API calls. They track how many handoffs complete without the coordinator having to re-type anything. That single metric forces the design to respect the permission gate instead of routing around it.
Your Turn: Apply This Today
- Pick one agent workflow you shipped in the last quarter and list every human who must approve before the output becomes visible to volunteers.
- Shadow the final approver for one full cycle this week and note exactly which artifact they check first when they sit down.
- Change the agent’s output destination so it writes only to the folder or inbox that person already opens without being asked.
- Remove the agent’s ability to push any change past that single gate until the approver has moved or signed the file.
- Log the time between agent suggestion and approver action for the next ten instances and compare it to the time the agent spent generating the suggestion.
- Bring that timing data to the next planning meeting and adjust the next agent task to reduce the gap by half.
The Permission Gate That Kept the Agent From Running the Schedule and Why Ministry Coordinators Still Ask Me About the Routing Step both trace the same pattern of agents that stopped at the first real handoff.
I consult with faith-tech product leaders on mapping agent workflows to permission boundaries and running continuous discovery inside existing ministry approval chains. Let’s talk.