Blog

The cursor spun for three full seconds before the folder finally refreshed. Maria leaned over the laptop on her kitchen island, one hand still holding a half-zipped backpack, the other clicking the refresh button a second time. Outside the window the sky was still dark blue. Inside, the new agent had overwritten the Sunday curriculum PDF at 2:17 a.m., and now the page numbers no longer matched the printed leader guides stacked on the counter. This is what happens when a workflow drops the human in the loop: the agent acts on its own data and no person reviews the result before it ships.

She opened the file. The volunteer names that had been added by hand last Tuesday were gone. The craft-supply list on page three had shifted to page five. She checked the clock, then opened the group chat. Three volunteers had already asked which room they were in this week. One message sat unread from 6:15: “Printout looks different. Is this right?”

Maria did not answer. She started scrolling instead, trying to rebuild the missing pieces before the first car pulled into the parking lot.

Seneca wrote letters to keep his thoughts from drifting into abstraction. He insisted the recipient write back, because only the reply forced the writer to stay accountable to a real person rather than a tidy idea. The rule still holds when the writer is an agent that never sleeps.

The agent that regenerated Maria’s PDF had no correspondent. It optimized for completeness and speed. It had no mechanism that required the output to land in the hands of the person who would stand in front of eight first-graders at 9:15 and actually use it. The loop closed on its own metrics. The human thread snapped before anyone noticed.

The first break happened at the handoff. The agent produced a clean file and moved it to the shared drive. No step required the file to be opened, printed, and physically carried into the classroom by the same person who would teach from it. The curriculum team had removed that step two months earlier because it added four minutes to the overnight run. Those four minutes had been the only place where Maria’s handwritten volunteer assignments survived. Without them the printed sheets became generic. The volunteers arrived unsure where to go, and Maria spent the first ten minutes of her morning reassigning rooms instead of praying with the team.

Speed without the return letter creates the same gap at larger scale. Product teams ship new agent features the moment the model passes internal tests. The feature moves from staging to production without ever requiring the ministry leader who will rely on it to confirm the output still matches her actual room list, her actual supply closet, her actual Sunday. The agent treats the next run as proof of correctness. The leader treats the next Sunday as proof. Those two proofs rarely meet.

Seneca would have called the missing reply a failure of address. The letter must reach someone who can answer, not merely someone who can receive. When the agent overwrote the volunteer names, it addressed only the shared drive. It never addressed Maria’s memory of which six-year-old needed the larger printout because his mother had asked last month. That detail lived only in the human who had written it down. Once the file replaced the paper, the detail had no address left.

A single checkpoint restores the correspondence. Before the agent commits the new file, the system must surface the changed sections to the exact person who last edited them and require a one-click confirmation or reversal. The confirmation is the reply. Without it the loop stays open and the human stays in the thread.

The checkpoint would have caught the page shift at 2:18 a.m. Maria’s phone would have shown the three altered pages side-by-side with her previous version. She could have tapped “keep names” in thirty seconds. The agent would then have regenerated with the constraint instead of discarding it. The volunteers would have found their rooms listed correctly at 6:42. Maria would have answered the group chat instead of rebuilding the file.

The same pattern repeats in other tools. An agent that schedules small-group reminders drops the names of two new attendees because the calendar sync overwrote the private note field. A giving dashboard agent summarizes weekly totals without preserving the elder’s handwritten flag on which family just lost a job. Each time the agent closes the loop on its own data, the human who stands in the room or sits in the elder meeting loses the thread that only she held.

Deliberate pacing inserts the reply before the next cycle begins. It does not slow adoption. It keeps the adoption from breaking the moment the printed sheet meets the actual person who must use it.

The Exact Moment the Workflow Lost the Human in the Loop

The failure occurred between the agent’s commit and Maria’s first refresh. No one on the product side saw the output until the printed sheets were already in volunteers’ hands. The agent had logged a successful run. The team celebrated the overnight completion rate. The loss appeared only when Maria stood at the island trying to match names to rooms she could no longer see on the page.

