Automation breaks. Delegation adapts.

The wholesale invoice rule at the bakery had fired every Friday for two years without anyone touching it: read the week’s delivery log, total each account, email the invoice. Then a regular account called in a change on a Wednesday, and the rule kept doing exactly what it was told, which turned out to be the entire problem.

Most weeks that rule is invisible in the best way. Twenty-odd cafes order the same bread on the same schedule, the log fills in the same shape every time, and the invoice that goes out matches the order that came in. A trigger-action automation is built for exactly that: a fixed set of inputs, a fixed response, no thinking required because none was ever needed.

The order that stopped fitting

The account was a corner cafe, a regular, the kind of order nobody thinks twice about. On Wednesday the owner called, not the order form, because she was catering a small wedding brunch that Saturday and wanted double her usual sourdough for the week. One wrinkle: the wedding portion needed to be billed straight to the couple, not folded into her own monthly account, since they were paying for their own catering separately.

The rule was not built to notice any of that, because a trigger-action rule cannot notice anything it was not told to watch for. It watches a form field, a schedule, a quantity on a line. A phone call updating a standing order with a one-off billing split is not a field, so it never reached the rule at all. Someone just bumped the quantity on the existing order, because that was the only box available to change it in.

Friday, the rule ran anyway: read the doubled quantity, folded it into the week’s regular total, and emailed one invoice to the cafe’s usual contact for the full amount. The owner opened it, saw the wedding portion buried inside her own monthly bill, and had to call back, explain the split herself, and wait for someone to fix it by hand. The rule did not fail. It did precisely what it was configured to do. It was just configured for a shape of order that, for one week, no longer existed.

The same order, delegated

Hand that same outcome, accurate invoices with nothing billed to the wrong party, to an operator instead of a rule, and the Wednesday phone call is not an exception the system misses. It is the whole job. An operator working from an outcome does not need the change to arrive as a form field. A quick message describing the wedding order and the separate billing, sent whichever channel is closest to hand, is enough to work from, because she is tracking the account, not watching one input for a match.

Because she also has no rule to blindly execute, she treats the split as what it actually is: a judgment call. Not silently apply the old rule, and not silently guess. One question, with the context already attached, the same one-question workday that handles any other exception: the wedding portion needs a new billing contact this once, so does it go out separately at the usual terms, or does a first-time client with no account history need something faster? The cafe owner answers once. The regular invoice goes to her account untouched, and because the wedding client is a one-off with no track record, someone keeps an eye on that invoice and nudges if it goes quiet, instead of it aging silently the way the rule-generated ones never do. The next order shaped like this one, she already knows how it gets split, and does not ask twice.

Why one bends and the other does not

The difference is not that delegation is smarter. It is that a trigger-action rule is a decision tree someone finished writing in advance, and it can only be as wide as the branches somebody thought to add. Patch it for the wedding-order case and you have a rule that handles weddings and still breaks on the next thing nobody predicted: an account paused for a month, a delivery address that changes for one week only, an order split three ways instead of two. Every fix narrows the gap for exactly one case and leaves the shape of the next one just as invisible as this one was.

A delegated outcome does not enumerate cases at all. It carries a goal (accurate invoices, nobody re-explaining themselves), a standard for what normal looks like, and a rule of its own: anything that does not match the standard becomes a question, never a guess and never a silent skip. That is a smaller thing to build than it sounds, and worth writing down properly the first time instead of reconstructing it from memory during the next Wednesday phone call.

Where the rule is still right

None of this is an argument against automation. The bakery’s Friday run for the twenty cafes whose orders never change should stay exactly the plain rule it already is: same log, same total, same email, no judgment required because there is no judgment to make. Asking anyone, human or operator, to eyeball twenty identical invoices a week for the privilege of confirming nothing changed is not delegation. It is busywork wearing a review step. The same goes for anything with a closed set of inputs and one correct output every time: a reorder point on flour, a receipt confirmation, a newsletter slot that is always Thursday at nine. High volume, zero judgment, the same answer every single time, that is a rule’s home turf, and a rule that never gets asked a question it cannot answer is not brittle. It is just doing its job.

The test that actually matters

The honest test is not whether a task repeats. Invoices and newsletters both repeat, and both can go either way. The test is whether the input can arrive in a shape nobody planned for. If every version of the task looks identical every time, wire the rule and stop thinking about it. If a phone call, a one-off request, or an “actually, this time” is even occasionally part of the picture, that task is a delegated outcome wearing an automation costume, and it will keep breaking in a new place every time you patch the last one.

Look at whatever rule broke on you most recently. Odds are it was not a bad rule. It was a delegated outcome someone tried to save time on. Here is what handling it the other way looks like.