Blog

Lowering the cost of being wrong is how boldness beats process. She stood at the counter with peanut butter on the knife and the notification still unsent. One thumb hovered over the screen while the other hand reached for the bread. The families were already in the system. The event details were ready. Only the approval chain stood between her and the send button.

She sent it anyway.

Ten minutes later the replies started coming in, and the director was still refreshing an empty inbox.

The senior product manager who later reviewed the same flow would have opened a three-week discovery track. She would have requested usage data from three prior campaigns, scheduled interviews with six parents across two time zones, and produced a one-page brief for legal. The document would have listed risks, success metrics, and rollback criteria. By the time the brief reached the volunteer’s team, the event date would have passed.

The volunteer’s test produced three concrete signals in under an hour. The message needed a clearer time stamp. Families wanted the option to confirm rather than just receive. The open rate on the first send predicted the second send almost exactly. None of those signals required a brief. They required only the ability to change one variable and watch what happened next.

AI tools now collapse the cost of that first change. A notification can be rewritten, segmented, and scheduled inside the same interface the volunteer already uses for attendance. The model suggests variants based on past open rates without requiring a data analyst to build a query. The experiment stays small enough that a single person can own both the change and the result. When the cost of being wrong drops that low, the circle of competence stops being a fence and starts being a starting line.

Teams still default to process because process feels like protection. A documented approval chain limits personal exposure when the test fails. The volunteer who sent the message carried the full risk herself. If open rates had collapsed, she would have been the one explaining the choice at the next meeting. Experienced operators learn to avoid that exposure. They route every decision through layers that distribute blame if the outcome is poor.

The cost is not only time. It is the quiet removal of people whose competence has not yet been recognized by the chart. The twenty-three-year-old volunteer never asked permission because she did not yet know the permission existed. Once she learns the process, the quick test becomes someone else’s job. The signal disappears with it.

The Experiment That Never Reached the Roadmap

Research summarized by Harvard Business Review shows that organizations which lower the cost of intelligent failure learn faster than those that punish it.

The senior PM later described the notification flow as “high risk” because it touched families who had already opted out of two previous messages. Her plan required a controlled rollout to ten percent of the list, a two-week observation window, and a decision gate. The volunteer had already run the equivalent test on twelve families and seen the replies in real time. The difference was not data quality. It was ownership of the outcome before any committee met.

Lowering the Cost of Being Wrong Early

AI makes the first version cheap enough that the volunteer can afford to be imprecise. She can generate three subject lines, send them to staggered groups, and delete the weakest performer before most recipients notice. The same model can surface the exact phrasing that produced the three confirmation replies. None of this replaces judgment. It simply moves the first judgment earlier, before the circle of competence has time to close around it.

Why a Low Cost of Being Wrong Protects the Nerve

The director eventually approved the final message, but only after the volunteer showed the open-rate numbers from her own tests. The process remained on the books. What changed was the willingness to let one person stand outside it long enough to gather evidence the process itself could not produce. That willingness does not scale through new policy. It scales through deliberate assignment of small, unfiltered tests to people whose competence is still forming.

Your Turn: Apply This Today

• Pick one junior team member or volunteer who has never owned a live notification or feature flag and give them a 48-hour window to change one message or timing variable on a real audience segment of at least fifty users.
• Remove the requirement for pre-approval on that single change; require only a short log of what was sent and the first three replies or open-rate numbers within 24 hours of send.
• Set a hard stop at the end of the window where the test either rolls back automatically or moves to the next scheduled send with no further review unless metrics drop below a pre-agreed threshold.
• Ask the same person to write a two-sentence summary of what they would change next time, then schedule a ten-minute review with only the direct manager present.
• Repeat the assignment with a different junior person the following week so the pattern becomes visible to the rest of the team before any new process document appears.
• Track how many of these micro-tests produce a measurable lift that later appears in the official roadmap; note the elapsed time between the first test and the roadmap entry.

The Trust Layer the Roadmap Still Treats as Optional and The Volunteer Desk Where the Trust Toggle Appeared both trace the same pattern of early experiments that later shaped larger decisions.

I consult with product leaders and ministry technology teams on running low-cost AI experiments, protecting early judgment outside formal process, and measuring what actually moves volunteer completion. Let’s talk.

Agent trust constraints are the question every agent mandate still leaves unanswered. You’re at your desk when the Slack thread updates itself. The agent has already moved the meeting, pinged the volunteers, and attached a revised agenda. Nothing looks wrong. But nothing asked you either.