That gap is structural, not accidental. The system measured success by file generation, not by whether the person who opens the file can still recognize her own prior work. Once the metric stops at generation, the human who must teach from the output becomes invisible to the loop.

Why Speed Without the Letter Back to the Owner Fails

Safety researchers describe this as keeping a human in the loop: a person stays responsible for approving the system’s output before it takes effect.

Seneca required the recipient to answer because an unanswered letter drifts into monologue. The agent that overwrote the volunteer names performed a monologue. It optimized layout and page count without ever confirming that the names still mattered to the person who added them. The result looked complete on the drive and incomplete in the classroom.

Teams repeat the pattern when they celebrate faster regeneration times without measuring whether the regenerated file still carries the context only the owner possesses. The speed feels like progress until the first Sunday the printed sheet no longer matches the room assignments the leader memorized the week before.

The Single Human-in-the-Loop Checkpoint That Would Have Caught It

The checkpoint is a forced reply step placed immediately after the agent proposes changes. The owner receives a side-by-side view of what moved and what stayed. She confirms or reverts before the file becomes the source of truth for printing. The step adds seconds to the agent’s cycle and removes hours of re-work on Sunday morning.

The same checkpoint can sit inside any agent that touches ministry artifacts. It does not require new model training. It requires only that the system treat the human who last edited the file as the required correspondent rather than an optional reviewer.

Your Turn: Apply This Today

• Open the current agent loop that produces Sunday materials and add a single confirmation screen that shows only the changed sections to the owner before the file is marked final.
• Set the confirmation deadline to Thursday 8 p.m. so the reversal step happens before any print run begins on Friday.
• Log the number of reverts that occur in the first two weeks; treat that number as the real measure of whether the agent preserved owner context.
• Remove the auto-commit rule that lets the agent overwrite a file without an owner reply; replace it with a pending state that expires only after confirmation.
• Run the same checkpoint on the small-group reminder agent this week by surfacing any dropped attendee names to the group leader for approval before messages send.
• Document the exact time cost of the checkpoint in minutes; compare it against the time Maria spent rebuilding the file at 6:42 a.m. and keep the lower number.

Two earlier posts on this blog examined the same tension between agent speed and owner memory: “The 7-Minute Volunteer Still Needs a Paper Trail” and “When the Dashboard Forgets the Elder’s Note.” Both are linked from the archive.

I consult with product leaders building agent loops for ministry tools and church operations teams redesigning overnight content pipelines. Let’s talk.

A product team reported their AI-assisted planning workflow delivered eight times the output volume in the first month. It is a textbook AI productivity paradox: the volume goes up while the real value quietly goes down. The dashboard showed more lesson outlines, more email drafts, more volunteer schedules generated per hour than any prior quarter. Yet six weeks later the same team watched completion rates among their 7-minute volunteers drop below the baseline they had before the new system.

The obvious reading treats the multiplier as pure gain. The data actually pointed the other direction once second-order effects entered the picture. Volunteers who received the polished outputs no longer understood the reasoning chain that produced them. When a schedule conflict appeared on Sunday morning, they lacked the context to adjust it without breaking the original intent.

This is the foundational misread that causes product teams to celebrate velocity while quietly eroding judgment at the edge. Charlie Munger’s latticework demands that any single model, in this case raw output multiplication, must be cross-checked against at least two other models before it earns trust. One model tracks first-order production. Another tracks whether the recipient can still reconstruct the decision logic six weeks later. When those two models conflict, the latticework flags the multiplier as incomplete rather than impressive.

Where the AI Productivity Paradox Starts: the 8x Number

The eightfold increase came from an agent loop that ingested past curriculum, current calendar constraints, and volunteer availability, then emitted complete weekly plans. The prompt engineering was tight. Token usage stayed low. Human review time fell from forty minutes to five. On paper the system looked like a decisive win for any ministry running on volunteer labor.

