Here's the uncomfortable pattern behind most failed agent deployments: the ROI analysis happens after the build. The team ships the agent, the demo lands, and only then does someone ask what it's actually saving. By that point the sunk cost answers for itself, and the agent lives on as expensive decoration.
We run the sequence in the opposite order. In our ventures, an agent cannot enter the backlog — let alone production — until the workflow it targets has passed five gates. None of them require writing agent code.
Gate 1 — Baseline the workflow in dollars, not vibes
Pick the workflow and measure it as it runs today: volume per month, minutes per unit, fully-loaded cost of the people doing it, error rate, and the cost of each error. If the workflow isn't measurable today, that's the project — instrument first. You cannot compute a return against a baseline that doesn't exist.
This step kills more agent ideas than any other, in the best way: workflows that feel painful frequently turn out to cost less than the agent that would automate them.
Gate 2 — Price the failure modes
Every automation has a failure bill. For each way the agent can be wrong — wrong extraction, wrong decision, wrong tone with a customer — estimate frequency and unit cost, including the review time needed to catch it. Then ask the boundary question: what's the worst single action this agent could take, and can we cap it? If the worst case can't be capped with permissions, thresholds, or human sign-off, the workflow isn't ready for an agent, whatever the average case says.
Gate 3 — Run the wizard-of-oz test
Before building, fake it. Have a person execute the workflow following the exact policy the agent would follow — same inputs, same rules, same escalation paths — for a week or two. This is cheap and brutally informative. It tells you whether the policy is even writable, where the edge cases actually are, and whether downstream teams accept the output. If a human following the agent's script can't produce acceptable results, the agent won't either.
If you can't write the playbook a temp could follow, you can't write the prompt an agent can follow.
Gate 4 — Model the build-vs-buy-vs-human blend
Only now does the architecture question open, and it has three honest answers, not one. Build in-house when the workflow is core IP and volume justifies it. Compose from third-party agents and services when someone else has already paid the development cost — being agentic native does not mean building every agent yourself. Keep it human-led when the economics say so, and revisit next quarter. Model all three with the numbers from gates 1–3; the spreadsheet, not the roadmap, picks the winner.
Gate 5 — Set the kill criteria before the kickoff
The last gate is a signed sentence: "By [date], this agent handles [X]% of volume at [Y] quality for less than [Z] per unit, or we retire it." Written before the build, this costs nothing and prevents the zombie-agent problem entirely. Written after, it never gets written.
What ships is a claim, not a hope
An agent that passes all five gates launches with a baseline to beat, capped downside, field-tested policy, deliberately chosen architecture, and a pre-agreed verdict date. The post-launch review becomes arithmetic instead of politics.
It's slower than shipping the demo. It's dramatically faster than shipping the demo twice.