The Folder Is the Agent — Kieran Klaassen (Every)
Why this is in the vault
Klaassen (GM of Cora, Every’s AI email product) articulates the most concrete practitioner account we have of the “folder as agent” pattern at scale: 44 concurrent agents, each differentiated not by model but by the project directory they point at. This directly validates the RDCO architecture (skills directory, vault-as-memory, CLAUDE.md as personality layer) and extends it with a dispatch/orchestration layer we have not yet built. It also provides a useful failure catalog — context drift, agent stalls, encoding bugs — from someone running a setup structurally identical to ours.
⚠️ Sponsorship
- Format: Thought-leadership (single-author essay, first-person experience report).
- Sponsor: Softr — native ad block mid-article promoting their no-code AI app builder. No editorial connection to the agent-architecture thesis.
- Self-promo: Heavy — the article plugs Every’s compound engineering camp (paid subscriber event), the compound engineering GitHub plugin (14,000+ stars), and three Every AI products (Cora, Spiral, Monologue). None of these compromise the technical argument but the reader should note the author is selling the methodology.
- Bias: Klaassen is building Cora on this architecture, so he has a vested interest in the “folder is the agent” framing winning. No competing approaches (e.g., framework-heavy orchestration, LangGraph, CrewAI) are discussed or rebutted.
Core argument
-
A folder with a CLAUDE.md, skills, and accumulated context IS an agent. The model is commodity; the folder is the specialist. Changing the folder changes the agent’s role entirely — same Opus model pointed at
~/cora/is a Rails engineer, pointed at~/cora-agent/is an ops engineer. -
Scale comes from multiplying folders, not models. Klaassen runs 44 agents across a handful of specialized folders — multiple agents work inside the same folder on different tasks in parallel using git worktrees.
-
Orchestration requires a dispatch layer, not a smarter model. A Ruby daemon watches a directory for spawn requests. A lead agent breaks tasks into subtasks written as files; the daemon routes workers to the correct folders. Coordination is file-based, checked every 60 seconds. No custom networking or agent protocols.
-
You cannot “vibe orchestrate.” The author tried swarm-style coordination for three months and abandoned it. The lesson: build the folder, use it yourself, trust the flows, then hand it to the dispatch layer. Skipping the trust-building phase produces duplicate work and wasted tokens.
-
Anthropic’s own research supports the pattern — Opus lead + Sonnet sub-agents outperformed single Opus by 90% on research tasks, but multi-agent burns 15x more tokens.
Mapping against Ray Data Co
The convergence between Klaassen’s setup and RDCO is structural, not metaphorical:
| Klaassen’s concept | RDCO equivalent | Gap / opportunity |
|---|---|---|
| Project folder = agent | ~/.claude/skills/, ~/rdco-vault/, CLAUDE.md + SOUL.md | Identical pattern. Our vault IS the accumulated context that makes the model a specialist. |
| CLAUDE.md as personality layer | CLAUDE.md + SOUL.md + skill description fields | We go further — SOUL.md separates identity from instructions, which Klaassen doesn’t do. |
.claude/agents/ specialists | ~/.claude/skills/ (process-newsletter, check-board, compile-vault, etc.) | Same concept, different directory name. Our skills are invoked by the harness, not by a dispatch daemon. |
docs/ as institutional memory | ~/rdco-vault/06-reference/ (400+ diarized entries) | We have deeper accumulated memory; Klaassen has more operational runbooks/postmortems. |
| Dispatch layer (Ruby daemon + file-based messaging) | We don’t have this yet. Our /loop cron + /check-board is the closest analog, but it’s single-agent, not multi-agent dispatch. | This is the clearest gap. Klaassen’s daemon spawns workers, tracks status, and routes results — we do this manually. |
| Git worktrees for parallel agents | Not yet adopted. | Worth testing for parallelizing vault work (e.g., compile-vault + process-newsletter simultaneously). |
/hey morning briefing | /morning-prep skill | Functionally equivalent. |
| Failure modes (context drift, stalls, encoding) | We have not hit these at scale because we run single-agent. | These become relevant the moment we move to multi-agent. File as pre-mortem. |
Key takeaway for RDCO: We have the folders (vault, skills). We have the specialist context. What we lack is the dispatch layer that would let multiple agents work the vault and task board in parallel. Klaassen’s file-based approach — daemon watches directory, spawns workers, checks status on interval — is simple enough to prototype without heavy infrastructure.
Related
- 2026-04-11-garry-tan-thin-harness-fat-skills — Tan’s framework names the same components Klaassen implements: fat skills in folders, thin harness as the CLI, resolvers as CLAUDE.md pointers. Klaassen’s 44-folder setup is the largest documented production instance of this architecture.
- 2026-04-12-cross-check-agent-architecture — Cross-check cluster covering the “thin harness” convergence across 10 sources. This article adds source #11 and strengthens the “folder is the unit of agency” sub-thesis.
- 2026-04-12-harrison-chase-harness-blog — Chase’s “Your Harness, Your Memory” argues memory/context ownership is the moat. Klaassen’s postmortems and runbooks are exactly this kind of sticky institutional memory.
- 2026-04-09-every-four-ai-agents — Every’s earlier piece on running four company-wide agents. This article zooms in on Klaassen’s personal engineering setup rather than the company-level ops agents.
- 2026-03-13-every-compound-engineering-camp — Prior vault entry on Klaassen’s compound engineering methodology, which is the foundation for the folder-as-agent pattern described here.
- synthesis-harness-thesis-dissent-2026-04-12 — Dissenting views on the harness thesis. Klaassen’s candid failure catalog (context drift, vibe orchestration failures, 15x token cost) partially validates the dissent’s concern about scaling costs.