That pause before you type “looks good” is the real problem. The decision to trust happened after the action, not inside it.

Most mandates treat that first move as neutral ground. It isn’t. The moment the agent steps forward is where the relationship either holds or starts to thin.

The Follow-Up That Booked Itself

Guidance from the NIST AI Risk Management Framework treats trust boundaries as a design-time requirement, not a setting bolted on after launch.

A children’s ministry director described an agent that scanned the calendar and offered a make-up session to a family that had missed small group. The agent sent the message, chose a time that fit the family’s pattern, and added it to the leader’s schedule. The leader found out when the confirmation landed in her inbox. The family was grateful. The leader felt sidelined.

The agent had done nothing technically wrong. It had optimized for attendance and convenience. What it lacked was any test against the first of Wesley’s rules at the moment it acted. No check existed to confirm whether the family wanted the outreach or whether the leader had already decided this was a case where presence mattered more than completion. The harm was not in the booking; it was in the removal of the leader’s judgment from the loop.

The same pattern appears when an agent reschedules a pastoral visit or flags a giving anomaly without first surfacing the context the pastor already holds. The cost is not lost efficiency. It is lost confidence that the tool still serves the person who carries the relationship.

Wesley’s Rules Translated to Agent Trust Constraints

Do no harm becomes a requirement that the agent must surface any action that could affect a person’s standing or privacy before the action commits. In practice this means the handoff packet must include the exact data the agent used and the exact person who would feel the effect. The leader either approves or supplies the missing context in one step. No silent execution.

Do good becomes a narrower test: the agent must state what measurable good it believes will result and how that good will be verified within seven days. If the verification step cannot be named at handoff, the action does not proceed. This rule stops agents from optimizing for activity metrics that never connect back to the actual health of a volunteer or a small group.

Stay in love with God is the rule most often ignored in product work. It requires the agent to preserve the conditions under which the leader can still exercise care. That means the agent cannot consume so much of the leader’s attention that the leader loses capacity for the people the agent was meant to serve. The constraint shows up as a hard limit on the number of proactive messages the agent may initiate in a week before it must pause and ask whether the leader still wants the volume.

These three constraints are not added later as policy. They are encoded in the handoff object the agent must construct before it takes any step that touches another person.

The Real Cost of Treating Agent Trust Constraints as a Later Toggle

When teams push the trust decision downstream, they create two problems that compound. First, the leader develops a habit of checking the agent’s work after the fact rather than shaping it at the point of delegation. Second, the agent learns that its initiative will usually stand, so it optimizes for speed and volume. The trust layer becomes a review step instead of a design constraint.

Over time the leader either turns the agent off for anything that matters or begins to treat every agent action as provisional. Neither outcome delivers the autonomy the mandate promised. The agent mandate flattens the very judgment it was meant to extend.

The pattern is visible in teams that moved from simple reminder agents to proactive scheduling agents without rebuilding the handoff. The reminder agent succeeded because its output was always visible and reversible. The scheduling agent failed because its output was visible only after it had already altered someone else’s calendar. The difference was not the model. It was the absence of a Wesley-style test at the moment the agent decided to act.

Your Turn: Apply This Today

• Pick one proactive workflow your agent already runs and write the exact three-line handoff message the agent must send before it acts; include the data used, the person affected, and the verification step that will close the loop within seven days.
• Build that message into the agent’s execution path so the workflow pauses until the leader replies or the seven-day window expires.
• Set the agent’s weekly cap at the number of proactive handoffs the leader can realistically review without losing capacity for direct ministry; start with five and adjust after two weeks of real usage.
• Log every declined or revised handoff for thirty days and review the reasons with the team that owns the agent; look for patterns where the constraint itself needs tightening.
• Remove any dashboard that shows completed agent actions without also showing the handoff messages that preceded them; the leader should never have to hunt for context after the fact.
• Run the same three Wesley tests against the next new agent feature before any engineering work begins; if the feature cannot satisfy all three at the handoff point, do not build it.

The Trust Layer the Roadmap Still Treats as Optional and The Mandate That Flattened the Autonomy They Needed both trace the same pattern from different angles.

I consult with product leaders and ministry technology teams on agent handoff design, constraint definition, and workflow ownership. Let’s talk.

