Context engineering is deciding what the model sees before you ever write a prompt — which files, rules, memories, and tools are in front of an AI at the moment it starts working. The prompt is a sentence; the context is the room the sentence is spoken in. Over the past two years I’ve rebuilt my whole business — a small agency, a personal brand, one human, a fleet of Claude Code sessions — as a set of context layers, so that any session, opened cold, wakes up already knowing the company. This guide is that architecture, with the actual files.
The test I hold everything to is simple and a little unforgiving: open a fresh session with zero conversation history and ask it to do real work — draft the proposal, close the books, write the launch kit. If it has to ask who the client is, where things live, or what I decided last month, my context has failed. If it starts working like a colleague on day two hundred instead of day one, the context did its job. Most of what follows is how I make that test pass — and what the AI labs published this past year that explains why it works.
The labs converged on one lesson: manage what the model sees
The term is young. In June 2025, Shopify CEO Tobi Lütke suggested retiring “prompt engineering” in favor of context engineering — “the art of providing all the context for the task to be plausibly solvable by the LLM.” Andrej Karpathy seconded it with the definition everyone now quotes: “the delicate art and science of filling the context window with just the right information for the next step.” Simon Willison logged the moment two days later. Neither of them coined the phrase — Lütke popularized it, Karpathy defined it — and the field moved in.
That September, Anthropic formalized it: context engineering is “the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference” — everything the model sees, not just the instruction on top. The same post names why it matters. Models suffer “context rot”: as the tokens in the window increase, the model’s ability to accurately recall information from that context decreases, because every token draws down a finite “attention budget.” And that isn’t one lab’s framing — Chroma tested eighteen frontier models and found reliability degrades as input grows, even on simple retrieval, well before the window is full.
Anthropic’s Claude Code documentation compresses nearly all of its best practices into one sentence: “The context window is the most important resource to manage.” OpenAI reports the same physics from its side of the street: in its GPT-5 prompting guide, the model’s Tau-Bench Retail score rose from 73.9 to 78.2 percent just by preserving its prior reasoning between turns — same model, same task, better context.
None of this made careful prompting obsolete. It demoted it. The sentence you type is the last layer, and by the time you type it, most of the outcome is already set.
A small business is five layers of context, smallest at the top
When I read those posts, the feeling wasn’t discovery — it was recognition. Running a business on AI had pushed me to the same mechanisms from the other direction, by way of deadlines and a couple of honest burns. Here is the stack, top to bottom. The rule underneath all of it: the layers that load in every session stay ruthlessly small; everything else loads only when needed.
Layer 0 — the foundation file shared truth
One file, about seventy lines, that sits above every project: what we believe (story is infrastructure; the human is the center), how we sound, and where my two brands — the agency and the personal one — are allowed to differ. Both inherit it; neither dictates the other. The lab guidance stops at the repo, but a business needs context engineering at the identity level, because every downstream artifact inherits identity silently — the proposal, the homepage, the invoice email, all of it.
Layer 1 — sixteen lines of global rules always on
The entire always-on layer of my setup is sixteen lines:
The always-on layer, complete — sixteen lines, lightly genericized. It costs context in every single session, so every line pays rent.
Notice what it is: not a manifesto, an information architecture. Every piece of work has an address; every project is a git repo; downloads are an inbox, never a workspace. The Claude Code docs give the per-line test I apply to this file — would removing this line cause the model to make mistakes? If not, cut it.
Layer 2 — an identity file per project 22 folders
Each of my twenty-two client and brand folders carries its own identity file: who this is, what lives here, and the working rules — verify at phone width before handoff; never expose agency economics; draft alongside live assets, swap on sign-off. The agency’s file is thirteen lines. The standard is the cold-open test from the top of this guide: a fresh session should be able to do correct, on-brand work from the file alone.
Layer 3 — memory as a menu, feedback as law indexed
About twenty of my projects carry a persistent memory directory: one fact per file, indexed by a curated MEMORY.md that works like a menu — one line per fact, thirty-one facts on the personal brand alone. The model reads the menu, then opens only the file it needs. Anthropic lists structured note-taking as one of its three techniques for working past a finite window — “the agent regularly writes notes persisted to memory outside of the context window” — and the index is what keeps those notes from becoming their own rot.
The menu, not the dump — the model reads one line per fact, then opens only the file it needs.
Two species of memory matter most. project-* files hold ratified decisions and the state of ongoing work. feedback-* files hold corrections — written as law, with the why attached. That fifth line above exists because a misconfigured deploy really did serve an entire repo publicly for six days; the correction became a standing rule the same day, and the mistake is now structurally hard to repeat. The labs describe memory as notes. I’d push it further: the highest-value memory in a business is governance — feedback that becomes law.
Layer 4 — skills: procedure, not prompt on demand
Around forty skills, thirteen of them built at this desk. A skill isn’t a saved prompt; it’s a directory holding a procedure — trigger conditions, steps, guardrails, output format — for a job that recurs: drafting inbox replies (drafts only, never sends), turning a scoped call into a statement of work, closing the monthly books. The design principle, from Anthropic’s agent-skills post, is progressive disclosure: at startup only a name and description preload — roughly a hundred tokens per skill — and the full procedure loads only when the task calls for it. “Progressive disclosure ensures only relevant content occupies the context window at any given time.” My house rule on top: skills reference canonical context, they never restate it. One source of truth per fact; skills are pointers plus procedure.
Loops and fresh-context reviewers turn the stack into a harness
Context layers make one session smart. The harness is what makes many sessions a company. I keep a register of every recurring process in the operation — each with a status:
The loop register — eight routines running on schedules, ten-plus candidates earning their way up the ladder.
The discipline is the promotion ladder: I fire it by hand → I fire it on a cadence → an event fires it → a schedule fires it. Nothing gets automated until it has run manually enough times to trust, and everything that recurs gets written down so it can be promoted. I’ve written up the org-chart view of this in the graph engineering guide, and the day-to-day of conducting the terminals in how I manage multiple Claude Code sessions.
The pattern I lean on most is plan-execute-review: one context plans, a second executes, a third grades the work against a written standard and sends it back until it passes. That’s the Writer/Reviewer pattern straight from the Claude Code docs — “a fresh context improves code review since Claude won’t be biased toward code it just wrote.” The reviewer sees only the work and the criteria, not the reasoning that produced it. Which is exactly the editor you want.
For research, I fan out. The research behind this guide ran as a 109-agent workflow — searches, source fetches, a three-vote adversarial check on every claim — each agent in its own context window, reporting back a short summary. The economics are real, and the labs are honest about them. Anthropic reports that its multi-agent research system outperformed a single-agent setup by 90.2 percent on an internal eval, and that capacity did most of the work — token usage by itself explained 80 percent of the performance variance. It also reports the bill: agents burn about four times the tokens of a chat, multi-agent systems about fifteen times — “only economically viable for high-value tasks.” And it’s task-dependent, not gospel: Cognition’s “Don’t Build Multi-Agents” argues tightly coupled work belongs in one context — and I run it that way. Fan out for breadth; stay single-session for anything where the pieces have to agree with each other.
What context engineering does for client work
All of this sounds architectural until a deadline touches it. Three patterns from my client work, names withheld because the names aren’t the point:
The launch kit. One client announces a new university partnership several times a year — press release, social posts, partner emails, the full set. That used to be a multi-day scramble of hunting down the last announcement and reverse-engineering what worked. Now it’s one skill with the brand rules, the templates, and the past examples baked in. “Same game plan for the new school” is the entire brief. The context does the remembering.
The voice profile. Several client executives have living voice profiles — one canonical file per person. Interview transcripts go in; on-voice LinkedIn drafts come out. The ghostwriting skill deliberately contains no voice rules at all — it points at the profile. When an exec gives feedback, one file changes, and every future draft inherits the change. OpenAI’s guide warns that contradictory instructions are especially expensive, because the model burns reasoning trying to reconcile them; one-source-of-truth-per-fact is my version of that warning, applied to files instead of prompts.
The copy pipeline. A messaging framework, a canonical template, and a skill that maps one onto the other — preserving structure exactly and verifying character counts with code. New program, same rails.
The common thread: deliverable quality stopped depending on what I happened to remember on a given Tuesday. It lives in the context now, where it compounds.
Start Monday morning: five moves, none of them code
- Write a fifteen-line rules file. Where work lives, what never gets overwritten, where finished things go. Apply the per-line test: if deleting the line wouldn’t cause mistakes, delete it.
- Give each project an identity file. Who this is, what lives here, the working rules. A fresh session should do correct work from that file alone.
- Write the next correction you give the AI as a standing rule — with the why attached. That’s your first feedback-becomes-law memory.
- Pick one recurring job and write it down as a procedure. Trigger, steps, guardrails, output. That’s your first skill.
- Promote nothing until it has run manually three times. Automation is a promotion the process earns, not a place it starts.
More context is not better context
Every failure I’ve had with this system came from adding, not from lacking. The docs are blunt about the failure mode: “Bloated CLAUDE.md files cause Claude to ignore your actual instructions!” — the rules that matter drown in the ones that don’t. Context rot means the sixteen-line file genuinely outperforms the six-hundred-line one. So hygiene is itself a loop at my desk: a monthly audit retires memories that have drifted from reality, and a quarterly sweep archives what’s dead. Two more honesties. A reviewer prompted to find gaps will report some even when the work is sound — scope reviews to correctness, or the loop will gold-plate forever. And the heavy harnesses cost real money; at roughly fifteen times chat tokens, a multi-agent run is for questions whose answers are worth it.
“The human in the loop” usually gets said as a safeguard. I mean it as a job description. The machines got fast; what a business still needs from its human is judgment about what’s true, what matters, and what the machine should be looking at. Context engineering is that last thing, written down and kept pruned. The company is the context — and somebody has to be its editor.
— Joe
