On August 25, Shopify's CEO Tobi Lütke posted that he was thinking about banning Claude Code across his company. Not over quality. Not over cost. Not over security.
Over a Markdown filename.
Claude Code reads CLAUDE.md. Most other coding agents read AGENTS.md, a convention now sitting in more than 60,000 open source repositories. In a monorepo with thousands of engineers using different agents, that discrepancy means two agents working the same directory can follow two different sets of rules. Lütke called it a split-brain problem, and said Shopify had built automation to paper over it — automation his platform team shouldn't have had to write.
Anthropic responded the same day. They're making Claude Code more hackable, AGENTS.md support included.
So it resolved. But the reason it made noise is worth more than the resolution: a company that size treated a proprietary context format as a reason to walk away from a tool it otherwise liked. Not the model. The format.
That instinct is going to get much stronger, and it's about to hit something far more valuable than a config file.
The category error everyone is making
The AGENTS.md fight was about instruction configuration: declarative, human-authored, version-controlled, small, lives next to the code.
The fight that's coming is about memory: agent-authored, accumulated, growing, contradictory, temporal.
These are not the same problem, and they don't have the same solution. Configuration wants determinism and a small surface. Memory wants retrieval, conflict resolution, provenance, and decay. The AGENTS.md problem is solved by putting a file in git. Memory isn't.
I'm calling this out because a lot of commentary this month has collapsed the two, and the conflation matters. It leads people to think "portable memory" means "put your memory in a Markdown file," which works right up until you have forty thousand facts and no way to decide which twelve belong in the current context window.
Why memory can't live in a model lab
Anthropic recently unified memory across Claude chat and Cowork, killing the cold-start gap between interactive sessions and background agent runs. It's genuinely good work. It's also solving the wrong scope.
Unifying memory across your own surfaces only creates value if the user's work happens inside your surfaces. Increasingly it doesn't.
Two structural shifts are running simultaneously:
Work is migrating into specialized harnesses. Foundation models are converging on capability and price. The differentiated work is moving into Cursor, into internal agent loops, into domain-specific tooling built by teams who know their domain better than any lab does. Every one of those migrations shrinks the fraction of your real work that any single provider can observe.
The world-domination tour is ending. The premise that one prompt box absorbs every interface, budget, and workflow is finished. A chat window is a poor UI for complex stateful work, and everyone building seriously has figured that out. The durable position for a model lab isn't owning every vertical interface — it's being the intelligence behind teams doing deep R&D on human-agent interaction, state inspection, and onboarding.
For that future to function, memory has to stop being a retention mechanism and become infrastructure:
Model-agnostic and harness-independent
Inspectable and editable by the owner
Auditable, with provenance on every fact
Models are rented intelligence. Memory is accumulated capital. Enterprises are not going to leave their capital inside someone else's garden, however smart the garden is.
The architecture
I've been sketching what this actually looks like as a build. Here's the shape.
The governing constraint: the source of truth must have no vendor, and every index must be disposable.
Everything else follows from that.
L0 — Substrate
A git repository. Markdown with YAML frontmatter, one file per entity, facts as lines carrying provenance tags.
Git because it's diffable, mergeable, auditable, offline-capable, and portable by construction rather than by vendor promise. It's also already the thing enterprises trust with their most valuable asset.
Note what this buys you for free: "inspectable and editable by the owner" isn't a feature you build. It's git log and a text editor.
L1 — Derived index
Vector, BM25, optionally a graph.
The rule that makes portability real rather than rhetorical: this layer is a cache. Never authoritative. Always rebuildable from L0. Violate it once and you've re-created lock-in with extra steps. Honor it and you can swap retrieval engines without a migration project.
L2 — Access, in two directions
Harness-independence is earned here, and it requires both:
Pull — one MCP server over L1. MCP is the closest thing to a cross-vendor wire format the industry has. Tools like Cognee already expose memory this way, so Claude Code, Cursor, and Windsurf read and write against the same store.
Push — a materializer that renders scoped subsets down to
AGENTS.md,CLAUDE.md,.cursor/rules, or a raw system-prompt block.
Push covers the small always-loaded hot set and the harnesses that only read files. Pull covers the long tail. Neither is sufficient alone, and most designs I've seen ship only one.
L3 — Write pipeline
This is the product, and it's where nearly everyone is weakest.
Extract, deduplicate against what exists, detect supersession, attach provenance, apply policy filters, commit. Every write is a git commit authored by a named agent and session — which means the audit trail falls out of the design rather than being bolted on.
Model facts with validity windows, not timestamps. Zep's temporal knowledge graph does this — it records when a fact stopped being true rather than storing snapshots — and on LongMemEval with GPT-4o it scores 63.8% against Mem0's 49.0%. Fifteen points, attributed to that single modeling decision. For enterprise memory, "what was true, and when" is the query that actually matters.
L4 — Governance
RBAC, tenancy, retention, redaction, residency.
For an enterprise sale this is more than half the build and the actual reason anyone buys. It is also the layer the entire open-source memory tier currently hand-waves.
Build versus buy
Don't build the memory engine. That layer is commoditized — Mem0, Letta, Zep, and Cognee all ship Apache 2.0 cores, so licensing isn't a differentiator. What's interesting is that they've placed three genuinely incompatible bets on what memory even is: passive background extraction, agent-curated tiers, and a temporal graph where facts expire rather than vanish.
Build L0, L2, L3, L4. Rent L1.
Your differentiation is portability and governance. It is not retrieval quality, and you will lose if you try to make it retrieval quality.
Three things that will bite you
Retrieval is the hard part, not storage. Writing facts down is trivial. Deciding which twelve of forty thousand belong in this context window is the entire problem.
Portability is real at the data layer and aspirational at the effectiveness layer. Memory tuned for how Cursor injects rules is not automatically well-shaped for a chat system prompt or a background agent loop. You will genuinely escape lock-in. You will not get identical performance across harnesses, and anyone promising that is selling. Promise ownership and auditability — those you can deliver completely.
Curation determines whether any of it is worth having. A store that accumulates uncritically becomes noise inside a month, and noise is worse than cold-start, because cold-start merely knows nothing while noise actively misleads. Budget more engineering for what doesn't get written than for what does.
Sequencing
Phase 1 (~1 month): L0 plus the push materializer. Git repo, schema, rendering to the three or four file conventions your teams actually use. Manually authored. No extraction.
This alone solves the split-brain problem Lütke was complaining about — and it lets you validate demand before building anything hard.
Phase 2: MCP server over a rented index. Now it's bidirectional and agents can read.
Phase 3: Write pipeline and governance. The enterprise product. Where the real work is.
If Phase 1 doesn't get adopted by a team that already feels the pain, Phases 2 and 3 won't rescue it.
The bottom line
The AGENTS.md episode was a small fight over a filename that revealed something large: at organizational scale, teams will trade away model quality for operational optionality.
That instinct is currently aimed at config files. It's going to arrive at memory next, and the stakes there are an order of magnitude higher — because config is something you write once, and memory is something you accumulate for years.
Models are rented. Memory is owned. Build accordingly.
Techgres is a newsletter on AI infrastructure, engineering leadership, and what's actually working in production. Written from the seat of a fractional CTO across HPC and AI platform builds.
#AIInfrastructure #AgenticAI #PlatformEngineering

