Each Folder Is Its Own Agent
A CLAUDE.md in a folder turns that folder into a scoped agent. The folder is the memory, the file is the rules. Sales folder, sales agent.
A CLAUDE.md file dropped inside a folder turns that folder into a scoped agent. The folder is the working memory. The CLAUDE.md is the personality and the rules. Claude, mounted at the folder root, reads both and acts inside that scope. Sales folder, sales agent. Content folder, content agent. Same primitives, different domain.
The line that travelled
We gave a talk at the Claude Code meetup in Odense at the end of April. The line people pulled out afterwards was this: "Each of these folders is essentially its own agent. I don't deploy agents. I make folders."
It is a small claim that hides a useful pattern. The pattern is what this post is about.
A CLAUDE.md is a markdown file the agent reads at the start of every session inside a directory. Anthropic documents this in the Claude Code memory reference: project memory at the repo root, sub-directory memory loaded on demand when the agent reaches that directory. The same loader behaviour applies in Cowork mode. This blog folder has its own CLAUDE.md that overrides the vault-wide one. The agent writing these words is reading that file right now.
You do not configure an agent the way you would deploy a service. You write the instructions in a file. The file lives where the work lives. Whatever Claude product reads that folder is the agent.
Why the folder is the right scope
The folder is the smallest unit that already carries domain context.
The files inside a folder share a topic. They use the same vocabulary. They follow whatever naming convention you settled on once. An agent that opens that folder gets all of it as background, automatically, without you spending a turn explaining what the work is. The folder is the context.
Compare with the alternative: a generic chat with a stack of attachments and a fresh system prompt every time. You spend the first three messages re-establishing what you spent six months teaching the last assistant. The folder pattern collapses that re-establishment to zero, because the folder is already organised the way the work is organised.
Same primitives, different substrate
Niclas Johansen spoke just before us at the meetup and walked the room through CLAUDE.md, skills, MCPs, subagents, and hooks at team scale. The thing we wanted to add on top is that those primitives are not Claude Code primitives. They are coworker primitives. The substrate is the variable.
The CLAUDE.md scopes the agent's behaviour. Skills package how a specific task is done. MCPs are how the agent reaches outside the folder when it needs to (a CRM, a search index, a calendar). Subagents handle work that should run in a fresh head. Hooks fire on lifecycle events.
The same five pieces apply whether the folder holds a Go codebase, a marketing vault, a sales workflow, or a single consultant's client list. You do not switch tools. You assemble the primitives differently per domain. The pattern stays the same, and the substrate underneath changes.
What you actually drop in the file
The contents that earn their keep: what this folder is for, what conventions the files follow, what context the agent needs every session, what behaviours you want, and what it should refuse to do.
In our vault the blog folder's CLAUDE.md defines voice mechanics, lists the anti-slop patterns, points at the post template, and tells the agent to refuse to fabricate sources. A sales folder's CLAUDE.md defines the customer profile, the deal-stage vocabulary, and the format for a pre-call brief. Different files, same shape: a one-page brief for a new hire on their first day in that specific role.
The folder holds more than the brief. A log file the agent appends to as it goes, the work itself, sometimes an index of what is where. Personality lives in the CLAUDE.md. Memory and work live in everything else. The whole pattern sits on a Claude subscription pointed at the folder, which for most small companies is enough on its own (argued separately here).
The line from the talk that landed with the room was "personality as text." That is what this is. The model is the same. The personality, the rules, and the refusals are markdown.
Where the pattern stops
The folder-as-agent pattern is single-user and single-tenant by default. That is its honest ceiling.
Three people sharing a folder with different permissions is not a problem this pattern solves. Audit logging across many sessions is not in the file. Real-time data outside the folder lives in MCP servers, not in markdown. None of that is a defeat. It is the line where the pattern reaches the edge of what a file can carry, and you start adding infrastructure on purpose.
The thing the folder pattern still does, even at that ceiling, is force the work of writing down how the work actually gets done. That writing is what makes any larger system possible later. Skip it and you are buying a platform to compensate for a missing one-page brief.
The technical case for why this pattern beats most enterprise document retrieval setups is in Why You Might Only Need a Folder Structure and a Claude Subscription.
The connectivity layer that lets a folder-agent reach beyond the folder when it needs to is MCP.
What goes inside a CLAUDE.md file?
A short brief the agent reads at the start of every session in that folder. What the folder is for, what filename conventions it follows, what context the agent needs every time, what behaviours you want, and what it should refuse to do. Think of it as the page you would give a new hire on day one.
Does this work in Cowork mode or only in Claude Code?
Both. Cowork reads project instructions from a CLAUDE.md in any folder you mount, the same way Claude Code reads it at a repo root. The substrate is different (desktop app, CLI, or IDE), but the loading behaviour is the same. The folder-as-agent pattern is a property of the file, not of the product.
How is a folder-agent different from a regular AI chat?
A regular chat starts cold every session and has no opinion about your work. A folder-agent starts with your conventions loaded, your domain vocabulary in scope, and rules about what to do and refuse. The difference is the difference between asking a stranger for advice and asking the person who has worked in that room for six months.
Can I have multiple folder-agents for different parts of my business?
Yes, and that is the point. Each folder is independently scoped. Sales has one CLAUDE.md. Content has another. Operations has a third. They share no behaviour unless you build that bridge deliberately. You can also nest them: a vault-wide CLAUDE.md sets defaults, and per-folder files override or extend them.
Where does this approach stop working?
When you need multi-user permissions, audit logging, role-based access, or real-time data that does not live in the folder. The pattern is single-user and single-tenant by default. At that ceiling you start adding deliberate infrastructure on top of folders, not in place of them. The work of writing down conventions is still what makes the next layer possible.