Architecting Intelligence - Chapter 3: Memory Routing and Context

Context is not a prompt-length problem. It is a memory-management problem, and it is the first place this book's central argument surfaces.

“An intelligent system is only as reliable as the context it remembers.”

Introduction: Intelligence Needs Memory

One of the biggest misconceptions in modern software engineering is that Large Language Models “know” your project. They don’t. An LLM only knows what it has been trained on and what is visible within its immediate window of attention. Everything outside that window is effectively invisible — not forgotten in the human sense, but simply nonexistent from the model’s point of view at the moment it reasons.

This creates the primary challenge of LLM-driven development: continuity. A model might design a perfect authentication system today, but if that decision isn’t explicitly present in its context tomorrow, it will likely contradict itself — not out of carelessness, but because it genuinely has no access to yesterday’s reasoning unless you provide it. The problem isn’t intelligence; it’s memory. Successful AI-assisted development is not about writing better prompts; it is about building better systems to manage project context.

Context Is the Project

In traditional development, knowledge is distributed across source code, design documents, issue trackers, and team conversations. Humans have a natural ability to connect these dots over time, drawing on memories formed weeks or months ago even when they aren’t looking at any particular document. LLMs, however, rely on whatever data is fed into them at the moment of reasoning. If critical information is missing from the prompt, it doesn’t exist for the model. For an AI agent, the provided context is the project — there is no background knowledge to fall back on beyond what’s explicitly supplied.

The Cost of Context Drift

Imagine asking an AI to build a messaging platform. On Monday, it decides on a stack: PostgreSQL, JWT authentication, and REST APIs. A week later, you ask it to add notification logic. If that earlier architectural decision is no longer in its context window, the model might suggest MongoDB, session-based authentication, and GraphQL — each individually defensible, but none of them consistent with what was already built.

THE DRIFT TAX

Context drift rarely announces itself. It shows up as a slow rise in the number of corrections you make per session, a growing sense that the model is nearly right but consistently off in some direction you keep having to name again.

Track one number for a week: corrections per session. If it climbs while the work stays comparable in difficulty, your context is degrading, not your model.

None of these are “wrong” in a vacuum, but they are disastrous for a project. This is context drift — the gradual loss of alignment as earlier decisions fall outside the model’s working memory. As projects scale, drift acts as a silent killer of software integrity. It rarely announces itself with an error message; instead, it manifests slowly, as a codebase that becomes progressively harder to reason about because no two parts of it were built against the same set of assumptions.

Memory Routing

Memory routing is the tactical process of ensuring the right information reaches the right agent at the right time. You don’t need to provide the entire project history to a UI designer, nor does a testing agent need a copy of your marketing copy. Flooding every agent with every piece of context available is not a safety measure — it actively degrades performance, because the agent has to spend its reasoning capacity filtering signal from noise.

Effective memory routing delivers only what is necessary: the current task, relevant architectural guardrails, specific coding standards, and the history of recent changes. The goal isn’t “more context”; it is “precision

context.” A well-routed system feels almost invisible in operation — each agent simply seems to already know exactly what it needs to know, because someone (or something) has done the work of filtering the firehose of project information down to what’s relevant for that specific task.

The Living Project Brief

Every project should have a single, canonical “Project Brief” that acts as the source of truth. This is the project’s long-term memory. It defines:

The Mission: What are we building and who is it for? The Tech Stack: What are our mandatory technologies? The Principles: What are our non-negotiable design patterns? The Decisions: What are the key architectural choices made to date?

When an agent begins a task, it must ingest this brief. It serves as the anchor that prevents the model from wandering off into inconsistent design territory. Think of the Project Brief as the equivalent of a well- maintained README combined with an architectural decision log — except that, unlike most human teams’ documentation, it must actually be read and internalized before every single task, not just consulted occasionally by a new hire.

Separating Stable vs. Dynamic Knowledge

Context is not a monolith. You should organize it by its rate of change:

Stable Knowledge: Architecture, programming languages, and design philosophy. These rarely change and should form the foundation of every prompt. Dynamic Knowledge: Bug reports, sprint goals, and active tasks. These change daily, sometimes hourly.

By compartmentalizing these, you reduce noise. Agents can always stay grounded in your core philosophy while focusing their limited attention on the current, shifting task. This separation also has a practical benefit: stable knowledge can be cached, reused, and trusted across many sessions, while dynamic knowledge must be re-verified every time — treating both categories the same way, as if everything were equally volatile, wastes effort re-confirming things that never actually changed.

Documentation as Memory

In traditional software, documentation is a “post-production” activity — something written after the code is finished, often as an afterthought, and often the first thing to go stale. In agentic development, documentation is a “pre-production” activity. It is the fuel for the agents. If your documentation is vague, the model will be forced to make assumptions; if your documentation is crisp and authoritative, the model will follow it with precision.

This inverts the traditional relationship between code and documentation. Rather than documentation describing code that already exists, the documentation becomes the specification that generates the code in the first place — which means investing in clear documentation is no longer a “nice to have” cleanup task, but a direct lever on the quality of everything downstream.

