You cannot automate what you never wrote down

On 30 September I am speaking at the Redis AI Roadshow in Munich, an afternoon built around context engineering and memory for agents (session details on my speaking page). That framing is exactly right, and this post is the organisational half of it. Before you engineer context for an agent, somebody has to write that context down — and that writing is where the real work sits.

Back in December I said one of my goals for 2026 was building AMOS — an Agent Management and Orchestration System. I listed the workloads I wanted it to carry: vulnerability triage, dependency management, incident response, compliance evidence. Nine months in, I am still building it, and the part that consistently takes longest is not the agents.

It is arriving at a shared, written answer to what the process being automated actually does.

The failure everyone is describing wrong

Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. MIT’s Project NANDA put it more bluntly a year earlier: 95% of enterprise GenAI pilots returned nothing, and the divide was not driven by model quality.

Read the post-mortems and they all land in the same place. Brittle workflows. Misalignment with day-to-day operations. Tools that never entered the process they were bought to change.

Nobody writes the finding down in plain language, so I will. These projects failed because the buyer could not describe the work. You cannot hand over a process you have never articulated. An agent given a vague goal and no operating context will produce something vague, and then everyone concludes the model is not ready.

The model is ready. The documentation is not.

What “documented” actually means

Ask for the documentation of a process and what usually comes back is a Confluence page with eight bullet points and a flowchart last edited by someone who left in 2023. That is a list of steps, and a list of steps is worth almost nothing to an agent — it is worth almost nothing to a new joiner either, which should have been the warning.

A process is properly documented when it answers four things:

• What it does. The concrete operation, start to finish, including the systems it touches and the data it moves.
• Why it exists. The business reason. Which risk it manages, which obligation it satisfies, which customer promise depends on it. This is the part that lets anything — human or agent — reason about an unusual case instead of stalling.
• How it is executed. The real path, including the exceptions. Not the happy path somebody drew in a workshop.
• What outcome counts as success, and how you know. A finished state you can verify, not “the ticket is closed”.

There is no reliable public number for how much of this is undocumented, because by definition nobody counted it. The process discovery vendors estimate around half of the work in a company runs on undocumented practice, and they say plainly that the evidence is anecdotal. My own experience says half is generous. Ask three people in the same team to describe the same process and you will get three answers, all partially right, none complete.

That is not a documentation problem. It is an operational risk you have been carrying for years and only noticed now that you want to hand the work to something that reads.

Why this time it is worth doing

The obvious objection: we tried this. We did the BPM programme, we bought the RPA licences, we mapped the processes, and it did not pay off.

Fair. Industry research from Deloitte and EY puts RPA underperformance at 30–50%, and anyone who has built these flows knows the shape of it: roughly 20% of the effort goes into the happy path and 80% into exception handling. Bots break when a UI moves. They break when a document arrives in a new format. They break when a rule changes quarterly.

They break because if-else cannot reason. Every deviation you did not anticipate had to be encoded in advance, by hand, forever. That is why the guidance was always to automate only processes with a low exception rate — which quietly excluded most of the work that actually costs money.

Agents remove that constraint. Not because they are magic, but because they can be given the why and asked to make a judgement inside stated boundaries. The invoice arrives in a layout nobody has seen: an agent that knows the purpose of the check can evaluate it and escalate what it cannot resolve. The dependency bump breaks a build in a way the runbook does not cover: an agent that knows what the runbook is protecting can work out whether it matters.

This is the genuinely new capability, and it is worth being precise about it: the class of automatable work just expanded from “deterministic” to “describable”. Everything you could not automate because it needed a small amount of judgement is now in scope — but only if the judgement can be grounded in something written down. No document, no judgement, no automation.

The old rule was: automate what never varies. The new rule is: automate what you can explain.

Explaining it is the work. Not the model.

The tempting shortcut at this point is to skip the writing. Give the model access to the systems, describe the goal in a sentence, and let it work the rest out. It will produce something. It is not a substitute for the document, for three reasons that all get worse at scale.

It is not repeatable. A model handed a vague goal will take a different path on Tuesday than it took on Monday, and both may look plausible. Without a written definition of the process there is nothing to compare a run against, so there is no test to write, no regression to catch and no way to say whether a change to the prompt or the model made things better. You have not automated a process; you have delegated it to something that improvises. That is acceptable for drafting an email and unacceptable for anything with money, customers or auditors attached.