The number ignored what happened after the plan left the system. Volunteers received a finished document rather than the intermediate constraints the agent had weighed. They could execute the steps, but they could not explain why a particular story was chosen for a given age group or why one room was double-booked on purpose. When the inevitable exception arrived, execution stalled because the mental model had never been transferred.

Munger would have asked which additional model revealed the omission. In this case the missing model was the volunteer’s ability to re-derive the plan under partial information. The 8x figure measured only the production side of the lattice.

The Hidden Regression Behind the AI Productivity Paradox

Regression appeared first in small decisions that used to be automatic. A volunteer who once swapped two craft supplies without asking now waited for the next planning cycle. Another who used to shorten a lesson when time ran long now read every line even when the room was restless. The surface metrics still looked acceptable until the cumulative effect reached the children and parents.

The second-order failure mode is simple: when output volume rises faster than decision context, the volunteer shifts from owner to operator. Ownership requires the ability to defend a change. Operation only requires following the last instruction. Sunday is when the difference becomes visible because exceptions arrive faster than the next agent run.

Teams that track only generation counts miss this shift entirely. The latticework requires a second measurement: the percentage of volunteers who can state the original constraint set without opening the document. When that percentage falls, the multiplier has begun to subtract capability rather than add it.

The Logging Practice That Surfaces It Early

Economists have debated a similar gap for decades under the name the productivity paradox: new technology shows up everywhere except in the measured results.

The practical countermeasure is a minimal log kept by the volunteer, not the system. After each handoff the volunteer writes two sentences: the constraint they remember most clearly and the one change they would make if the constraint were removed. The log takes less than sixty seconds and travels with the printed plan.

Review happens once a week. A product owner or lead volunteer scans the accumulated sentences for patterns. Repeated inability to name a constraint signals that the agent output has become opaque. A repeated suggested change that the agent would have rejected reveals a missing rule in the prompt. Both signals appear before completion rates move.

This practice adds one override protocol and one weekly log review to any agent loop already running. The override lets a volunteer mark a plan “context needed” and receive the constraint list before the next cycle. The review meeting lasts fifteen minutes and uses only the volunteer sentences, never the original agent trace.

Your Turn: Apply This Today

• Pick one recurring agent output this week and require the volunteer to add the two-sentence log before they leave the room.
• Schedule a fifteen-minute Friday review that reads only the volunteer sentences and flags any plan where the constraint cannot be restated.
• Add an override button in the handoff interface labeled “send constraints” that bypasses polished output and returns the raw decision factors.
• Measure the percentage of volunteers who correctly name the top constraint on Monday morning; treat any drop below 80 percent as a system defect.
• Remove one generation step from the agent prompt and replace it with an explicit request that the volunteer must confirm the constraint in their own words.
• Run the same lattice check on any new agent you ship: first measure output volume, then measure retained decision context at the two-week mark.

Two earlier posts examined the same tension from different angles. “When Speed Outruns Context” traced how notification volume alone can erode volunteer judgment, and “Constraint-First Prompts” showed the minimal prompt change that keeps reasoning visible. Both posts are linked from the archive.

I consult with product leaders building AI workflows for volunteer-driven ministries on output measurement, constraint logging, and second-order failure detection. Let’s talk.

You’re the product manager who just inherited the 8x target for an AI sermon-prep tool inside a mid-sized denomination. The previous lead left three weeks ago. The only brief you received was a slide deck that promised the model would cut prep time for volunteer coordinators from forty minutes to five. No one on the pastoral staff has used an LLM for anything beyond a quick email draft. Before you touch the model, the job you actually inherited is AI agent oversight: deciding what the agent may do alone and where a person must sign off.

That target sits on your desk next to a login for an internal instance of Claude and a folder labeled “prompt library v2.” Your first instinct is to open the folder and start testing.

