The Three Laws of AI Delegation

Almost everyone has an opinion on AI right now but almost nobody has a test for the concrete case in front of them. Compliance manuals are too long for that, and gut feeling does not scale. So, this is the practical other half of the Watershed Effect: how to hand work to a machine without quietly handing away the part that matters.

In 1942, Asimov wrote three laws for robots.¹ Their strength was never completeness. It is that they resolve conflict: when two laws collide, the earlier one wins, which makes them usable under pressure. I borrowed that format and turned it around. These laws do not constrain the machine - they discipline the person who delegates.

The question before the laws

Before any of the laws fires, there is a duty: for every task, ask whether an AI could do this for you, or with you.

This sounds like permission to use more AI, and people like to hear it that way. It isn't. It cuts in both directions, and the second direction is the one that gets missed. Failing to ask is the same failure as asking and then choosing the machine for the wrong reason. The colleague who automates a judgement that should stay human has erred. So has the one who spends a weekend hand-building something a model would have done in four minutes, because they never thought to ask.

For every task, ask whether an AI could do this for you, or with you. Ask it every time. Then let the laws decide the how.

First Law — Consequence

Whoever delegates a task to an AI remains responsible for its consequences.

Before you delegate, be clear about whom the consequences land on when the system gets it wrong. Turns out that this is not about AI at all.

The machine can produce the work but it cannot hold the consequence. It cannot be the one who answers to a board for a bad call, to a patient for a missed tumor, to a regulator for a flawed filing. Accountability is not a task you can route to a model. Someone human is always standing underneath the outcome, and that someone is whoever pressed delegate.

Once you accept that, the law does something useful: the answer to "who bears the consequence" sorts every task onto a pyramid, and the height of the pyramid has nothing to do with how clever the AI is. It is measured in stake. If the consequence lands only on me, the task is personal — experiment freely, the burden of proof is nil. If it lands on my team or my firm's reputation, it is internal — document the choice, check it against what compliance allows. If it lands on a third party — a customer, a patient, the public — it is client-ready, and now I owe an audit trail, validation, and sometimes a regulator's sign-off before anything moves.

Every capability-maturity model being sold this year sorts AI by how autonomous or how smart it is. This pyramid sorts by who gets hurt if it's wrong. That is the whole difference, and it is the one that keeps you honest — because the temptation is always to talk your stake down. If the honest answer to "who bears the consequence" takes more than two sentences, you are negotiating with yourself.

Second Law — Tool

A delegated task runs on the simplest tool that carries it - and stays self-work when the learning is part of what the task delivers.

That also means: Determinism before AI.

Let's look at the two sub-rules inside this law which do most of the day-to-day work:

Determinism

Before reaching for a model, ask whether the task can be done deterministically. A workflow engine, a script, a lookup table, even a spreadsheet — if any of them can carry the task, they should. Determinism is reproducible, auditable, cheap, and it ages well. Using AI where determinism suffices results in unreliable output and unjustified complexity in the tech stack. The hardest part of using AI well is neither model choice nor prompt engineering. It is the discipline to admit which tasks don't need AI at all. Whenever you hear someone talk about an "AI use case", look closer. Maybe you'll find a plain old decision tree underneath.²

Competence

Some tasks are worth doing yourself because the doing is the point. Let a model write the message you owe a friend, and you have outsourced the one thing it existed to prove — that it came from you. Delegating a task means giving up the learning it carried. The question is not "can the machine do this?" The answer to that is increasingly yes. The question is "would I lose something I'm not willing to lose by not doing it myself?"

Only after those two filters do the familiar engineering questions even arise — standard model or reasoning model, local or frontier, cloud or on-prem. They matter, but they matter last. Most delegation decisions are settled before you get to them.

Third Law — Loop

Where the consequences are irreversible or reach third parties, a human decides. Where they're reversible and stay with you, you may let the AI act.

This is the smallest law and the easiest to apply. Can I undo this, and does it touch anyone but me? Reversible and mine alone — let the machine run, review later if at all. Reversible but it touches others — a human reviews before it ships. Irreversible — a human approves in advance. Irreversible and it reaches third parties — a human decides, with a second pair of eyes and a trail you could show a court.

The failure mode here is the human-in-the-loop who is only there for the photograph: the person who clicks approve without reading, so the org chart can claim oversight that doesn't exist. Stay vigilant.

This is a draft, not a doctrine

I am not always sure I agree with every line here. It is a draft. But it is an ordered draft, and that is already more than most of the AI doctrine on offer in 2026, which is either a thousand pages no one reads in the moment or a slogan that decides nothing. Help me find out where it breaks. That is what drafts are for.

The Watershed Effect

These Three Laws of AI Delegation connect to the other thing I've been writing: The Watershed Effect. It's a map that tells you that as AI converges everyone's tools down to a common floor, the only value left is the human factor.³ These laws are how you walk that map. They are how you work with machines every single day without quietly handing the human factor away, one delegated decision at a time.

The machine can do the work. It cannot be the one who answers for it, learns from it, or is changed by it. Build your habits around that single fact, and most of these rules write themselves.

Delegate the task. Keep the consequence.


Notes & Sources

  1. Isaac Asimov first stated the Three Laws of Robotics in the short story "Runaround" (1942), later collected in I, Robot (1950). He added the Zeroth Law — "A robot may not harm humanity, or, by inaction, allow humanity to come to harm" — in Robots and Empire (1985). The strength I borrow is structural: hierarchical conflict resolution, earlier law wins.
  2. On the determinism-first discipline, see the industry's "workflow vs. agent" debate (2026) and the long-standing observation that a deterministic workflow is reproducible and auditable in ways a probabilistic model is not. The full statement of this idea is the Second Law's determinism sub-question in my own framework.
  3. Companion essay: The Watershed Effect — what AI does to every profession and the question my own industry can't answer. The fuller framework — the standing Imperative, the stake/maturity pyramid, and the worked examples that don't fit an essay — lives in the directive itself.