#011 - Context as Infrastructure
April 8, 2026
Enjoying this newsletter?
Subscribe to get future issues
April 7 2026
Claude Code ships with a few context primitives. A CLAUDE.md file for project instructions. Auto-memory that saves corrections between sessions. Skills you can invoke. Most developers write a CLAUDE.md, maybe tweak a few settings, import a couple skills and stop there.
I didn’t stop there.
I started by stretching the built-in features as far as they’d go. Project-specific memory files that track API quirks, architectural decisions, and lessons from past work. Skills that encode entire workflows. Hooks that automatically block dangerous commands before they execute. That got me surprisingly far. But there was a ceiling. The primitives are per-session, per-project. They don’t coordinate. They don’t compound across your entire practice.
So I built a platform on top. I call it PlanMode. It’s a Laravel app with a dashboard, a CLI, and a set of composable packages that sit above Claude Code and add the layers it doesn’t have: task management with a kanban board agents can read and write to. A memory system with hybrid scoring that goes beyond auto-memory. An agent pipeline that orchestrates the full cycle from ticket refinement to code review to merge. Session tracking so I can see what every agent did, what it cost, and what it learned. Multi-channel communication so agents can reach me on Telegram or Slack when they need a decision.
It started as an internal tool for my own practice. It’s grown into something I’m thinking about ways to share; I plan to open-source some of the packages and possibly productize the platform.
Last week I opened a session on a project I hadn’t touched in two weeks. Between Claude Code’s built-in context and PlanMode’s memory system, it already knew the webhook signature format we’d debugged last month. It knew the queue architecture and why we’d designed it that way. It knew not to put sensitive details in PR descriptions because that mistake had already been made and recorded. I didn’t paste anything. I just started working.
The built-in tools are a foundation. But the gap between a CLAUDE.md and a full context system is the same gap between a to-do list and a project management platform. Same idea. Completely different capability.
Two layers of context
Most people hear “context” and think chat history. Or maybe RAG; stuff a vector database with your docs and let the model search them. That’s part of it. But it’s like saying a filing cabinet is an operating system.
The context I work with lives in two layers.
Layer one is Claude Code’s built-in primitives. These are powerful on their own and most developers aren’t using them fully:
CLAUDE.md files that tell the agent what this project is, what conventions to follow, what tools are available. Static. Declarative. The equivalent of onboarding docs for a new hire.
Auto-memory that saves corrections between sessions. When I tell it “this provider’s webhook signature uses a non-standard format; here’s the actual payload structure,” that gets recorded and recalled next time. One correction, applied permanently.
Skills that encode reusable processes. A newsletter publishing workflow. A PR review checklist. A daily planning routine. Instead of re-describing a multi-step process every time, I invoke it by name.
Hooks that enforce guardrails automatically. Block destructive git commands. Prevent commits to main on projects that use feature branches. Catch dangerous operations before they happen, without relying on the model’s judgment.
Layer two is the platform I built on top. This is where it goes from “smart assistant” to “operating system for my practice”:
A memory system that goes beyond one-off entries. Six-dimension hybrid scoring (keyword, vector, recency, importance). Entity graphs that link memories to projects, people, and decisions. Truth lifecycle tracking that can supersede outdated memories automatically. Heavily based on research from Mastra.
Task management where agents and I share the same board. I assign work. Agents pick it up. Progress is visible in one place. A kanban board, CLI, and set of AI tools all pointing at the same data.
An agent pipeline that orchestrates the full development cycle. Refine a ticket, get human approval on the spec, implement in a sandboxed environment, run AI code review, fix feedback, merge. Configurable per project; some run fully autonomous, others need me at every gate.
Session observability. Every agent session is tracked. What it did, what it cost, what tokens it used, what it learned. I can see across all projects in one dashboard.
Each piece in layer one is simple on its own. Markdown files. Prompt templates. Shell scripts. But coordinated through layer two, they create something that feels less like a chatbot and more like a colleague who’s been on the project for months.
The counterargument
There’s a reasonable objection to all of this. Daniel Miessler calls it “Bitter Lesson Engineering,” building on Richard Sutton’s famous essay, “The Bitter Lesson.” The argument: stop hard-coding human knowledge into AI systems. Be specific about what you want, give the model good tools, and let it figure out how to get there. As AI gets smarter, your carefully encoded rules become dead weight. Scaffolding that makes the system worse, not better.
There’s truth in that. I’ve seen it myself. Overly prescriptive instructions that box the model into a worse solution than it would have found on its own. Rules written for last month’s model that don’t apply to this month’s. The more you micromanage, the less room the model has to be smart.
But there’s a line between encoding methodology and encoding context. “Use this specific algorithm” is methodology. “This client’s API sends webhook signatures in a non-standard format” is context. One constrains intelligence. The other informs it.
The memories I save aren’t telling the model how to think. They’re telling it what I know. What happened last time. What this project cares about. What went wrong and why. That’s not scaffolding. That’s institutional knowledge.
A new engineer joining your team doesn’t need you to tell them how to write code. They need you to tell them where the bodies are buried. Context serves the same purpose for AI.
Context compounds (if you maintain it)
When implementation cost is zero, what’s left? Most people say ideas. I don’t think that’s quite right.
Ideas are cheap. I have a folder with 100s of them. The scarce resource isn’t the idea. It’s the accumulated understanding of a specific project, a specific client, a specific codebase. The knowledge that compounds over months of working on something.
Right now, a lot of that knowledge lives in my head. Some of it lives in my memory files and CLAUDE.md instructions. More of it lives in PlanMode’s memory system. But every week, more of it gets encoded into the system. And the system gets better at the work without me in every session.
This is what Kieran Klaassen at Every calls compound engineering: every unit of work should make the next unit easier. Most codebases get harder to work with over time. Compound engineering flips that. Bug fixes eliminate entire categories of future bugs. Patterns, once codified, become tools for future work. The same principle applies to context. Every correction I save, every quirk I document, every workflow I encode makes the next session on that project smoother than the last.
But context that compounds also needs to be maintained. Decisions get reversed. Architectures change. A memory that says “we use SQLite for tests” becomes actively harmful the week you migrate to PostgreSQL. Stale context is worse than no context because the model trusts it. I’ve had agents confidently follow an outdated memory straight into a bug that the old approach would have prevented.
So part of the work is curation. Reviewing memories, updating instructions when things change, deleting what’s no longer true. It’s not glamorous and it can be tedious. But it’s the difference between institutional knowledge and institutional debt. Your AI needs to know when you’ve changed your mind.
The good news: if you set it up right, the AI can manage this itself. Mine checks its own memories against the current state of the code before acting on them. When it finds a conflict, it updates or removes the stale entry as part of the session. The context system maintains itself. Not perfectly, not always. But enough that the maintenance burden doesn’t scale linearly with the number of memories.
That’s the real advantage of treating context as infrastructure. Not just that today’s sessions are smoother. But that every session, if you maintain the system, makes the next one better. An AI agent with six months of maintained project context will ship better work than a fresh session with the smartest model. Not because it’s faster. Because it’s informed.
Context is how you give AI your judgment without writing it a novel every morning.
Cool stuff from the internet
Claude Code Architecture Breakdown by Mal Shaik
After Claude Code’s source leaked last week, Mal studied the internals and found an 11-layer agent orchestration platform underneath the terminal interface. The most relevant part for this issue: tiered context management. Not just simple truncation, but multiple compression strategies that preserve the most important information. Smart concurrency for tools, layered permissions, async generator state machines. If you’re building on top of Claude Code, this is the best breakdown of what you’re building on.
Agent Responsibly by Vercel
Vercel’s internal talk on shipping agent-generated code safely, made public. Their core distinction: there’s a difference between leveraging AI and relying on it. The piece argues that judgment is the new bottleneck, and that operational knowledge should be encoded as runnable tools rather than documentation. Self-driving deployments with automatic rollback. Executable guardrails. The infrastructure angle maps directly to what I’m describing with hooks and skills.
The popular AI productivity narrative is about output. Ship more. Code faster. 10x everything.
I’m more interested in a different metric: how much can I skip re-explaining? How much does the system already know before I type a single prompt? How much of my judgment is encoded in a form that survives me closing the terminal?
That’s the work right now. Not building faster tools. Building informed ones.
Keep shipping, Joey
P.S. If you’ve built context layers on top of Claude Code (or any AI tool), I want to hear what’s working for you. Hit reply.