AGENTS.md spread faster than almost any convention in the coding-agent space. OpenAI published it in August 2025 as a plain, open format: one markdown file at the root of a repository, read by the agent before it starts working. By December 2025 it had been donated to the Agentic AI Foundation under the Linux Foundation, alongside the Model Context Protocol and Block's goose, with OpenAI, Anthropic, Google, and Block all backing the same foundation.
What AGENTS.md standardizes, and why it spread so fast
The problem AGENTS.md solves is narrow and real. Before it existed, every coding agent read project instructions from wherever its own vendor decided to look, a .cursorrules file, a CLAUDE.md, a tool-specific config buried in a dotfolder. A team supporting more than one agent had to duplicate the same build commands, coding conventions, and test instructions in three or four formats, and keep them all in sync by hand. AGENTS.md gives every agent one predictable place to look, separate from the README a human reads first.
That's enough to explain the adoption curve. Agents.md's own count puts it at over 60,000 open-source projects and more than 20 supported tools, OpenAI's Codex, Google's Jules, Cursor, Factory, Aider, VS Code, GitHub Copilot, JetBrains' Junie, and Devin among them. A format that every major agent vendor reads for free, with zero lock-in, was always going to spread. The Linux Foundation donation formalizes what was already true in practice: this is the one instruction format a team can write once.
Instruction file versus delivery record: two different jobs
Here is where the coverage of AGENTS.md, almost all of it written as adoption news or a "how to write a good one" guide, quietly conflates two jobs that have nothing to do with each other. An AGENTS.md file is read before the agent starts a task. It tells the agent which test command to run, which directories to leave alone, which conventions the codebase follows. It's input. Once the session ends, AGENTS.md hasn't moved: it still says the same thing it said before the agent touched anything, because it's a description of the project, not a description of the session.
What a reviewer needs after the fact is the opposite object: a record of what actually happened in that specific run, which files changed, which commands executed, which of the instructions in AGENTS.md the agent actually followed versus quietly ignored. The loop that produces a coding agent's output, plan, edit, run, verify, generates exactly that information as it runs. AGENTS.md is not built to capture it, and nothing in the format asks it to. A perfectly written AGENTS.md and an empty one leave a team in the same position the moment someone asks what happened in last Tuesday's session: neither file changes.
What the adoption numbers do not tell you
Sixty thousand repositories with an AGENTS.md file is real signal about how many teams standardized their instructions. It says nothing about how many of those teams can also answer, for any given change, who authorized it, what context the agent was allowed to see, and what evidence exists that the delivered code matches what was asked. Those are different questions, and the second one doesn't get easier to answer just because the first one got easier to ask.
It's also worth being honest about whether more instructions even help. A study from ETH Zurich, evaluating AGENTS.md and similar repository-level context files across SWE-bench tasks and a separate set of repositories with real developer-written files, found that context files reduced task success rates compared to giving the agent no repository context at all, while increasing inference cost by more than 20%. The mechanism the researchers describe is specific: agents follow instructions faithfully, so when an AGENTS.md tells them to run more tests, read more files, or search more broadly, they do exactly that, even when none of it is necessary for the task at hand. That's not an argument against AGENTS.md. It's a reason to keep it minimal, and a reminder that a file built to steer behavior is not the same object as a file built to prove what the behavior was.
Why a well-written AGENTS.md can still leave nothing provable behind
Take a team that does everything right: a lean, well-maintained AGENTS.md, an agent that follows it faithfully, a task that finishes cleanly. That team still can't hand a client, an auditor, or a new hire an object that says, for this specific delivery, here is the authorized context, here is what ran, here is who reviewed it, here is the signature. AGENTS.md was never going to produce that, because it answers "what should the agent do here" once, at the start, for every session that will ever run against this repository. It doesn't know, and has no field for, what actually happened in any one of them.
That's the same gap Claude Code's hooks get close to but don't close either: a hook can intercept an action as it happens, which is a step past reconstructing it later from a transcript, but interception still isn't a signed record tied to a specific task and a specific person's authorization. AGENTS.md sits one layer further back, upstream of the session entirely. Getting the instruction file right is table stakes now, not a differentiator. It was never going to be the layer that answers the harder question.
What a software house should keep alongside its AGENTS.md
Write the AGENTS.md, keep it short, and don't expect it to do double duty. What proves a delivery is a separate artifact: which context the agent was authorized to see for this specific task, what it actually did, and a human signature on the result before it ships, the layer that sits above the agent, not inside its config. A standardized instruction file makes the agent easier to brief. It was never meant to make the delivery easier to prove, and treating it as though it does is the gap a team finds out about only when someone asks the question AGENTS.md was never built to answer.