The kill criterion is the contract.

Every contract we sign for a Build engagement includes a clause we call the kill criterion. It’s a specific, measurable condition under which we’d shut a workflow down. Written before the build starts. Agreed by both sides. Reviewed quarterly.

An example. For a customer-support deflection workflow, the kill criterion might read: “If deflection rate stays below 30% after 60 days in production, or if CSAT on AI-handled tickets drops more than 0.4 points from baseline, we’ll recommend killing this workflow rather than continuing to optimize.”

This sounds like an unusual thing to write into a paid engagement. Most consultancies prefer to keep options open: if a workflow underperforms, you spend more time optimizing it. We do the opposite. We write the failure mode in before the project starts, so the conversation about “is this working?” isn’t a judgment call, it’s a measurement.

Three reasons we do this. First, it forces us to be honest at scoping time. We can’t write a kill criterion for a workflow we don’t actually understand, which means we can’t scope work whose value we can’t define. This is how most bad consulting engagements start, and the kill criterion is our defense against starting one.

Second, it protects the client from sunk-cost spending. The natural human bias is to keep paying for something that isn’t working, because abandoning it admits failure. The written criterion removes that emotional weight: shutting the workflow down isn’t a failure, it’s the agreed protocol.

Third, and most important: it tells clients what kind of consultancy we are. We’d rather kill a $24,000 workflow at month three than keep billing to maintain it for two years. That decision is what we sell. The kill criterion is just where we write it down.