A mail rule that files everything from one domain into a folder, and an assistant told to sort out your inbox, can save you the same hour. Only one of them can be wrong in a way you will never notice.
Automation and delegation get used interchangeably. They are different transactions with opposite failure signatures, and the controls that work on one are close to useless on the other.
The line is drawn where the judgment happens
Automation executes a rule you specified. You decided the outcome in advance, for every case at once, and the machine reproduces your decision. The work it does is not deciding. It is repeating.
Delegation hands over a decision you did not make. The situation is underspecified, deliberately — specifying it completely would be doing the work yourself. What comes back depends on how the delegate read a situation you never fully described.
One test settles most cases. Could you have written down the correct answer in advance, for every input you care about? If yes, you automated, whatever technology you used. If no, you delegated — and you delegated exactly the part you could not write down.
The technology does not decide which it is. A script rejecting invoices above a threshold is automation; a model asked whether an invoice looks reasonable is delegation, with identical plumbing around it.
Automation fails loudly
A wrong rule is wrong the same way every time. That consistency is why automation is comparatively safe to leave running. Its errors correlate, so they surface in aggregate; they reproduce on demand, so they can be bisected; they accumulate into a shape somebody eventually notices — a number that drifted, a queue that stopped moving.
The rule is also inspectable before it runs. You can read it, argue with it, and know what it will do to a case it has not seen. So a wrong rule costs many identical errors, discovered together and fixed once — unpleasant, and cheap to reason about.
Delegation fails plausibly
A wrong judgment is one wrong judgment. It does not repeat identically, does not correlate with anything, and never stacks into a pattern. There is no aggregate in which it appears.
It also arrives dressed exactly like a right one. That is not a defect of a particular delegate — it is what competence looks like. You delegate because the delegate produces reasonable-looking work; a delegate whose wrong answers looked wrong would be incompetent, not safe. The property that makes delegation worth doing is the property that hides its failures.
There is no rule to inspect, either. There is the output and the situation, so checking is partly redoing the work — the thing delegation existed to avoid. The check cannot be exhaustive. It has to be placed.
Two qualifications. Automated systems fail silently too, when the rule discards things nobody counts. And most real systems are a chain of both. The distinction still earns its keep, because it locates where in that chain the failure signature changes.
Monitoring is for rules, review is for judgments
Because automation errors correlate, monitoring works. Watch rates, alert on drift, sample occasionally, and one alarm catches every instance. Inspecting individual runs is waste — every run is the same run.
Because delegation errors are independent and plausible, monitoring finds nothing. Aggregates over judgments say almost nothing about whether any particular judgment was right. You have to look at the instance.
You cannot look at all of them. So the question is which, and the answer is not "the important ones" — importance gets assigned afterwards, by whoever turned out to be wrong. It is the ones crossing a boundary: where output leaves your control or stops being cheap to correct. Drafting, summarising, searching, and being wrong costs a redo. Sending a message, moving money, deleting a record, and being wrong is permanent. Where the gate belongs, and why gates decay when they fire too often, is its own problem.
Assistants are sold as automation and behave as delegation
The vocabulary around AI assistants is automation vocabulary. Workflows. Autopilot. Set it up once. The promise is that you specified something and it now runs. The mechanism is delegation: every run resolves ambiguity you did not resolve, and a plausible answer to a question you never asked is indistinguishable from the answer you wanted.
The prompt feels like the rule. It is not one. A rule constrains every case in advance; an instruction to a delegate is a starting point they interpret, and two identical requests can be handled differently with both readings defensible.
So people apply automation-shaped oversight to a delegation-shaped system. They check that it is running. They watch error rates. Meanwhile the failure that matters produces no error and no outage — it produces one confident, well-formed, wrong result. That is the observability half of the principal-agent problem, the half that does not respond to better incentives.
Correspondence is the worst case for the confusion
Ask an assistant to handle a message and you have delegated four judgments at once: what you are asking for, what the recipient needs to know, what you are willing to commit to, and how to say it. Each is underspecified. The result reads as your position, to someone who will act on it, and nothing afterwards makes it un-sent.
RelayLink treats that as a boundary rather than a workflow step. Composing is delegated — a bad draft costs a redo. Releasing is not: the send is split in two, so a person sees the exact package before anything leaves. Inside it, the assistant's judgments are marked as judgments — assumptions labelled stated by sender or inferred by sender's AI — so a recipient can challenge the inference rather than the conclusion. The send tool is titled "Send package (irreversible)" for the same reason, though what a tool declaration guarantees is less than it looks.
The distinction decides something practical: whether you should be watching a dashboard or reading the thing before it goes. If you want the second built into the send path rather than remembered, connect your assistant.