The Outcome Price the First Ministry Agent Actually Earned

I still have the email. The subject line just said “AI pilot next steps,” and the attachment was a contract that billed per successful run. Nobody had defined what success meant. Not the vendor, not the leadership team, not even the guy who’d been asked to run the thing.

I kept reading the same sentence: “Payment tied to measurable ministry outcomes.” I remember thinking, we can’t even agree on what counts as a pastoral visit. How are we going to price an agent that’s supposed to do the same work?

That gap sat there, quiet, while the budget line got approved anyway. What we needed was outcome-based agent pricing tied to something a human could verify, not a per-run invoice.

The ledger started as a simple shared sheet. One column for the exact output the agent produced, one for the observable change in a ministry workflow, and one for the dollar amount we would only pay if both columns were verified by a human reviewer. We added rows only after the agent ran against real curriculum data from a volunteer-curriculum provider we work with. Nothing entered the ledger until a children’s ministry coordinator confirmed the output was usable without rewrite.

The invoice that arrived before anyone agreed what counted as success

The first invoice listed thousands of successful generations at the agreed per-outcome rate. When we opened the attached log, most rows showed the agent producing sermon illustration summaries that still required a pastor to fact-check and rewrite the application points. The vendor counted them as successes because the model completed the prompt. We counted them as incomplete because no volunteer could hand the summary to a parent without additional work.

We had never written the single sentence that would have prevented the mismatch: the agent must generate a complete, print-ready small-group question set that a 7-minute volunteer can use without opening another document. Until that sentence existed, every generation was open to reinterpretation.

The mismatch showed up in the numbers first. Our internal tracking showed that only a small fraction of the billed outputs survived a single volunteer test without edits. The vendor’s own dashboard showed the vast majority as successful. The ledger made the gap visible in one view.

How the ledger changed vendor conversations

We sent the vendor the ledger instead of a revised scope document. The next call shifted immediately from feature requests to outcome definitions. The vendor’s team asked what evidence we needed for each row before payment triggered. We answered with three artifacts: the generated file, a timestamped screenshot from the volunteer who used it, and a one-sentence confirmation that the workflow step finished without further input.

That single change removed half the proposed use cases. The vendor stopped pitching broad “content creation agents” and started asking which narrow workflow step carried the highest cost when it failed. The conversation moved from model capabilities to the exact point where ministry labor was currently wasted.

The ledger also surfaced internal disagreements we had ignored. One curriculum director wanted the agent to increase the number of lessons produced per month. Another wanted the agent to reduce the time between lesson assignment and volunteer completion. Those two goals pointed to different outcome definitions and different price points. The ledger forced the choice before any new pilot began.

The outcome-based agent pricing we finally settled on

We settled on one outcome only: the agent must produce a complete, age-appropriate memory verse activity sheet that matches an existing lesson outline from our curriculum provider, passes a quick review by the volunteer coordinator, and is printed and handed to children within the same planning cycle. The dollar value attached to each verified sheet was set at the internal cost of a staff member creating the same sheet from scratch.

Payment now triggers only after the coordinator uploads the printed sheet with a date stamp and a short confirmation that no additional writing was required. The vendor accepted the definition because the success criteria are binary and the verification artifact is cheap to produce. We accepted it because the outcome directly reduces the labor that was previously blocking volunteer retention.

Everything else the agent can generate sits outside the ledger and outside the contract until we run a second, separate pilot with its own measurable finish line.

Your Turn: Apply This Today

• Write the single sentence that defines the exact output your agent must produce before any payment can trigger, then send that sentence to the vendor before the next call.
• Pick the one ministry workflow step that currently costs the most staff or volunteer time and attach a dollar value equal to the internal cost of completing that step manually.
• Build a three-column ledger in the shared project tracker with columns for output, verification artifact, and dollar amount, and add no rows until the first human confirmation arrives.
• Run the current agent against ten real records from your curriculum or scheduling data and count how many outputs meet the sentence you wrote; share that count with the vendor this week.
• Remove every use case from the pilot scope that cannot be verified with a single artifact a ministry leader already produces in their normal workflow.
• Schedule the payment trigger for the narrow outcome only after the verification artifact is uploaded, not after the model finishes generating.

The same pattern appears in the posts on evaluation layers and the agents that only became usable after we added the knowledge graph. The PM who just shipped an agent and now needs an evaluation layer ran into the identical pricing gap when the model output could not be tied to a single ministry result.

I consult with faith-tech product leaders on defining measurable agent outcomes, building verification workflows, and shifting contracts from usage to verified ministry results. Let’s talk.