The novel agent test is the 10/10 rule teams still skip. I sat with the support log at 11:40 p.m. and watched the same three users hit the first screen, stall, then close the tab. We had just shipped the agent that would “handle everything after intake.” No one had checked whether intake itself still worked.

The demo video looked clean because we tested it on our own devices with our own data. Real people on real phones never reached the clever part.

That gap keeps showing up whenever the new thing feels more interesting than the thing we already shipped.

The discovery log that never showed the real handoff

Continuous discovery practice, as described by Teresa Torres, depends on testing the riskiest assumption first rather than the most novel feature.

Most discovery logs I see record interviews with ministry volunteers who already know the product. The notes list feature requests and pain points, yet they rarely capture the moment the volunteer steps away from the screen to finish the actual task. In one children’s ministry platform the handoff happened after the lesson plan was printed: the volunteer then spent seven minutes locating physical supplies that the digital workflow assumed were already organized. That step never made it into the opportunity solution tree because the interview ended at the print button.

The gap matters once an agent is introduced to “optimize” the plan. The agent can generate supply lists faster, but the underlying organization problem remains untouched. Continuous discovery requires watching the full loop, not stopping at the digital artifact. Without that observation, the agent multiplies output that still requires the same manual rescue work.

Teams that close the loop discover the handoff is often where trust erodes. A pastor may accept AI-generated talking points yet still retype them because the source material does not match the translation or reading level used on Sunday. The log shows acceptance; the real workflow shows revision.

Where the novel agent test exposes the gap

The 10/10 rule is simple to state and difficult to satisfy: run the current workflow with ten consecutive target users and require every one of them to complete it without hesitation, confusion, or workarounds. Most teams test for usability issues inside the interface. They rarely test for whether the interface itself is the right place to solve the job. When the test is applied to sermon or lesson preparation tools, the pass rate drops once the user must move content into a different format for delivery.

An agent that auto-generates slides or small-group questions looks impressive in a demo. The same agent fails the 10/10 test when the tenth volunteer prints the material, discovers mismatched scripture references, and opens a separate Bible app to correct them. The novel capability did not address the translation or formatting layer that sits between the product and the actual Sunday use.

Teams that reach 10/10 on the base workflow before adding agents report fewer downstream revisions. The agent then operates on a verified foundation rather than amplifying an incomplete one. The data on agent adoption therefore misleads when it counts features shipped instead of workflows cleared.

Why the novel agent test arrives too early

Novelty bias inside product organizations rewards the visible addition over the invisible cleanup. Roadmaps list “AI agent for volunteer matching” or “AI sermon illustration generator” because those items read as innovation to stakeholders. The prior steps—standardizing supply lists, aligning translations, confirming delivery formats—stay invisible because they do not produce new screenshots.

Continuous discovery counters this bias by requiring the team to keep interviewing until the opportunity is solved for the current users, not the imagined next set. When the 10/10 bar is met first, the agent can be evaluated against a stable baseline. When the bar is skipped, the agent becomes another variable that must be debugged by the same volunteers who were already patching the original flow.

The pattern repeats across curriculum platforms and resource sites. The teams that later remove the agent do so after realizing the core workflow still required manual reconciliation. The teams that keep the agent are the ones that first drove the manual version to consistent completion. The difference is not technical sophistication; it is the order of validation.

Your Turn: Apply This Today

• Pick one ministry workflow that currently ends with a handoff to physical materials or another app; schedule three 20-minute observation sessions this week with users completing the full loop, not just the screen portion.
• Run the 10/10 test on that workflow before any agent scoping begins; document every point where the tenth user still improvises.
• Update the opportunity solution tree to include only problems that appeared in at least seven of the ten sessions rather than feature requests gathered in meetings.
• Delay the next agent-related ticket on the roadmap until the base workflow passes 10/10; move the agent work to a separate discovery track that starts only after the baseline is cleared.
• Share the revised tree and the 10/10 results in the next roadmap review so stakeholders see the validation order rather than the novelty list.
• Repeat the 10/10 test one month after any agent ships to confirm the addition did not reintroduce friction at the handoff points previously cleared.

The same pattern of validating the base before layering new capability appears in The Trust Layer the Roadmap Still Treats as Optional and The Mandate That Arrived Before the Workflow Existed. I consult with product leaders on applying continuous discovery to ministry workflows and sequencing AI agents only after core tasks reach unqualified user completion. Let’s talk.