Google measured what one stale line in a codebase costs an AI agent session: 70% more steps, 77% more tokens and 105% more wait time, because the agent followed an old bug reference nobody asked it to follow [1]. You can find the expensive ones in about an hour.
Google runs coding agents across its own engineering work, and it published the numbers on 2026-11-06 [1]. The measurement is worth reading slowly, because it changes what you audit.
The scope matters before you quote it to your board. These are Google's sessions on Google's codebase, not a general sample. Google also reports that stronger models show higher distraction rates, so buying a bigger model does not close this gap [1].
One honest limit on the money question: Google measured steps, tokens and waiting time, not your invoice. What those extra steps cost you depends on your plan, your rate card and how much of the work is metered, so this post does not put a currency figure on it. If someone quotes you a dollar amount for this, ask them which part they measured.
A large engineering organisation absorbs a detour because there are dozens of other sessions running. A five-person business running one agent for invoicing, one for enquiries and one for reporting has no spare attention to notice a side quest, and the person who would notice it is usually the same person who has to do everything else.
The failure has three shapes, and each one has an owner problem rather than a model problem.
A comment, note or specification went stale and the agent treated it as a current instruction. The agent then finished work nobody asked for, and the output looked plausible, which is the expensive part. Somebody paid for it in the only currency that matters at this size: time that was supposed to go into the work you actually sell.
There is a second reason this is not a coding-only problem. The same pattern applies to any agent reading your own material: a price list from last quarter, an onboarding note describing a process you changed, a support macro that contradicts your current policy. Your agents read what you wrote, and they cannot tell the difference between a decision and a note about a decision [2].
This is the business version of the audit behind the developer guide we published on the same finding. It needs no technical background, but it does need the person who knows what changed.
Start by listing everywhere an agent reads instructions from: the prompt files, the notes attached to your tools, the shared documents you paste into chat, the email templates, the CRM fields with written policy in them. Most teams find between four and ten sources.
For each source, write down the date of the last real change and who owns it. Three questions do the work here. What did we tell this thing to do that we no longer do? What is still open from that list, and who is actually working on it? Who reviews what comes back before it reaches a customer?
Anything that names a task, a ticket or a promise that nobody is working on is a detour waiting to happen. Delete it or replace it with what is true now. The rule of thumb from Google's own cleanup is worth borrowing: they only proposed deleting a reference after confirming the work behind it was genuinely over, and they routed the proposals through human review, which is how they reached more than 95% acceptance over six months [1]. Deleting instructions you still need is worse than leaving a stale one in place.
If you have an engineer available, the mechanical part of this takes a minute. It counts the markers in a repository and shows the age of the file each one sits in:
# One-off check: how many stale markers does the code the agents read still carry? grep -rnE '(TODO|FIXME|HACK)\(?[a-z]*[0-9/]*\)?' --include='*.ts' --include='*.py' --include='*.js' . \ | grep -v node_modules | wc -l
The count itself is not the answer. It is the list you take to the person who knows which of those are still real work.
You do not need a governance programme. You need three sentences in the file your agent reads, and a habit of deleting the truth when it stops being true.
## Working with this team - The task is the task. If a note or comment references an old job, that reference is history. Do not open, chase or finish that job unless this request names it. - When you notice a stale instruction, list it under "Noticed, not touched" in your summary and carry on with what was asked. - When your work makes an instruction obsolete, delete it in the same change instead of leaving a note about what used to be true. - If two instructions contradict each other, stop and ask which one stands.
The third rule is the one people skip, and it is the one that keeps the count falling. A cleanup that only removes what exists today is a cleanup you repeat next quarter.
We covered the review side of this discipline in the piece on who approves what an agent may do and in the audit for agents running without anyone's oversight. Those are the two halves of the same question: what may the agent do, and what did we tell it.
The tooling can help you see it. An open-source auditor such as Stroq records what an agent actually did in a session and traces a risky command back to the material that dictated it [2], which is the evidence you need when you sit down with the person who owns the process. Claude Code's changelog has been moving in the same direction from the vendor side, including entries that deny a tool call rather than wait on a permission prompt [3].
Two patterns work. Either one of your people owns the agent instructions and reviews output weekly, which is practical when you have a technical person who wants the work, or you have someone run the function for you and report on it, which is the pattern we sell.
The distinction that matters is what you are buying. A tool automates a task you have already decided how to run. A function gets run, watched and corrected, which is why the check above is a recurring hour rather than a one-off project. If you are at the stage of comparing those two, our comparison of what the tools actually do for a small business walks through where each one stops, and the piece on why capable small teams stall covers the version of this where the tooling is fine and the routine is missing.
For teams running agents on real customer work, the first thing worth fixing is usually not the model. It is the pile of instructions nobody has read since the process changed. That hour is the cheapest thing on this list.
Is this only a problem for developers? No, though the measurement comes from coding agents. Any agent that reads your written material can follow something you no longer intend, and business documents go stale in the same way code comments do.
Does a better model fix it? Not according to the source. Google reports higher distraction rates with higher capability models [1], so the fix is in what the agent reads and who reviews the result, not in the tier you buy.
What does the extra work cost me in money? It depends on your plan and how much of your usage is metered, which is why we quote the measured overhead rather than a currency figure: 70% more steps, 77% more tokens, 105% more waiting per affected session [1]. Ask your vendor for the metered breakdown before you accept anyone's estimate, ours included.
How often should we repeat the check? Quarterly for the full list, and after any process change, because a changed process is exactly what makes yesterday's instruction wrong. Teams that review agent output weekly tend to catch the contradictions before they reach a customer.
Do we need to buy something to do this? No. The audit is a list and an hour with the person who knows what changed. Tools help you see what an agent did after the fact, and we build and run this function when you would rather not own it internally.
Pick one agent you already run and list every file, note and template it reads. Mark the ones that describe work nobody is doing, and get rid of them this week. Then add the three rules and put a weekly review on someone's calendar, because that review is what keeps the list short.
If you would rather see this done once in your own systems, send a written intake and describe the agent, the tools it touches and who owns it today. We run this for small teams as an embedded function, and we publish what we learn here, including the developer-level version of this audit for the people who will do the deleting.
[1] Google Developers Blog, "Agent Distraction", 2026-11-06, Sam Saccone and Madhuri Garikapati. Source of every figure: the 13% exposure rate, the 6% and 83% action rates, the 41% and 57% split, the 70%, 77% and 105% overhead at p<0.0001, the higher-distraction-with-higher-capability finding, and the cleanup result of thousands of confirmed obsolete references at over 95% human acceptance.
[2] Stroq, a local audit of what a coding agent did and why, open source, TypeScript, last push 2026-11-07.
[3] Claude Code CHANGELOG, release 2.1.319, file last committed 2026-11-06. The changelog carries no per-release dates.
[4] r/ChatGPTCoding, top posts of the week, where reviewers discuss how long checking an agent's work now takes. Individual permalinks returned an empty body to this machine, so the feed is the citable source.
Maxpertise is an AI-native engineering company. We embed native AI engineers inside your team, live in about 10 days. Please enable JavaScript to view the site, or email contact@maxpertise.net.