I once received a reader comment on this topic: the core of an AI workflow is actually very simple—the human defines the acceptance criteria, and the AI performs the work and checks it against those criteria.
The reader was not wrong, but putting that idea into practice is not easy. Where do the “criteria” come from? How do we ensure they are respected? As a context grows, or when the work moves into a new context, the criteria can drift or even be silently rewritten.
I need a way of working with AI that I can trust. Put simply, I need it to be delegable: the human should not have to watch every step, yet the work should continue within explicit boundaries; when it reaches a gap, it should stop and hand control back; and after a context switch, it should resume from the same state.
This is Part 2 of a two-part series. Part 1 describes several problems in AI work that will not disappear as soon as models improve. This article explains what I want instead, and how Task-Driven puts it into practice.
Stability Matters More Than Occasional Brilliance
I cannot hand work to a system that sometimes produces an A and sometimes falls to a C. A consistent B+ is more valuable.
Stability here does not mean requiring the model to return the same answer every time. It means keeping variation in the overall process under control: the scope does not keep expanding, the acceptance criteria do not change halfway through, different contexts do not each work on a different version of the task, and a poor result does not reach the final delivery without review.
Within the boundaries, the model should have room to perform at its best. What needs to be constrained is how variation propagates, not the existence of variation itself.
Delegability is not something a system can offer to “anyone” in the abstract. The person delegating the work must provide intent, boundaries, and authorization. The system, in turn, is responsible for actively requesting information that is required but cannot be inferred. If a user never supplied an answer because the system never asked the question, that is a gap in the system’s design.
To Make Cost Predictable, Acceptance Criteria Need Boundaries
Predictability has two parts: quality and cost. Without both, work is difficult to truly delegate.
A task that may take three rounds or thirty is hard to schedule or budget, even if the final quality is good. The lever we can actually control is the acceptance criteria: whatever level of quality we require, we must be willing to pay the corresponding cost.
The order should therefore be: the value of the work determines the acceptance criteria, and the acceptance criteria determine the cost. Low-value work should use a lightweight process. Only high-value work justifies multiple rounds of review. A lightweight process does not mean applying the same requirements carelessly; it means choosing a definition of done that matches the value of the work from the outset.
The process can be lighter, but its foundations cannot disappear. The external record remains authoritative, out-of-scope problems must still be stated explicitly, and authorization cannot be inferred. What can be reduced is ceremony, not these properties.
I Do Not Try to Prove That Every Problem Has Been Found
Once cost has a boundary, we also need to accept something else: not every task should carry the obligation to “prove that every problem has already been found.”
This does not mean lowering the bar for review. A known problem should still block completion by default. What I am giving up is the nearly endless additional goal of not only resolving known problems, but also proving that no unknown problem remains.
If work must end with residual issues, those issues need to be recorded explicitly. A person with the authority to decide can then accept or reject them according to the value of the work. A problem that is not recorded cannot be reviewed or challenged. A boundary cannot simply move defects out of sight.
What Humans, Models, and Tools Each Do
The rule for assigning responsibility is simple: whoever can provide something reliably should own it.
- Humans are responsible for intent, boundaries, acceptance criteria, value judgments, and authorization.
- Models are responsible for judgment and execution within those boundaries.
- Tools are responsible for facts, state, records, and boundary enforcement.
Problems arise whenever one of these parties crosses its boundary.
If tools replace judgment, the process becomes rigid. If models decide their own boundaries, the task gradually drifts with their interpretation. If humans have to perform large amounts of mechanical confirmation, they become the bottleneck.
Authorization is the one responsibility that must not be surrendered. Authorization expresses human intent; it is not a judgment about facts. A model may analyze whether an action is worthwhile, but it cannot infer from that analysis that the action has been approved. Actions such as committing, pushing, or publishing—which change shared history or an external environment—still require separate confirmation.
This does not mean that humans must write every contract by hand. The model should actively organize the discussion, expose assumptions, and ask questions. Human attention should be reserved for decisions that cannot be inferred and genuinely require a person.
Handoffs Must Be Written Outside the Conversation
Delegated work spans multiple contexts. A goal or boundary that exists only in the current conversation is invisible to the next context and cannot support continued work.
We therefore need an external record that is independent of the conversation and can persist over time. It is not a summary of the authoritative content; it is itself the authority for the current work. Conversation history, model memory, and temporarily supplied context can all help with understanding, but when they conflict, the external record wins.
The handoff must also work in both directions. Problems found downstream, objections raised, and decisions made must all be written back and preserved. A document that moves only from upstream to downstream is more like a briefing. It cannot record that an earlier judgment was later overturned.
This is also why “have another AI review it” is not enough. Another model can add an independent perspective, but if it does not read the same authoritative record, or if its result cannot be written back, it is merely offering an opinion from another room.
Each new context avoids passing the previous conversation along directly. It reads the external record, performs the current work, and writes the result back. The next context starts again from the updated state.
Isolation and handoff solve two different problems. Isolation reduces the influence of one round’s thinking on the next round’s judgment. Handoff prevents history from being lost and goals from drifting. Both are necessary.
Keep Only Rules That Will Not Soon Become Obsolete
One way to test whether a working method will last is to ask: will this rule become unnecessary after the next model upgrade?
If the answer is yes, it usually should not become a fixed part of the system. It should remain with the model.
How to investigate, how to implement, and which reasoning method to use may all change as models improve. Human intent, value, and authorization will not disappear. Facts and task state will still need to be preserved reliably rather than guessed again by every model.
What should remain fixed are responsibility boundaries and handoff rules, not an ever-thicker execution manual.
The Full Structure of Delegability
Only at this point do the pieces truly connect.
Models, contexts, and execution methods may all vary, but the entire system cannot consist only of variables. The external record provides continuity; the runtime provides determinism.
The runtime does not decide on the model’s behalf. It uses fixed rules to determine where a task begins, what the current context may do, which preconditions must be satisfied, where the result is written, and who receives the next handoff.
It does not guarantee that the model will produce the same answer every time. It guarantees that different answers pass through the same rules for reading, validation, write-back, and handoff. The model’s judgment may vary, but the way that judgment enters task history must be deterministic.
With an external record but no runtime, the model may fail to read it, misread it, or forget to update it after completing the work. With a runtime but no external record, the system can constrain only the current round; it cannot tell the next context why earlier decisions were made.
“The human sets the criteria, and the AI executes and checks against them” is not wrong. It is simply missing two layers: the external record keeps different contexts working on the same task, while the deterministic runtime ensures that every round enters, writes back, and hands off under the same rules.
Task-Driven: One Concrete Implementation
Since late last year, I have been putting these ideas into practice and gradually shaping them into a way of working that I call Task-Driven. It is not the only answer to delegability; it is simply the implementation I currently use.
A piece of work usually begins with discussion. AI first lays out its understanding of the goal, boundaries, assumptions, and missing authorizations. Only after a person confirms them does the work become an executable, testable task. Here, the task is both a contract and the basic unit of handoff across contexts.
Complex work moves through different roles: shaping the task (Frame), converging on value and scope (PM), defining behavior and flow (Design), implementing and producing evidence (Dev), and making an independent judgment (QA). Each role works in a fresh context and carries only its current responsibility. The path can be shortened, or a new finding can send it back upstream, but those changes must be recorded. The model cannot quietly omit them during execution.
At the beginning of each role, the runtime provides the current state, the actual handoff, feedback, and relevant records. At the end, it controls how judgments, evidence, and the next step are written back. What passes between roles is not the previous conversation, but a state change confirmed by the runtime.
Validation evidence is bound to the code state at the time: the product repository’s revision, whether uncommitted changes exist, and a summary of those changes. Once the code changes, old evidence cannot automatically prove that the new version still satisfies the task.
Actions that change shared history or an external environment still require separate authorization. Simple, one-off work can take a lighter path and let the model choose its own execution and review method. What becomes lighter is the process—not the external record, evidence, or authorization that forms its foundation.
Costs and Limits
Task-Driven uses more time and tokens, and it requires a model with sufficient understanding and tool-use ability. It is not a way to make a weak model suddenly strong, nor does it guarantee a better result every time.
What it provides is something different: more stable results, a traceable process, work that can continue after an interruption, and clearer responsibilities between the human and the model.
The extra cost pays off most clearly for complex, important work that requires multiple rounds of collaboration. Chat, completion, and one-off questions still have their own place.
For me, moving from using AI to delegating work to AI is not about writing a longer prompt. It is about separating judgments that may change from boundaries that must not.
Once those boundaries become stable, AI is no longer merely a tool waiting for the next instruction. It begins to act as a collaborator that can take responsibility for a piece of work.