Context engineering is the term of the year in AI-assisted development, and it arrived with the usual mystique: frameworks, diagrams, job titles. The 2026 industry writing — Martin Fowler’s essays, Sourcegraph’s practical guide, Anthropic’s agentic coding trends report — converges on one finding: for the majority of teams now running coding agents in production, context quality, not model quality, is the ceiling. The reports are right about the diagnosis. But after months of running agents daily on my own repos, I think the discipline deserves a less glamorous name.
It’s plumbing.
Nothing in my setup is clever. It’s four pipes that carry facts to the agent, a drain that keeps sludge out, and a routing valve that decides which pipe serves which question. Install once, maintain rarely, and the whole system compounds quietly in the background. Here’s the full diagram.
Why context engineering displaced prompt engineering
Prompt engineering was interior decorating: rearranging words on the wall of a single request. It mattered when models were weaker and every request stood alone. Agents broke that model. An agent working in your repo doesn’t need a beautifully phrased instruction — it needs to know things: what the codebase looks like, what you decided last month, what it should never touch, where you left off yesterday.
None of that fits in a prompt you type by hand. It has to be piped in — automatically, at the right moment, in the right amount. That’s the entire discipline. The reason “context engineering” displaced “prompt engineering” as the quality barrier is that the bottleneck moved from how you ask to what the agent can see when it acts.
So the question stops being “what’s the magic prompt?” and becomes “what infrastructure feeds this thing?” Infrastructure questions have boring answers. Good.
Pipe 1: a curated file index — the supply line
The base pipe is a plain markdown file, versioned in git, loaded at the start of every session. Claude Code reads CLAUDE.md automatically; every agent harness has an equivalent. Mine is layered: a global file with rules that apply everywhere (“use Bun, never bare npm”), and a per-repo file with the facts of that project (commands, architecture, conventions, deploy targets).
The discipline is ruthless curation. This file is loaded into every single session, so every line costs context forever. Ten durable facts beat two hundred stale ones:
## Package manager
Uses **Bun** (`bun.lock` present). Run commands with `bun` or `bunx`.
## i18n
Primary language is Spanish (`es`). English content lives under `/en/`.I’ve written about this layer in more detail in how I keep context between sessions — the short version is: durable facts belong in a reviewable, diffable file, not in a chat log.
Pipe 2: semantic memory — the well
The file index holds what’s always true. It’s useless for the thousand things that were true once: the reasoning behind an old decision, the dead end you explored in May, why a config value is set to exactly that number.
For that I run a memory server over MCP — mine indexes the codebase plus session notes into a Postgres database on Supabase, embedded with a code-tuned model (voyage-code-3, 1024 dimensions). One of my repos currently has 118 pages embedded. The number that sold me: I asked it for “portfolio filter isotope” — vague, half-remembered intent, not a symbol name — and it returned src/lib/portfolio-filter.ts at 0.88 similarity, first hit.
That’s the property a semantic pipe buys you: recall by meaning. grep finds strings you already know. The well finds things you can only describe. And because it’s wired in over MCP, the agent queries it mid-task on its own — I’m not the librarian.
Pipe 3: a code graph — the blueprint
Semantic search answers “where is X handled?” It does not answer “who calls X?” — that’s a structural question, and embeddings are the wrong tool for it. So the third pipe is a knowledge graph of the codebase: functions, classes, and routes as nodes, calls and imports as edges. The same repo that has 118 embedded pages carries a graph of 1,205 nodes and 1,783 edges.
When the agent needs impact analysis — “if I change this helper, what breaks?” — it traces the graph instead of reading twenty files into its context window. Public reports on graph-based context claim token savings anywhere from roughly 7× to 49×. I don’t have a benchmark that clean, but the qualitative difference is obvious: the agent stops flooding its own memory with file dumps and starts asking the blueprint.
Pipe 4: session pointers — where the water was left running
The mundane pipe, and the one with the best effort-to-payoff ratio. A hook flushes a small pointer at the end of each session: branch, working directory, last commits, state of the working tree. The next session starts with that pointer injected — here’s where you left off — and re-orients from live git before touching anything.
Without it, every session opens with five minutes of archaeology. With it, the agent sits down already knowing which drawer was open. If you run more than one agent at a time, this pipe also carries the warning that saves your branches — I learned that one the hard way in two AI agents, one repo.
The drain: what you keep out of the pipes
Half of plumbing is drainage, and half of context engineering is exclusion. Every byte a tool returns occupies the agent’s working memory for the rest of the session. A 400-line log dump to answer a yes/no question is sludge in the pipes.
So the drain rules are simple: process large outputs outside the context window and surface only the derived answer; summarize instead of paste; and keep the always-loaded file index short enough that nothing important drowns. An agent fed everything remembers nothing.
The routing valve: which pipe for which question
The pipes only pay off if queries go down the right one. My routing table:
| Question shape | Pipe |
|---|---|
| ”What are the rules here?” | File index (already loaded) |
| “Where is X handled?” / vague intent | Semantic memory |
| ”Who calls X?” / “what breaks if…” | Code graph |
| Exact strings, regex, file globs | Plain grep |
| ”Where was I?” | Session pointer + live git |
Note that grep keeps a seat at the table. Semantic search is for questions you can only describe; when you know the exact identifier, the dumb tool is faster and cheaper. Plumbing is not about the fanciest pipe — it’s about correct routing.
When plumbing fails: stale pipes
One warning from the field. A pipe that silently serves stale water is worse than no pipe, because the agent trusts it. I once queued a task spec written against an outdated index; it referenced a component that had been deleted from the codebase a week earlier. The agent would have confidently rebuilt a ghost. The fix is the same as real plumbing: re-index after meaningful changes, and treat “when was this last synced?” as a first-class question. My routine now re-syncs the semantic index after every merge window, the same way I validate a post before publishing — mechanically, not when I remember.
The takeaway
You don’t need a context engineering framework. You need pipes, installed in order of cost: a short git-versioned file of durable facts (an afternoon), session pointers (an evening), then — when the history outgrows any file — semantic memory and a code graph over MCP. Add a drain policy so junk stays out, and a routing habit so each question flows down the right pipe.
None of it is glamorous. That’s the point. The teams stuck at the context-quality ceiling aren’t missing a smarter model — they’re missing plumbing.
