Your Agent Config Is Standard Work. Check How Old It Is.

There is a story about a Lean sensei who walked onto a factory floor, stopped at one workstation, looked at the standard work document posted above it, and told the manager he was cheating the company. He had not watched anyone work. He had not looked at throughput. He had noticed that the paper had yellowed. Standard work describes how the job is currently done best, so if the document has not changed, nobody has found a better way, or somebody has, and it never made it back into how the work gets done. Either way the improvement loop is dead, and the yellowed paper is the tell.

Your CLAUDE.md is that document. So is your AGENTS.md, your skills directory, your prompt library. It is the written record of how your agents should work here, and if it has not moved in months while the codebase has, there is no chance it reflects what your team has learned about working with these tools. That is a compound-learning metric you already have and are almost certainly not looking at. This is how to read it properly, including the part I got wrong the first time, and what it turned up when I ran it across my own repositories.

I told this story on the podcast recently while talking with Tomer Elias about how enterprises decide what their AI spend is actually buying. It came up because we had circled into the question of what a manager should measure once people are genuinely using the tools, and the honest answer is that most of the available measurements are about volume.

What makes the sensei story useful is how little he needed. He was not running an assessment. He was reading a single artifact that, in a healthy system, cannot stay still. Standard work is supposed to churn, because every improvement that survives contact with reality has to be written into it or it evaporates when the person who found it moves teams. A yellowed sheet is proof the loop is not closing, and he could see it from across the floor.

The same logic transfers cleanly. If your team has been using coding agents for six months and genuinely learned something: that the agent needs the migration conventions spelled out, that it keeps reaching for the wrong test helper, that it should never touch the generated files: then some file has to carry that. If no file carries it, every session starts from the same ignorance, and the tenth month costs exactly what the first one did.

Here is where the obvious version of this metric falls apart, and I want to name it before anyone runs off and audits their repos on it.

When I first checked my own, several CLAUDE.md files came back six lines long and untouched since early July. On the yellowed-paper reading, that is damning. It is also wrong, because those six lines are a shim. They contain @AGENTS.md and a couple of harness-specific notes, and they are frozen on purpose: the actual standard work lives in AGENTS.md, which every tool reads, and the shim exists so Claude Code picks up the same file that Codex and the rest already use. A pointer that has not changed is not stale. It is stable, which is what you want from a pointer.

So counting the age of the file with the famous name gets you a number that means nothing. Worse, it means nothing in a flattering direction for anyone who has split their config across several files, which is most people who have been at this a while.

The measurement that survives is relative. Compare when the repository last changed to when its agent configuration last changed. That gap is the thing.

A repo committed to yesterday with an AGENTS.md from yesterday is a system where the work and the description of the work are moving together. A repo committed to yesterday with an AGENTS.md from three months ago is a system where the work moved and the description did not, which is exactly the sensei’s yellowed paper. And a repo with active commits and no agent config at all is not a subtle case.

One command, run in each repository:

echo "repo: $(git log -1 --format=%ad --date=short)   config: $(git log -1 --format=%ad --date=short -- AGENTS.md CLAUDE.md)"

That is the whole diagnostic. Here is what it returned across mine on 1 August 2026, unedited:

Two repositories where the loop is closing. Four where it is not, two of those with nothing written down at all despite recent commits. I did not go looking for a flattering result and I did not get one.

The interesting half is not the stale files. It is what the living one accumulated.

yeret-agility-site/AGENTS.md started on 14 March 2026 at 32 lines, in a commit called “Track repo agent guardrails in AGENTS”. That commit was itself a rename of a file previously called CODEX.md, back when there was only one harness worth writing for. By the end of July it was 596 lines across 33 commits. That growth is not documentation drift. Read the commit messages in order and it is a sedimentary record of things that went wrong exactly once:

• “Add rule to ask before pushing branch changes to main”
• “Document C-SDD preview link handoff rule”
• “Make the site audit trustworthy and unblock the weekly cadence”
• “fix the unbalanced brace blocking check”
• “Add context-efficiency guidance for future sessions”
• “Require voice gate for site copy”

Each of those is a session that went sideways, followed by someone deciding the fix belonged in the standard work rather than in their own memory. The rule about asking before pushing to main exists because an agent pushed to main. The voice gate exists because copy shipped that did not sound like me. The file is not a style guide someone wrote up front. It is the scar tissue.

That is what makes the age metric worth anything. A config file that grows is a config file that is absorbing failures, and a team that absorbs failures is compounding. A config file that sits still is a team where the same failure is available to happen again next week, to somebody else, who will also solve it privately.

The finding I did not expect: the two files that stayed alive are the two repositories I work in nearly every day. The frozen ones are not neglected because I decided agent configuration does not matter there. They are frozen because the work itself is intermittent, and intermittent work never accumulates enough friction in one sitting to be worth writing down.

Which inverts the advice you would expect at the end of a piece like this. The instruction is not “go update your stale config files.” Updating a config for a repository you touch twice a quarter is busywork, and you will be updating it from memory rather than from a fresh failure, which produces exactly the plausible, generic guidance that makes these files worse.

The real reading of a large gap is a question about the work, not about the file. If a repository is getting commits every week and its standard work has not moved in three months, one of three things is true. Nobody is learning anything there, which is worth knowing. Or people are learning and keeping it to themselves, which is worth fixing. Or the work is genuinely so routine that there is nothing to encode, which is worth verifying rather than assuming, because “routine” is often what a bottleneck looks like from the inside.

Run the command across every repository your team touches. Sort by gap. Then, for the worst offender that is also under active development, do not open the config file. Go and ask the two or three people working in it what has annoyed them about the agents this month. You will get concrete answers within a minute: it keeps rewriting the fixtures, it never remembers we use the other client, it puts things in the wrong directory. Those answers are the standard work. Write them down, in that repository, in the file the agents actually read.

Then set the metric where it belongs, which is not on the file. Tomer and I landed in the same place from different directions on the podcast: he from an industrial-engineering read of the enterprise as a factory, me from having watched teams get faster at writing code while everything downstream stayed exactly as slow. The measurement that matters is whether your ways of working are changing at all. Pull requests against your agent configuration and skills directory are the cheapest available proxy for that, and unlike token spend, the number is hard to game in a way that does not also make things better.

The sensei did not need a dashboard. He needed to know whether the document had changed. Neither do you.

This came out of my conversation with Tomer Elias on Scaling AI: From Activity to Impact, where we spent an hour on what enterprises can actually attribute their AI spend to, and why the token cap is the least interesting question in the room.

Listen on the episode page or directly on Spotify. Find Tomer on LinkedIn. The longer write-up of that conversation is How to Measure AI Impact Beyond Token Caps.

Here is the moment itself:

A standard work document that never changes is not stability. It is the absence of improvement, written down where anyone who knows to look can read it.