DEEP DIVE · CONTEXT ARCHITECTURE

The Claude Code operating system

Claude Code is the interface I use across coding, CRM work, research, writing, project management, personal admin, and the production systems on this site. The trick is not giving it everything I know. It is giving it a small map of what I know, then loading the right context when the work calls for it.

production system Claude Code CLAUDE.md context files commands memory
The Referential System

Small indexes point to specific knowledge

Most people start by putting everything into one giant instruction file. That works until the file becomes a junk drawer. Important guardrails compete with API trivia, old notes stay in the prompt forever, and the model has to sort through a pile of irrelevant context before doing anything.

My main CLAUDE.md stays focused on two jobs. First, it holds the rules that should affect nearly every task: ask instead of guessing, read documentation before writing config, protect production systems, and get approval before contacting a real person. Second, it acts as a routing table. If a task involves HubSpot, cold outreach, AirOps, writing, or a specific API, it points Claude to the file that owns that knowledge.

Memory works the same way. MEMORY.md is an index, not the memory itself. Each line captures the lesson in one sentence and links to a focused feedback_*.md or reference_*.md file with the evidence, why it matters, and how to apply it. Claude sees the compact index every session, then follows a reference only when it becomes relevant.

.claude/                       # shared, version-controlled system
├── CLAUDE.md                 # always-on rules + context router
├── ben-context.md            # how I think and prefer to work
├── airops-team.md            # people and organizational context
├── airops-sales-process.md   # pipeline and operating model
├── hubspot-schema.md         # CRM-specific source of truth
├── api-docs/                 # one verified reference per tool
├── references/               # checklists, ICP, messaging, SOPs
└── commands/                 # repeatable multi-step workflows

~/.claude/projects/.../memory/ # Claude's project-scoped memory
├── MEMORY.md                 # compact index loaded each session
├── feedback_*.md             # corrections to future behavior
└── reference_*.md            # durable facts learned in practice
The organizing rule
If Claude needs it on almost every task, it belongs in the router. If it belongs to one domain, tool, procedure, or learned lesson, the router or memory index should point to a separate file. The system keeps the map in context, not the entire territory.
The Layers

Rules, context, procedures, and memory stay separate

flowchart TD
  TASK[Task arrives] --> CORE[Always-on judgment rules]
  CORE --> ROUTE{What kind of work is this?}
  ROUTE -->|business question| CTX[Load the relevant
business context] ROUTE -->|specific tool| DOC[Load its verified
API notes] ROUTE -->|repeatable process| PROC[Load the checklist
or command] CTX --> WORK[Do the work] DOC --> WORK PROC --> WORK WORK --> LEARN{Did reality differ
from the docs?} LEARN -->|yes| FIX[Fix the task and update
the source of truth] LEARN -->|durable lesson| MEM[Propose a memory update] LEARN -->|no| DONE[Finish and verify] FIX --> DONE MEM --> DONE style CORE stroke:#8b5cf6 style ROUTE stroke:#10b981,stroke-width:2px style FIX stroke:#10b981
Why It Compounds

Every kind of work improves the same system

Email is one application of this system, not the system itself. The same context architecture supports building software, querying the CRM, researching a company, planning work, writing an article, or handling personal logistics. Each task loads a different branch of knowledge while inheriting the same judgment rules and memory.

The useful part is not that Claude remembers more. It is that failures become infrastructure. If an API returns a field differently than expected, I fix the immediate task and correct that tool's reference file. If a workflow reveals a missing safety check, the check goes into the shared procedure. The next project inherits the correction automatically.

The shared context and procedures are version controlled, so I can see when a rule changed, roll back a bad assumption, and carry the core environment between machines. Claude's project-scoped memory stays separate and gets promoted into the shared source of truth when a lesson belongs there. The company-specific layer can be swapped during onboarding while the judgment rules, documentation pattern, commands, and self-healing loop stay intact.

That is why I call it an operating system. The individual model can change. The durable advantage is the context architecture around it: what the agent knows, when it loads that knowledge, what it is allowed to do, and how every mistake makes the next run better.

Want systems like these at your org?

Contact Me 727-637-2778