I stood at the back of the fellowship hall on a Tuesday night, watching the small-group leader flip through printed notes on her phone because the PDF from the agent never made it to her inbox in time. The questions were solid. They just didn’t reach the person who actually had to ask them.
That was the third prototype. The first two had already gone the same way—clean demos, then silence once real people had to carry the output across the actual week. I kept thinking the problem was the prompting or the chaining. It wasn’t.
The constraint was never the model. It was the handoff that happens between one person’s work and another’s lived responsibility, the same quiet transfer the church has always depended on.
Teresa Torres’s continuous discovery work makes the same point about product teams who interview users once and then build. The method only works when teams keep returning to the actual moments when someone accepts or rejects the work. In agent projects, that means mapping the exact gatekeepers and formats that determine use, not just testing prompt quality.
Where the fluency training stopped short
Our first prototype handled volunteer reminders. The agent pulled from a shared calendar, wrote personalized texts, and scheduled them. In the sandbox it looked clean. When we ran it against the actual Monday morning routine, the coordinator who approves every outgoing message still needed a printed list to cross-check against the physical sign-in sheet she carries. The agent never produced that list, so the texts stayed in draft.
Fluency had taught us to measure correctness of the reminder text. It had not taught us to measure whether the coordinator could complete her existing Monday checklist without adding new steps. Torres would call this an interview that stopped at the moment of delight instead of continuing to the moment of rejection.
The second prototype generated adapted curriculum for different age groups. The output passed every internal review. The volunteer who actually teaches the class works from a single printed page she receives on Wednesday night. The agent delivered a multi-page document inside a shared drive folder she does not open. Again, the output existed; the handoff did not.
How discovery loops exposed the real gates
We shifted to weekly fifteen-minute calls with the actual people who would receive the agent output. We asked only two questions: what arrives on your desk or phone the day before you need it, and what format lets you finish your current checklist without starting a new one. The answers were never about model performance.
One coordinator keeps a physical three-ring binder. Another volunteer opens email only on a shared church computer after evening events. A third person routes every schedule change through a single admin who updates a whiteboard. These were not edge cases. They were the operating system.
Continuous discovery turned these details into testable assumptions. Each week we adjusted the agent to produce the exact artifact that already fit the existing gate, then watched whether it survived the next handoff. Most versions failed the first live test. The surviving version for scheduling now outputs a single column of names and times that prints on half a page and lands in the binder.
Rebuilding the evaluation step around live constraints
We stopped scoring prototypes on prompt accuracy alone. The new rubric asks whether the output reaches the person who must act on it, whether that person can complete their existing task without new friction, and whether the next person in the chain receives what they expect. These three checks happen inside the actual workflow, not in a demo environment.
The change also altered how we chose which agent to build next. Instead of starting with the most technically interesting task, we now start with the narrowest permission gate we can observe. If the gate requires a printed page delivered by a specific person on a specific day, the agent must produce that page in that format or it fails the first discovery loop.
This approach surfaces constraints earlier and keeps the team from investing weeks in fluent but unusable systems. The cost of the earlier prototypes was not wasted compute. It was the months during which real scheduling and curriculum decisions continued without any agent support at all.
Your Turn: Apply This Today
- Pick one current AI workflow your team runs and list every person who must approve or receive the output before it reaches the end user.
- For each person on that list, note the exact format and timing they currently use to complete their part of the task.
- Run the agent once and deliver its output to the first gatekeeper exactly as they would receive it in a normal week; observe whether they can finish their step without extra work.
- Document the first rejection or workaround you see and adjust the agent to remove that single friction before testing the next gate.
- Repeat the loop with the same workflow until the output survives three consecutive live handoffs without modification.
- Write the permission and format requirements into the project brief before starting the next agent build.
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 fluent tools that never cleared the actual handoff steps.
I consult with product leaders in faith-tech and ministry organizations on mapping AI agent workflows against real permission gates and handoff constraints. Let’s talk.