The easiest time to decide when a project should stop is before the project has a name people defend, a dashboard people admire, and six months of effort nobody wants to waste. That moment is also the easiest time to avoid the decision. The idea looks promising; stopping feels like an unnecessarily gloomy subject.
A kill engine is a set of explicit conditions and operating controls that let a project pause, retreat, or end when the evidence or risk requires it. The name is blunt. The purpose is ordinary stewardship: preserve cash, attention, customer trust, and the ability to try something better.
It is not a machine that decides every project is bad, nor a rule that uncertain work must produce immediate profit. It distinguishes useful uncertainty from indefinite consumption. A project can continue while learning, provided the learning is worth its cost and the exposure remains within an agreed boundary.
The central design question is which facts should change the decision, who has authority to act on them, and what actually happens when the rule is triggered.
Stopping has several meanings
A pause stops new work while preserving the possibility of resuming. A rollback returns a system to a previously accepted version. A scope reduction removes a risky function while keeping useful functions. A retirement ends an activity and handles the obligations it leaves behind.
These actions should not be collapsed into a single dramatic red button. A temporary data problem may justify a pause. A flawed deployment may justify a rollback. An offer with persistently bad economics may need retirement. The correct response depends on the cause and consequences.
Consider a hypothetical assistant that drafts supplier orders. If stock records are stale, pause drafting until the records are reconciled. If a new version changes quantities incorrectly, restore the previous version and inspect affected drafts. If the task does not save enough accepted work to justify maintenance, retire the automation while preserving the manual process.
A useful stop rule names the action. “Something seems wrong” is too vague. “No new purchase drafts when inventory reconciliation is overdue” connects a condition to a specific behavior. The rule becomes more valuable when the connected system can enforce it instead of relying on the assistant to remember.
Put the decision before the measurement
A project should begin with a question it can answer. “Will this improve our business?” is too broad. “Can it classify these ordinary inquiries accurately enough to reduce review time without missing urgent exceptions?” identifies an outcome and a risk.
Then decide what evidence would support continuing, changing, or stopping. A trial could succeed by meeting quality and net-time requirements. It could need revision if ordinary cases improve but exceptions fail. It could end if the required review consumes the expected saving or the failure risk exceeds the acceptable boundary.
The thresholds should be justified by the task, not selected because they make the tool look good. A minor categorization error in a draft may be tolerable. Missing a deadline with legal consequences may require a much stronger control. Some activities should not be autonomous at all.
This is where permission architecture and stopping rules meet. Permissions define what the system may do while operating. Stop rules define when continued operation is no longer acceptable. Both need an accountable human owner.
Separate a loss limit from a success criterion
A loss limit caps what the project can consume or endanger. A success criterion defines what useful result would justify the next step. They are different.
A hypothetical operator might permit a $200 trial and five hours of review work. Staying below those limits does not prove success. It only establishes that the trial remained within budget. Success might require correctly resolving a specified set of ordinary cases and reducing total accepted-work time compared with the current process.
Conversely, a promising result can still violate the loss limit. An assistant may save time while making an unauthorized purchase. The operator should not excuse the boundary violation because the average performance looked favorable.
This separation prevents a common ambiguity. Projects that have spent little money can claim they are safe; projects that have produced one impressive result can claim they are successful. Neither fact answers whether the project deserves broader use.
Define both before expanding exposure. Use monetary limits, action limits, data boundaries, and time budgets appropriate to the task. The numbers in a trial plan are design choices, not forecasts of income or guarantees of safety.
Evidence can justify patience
Some projects need time to reveal their value. A useful library, a supplier database, or a new service may have setup costs before it generates revenue. A stopping system that demands immediate cash from every investment will reject worthwhile work.
The answer is to define intermediate evidence. Does the library answer a recurring question accurately? Can the supplier record support a comparison the operator previously could not make? Has a real customer accepted and paid for the pilot service? Does the new process handle the exception that was the original problem?
Intermediate milestones should be consequential enough to change confidence. “The system generated more material” is weak when the question concerns usefulness. “Three representative users found the required information and identified a purchase limitation correctly” is more informative, though still narrow evidence.
A project can earn a bounded extension by producing a useful result and identifying the next uncertainty. It should not earn endless extensions by replacing the original question with a new exciting one. Keep the decision history so the operator can see whether the project is progressing or merely changing vocabulary.
Write a stop card for one workflow
A stop card can be short enough to use under pressure. Include the workflow, owner, permitted activity, success measure, loss limits, trigger, action, recovery requirements, and location of the relevant records.
For the hypothetical supplier-order assistant, the card might say that it prepares drafts from verified inventory and approved supplier terms. It cannot place orders. It pauses if stock reconciliation is overdue, source terms are missing, or a draft exceeds the allowed planning budget. A human checks the discrepancy, records the cause, and decides whether to resume.
The important property is clarity. A person unfamiliar with the implementation should understand which work stops and who decides next. If the rule requires reading an entire technical design document during an incident, it is unlikely to help when attention is scarce.
Keep the card connected to the actual system. A renamed workflow, new permission, or changed supplier can invalidate an old rule. Review stopping conditions whenever the activity’s authority or loss exposure changes.
The stop control must survive the failure
A stopping instruction inside a prompt is useful guidance. It is not a dependable boundary if the same model that may fail is responsible for honoring it. Higher-consequence limits should be enforced outside the model’s discretionary behavior.
A system can reject actions above a spending cap, restrict which records may be changed, require approval for a commitment, or stop accepting new work when a queue reaches a limit. The exact mechanism depends on the existing software. A small business should use the simplest enforceable control available rather than invent a new control platform.
OWASP’s excessive-agency guidance recommends limiting tool functionality, permissions, and autonomy, with authorization enforced in connected systems. A kill engine applies the same principle to stopping: the boundary should remain meaningful if a model produces unexpected output. OWASP LLM06:2025.
Also consider failure of the monitoring system. If the health check disappears, should the workflow continue or pause? For low-impact drafting, continuation may be acceptable. For spending or destructive changes, absence of confirmation may need to block new action. Decide explicitly; do not let a missing signal quietly become permission.
Pausing new work does not erase old work
A stop action must account for in-flight tasks. Some may be awaiting approval, others may already have changed a record, and some may have created an external obligation. Turning off a process does not automatically reverse those effects.
A hypothetical customer-message system could stop sending new messages while already scheduled messages remain queued. An order process could stop making new recommendations while previously approved orders continue to ship. A price change could be reverted on the website while quotations containing the old price remain with customers.
Inventory the states the workflow can occupy. Identify which can be cancelled, which can be rolled back, and which need reconciliation or communication. Preserve enough evidence to distinguish a task that never started from one that partially completed.
The practical recovery plan might include cancelling queued drafts, checking applied changes, honoring accepted commitments, and contacting affected customers where appropriate. This work is part of the cost of automation. A project whose recovery obligations are unknown is not ready for broad authority.
Test the stop while the stakes are small
A proposed stop control should be exercised on copies or a safe test environment before it protects real operations. Cause the triggering condition deliberately and observe the result.
Does new work actually stop? Does a queued item slip through? Is the responsible person notified? Can the person find the affected records? Does the system preserve the state needed to resume? Can someone else operate the control if the original designer is unavailable?
This is a test of the control, not a performance demonstration of the model. A polished answer to “what would you do?” does not establish that the connected workflow will do it. The relevant evidence is the system’s behavior under the defined condition.
Write down the result, the environment, and the limits of the exercise. A local test on copied records does not prove recovery will succeed under every production failure. It does establish whether the basic mechanism works before the business depends on it.
Include a counterexample in the exercise: an ordinary input that resembles the trigger but should continue. If a missing optional field stops every harmless draft, the control may generate so many interruptions that people disable it. If a genuinely missing authority record is treated as optional, the control is too weak. Testing both cases makes the distinction operational. Record false stops as well as missed stops, and revise the condition without quietly broadening the workflow’s authority. A usable boundary must protect the consequential case while leaving enough normal work possible that the business can keep the protection enabled.
Beware of a kill engine that only stops unpopular work
Stopping decisions can become political. A project with a powerful advocate may receive repeated exceptions. An unfamiliar project may be stopped after one weak result. Neither treatment reflects an impartial relationship between evidence and decision.
Make exceptions visible. Record who approved the extension, why, what new evidence is expected, and what additional exposure is permitted. A justified exception can be valuable; a hidden exception makes the rule meaningless.
The same discipline applies to successful projects. Once a workflow becomes ordinary, people may stop reviewing whether it still produces value. Conditions change: customer needs, model behavior, prices, data quality, and staffing. Continued use should remain accountable to a useful outcome.
A stop rule does not remove human judgment. It makes judgment easier to inspect. The owner can still decide that an unusual circumstance warrants patience, but should explain the reason and preserve the boundary around the extension.
Count attention as well as money
A low-cost subscription can support a high-cost distraction. The owner spends evenings debugging, checking answers, and reconciling records while neglecting customers or a more valuable activity. The cash bill stays small, so the project appears inexpensive.
Include review time, maintenance time, interruptions, and the work displaced. The estimate need not be perfect to improve the decision. A rough record of hours and recurring problems can reveal that the tool is consuming the very capacity it was supposed to release.
Attention limits also help prevent project proliferation. If every promising idea becomes a continuing experiment, the operator accumulates more unfinished systems than useful assets. A cap on active projects can make stopping or postponing a reasonable idea necessary.
This connects to making time behave like capital. Time becomes productive capacity when it is allocated deliberately and produces retained value. Merely filling it with technically interesting work does not establish that result.
Preserve the learning when the project ends
An unsuccessful project can produce valuable evidence. Record the original question, tested approach, important conditions, observed result, and stopping decision. Keep useful components and discard unnecessary complexity.
Suppose the supplier-order assistant fails because source terms are inconsistent. The business may learn that it needs a better supplier record before it needs more automation. That is a narrower, useful conclusion. It does not establish that all assistants fail or that the model caused every problem.
A retired project should leave the current operating process understandable. Remove unused permissions, scheduled tasks, and confusing interface elements. Archive the decision record where a future operator can find it. Preserve only data the business has a legitimate reason to retain.
The learning ledger is the natural home for this evidence. The kill engine protects the boundary; the ledger keeps the knowledge that made the decision worthwhile.
AI Leverage in Practice
What changed: a small operator can launch more experiments and give software more ability to act. The ease of starting can exceed the capacity to monitor, maintain, and retire.
What to do today: choose one active AI workflow and write its stop card. Name a success criterion, a loss limit, an objective trigger, and the exact action that follows. Identify the in-flight work and external obligations the stop must handle.
Exercise the control on copies. Verify that the system stops the intended action and preserves evidence for recovery. Record what was tested and what was not. If stopping depends entirely on the model’s willingness to obey, narrow the authority or add an independent boundary before expanding use.
Give every extension a new decision date and an explicit learning question. A project may continue because it is generating useful evidence, but it should not continue merely because it has already consumed effort.
What may come later: more capable agents and better monitoring may make some tasks safer to continue independently. They will also make it easier to create larger, faster processes. The need for a usable stopping decision grows with the process’s authority and possible consequences.
The freedom to choose something better
A kill engine protects the owner’s ability to change direction. It turns stopping from an admission made too late into a normal part of responsible experimentation.
The useful system is specific: a question, evidence that changes the decision, limits that remain enforceable, a person responsible, and a recovery path that respects existing obligations. It permits uncertain work while refusing unlimited exposure.
The result is more room for worthwhile ambition. Cash and attention that are no longer trapped in an indefinite project can support a better offer, a clearer experiment, or a dependable service customers already need.
Follow The Age of AI Leverage for the full sequence, or explore the wider AI section.
Sources
- OWASP, LLM06:2025 Excessive Agency, on enforcing scoped functionality, permissions, and autonomy.
- NIST, AI Risk Management Framework, voluntary guidance for managing AI risk across a system’s lifecycle. The proposed stop-card method here is an operating recommendation, not a NIST certification.
Loading comments…