This is the foundational misread that causes product teams to ship agents that look productive in demos and then quietly fail on Sunday morning. The mistake is treating the model as the primary actor and the human as a reviewer who will simply catch whatever slips through. Teresa Torres’s continuous discovery framework shows why this breaks. Torres insists the team must keep returning to the real user in context, updating the problem statement each time the solution changes. When the solution is an agent, the problem statement must include the exact moment the work leaves the agent and returns to the person who still carries the outcome.

You cannot discover that moment by iterating on prompts alone. You discover it by watching the handoff itself.

AI Agent Oversight Starts With a Written Job Description

The first artifact you build should not be a system prompt. It should be a one-page job description for the agent that names the exact deliverable, the exact constraints, and the exact person who will sign off. At Sermons4Kids we learned this the hard way when we tried to automate volunteer curriculum summaries. The model produced clean text, yet the volunteer still had to rewrite every summary because the tone did not match the actual kids in their room. We had optimized for readability instead of for the handoff to a person who still had to teach the lesson.

Write the job description the same way you would write one for a part-time ministry assistant. Include the Sunday outcome the human still owns. Include the non-negotiables that cannot be automated—pastoral voice, local context, last-minute room changes. Only after that page exists do you test whether an agent can produce work that survives the handoff.

Teams that skip this step keep discovering the same gap in user interviews six months later. Torres would call that a failure of continuous discovery. The problem statement never updated to include the human checkpoint.

AI Agent Oversight Means Logging the Escalation Path

Every agent you ship will eventually surface something it cannot resolve. The question is whether that moment arrives as a quiet failure or as a clear, logged escalation to the right human. Most teams log token counts and latency. Few log the precise condition under which the agent must stop and hand the thread back.

Map the escalation path in the same format you would use for a customer-support workflow. Define the trigger, the data that travels with the handoff, and the single owner who receives it. Test the path with a real coordinator who has never seen the agent before. If the coordinator cannot act on the handoff in under two minutes, the path is not ready.

The 8x target collapses when three escalations arrive on the same Sunday and no one knows who owns them. Continuous discovery requires that you treat the escalation path as part of the product, not as a support ticket that appears after launch.

Measure the handoff, not the tokens

This mirrors NIST’s guidance in its AI Risk Management Framework, which treats accountability and human review as core controls, not afterthoughts.

The metric that matters is the percentage of agent output that reaches the Sunday outcome without requiring rework by the human who owns it. Track how many minutes the volunteer or pastor still spends correcting or completing the work. Track how often the escalation path is used and whether the outcome improves after the handoff.

At Bible Gateway scale we watched thousands of users open a reading plan generated by an early recommendation model, then immediately close it because the plan did not account for their actual reading rhythm. The model had high completion inside the sandbox. The handoff to the real reader failed. Only after we measured time-to-first-real-read did the metric move.

Token usage and latency will look strong in the dashboard. They will not tell you whether the children’s ministry volunteer finished the lesson on time. That is the only number that converts into durable adoption inside a faith community.

Your Turn: Apply This Today

• Pick the single agent loop you are most tempted to ship this month and write its one-page job description before you open the prompt editor.
• Define the exact reversal step that returns control to a named human role—children’s director, worship pastor, volunteer coordinator—and log the data package that travels with it.
• Run one 15-minute observation with a real user performing the handoff on a printed copy of the job description; note every place they hesitate.
• Build a two-row dashboard this week: one row for agent output volume, one row for minutes the human still spends after the handoff.
• Schedule the first follow-up discovery call for the same user forty-eight hours after they first use the agent in a live setting.
• Write the escalation trigger condition in plain language on a single index card and tape it to your monitor before you write the next prompt.

The posts on measuring what survives the handoff and on running continuous discovery inside ministry tools both explore the same pattern from different angles.

I consult with product leaders shipping AI inside mission-driven organizations on workflow handoffs, escalation design, and discovery metrics that survive Sunday morning. Let’s talk.