The Principle of One Source of Truth

Conflict is the enemy of automation. If your architecture document says “Use JWT” and your API guide says “Use Sessions,” the agents will fluctuate between the two — sometimes following one document, sometimes the other, with no way to know which is authoritative unless you tell them explicitly. Every major decision must have exactly one authoritative home. If you need that information elsewhere, reference it rather than duplicating it. Consistency in your documentation is the direct precursor to consistency in your code.

A context window is not storage. It is attention, and attention that is spent on one thing is not available for another.

This principle borrows directly from database design — the same logic behind normalization. Just as a well-designed database avoids storing the same fact in two tables (because the two copies will eventually diverge), a well-designed project memory avoids storing the same architectural decision in two documents.

Clarity Beats Volume

Many believe that “more is better” — that feeding an LLM thousands of pages of raw documentation will yield superior results. Usually, this just dilutes the model’s focus. Large amounts of irrelevant information distract the model from what actually matters, the same way a human reader skims past the important paragraph in a hundred-page document because it’s buried among ninety-nine pages of tangential detail. A short, highly-structured architectural summary is worth more than a hundred pages of rambling implementation details.

Building Context Layers

A practical way to structure project memory is through layers:

Figure 3.1 Four layers, four rates of change. The routing decision is choosing which layers this particular task actually needs — and being willing to leave the rest out.

1. Vision Layer: The high-level goals.

2. Architectural Layer: The system design and boundaries.

3. Standards Layer: Coding conventions and style rules.

4. Task Layer: The specific “what” and “how” of the current job.

Each agent should receive the layers relevant to their role, but all must start with the same foundational vision and architectural bedrock. A Coder agent implementing a single function still needs to know the

Vision Layer, even briefly, because that context is what prevents locally “correct” code from being globally wrong — a function that’s technically bug-free but solves the wrong problem for the product.

Humans Manage Memory

Even in highly autonomous systems, the human remains the Chief Memory Officer. The model cannot know when a business pivot or a technical decision has been made unless someone tells it. You must document changes to the project brief as they happen — not at the end of the week, not after the fact, but at the moment the decision is made. A well-maintained project memory ensures that when you start a session tomorrow, the agents are working from the same foundation you built today.

This responsibility is easy to underestimate precisely because it doesn’t feel like “real work” in the traditional sense — it’s not writing code, it’s writing about the code. But in an agentic workflow, this curatorial discipline is often the single highest-leverage activity a human can perform, because every downstream agent’s output quality is bounded by the quality of the memory it’s given to work with.

Looking Ahead

As our software systems grow more complex, managing memory will become as important as writing logic. The most successful AI projects won’t necessarily use the largest, most expensive models; they will use the teams with the clearest, most well-organized context. When every agent shares the same “truth,” your software evolves consistently rather than drifting into chaos.

In the next chapter, we will explore how these foundations — specialized agents and governed memory — come together to create development workflows where humans and AI collaborate as a unified, high- functioning engineering team, beginning with the most foundational artifact of that collaboration: the Intent Schema.

What This Chapter Is Actually About

It is worth being explicit about something, because the rest of this book depends on it.

Everything in this chapter — the project brief, the layered context, the routing discipline, the single source of truth — is a set of manual techniques for compensating for a missing capability. You are doing, by hand and on every session, the work that a memory system would do automatically: deciding what is relevant, retrieving it, assembling it into a working set, and keeping it consistent with what was decided before.

That these techniques work is genuinely useful, and you should adopt them. But notice what their existence tells you. A capability that has to be simulated by the operator on every single interaction is not a convenience feature. It is a structural gap in the architecture. The practices in this chapter are scaffolding around a hole where memory should be.

Book One teaches you to build the scaffolding well, because the hole is real and you have work to ship. Book Two is about the hole.

Chapter Takeaway

Context is the project. What the model has in front of it at the moment of generation determines the output far more than which model you chose. Managing that deliberately — layering it, routing it, keeping one authoritative copy of each fact — is the highest- leverage habit in this book. It is also a manual substitute for something the architecture should provide.

Lab: Build a Routed Project Brief For a project you are actively working on, produce a brief split explicitly into the four layers from Figure 3.1.

1. Constitutional. Mission, non-negotiable constraints, priority ordering when requirements conflict. Target: under 250 words. If it is longer, you have smuggled in architecture.

2. Architectural. Stack, module boundaries, established patterns, the decisions you do not want relitigated.

3. Task. Empty for now. This layer is written fresh per task.

4. Ephemeral. Nothing goes here on purpose. It accumulates and is discarded.

Then run three different tasks, and before each one write down which layers you are loading and why. Keep a log.

What to look for. After three tasks, examine the log. You will almost certainly find that you loaded the architectural layer for a task that did not need it, and omitted it for one that did. That misallocation is the routing problem, and it does not go away with a bigger window — it just gets more expensive.

90 minutes · Artifact: project-brief.md