The Drift Machine Is the Problem, Not the Filename

On August 25, 2026, Tobi Lütke said he was considering banning Claude Code at Shopify until it reads AGENTS.md and .agents/skills the way it reads CLAUDE.md. At Shopify’s scale — one monorepo, recursively scoped instructions, and multiple agent harnesses — the compatibility gap can leave two engineers in the same tree operating under different effective instructions.

Lütke calls the automation required to reconcile that a complexity tax. He is right about the tax.

The filename is only where it surfaces.

What the complaint actually describes

Strip the vendor names out and the failure mode looks like this:

• Much of the policy and context presented to coding agents is expressed as free-text files.
• Those files live at arbitrary depths in the repository tree.
• They are authored locally, by whoever owns the directory.
• Each agent has its own discovery rules for which files it reads and how they compose.
• Coherence across all of this is maintained by an auxiliary automation layer built to preserve coherence.

That is an architecture that has chosen drift as its default state and then hired a robot to sweep up after it. Asking Anthropic to honor one more filename does not change the architecture. It makes the sweeping slightly cheaper.

Bespoke is the wrong instinct at scale

There is a belief in large engineering estates that goes something like: our teams are different, our subsystems are different, so their agent instructions should be different too. Every directory gets its own context file because every directory is special.

It is the same instinct that produced dozens of repositories where one would do, per-product CI pipelines that all deploy the same way slightly differently, and a shelf of nearly identical Dockerfiles. I have consolidated estates like that more than once, and the pattern is always the same. When you actually diff the “bespoke” artifacts, the overwhelming majority of the content is identical: how to build, how to test, what the conventions are, what is off-limits. The genuinely local part is small, and it is usually the only part anyone can defend.

Agent context files are that pattern again, a generation later. Build commands, test requirements, coding conventions, safety rails: much of that is shared content wearing a local filename. The differentiated part — the knowledge genuinely specific to this service — should remain local. The mistake is allowing shared standards to masquerade as local knowledge until every copy becomes its own source of truth.

The correct move with current tooling is not to tolerate the variation and automate around it. It is to standardize the shared content, preserve genuinely local knowledge as a governed extension, and generate the delivery artifacts.

Not everything in that file is the same kind of thing

Before fixing the container, be honest about the cargo. An agent instruction file typically mixes three classes of content:

• Context: what the system is and how it works. Build commands, service topology, domain facts.
• Standards: what the agent is expected to do. Conventions, patterns, review expectations.
• Controls: what the surrounding system will permit it to do. Permissions, protected operations, architecture boundaries, data-handling rules, release gates.

Distribution problems — the Shopify complaint — afflict the first two. The third class may be described in prose, but it cannot depend on prose for enforcement. Anthropic’s own documentation draws the boundary: CLAUDE.md is context that influences behavior, not enforced configuration, and it warns that long or contradictory instruction files reduce adherence. A few lines of prose in a directory can remind a model of an architecture, a threat model, or a compliance boundary. It cannot hold that boundary in place. Anything that must survive optimization pressure belongs in deterministic controls outside the prompt.

The Wrong Container, Again

I have argued before that every generation promotes an impressive tool to a container before the governance layer exists. The container here is the Markdown file in the repo. It feels natural because it is where the code is, it is versioned, and the agent finds it without being told. Those are exactly the properties that make it a bad home for authority.

A file in a directory is discovered, not delivered. Whether an agent honors it depends on that agent’s attention: its discovery rules, its precedence order, its notion of how nested files compose. Shopify’s split-brain problem is what it looks like when authority depends on attention. Two agents, two attention models, one repository, and the governance forks.

Authority has to live outside the model. It also has to live outside the model’s reading habits. The standard belongs in one place, owned like any other piece of platform configuration, and materialized into whatever each tool consumes. CLAUDE.md, AGENTS.md, .cursorrules, the next one: those become build outputs, not sources of truth. If a vendor changes what it reads, you change a template. Nobody gets lobotomized.

What the fix looks like

Nothing exotic. It is the same shape as any other standards problem, carried through to enforcement:

1. One governed logical corpus. Shared standards and scoped knowledge have owners, versions, review rules, and explicit precedence. Physically it may be distributed and federatively owned; what matters is a single composition model and an authoritative effective result.
2. Federated authorship, governed precedence. Organization-wide invariants, platform standards, domain rules, and service-local knowledge can have different owners. Their composition and override rights are explicit, versioned, and mechanically enforced. Local teams may extend the applicable context; they may not silently weaken inherited controls.
3. Tool-specific materialization. Compilers emit CLAUDE.md, AGENTS.md, .cursorrules, skills, prompts — whatever each harness consumes, placed wherever its discovery rules require. Different filenames, same content, mechanically.
4. Drift detection. Because the files are generated, any hand edit is a diff against the expected output. Drift becomes a CI failure instead of a Tuesday surprise.
5. Load attestation. Each harness records the effective instruction set it actually loaded: source versions, scope, precedence, and how nested instructions composed. A materialization record proves what was emitted; only load attestation proves what governed the session.
6. Deterministic enforcement. Anything load-bearing — permissions, architecture boundaries, data-handling rules, protected operations, release gates — is enforced by the harness, CI system, or policy engine. Generated instructions explain the rules; they do not constitute the control.
7. Execution evidence. The system retains the applicable policy version, attempted actions, permission decisions, control results, and resulting artifacts. That is what lets you distinguish “the instruction existed” from “the rule governed the act.”

Shopify has clearly built a sophisticated agent platform and some form of instruction materialization. Lütke’s complaint establishes that the last-mile interface still fragments by tool. It does not tell us how Shopify governs the upstream source. The general lesson is narrower — and stronger: materialization can absorb a filename mismatch, but it cannot substitute for governed ownership, precedence, runtime attestation, or enforcement.

The vendor fight is real, and it is not the point

I understand the frustration with Anthropic closing the request. From inside a platform team it looks like a vendor refusing a cheap fix that would make a real problem go away. And the interoperability complaint is legitimate: other harnesses recognize the AGENTS.md convention, and workarounds are not equivalent native behavior.

Vendor fragmentation is the trigger. Under-governance is what makes it consequential. If Claude Code reads AGENTS.md tomorrow, an estate whose locally authored, recursively composed, tool-specific governance files stay coherent only because a robot reconciles them still has the underlying problem. The next tool, the next filename, the next discovery rule reopens the wound.

Anthropic should support AGENTS.md. That would remove a needless compatibility tax. It would not create authority.

The durable architecture is a governed source, explicit inheritance, tool-specific materialization, runtime attestation, and deterministic controls outside the prompt. Once those exist, filenames still matter operationally — but they no longer decide what the organization believes.

Standardize the source. Compile the delivery artifacts. Attest what was loaded. Enforce what cannot be optional.

Then the filename becomes what it should have been all along: an adapter detail.

Part of a series on AI governance in regulated-data platforms: The Fireworks Phase, We’ve Been Choosing the Wrong Container for 35 Years, Authority Must Live Outside the Model, and The Somebody Else’s Problem Field Is Running in Production.