I have been trying to understand why the word “delegation” annoys me so much when people talk about AI agents. It should not annoy me. Delegation is fine. Delegation is how work happens once there is more work than person, which, in my experience, is roughly five minutes after starting anything useful. I am a modern manager, so I call it volunteering (or voluntelling, for the stubborn), but the impact is the same.
You delegate the meeting notes, the follow-up, the invoice, the ticket nobody wants to touch because the description says “quick fix” and therefore definitely contains a distributed systems problem. You delegate the spreadsheet, the vendor email, the meeting where everyone already knows what will be said but the calendar required a sacrifice anyway. That is normal. Annoying, often, but normal.
So when people say that we should “delegate work to AI agents”, the sentence sounds harmless enough. Almost boring. It has the shape of a productivity sentence. It belongs on a slide next to a soft gradient and a diagram where three boxes point at another box, which is how you know civilisation has produced value.
But I do not think we are only delegating work. I think we are delegating write access and pretending it is the same thing.
That is the bit I keep getting stuck on. In the last posts I wrote about statistical approximation and Compiled-AI, I mostly circled around the question of where probabilistic systems belong. LLMs are useful. Obviously. Painfully useful, sometimes. But they are useful in a very particular way: they are good at turning messy context into plausible structure. And plausible structure is not nothing. It is often exactly what you need before something becomes software, policy, documentation, tests, mappings, migrations, or whatever ugly intermediate artifact the work requires. The trouble starts when that plausible structure stops being something we can inspect, argue about, test, and throw away, and starts touching state instead. The model is not suddenly worse there, it’s just that the mistake now has somewhere to go where it really hurts. The problem is not only approximation. It is approximation with write access.
That sentence feels close to the thing I mean.
A model saying something wrong in a chat window is one problem. A model rewriting the thing everyone will later treat as the document is another. The first one is output. The second one is state. The first one can be ignored, copied, deleted, mocked, or sent to Slack with the usual “lol”, because apparently that is how adults communicate now. The second one lives somewhere, and things that live somewhere have consequences.
I came across a recent paper called LLMs Corrupt Your Documents When You Delegate, which is a very good title because it contains almost no optimism. I appreciate that level of honesty. The paper looks at long document workflows where models are asked to keep working on an artifact over time. Not answer one question, not produce one summary, not do the little benchmark dance where everyone pretends the test set was discovered in the wild by innocent hikers. Work on it. Modify it. Continue it. Preserve some things, change other things, and keep the document coherent across time. Basically the kind of thing people mean when they say “agent”, just without the reassuring animation.
The result is not surprising in the abstract, but still ugly in the concrete: the documents degrade. Not always dramatically, which would almost be easier. It is not always the machine driving into a wall while shouting that it has successfully reached the destination. It is more like the document becomes slightly less itself. A clause moves or disappears. A definition shifts. A table survives visually but not semantically. A distractor file sneaks into the main artifact. The tone remains fine, which is very rude, because tone is the cheapest part to preserve while meaning quietly leaves through the side door.
That is the uncomfortable version of failure. The work still looks like work, so now you need to inspect it like evidence. This is something very similar to what I wrote on my private blog already: This [is one of the more dangerous properties of these systems: they fail in complete sentences.](https://matthias-kainer.de/blog/posts/llm-meet-ml-pipeline/)
And this is where I think the agent story becomes strange. We already understand this problem in normal software. A suggested patch is not the same as a merged patch. A migration plan is not the same as a migration that ran. A draft email is not the same as an email sent to 40 customers and one person who will reply-all with “thanks”. We know this. We have built entire ceremonies around this. Branches, reviews, tests, diffs, staging environments, preview environments, feature flags, canary releases, dry runs, migrations, rollbacks, audit logs, access controls, approval flows, schema checks, type checks, linting, CI pipelines, deployment gates, monitoring, alerts, traces, backups, restore drills, runbooks, incident reviews, postmortems, ownership maps, change requests, dependency locks, version pins, checksums, immutable artifacts, reproducible builds, golden files, contract tests, snapshot tests, integration tests, smoke tests, load tests, permissions, rate limits, idempotency keys, transaction boundaries, validation rules, invariants, and the small prayer every engineer performs before pressing enter in production. Yeah, I’m a nerd, I love long lists, deal with it. Half of software engineering is just inventing increasingly elaborate ways to say: maybe don’t mutate the important thing directly.
Then AI agents arrive and the industry starts acting as if write access is a UX detail.
It is not. Same button, different animal. If an assistant writes a bad summary of a contract, the contract is still there. Annoying, but recoverable. If an agent updates the contract and silently changes a term, the model’s mistake may now be part of the artifact. It is no longer next to the work. It is in the work. And once it is in the work, future work can build on it, which is how small mistakes become durable without ever needing to become loud.
This is also where “human in the loop” often does not calm me down as much as it is supposed to. Which human? Seeing what? Before or after the mutation? With a diff? With invariants checked? With the original preserved? With enough context to notice that the model kept the style and damaged the meaning? A human approving a clear proposed change is one thing. A human skimming a polished artifact after a probabilistic system has already rewritten it is something else. That is not supervision. That is archaeology with a nicer interface.
We spend quite a bit of time on this at INXM, and the more time we spend on it, the less I believe in the comforting version of “just put a human in the loop”. The hard part is not adding a little approval box somewhere and pretending responsibility has now been routed through a mammal. The hard part is showing the person what will actually happen before the plan runs for the first time. What state will change. What might break. What assumptions the system is making. What the decision means, not in the abstract, but in terms of the artifact; the workflow, the customer, the invoice, or whatever piece of reality the agent is about to touch.
And then you have to do all of that without punishing the user for reading it. You cannot throw a wall of generated text at them and call it transparency. You also cannot hide the important parts because the UI looked cleaner in Figma. Somewhere between those two failures is the thing you actually need: enough context to make a decision, shaped in a way that a tired human can still understand before clicking the button. So if there is a human in the loop, the loop has to mean something, and it should be scarce so it becomes important to care. And it has to show impact, not vibes. It has to preserve the relevant context, not summarize it into corporate soup. It has to make the boundary visible: before this point, the workflow is proposing; after this point, state changes. Otherwise we have not built supervision. We have built a button that lets everyone feel briefly responsible before the system does whatever it was going to do anyway. None of this is something were my old pals Claude, ChatGPT or Gemini had been particularily convincing to me neither in user flow, nor in actual execution.
I am not saying agents are useless. That would be too easy and also wrong (which is a very efficient combination if you want a career in commenting on technology on LinkedIn, but this is a serious blog post). Agents are useful already, and they will become more useful. For isolated, reversible, low-risk work, go ahead. Let the model explore, draft, sort, prepare, triage, rename, format, summarize, all of that. There is plenty of real work hiding in the annoying edges of work, and if a machine wants to spend its short statistical life making those edges less annoying, I am not going to stand in its way.
But once the model crosses into durable state, I want the system to become boring very quickly.
This is where I keep coming back to Compiled-AI. Not as a grand theory, and not because every workflow should suddenly pretend to be a compiler. More as a shape I trust. Use the model where the input is messy. Let it turn ambiguity into candidate structure. Let it propose the mapping, the rule, the edit, the migration, the classification, the test, the plan. Then stop. Put the thing on the table. Diff it. Version it. Review it. Test it. Run something boring after that. The model can be clever before the boundary. After the boundary, clever is not the feature I want. I want repeatable. I want inspectable. I want something I can blame without it producing an apology in bullet points, starting with “You are right!”
Maybe that is the actual line. AI before the boundary can be weird and useful. AI after the boundary needs a leash, a log, and ideally fewer vibes.
There is also a second reason why this matters, and it is less about one corrupted document and more about how work actually accumulates. Organisations do not usually fail because one artifact is wrong in a beautiful, isolated way. They fail because the wrong artifact becomes input. Someone copies it into the next thing. Someone references the shifted definition. Someone trusts the summary because it looks more finished than the source. Someone builds the migration from the plan. Someone approves the customer email because the tone is good, and tone is apparently enough to pass as competence if the font is clean. That is where approximation with write access becomes unpleasant. It does not just produce mistakes, it’s worse - It produces material for future mistakes.
This is also why I do not think benchmark success, by itself, tells us enough. A system that succeeds once on a clean task has succeeded once on a clean task. Congratulations to the system, and also to the clean task for being so clean. But real workflows are not clean. The input changes slightly, the wording changes, the API returns partial data, a tool times out, a file has a misleading name, a user says “the thing from last quarter”, and suddenly the question is not whether the model can produce a plausible next step. The question is whether the operational end state is still correct.
For agents, the end state is the product. Not the explanation, not the trace, not the confident summary, not the little checklist of what it claims to have done. The state. Did the right thing change? Did the wrong thing remain untouched? Can we prove it? Can we replay it? Can we roll it back? Can we see the difference between the intended change and the actual change?
That is a much less glamorous conversation than “autonomous AI workers”, but glamour has a disappointing incident record.
Delegation sounds like productivity. In systems, it is permission. It is deciding what gets to mutate the world, or at least the small local piece of the world currently represented by a document, database row, ticket, pull request, workflow state, CRM record, invoice, or customer email. That does not mean we should never delegate to AI. It means the word “delegate” is doing too much deodorant work. Say what it REALLY is: the model gets write access. It gets to mutate state. Its approximation may become part of the artifact other people rely on, and once that is the case, the useful conversation changes. It is no longer enough to ask whether the model can do the task. We have to ask what it is allowed to touch, which changes are only proposed, which changes become real, what can be rolled back, what remains the source of truth, and where exactly approximation ends and state begins.
I do not think these questions make AI less useful. I think they are the questions that make it useful without becoming another mess future teams have to excavate. Use the model where ambiguity is the input, where the work is still fluid enough that a plausible structure is valuable. Let it help form the mapping, the edit, the rule, the migration, the classification, the test, the plan. But do not confuse that with execution. And when possible, compile the model’s fuzzy understanding into something dull enough to run without improvisation. That does not make the system perfect. Nothing does. But it puts the uncertainty somewhere visible, before it has quietly entered the artifact and started pretending it was always there.
That is probably my whole discomfort with delegation. It sounds like handing off work, but in AI systems it often means handing over the pen. And the pen is not floating in a chat window. It is attached to production.
I love long lists too