From Q&A to code generation, and then to having agents take on entire pieces of work, I’ve been using AI for several years now.
Over that time, it isn’t only model capabilities that have changed. The ways people work with AI have evolved as well, and I’ve continually adjusted my own approach alongside them.
There is no single best way to use AI. Chat works well for discussion and synthesis. AI embedded in other tools is useful for immediate assistance. Agents extend a single exchange into a sequence of operations in which they can explore, use tools, and revise their own results. Each serves a different kind of situation; none has truly replaced the others.
This article focuses on one narrower case: when a piece of work already has a clear goal, explicit boundaries, and acceptance criteria, how can we genuinely hand it over to AI?
The more complex the work an agent can perform, the more visible this problem becomes. Model outputs remain variable. As context grows, goals and rules can gradually fade from attention. Splitting work across multiple contexts introduces information loss and handoff drift. Having another model review the result does not guarantee that the process will naturally converge.
So my concern is no longer simply whether AI can complete the work. I also want to know whether its execution scope will remain stable, whether the result can be trusted, whether the required effort will be predictable, and when a person will need to step in.
All of these questions point to the same idea: the ability to delegate with confidence—delegability.
What I Want Is AI I Can Confidently Delegate Work To
Consistency Matters More Than Occasional Excellence
Delegation requires trust, and trust comes from predictability rather than occasional brilliance: a consistent B+ can be trusted with work; an erratic A cannot.
What I want to control, therefore, is not the upper limit of a model’s ability, but the variability of the process as a whole. How many iterations will a task require? Will its scope keep expanding? Will the acceptance criteria change halfway through? Will different contexts interpret the same task in different ways?
This does not mean forcing the model to produce the same answer every time. Individual outputs are inherently variable, and excessive constraints would only weaken the model’s ability to reason and act. What truly needs to be controlled is whether a poor result can travel all the way to final delivery without being caught.
Within the boundary, the model should have room to perform. Beyond it, independent verification and externalized handoffs should stop errors from propagating. We cannot eliminate every fluctuation, but we can keep those fluctuations from being amplified.
Delegability does, of course, have prerequisites. The person delegating the work must consistently provide intent, boundaries, and authorization; no system can replace that responsibility. At the same time, the system must actively request information that is essential but cannot be inferred. A user should not be blamed for failing to provide an answer they were never asked for.
Predictable Cost Requires Bounded Acceptance Criteria
Predictability has two dimensions: quality and cost. Without both, work cannot truly be delegated.
A task may take three iterations or thirty. Even if the final quality is consistently good, unpredictable effort makes the work difficult to schedule, budget, or supervise. It also becomes unclear when a person should intervene.
The cost of AI work is difficult to reduce to a single number. Models have different prices, iteration counts change with task difficulty, and latency varies with the environment. The practical lever is not an abstract cost ceiling, but the acceptance criteria: the more you require, the more you must be prepared to spend.
Unbounded acceptance criteria produce unbounded cost. Adding more review after the fact does not solve the problem, because each stricter round is still pursuing a goal with no defined endpoint.
The order should therefore be: the value of the work determines the acceptance criteria, and the acceptance criteria determine the cost. You cannot bypass the criteria and simply demand that a complex task be cheap, fast, and completely reliable.
This also means that processes need tiers. Lower-value work should use a lighter process; only higher-value work justifies a heavier one. A light process does not mean applying the same standard carelessly. It means choosing an acceptance standard that is proportionate to the value of the work from the outset.
The process can be simplified, but its foundations cannot be removed. The external record remains authoritative. Out-of-scope issues must still be identified. Authorization must never be inferred. Ceremony can be reduced; these properties cannot.
Do Not Try to Prove That Every Possible Problem Has Been Found
If we are not optimizing every task for peak model performance, we must also accept something else: proving that every possible problem has already been discovered should not be a universal obligation.
This does not mean weakening review. Problems that have already been found remain blockers by default. What we give up is the nearly endless additional requirement to solve known problems and then also prove that no unknown ones remain.
If a piece of work must conclude with residual issues, those issues need to be recorded explicitly and accepted by someone with the authority to make that decision in light of the work’s value. An unrecorded flaw can neither be evaluated nor challenged. A boundary is not legitimate if it merely pushes defects out of sight.
What Humans, Models, and Tools Should Each Do
To delegate work, we first need to give the recipient an assignment with clear boundaries. Someone must also make value judgments, while reliable tools must provide facts, preserve state, and enforce those boundaries.
The rule for assigning responsibility is simple: whoever can provide something reliably should own it.
-
Humans own intent, boundaries, acceptance criteria, value judgments, and authorization.
-
Models own reasoning and execution within the boundary.
-
Tools own facts, state, records, and enforcement of the boundary.
Problems arise whenever one of these parties crosses into another’s role.
When tools replace judgment, the process becomes rigid, and situations the rules fail to cover may break silently. When a model defines its own boundaries, the work drifts, because a model’s output does not clearly distinguish what it inferred from what it actually knew. When humans take on large amounts of mechanical work, they become both a bottleneck and an unreliable one.
Every additional human confirmation creates friction that compounds with frequent use. Human attention should be reserved for judgments that cannot be inferred and must genuinely be made by a person.
Authorization is the part that can least be delegated. Authorization expresses human intent; it is not a factual conclusion. A model may determine whether an action seems worthwhile, but it cannot infer from that assessment that the action has been approved.
One approval therefore cannot automatically extend to later actions. Prior discussion, a completed draft, or the fact that the process would normally continue do not amount to authorization. Actions that change shared history or have external effects should be approved separately. At the same time, authorization gates should be few, and each should correspond to a decision that only a person can make.
Handoffs Must Exist Outside the Conversation
Delegated work spans multiple contexts. Goals and boundaries that exist only in the current conversation are invisible to the next context and cannot reliably guide subsequent work. We therefore need a durable handoff medium that exists independently of the conversation.
This externalized record is not a summary of the source of truth; it is the source of truth. Conversation history, model memory, and context supplied by an orchestrator are all secondary. If any of them conflict with the external record, the external record wins.
A handoff also cannot move in only one direction. Findings, objections, and decisions made downstream must be able to flow back and be preserved. A document that can only travel from upstream to downstream is a briefing, not a complete handoff, because it cannot record that a previous judgment was later overturned.
The record should preserve the what, not the how. Intent, boundaries, acceptance criteria, decisions, and the reasoning behind those decisions need to endure. Execution methods can be reconsidered by the model available at the time. Those methods will change as models improve; there is little value in freezing them into an ever-growing operating manual.
Independent contexts and externalized handoffs solve different problems. Independent contexts reduce the influence that judgments exert on one another. Externalized handoffs prevent information loss and goal drift. Independent contexts without reliable handoffs become mere information loss. Handoffs without independent judgment allow everyone to remain consistent with the same mistaken assumption. Cross-context collaboration works only when both are present.
Externalized records provide one more benefit: future work can recover why a decision was made. A commit history alone rarely provides the full answer.
Keep Only Rules That Will Not Quickly Become Obsolete
The durability of a working method can be tested with one question: will a future model upgrade make this rule redundant?
If the answer is yes, the rule probably should not become a permanent part of the system. It should remain the model’s responsibility.
The share of work handled by models will grow as their capabilities improve, so the system should not use ever more text to prescribe work the model can already perform. Human responsibilities will remain because intent, value, and authorization cannot be inferred. Tool responsibilities will remain because facts need to be recorded and verified consistently rather than guessed again each time.
The same asymmetry applies to cost. Model-side cost may decline as capabilities improve: work that requires ten iterations today may take only two in the future. But the fixed costs imposed on people and tools will not disappear simply because models improve. Whether those costs are justified will always depend on the value of the work.
Task-Driven: Putting These Principles into Practice
Since late last year, I have been working in these directions and gradually shaping a method I call Task-Driven. It consists of Skills, documents, rules, and command-line tools.
While continuing to improve Task-Driven, I recently encountered several decision-making problems that could not be solved simply by adding more process or more rules. I then realized that I had been accumulating concrete practices without clearly distilling the principles that supported them. Without that layer of abstraction, many decisions lacked a stable basis whenever different goals and rules came into conflict.
This article emerged from that process. I did not begin with a theory and then implement it through Task-Driven. Instead, I worked backward from existing practice to articulate my principles for using AI, then used those principles to continue examining and adjusting Task-Driven.
From this perspective, the article itself is part of Task-Driven’s ongoing self-improvement. Task-Driven is being refined through its own working method—a form of bootstrapping.
To me, Task-Driven is closer to an operating method than a product in the conventional sense. Its daily operations fall into four categories: distill a piece of work, enter a role, complete a handoff, and close a task. A task is the carrier of the contract and the basic unit of cross-context handoff; it is not an all-encompassing product specification.
Where the Contract Comes From: Discuss First, Then Distill
Task-Driven may look similar to today’s Spec-Driven approaches, but it starts from a different place.
Spec-Driven approaches often assume that a sufficiently complete specification already exists and that plans, tasks, and code can then be derived from it. My day-to-day work rarely begins that way. The initial intent exists only in my head. I first discuss it with AI, then distill that discussion into a bounded, testable work contract.
The absence of a larger global document does not mean a step has been missed; it is the starting condition. Even when a broader document emerges later, it is the result of discussion, generation, and decomposition—not a prerequisite.
Distillation begins with an Intent Lock. The AI first lays out the goal as it understands it, any qualifying conditions, and any authorization that is still missing. A person then confirms it precisely. Confirmation must use an explicit, recognizable instruction; prior discussion, agreement, or an ambiguous “continue” does not count. Only after that confirmation may the AI write the Goal, Scope, Non-Goals, and Acceptance.
Two principles are at work here.
First, acceptance criteria should describe outcomes rather than mistake the examples currently in view for an exhaustive inventory. Examples establish minimum coverage. Uncertain details must be labeled as assumptions or open questions, not presented as settled facts.
Second, confirming intent and authorizing task creation are separate decisions. The first does not imply the second. Creation authorization must also be bound to a specific version of the draft; a material change invalidates the earlier authorization.
Who Works Within Which Boundary: Roles and Independent Contexts
For complex work with a clear goal but little chance of converging in a first draft, I usually begin with the path Frame → PM → Design → Dev → QA. This is a typical route, not a fixed assembly line that every task must follow in order.
Different tasks can take different paths. A small correction with a well-understood scope may go directly from Frame to Dev. A task whose behavior is already defined may skip Design. Decision and research work may not require Dev at all. Roles may be skipped, but only through an explicitly recorded decision—not because the model silently omits them.
Frame turns an idea into a task that can be discussed. PM narrows its value, scope, and success criteria. Design turns intent into implementable and verifiable flows and states. Dev implements within the boundary and supplies evidence proportionate to the work. QA makes an independent judgment against the contract rather than repeating the implementer’s conclusion. Ship is a lifecycle action, not a role that authors judgment records.
What remains fixed is the responsibility boundary of each role, not the order in which roles appear. A role definition states only three things: what the role owns, what it must not do, and where it should route a problem. The specific method remains the model’s responsibility.
The path does not always move forward. If Dev discovers an incomplete behavior contract, it can return the task to Design. If the goal or scope itself is wrong, it returns to PM. QA routes implementation defects to Dev and gaps in behavior definition to Design. If the task fundamentally needs to be rewritten or split, it may even return to Frame.
After the issue is resolved, work continues downstream from the appropriate point. The same role may therefore appear several times in one task—for example, Design → Dev → QA → Design → Dev → QA. This repetition is not a process failure; it means that new findings are returning to the party that actually owns the decision. Every cycle must bring back new facts, judgments, or evidence. If it merely keeps tightening rules around the same issue, the acceptance boundary should be reconsidered instead of allowing the loop to continue indefinitely.
By default, every role pass uses a fresh context and keeps the role fixed throughout that pass. The new context reloads the latest external record, so independent judgment does not mean losing history. This both reduces the influence of the previous line of reasoning and prevents the same conversation from implementing a change while also pretending to review it independently.
This is the durability principle in practice: execution methods belong to the model. The more of them we encode into the system, the faster the system becomes obsolete as models improve. Role boundaries and handoff rules, however, continue to matter.
Where Authority Lives: Externalized Records and Two-Way Feedback
Whichever path the task follows, the conversation is never authoritative. At the beginning of a role pass, the role reads the current boundary from the external task record. At the end, it writes its judgment, feedback, and next handoff back to that record.
Feedback has an explicit route. Every item identifies which role should handle it and whether it has been resolved. A downstream role can overturn an upstream judgment, and that reversal remains in the record.
By contrast, if one session merely says, “The previous design was wrong,” the next context may never know.
Tools, Not Models, Should Guarantee Facts
The runtime writes authoritative records; the model does not edit them directly. Task state, record indexes, feedback entries, and lifecycle fields are owned by the tool. The model contributes judgment only within the structures the tool provides.
One rule is especially important: whenever an aggregate fact will be used as the basis for a decision, it should be generated by a tool whenever possible rather than assembled through an ad hoc model search and count.
Numbers gathered by a model are difficult to audit. Others cannot know exactly what it searched or what it missed, and the same question asked in another context may produce a different answer. A mechanism intended to detect drift cannot do that job reliably if its own inputs are unstable.
Evidence Is Not “We Tested It”
In Task-Driven, validation evidence is bound to the state of the code at the time it was captured, including the product repository’s commit, whether uncommitted changes were present, and a summary of those changes.
When that evidence is checked later, the system compares the recorded tree state with the current tree state. It does not simply trust the sentence, “This was tested before.”
This is both an example of tools providing facts and an application of the principle that we should not claim exhaustiveness. A piece of evidence proves only that, for a specific code state, a specific command produced a specific result. It is not presented as proof that every possible case has been covered.
Two Process Tiers
Not every piece of work deserves the same process.
In addition to the role pipeline, Task-Driven has a freeform path. The runtime is responsible only for creating and resuming the task, recording its chronology, and closing it explicitly. How to understand the problem, how to perform the work, how to verify it, and whether to revise it are all left to the model available at the time.
Freeform is not a simplified version of the role pipeline. It is a different process tier with a lighter acceptance standard from the outset, suitable for simple or one-off work.
Both tiers nevertheless share the same floor: the record remains externalized and authoritative, and actions that change shared history or have external effects still require separate authorization. The process is lighter; the fundamentals are not.
Authorization Gates
Commits, pushes, and releases change history or affect an external environment, so each requires its own authorization. Prior discussion does not mean that the current action has been approved. Commits in the task repository and the product repository are independent as well.
The number of authorization gates is deliberately limited. Only a few points in the entire workflow genuinely require human confirmation—for example, confirming intent, authorizing task creation, and approving external actions or significant history changes. Anything a tool can verify reliably does not receive another human gate.
The reason is simple: every additional confirmation becomes a compounding burden under long-term, frequent use.
An Uncontrolled Loop Revealed the Boundary I Had Failed to Define
Task-Driven does not automatically produce good results. One previous task made that limitation very clear to me.
It was a decision task. In the acceptance criteria, Frame wrote that “its decoupling can be independently reviewed.” My intent was merely to rule out an unsupported claim that the work was complete. But the sentence did not specify who should perform the review or how far that review needed to go.
It gradually came to mean that the result had to be machine-verifiable. Yet asking a machine to prove that a specification document is correct has no natural endpoint: the validator itself becomes another artifact that must be validated.
The task eventually produced more than thirty records and over a dozen versions of the proposal. Nearly seventy percent of the final material concerned how to validate the design rather than the design being validated.
What is more troubling is that every independent review was valid under the criteria in force at the time. No individual round was obviously wrong. Every local step was correct, yet the overall process still drifted away from its goal.
This kind of problem is harder to detect than a single mistaken judgment because it produces no clear local error signal. Every round naturally reaches the same conclusion: the process could be made a little stricter.
In retrospect, the problem was not execution but the original contract. I had never stated how much the work was worth, nor had I defined what “enough” meant. At the same time, every force in the system pushed toward greater strictness: independent verification, escalation of recurring problems, completeness checks, and blocking on failure. Nothing in the system was responsible for deciding that the result was now sufficient.
This is where the principle that predictable cost requires bounded acceptance criteria came from. I did not work it out first and then write it down. I derived it after paying the price of not having it.
The Cost
Task-Driven uses more tokens, takes more time, and demands a certain level of model capability.
It is by no means a silver bullet that can work miracles for weaker models. On the contrary, the more rigid the contracts, state machines, and physical invariant constraints are, the more they require the intense abstract reasoning capabilities of flagship models during initialization and boundary-scoping (such as PM planning and Design). If a model’s baseline comprehension is lacking, it won’t even be able to take the first step under the strict validation of the runtime (For instance, the preview version of DeepSeek Flash V4 frequently suffered from tool-calling drift within runtime contracts due to insufficient post-training alignment; it was not until the official release—which overhauled its post-training specifically for agentic workflows and tool use—that this issue was fundamentally resolved.).
What it trades these for is more stable, handoff-friendly, and auditable outcomes, rather than claiming to produce a “better” result. At least for me, its output is stable and delegable.
It is primarily geared toward professional knowledge work such as software development and research, and is only cost-effective when the problem is sufficiently complex. Chat, autocompletion, and single-turn Q&A still have their respective places.
These are simply my personal, current reflections. They are closely tied to my technical background, usage habits, and specific work scenarios, and will undoubtedly continue to evolve. Perhaps once Task-Driven matures further, I will write a separate article to detail its technical implementation.