It is a security decision you did not make. An agent pointed at a vague goal needs broad access to be useful, and broad access is exactly what OWASP calls excessive agency — an agent holding more permission than the task requires. Combine that with prompt injection, where instructions arrive inside a document or a ticket the agent reads, and the blast radius is whatever the credential could reach. A documented process is what lets you scope the credential to the task instead of to the department.

It is the expensive way to buy the same outcome. An agent that has to rediscover the process rediscovers it on every single run — more calls, more retrieval, more context, all of it billed each time. The knowledge does not accumulate anywhere. Write the process down once and it costs nothing to reuse forever; leave it unwritten and you pay a model to reconstruct it, at production volume, indefinitely.

None of that is an argument against agents. It is an argument that the document is the load-bearing part and the model is the easy part to swap.

Every process gets a price

Here is where most transformation programmes lose the room, and where I want AMOS to be uncompromising.

If a process is not measured, it does not go in. Not because measurement is virtuous, but because without it every subsequent decision is somebody’s opinion.

The baseline is not complicated:

current cost = monthly hours × loaded hourly rate

That is it. No maturity model, no consultant framework. Three engineers spending six hours a week each on release coordination, at a loaded cost of €90 an hour, is roughly €7,000 a month. Now you have a number, and the number will surprise people — it usually surprises them upward.

Then you price the alternative honestly. The FinOps Foundation is direct about the fact that token metrics only mean something paired with a business-side measure of value — cost-to-serve reduction, cycle-time compression, defect-rate improvement. Cost per workflow completion, not cost per million tokens. And the AI cost is never only inference: it is tool calls, retrieval, storage, the human review step, and the engineering time to keep the thing alive.

Subtract, and you have an ROI figure that survives contact with a CFO. Sometimes the answer will be that the process is not worth automating. That is a good outcome. It took you a day of arithmetic instead of two quarters of a programme.

Attribute every execution

The second thing AMOS enforces: every action an agent takes is tagged — to a process, and to an owning team or budget.

This sounds like accounting hygiene. It is actually the difference between running an AI capability and guessing at one.

Cost attribution in AI has moved fast, from the cloud bill, to the token, to the individual agent run. Once each run carries a process ID and a cost centre, questions that were previously unanswerable become a query:

• Which processes consume the most and return the least?
• Which team’s agents are running away with spend, and on what?
• Did the ROI we projected in the business case actually materialise, or did we quietly triple the token budget to get there?
• Which process is a candidate for redesign rather than automation?

Without attribution you get the same conversation every organisation has had about cloud spend for a decade: a large invoice, no owner, and a working group. With it, the decision to expand or kill an automated process is data. That is the whole point — I would rather be told by a number than by the most confident person in the room.

Automate everything you can. Replace no one.

I want to be exact about the goal, because it is the part that gets misread.

The target is to automate as much of the repetitive work as possible. The target is not fewer people.

Humans stay for two reasons, and they are not sentimental ones.

Accountability does not transfer. Article 14 of the EU AI Act requires high-risk systems to be designed so that named, competent people can understand the output, intervene and override — with traceability and reversibility. Even where the regulation does not apply, the principle holds: when an automated process makes a bad call, a person answers for it. Design for that from the start. Named owner per process, a real intervention point, a full audit trail. An agent is not a defence.

Judgement is the work you actually want people doing. Apply a simple test to any task: if it is repetitive, it is almost certainly not producing anything new. Repetition is, by definition, the reproduction of a known answer. Nobody’s best work is the four hundredth instance of the same triage. Handing that to an agent does not devalue the person — it hands them back the part of the job that required them in the first place.

The organisations that get this right will not have smaller teams. They will have teams whose calendars are no longer full of things a well-briefed system could have done.

That is the honest state of AMOS at the moment: the orchestration layer is the easier half. The harder half is a company that can describe itself. I will keep writing about both as it goes.

If you are in Munich on 30 September, come and argue with me about it at the Redis AI Roadshow — the day is about context engineering and memory for agents, and process documentation is the least glamorous, most load-bearing context you will ever give one. Details of my session are on my speaking page.