Essay 5.1 — The Always-On Digital Cortex, Part 1 of 9. Essay 5 opens here; Parts 2 through 9 follow.

For four essays we have circled the claim that the agent is its filesystem. Now we open the filesystem.

Essay 4 showed you the persona file — CLAUDE.md at the project root — that defines who the agent is. Claude Code reads a sibling .claude/ directory automatically at startup; the seed agent fills that directory like this: ⓘ

your-project/
├── CLAUDE.md                ← the agent's persona (from Essay 4)
└── .claude/                 ← Claude Code's brain directory
    ├── CLAUDE.md            ← brain index (what is inside)
    ├── knowledge/           ← long-term memory, organized by topic
    ├── plugins/             ← the agent's reflexes and disciplines
    ├── agents/              ← specialist sub-agents
    └── settings.local.json  ← Claude Code's hook registry

That tree is the substrate. Plural forms — folders, files, scripts, narratives — because no single form serves every kind of memory. Topical recall needs different machinery than procedural reflex. Each plugin folder inside plugins/ carries more forms inside it: a voice.xml of coaching the agent hears at the right moments, an evolution.md narrative of how the plugin grew, hidden data.json state the plugin owns alone. ⓘ

The deeper move is representing different forms of cognition as different forms of memory, so the seed agent always carries the optimum context for what it is currently doing. As you customize your own seed agent, you will invent compartments that fit your work, your roles, your professional context. ⓘ

The one place memory does not live by design is the chat session. Chat context is capped by the model’s window and survives compaction only as a lossy summary. The rest of .claude/ is what makes the agent durable across sessions. ⓘ

Two plugin layers run above this substrate.

The always-on layer owns infrastructure that fires on every prompt, every tool call, every session start, regardless of which job the seed agent is currently working on. Locking the substrate for safe edits. Managing the context window. Structuring jobs. Summarizing long conversations. Gating how the agent asks questions. ⓘ

The phasic layer activates one plugin at a time, dictated by which phase the active job is in. The prototype’s cycle is called OPEVC — observe, plan, execute, verify, condense — and the phasic plugins make sure the seed agent operates differently in each compartment. OBSERVE and PLAN are read-only against project files; EXECUTE writes inside a fenced scope; VERIFY runs scripts only; CONDENSE writes inside .claude/ only, absorbing the cycle’s experiential data into durable memory. ⓘ We open the phasic layer in Essay 6.

Both layers are built from smaller plugins, each owning one narrow concern. The architecture’s value is what those single-concern plugins compose into — ceremonies no plugin could perform alone. ⓘ

We tour the always-on layer first because it surrounds everything else.

Image 5.1. Two plugin layers, one multi-form substrate — the phasic layer writes through the CLAUDE.md hierarchy and absorbs at cycle close; the always-on layer runs alongside, phase-independent.
Image 5.1. Two plugin layers, one multi-form substrate — the phasic layer writes through the CLAUDE.md hierarchy and absorbs at cycle close; the always-on layer runs alongside, phase-independent.

The journey ahead

Essay 5 splits into nine short sub-essays:

Essays 5.2 through 5.6 deep-dive the always-on plugins, one each. Essay 5.7 covers the substrate form the phasic layer USES. Essays 5.8 and 5.9 are for the architects in the audience — how single-concern plugins compose into emergent ceremonies, and how the operator gates substrate edits.

The phasic plugins get their own series in Essay 6. The cell template that lets new plugins be born safely is Essay 7. The four-stage arc from your first job to your first custom plugin is Essay 8.

Why "Single Concern" Matters

Each always-on plugin owns exactly one concern. ⓘ

plugin_integrity owns plugin edit safety — a test gate that commits on pass and auto-reverts to the last clean checkpoint on fail. (It has a second role gating whether plugin-layer edits are admitted at all, opened in Essay 5.9.) brain_guard owns self-compaction — long before the model’s context window runs out, it forces a structured summary so the next conversation starts rebuilt from the right parts, not the lossy tail. ⓘ job_core owns the job lifecycle — what the agent is working on, which phase that work is in, the refusal to stop while obligations remain. interaction_summary keeps a focused job’s cumulative mega-prompt legible as it grows across hundreds of turns. question_discipline owns the asking gate — every question the seed agent asks you carries a registered prefix and a per-prefix slot-set. ⓘ Different concerns, one shared discipline: each plugin stays inside its scope, and none reaches into the others' hidden state.

Each plugin lives in its own folder under .claude/plugins/<name>/ with its own hooks, scripts, hidden state, tests, and voice files. Naming the concern is easy because each plugin only has one to name. ⓘ

The single-concern principle is a minimize rule, not an eliminate rule. Pure isolation is what a traditional library aims for — clean modules with no shared state, talking to nothing they don’t import. The seed agent is a complex cognitive system, and a small amount of structured coupling between plugins is what lets the parts compose into ceremonies larger than any one plugin. Call this single-concern + careful coupling: each part stays narrow; the composition is what makes the ceremony possible. ⓘ

The historian ratchet inside plugin_integrity is a clean example — it blocks plugin editing when the plugin’s evolution narrative has fallen behind, and to do that it depends on question_discipline registering the [PLUGIN-LOCK] prefix, on job_core capturing the user’s approval answer, and on the safe-lock cycle protecting the plugin during the edit. Single-concern plugins compose into one ceremony, each contributing what it owns. We deconstruct this composition in Essay 5.8; the cell-anatomy view that lets new plugins compose this way is in Essay 7. ⓘ

The shape is not unique to software. A real-estate transaction closes the same way — the buyer’s agent, the listing agent, the escrow officer, the title underwriter, the lender, and the inspector each own one narrow concern, never reach into each other’s files, and coordinate strictly through published documents (purchase agreement, title commitment, loan estimate) on a shared timeline; the closing is a ceremony none of them could perform alone, made possible by exactly the same single-concern + careful coupling pattern.

The discipline is in how the coupling happens. When plugins talk to each other, they talk through public, stable interfaces — small command-line surfaces each plugin publishes (one read-only command per concern, job.sh focused being the canonical example), a registry of question prefixes, named voice handles, and the footer marker protocol that organizes the bus. A plugin reads what another plugin chooses to publish; it never reaches into another plugin’s private state. Each plugin’s internal data stays private; only the interface is shared — an honest design limit worth naming: the prototype enforces one-plugin-editable-at-a-time during edits (the safe-lock ceremony), but it does not mathematically prevent a plugin’s author from reading another plugin’s data.json if they choose to, so the discipline depends on plugin authors respecting the public-interface contract rather than on the architecture forbidding the reach. ⓘ

The shape buys three concrete things. Plugins evolve independently — a change inside interaction_summary cannot break job_core as long as the read-only job.sh API stays the same. Plugins are testable in isolation — each tests/ directory exercises one plugin’s behavior without standing up the entire seed. Plugins are addable — a sixth always-on plugin slots into the architecture by exposing its own public commands, not by rewiring anyone else’s. ⓘ

We start with plugin_integrity.

Essay 5.1 — The Always-On Digital Cortex, Part 1 of 9.

Previous: Essay 4 — The Language of Agents — vocabulary that prepares the architecture. Next: Essay 5.2 — Plugin Edit Safety — plugin_integrity — first of the always-on plugin deep-dives.