Context Engineering in Practice: a Working System

Context engineering is having its moment as a term, which means it's collecting the usual moss: diagrams of pipelines nobody runs, essays about paradigm shifts, vendors renaming their product category. I want to write the other version. My companies run on AI agents daily — about a dozen production repos, plus a scheduled layer that works while I sleep — and the thing that makes any of it trustworthy is not the model. It's the context system around the model. This post is that system, layer by layer, with the failure modes I paid for.

What is context engineering?

Context engineering is the practice of deliberately designing everything an AI model sees before it starts working: which instructions load always, which knowledge loads on demand, and which facts are treated as ground truth. Where prompt engineering tunes a single request, context engineering builds the standing environment around every request — repo instructions, skills, memory, and retrieval — so the model behaves consistently without being re-briefed in each session.

The mental model that finally made it click for me: onboarding, not prompting. When a senior engineer joins your team, you don't achieve good output by phrasing each task perfectly. You achieve it by what surrounds them — the docs they can trust, the conventions of the repo, the person who says "careful, that pipeline is live." Context engineering is building that surrounding for a model. Do it well and mediocre prompts still land, because the environment catches them. Do it badly and no amount of prompt wizardry saves you, because the model is brilliant, briefed on nothing, and confidently wrong.

Prompt engineering vs context engineering

The distinction is level, not technique.

Prompt engineering is request-level. It asks: how do I phrase this instruction so the model does what I mean? Useful — the way sentence-level editing is useful — and it's where everyone starts, because it's the only lever a chat window gives you.

Context engineering is environment-level. It asks: what does the model know before any request arrives? What's loaded always, what's loaded when relevant, what's authoritative when sources disagree, what accumulates between sessions?

The tell that you've hit the ceiling of prompt engineering is repetition. If your prompts keep re-explaining the same facts — what your product costs, how deploys work, what tone you write in — you're hand-delivering context that should be infrastructure. Every one of those explanations is a chance to explain it slightly wrong, and the model has no way to notice.

The prompt still matters. It's just the last mile, and last miles only work when the road behind them exists.

The five layers of a working context system

Here's the architecture that runs my portfolio. Five layers, from always-on to injected-at-runtime. None of it is exotic — the whole system is markdown files and one design principle — but each layer exists because its absence broke something.

Layer 1: Always-on instructions

Every repo carries one instructions file the agent reads at the start of every session — AGENTS.md (or CLAUDE.md) at the root. Mine contain: what this repo is, the commands that matter, the conventions, and the danger zones — the "never touch this env file, never reference that private subdomain" lines that protect you at 11pm.

The discipline here is brevity. This file is a tax on every single session, so every line must earn permanent residency. The instinct is to stuff everything you know into it; the result is a model that skims. Keep it to what a competent newcomer needs in their first five minutes, and push everything deeper down the stack.

Layer 2: On-demand knowledge (skills)

Deep knowledge — a product's full pricing structure, a deploy runbook, a brand voice guide — loads only when the task calls for it, packaged as skills that match on a description. A session fixing a CSS bug never pays for the email-marketing playbook; a session drafting a launch email gets it automatically. I've written a complete guide to skills, so I won't re-explain them here — for this post, the point is architectural: skills are the layer that lets always-on stay thin without losing depth.

Layer 3: Ground-truth facts, per repo

This is the layer most setups are missing, and it's the one that ends arguments. Each of my repos carries a small facts file — stack, integrations, SEO state, do-not-touch list — that is explicitly the authority for that repo. Shared skills carry method ("how to write a content brief"); the repo's facts file carries truth ("this site's keyword targets and their measured volumes"). When the skill arrives, it reads the local facts first, and facts there override anything remembered.

Why so rigid? Because the worst AI failure in a business context isn't a wrong answer — it's a confident wrong answer with a plausible source. The only defense is deciding, in writing, which document wins.

Layer 4: Accumulated memory

Sessions end; lessons shouldn't. My system keeps files that only grow: a lessons file (mistakes with enough context that an agent can avoid repeating them), decision records (why we chose X, so future sessions don't relitigate it), and periodic syntheses that compress weeks of activity into something a fresh session can absorb. When an agent does something subtly wrong on a Tuesday, the fix isn't just correcting it — it's writing the lesson down where every future Tuesday will find it. This is the layer that makes the whole system compound instead of reset.

Layer 5: Injected runtime context

Some context can't live in a file because it isn't stable — it has to be injected at the moment of execution. The canonical example from my scheduled jobs: the current date. An unattended agent that infers "today" from filenames or memory will eventually date something wrong, so the job runner injects an authoritative date line into every headless prompt. Same pattern for anything session-specific: which mode the job runs in, what it's allowed to touch tonight. Files for the stable, injection for the volatile.

The principle underneath: derive, don't duplicate

One rule governs all five layers: every fact lives in exactly one place, and everything else points at it. Tasks live in the task system, not mirrored into markdown. Product facts live in the product skill, not pasted into each repo. The moment two copies of a fact exist, they are already diverging — you just haven't noticed yet.

Why it matters: what fails without it

I can name each failure from experience, which is exactly why the layer above it exists.

Confident fabrication. Without a ground-truth layer, models fill gaps with plausibility. Two of my own documents once disagreed on a product's pricing by $400 a year — each looked authoritative. An agent caught it because the skill named which source wins; without that line, it would have picked one at random and sounded certain.

Silent drift. Without a single source of truth, duplicated knowledge rots. I ran product skills mirrored in two locations for months; a correction landed in one and not the other, and an agent later quoted the stale copy. The fix was context engineering at its least glamorous: one sentence declaring which copy is canonical, and a scheduled job that diffs the mirrors.

Context bloat. Without the always-on/on-demand split, everything gets shoved into the always-loaded file until the model skims it. Attention is a budget; an instructions file that tries to say everything effectively says nothing.

The daily reset. Without a memory layer, every session starts from zero and you become the memory — re-explaining, re-correcting, re-deciding. This is the treadmill most people are on when they conclude AI tools "don't really save time." The tools are fine; the context architecture is missing.

How to start (a working order)

You don't need the five layers on day one — I didn't have them either. Build in this order, letting each layer earn the next:

Write the thinnest possible always-on file. One page: what the repo is, the three commands that matter, the danger zones. Resist completeness; you're writing a five-minute orientation, not a handbook.
Create one facts file and declare it authoritative. Pick the domain where a wrong fact costs most — pricing, deploy targets — and write the sentence that ends arguments: "if this file and anything else disagree, this file wins."
Extract your first skill. Notice the thing you keep re-explaining across sessions. That's your first skill: package it once with a description specific enough to fire at the right moments.
Start a lessons file. The next time an agent does something subtly wrong, don't just fix it — record it, with enough context to prevent the rerun. This file feels pointless for two weeks and then becomes the most valuable one you have.
Only then, think about scale. Shared libraries across repos, drift-checking jobs, runtime injection — the portfolio problems. When I standardized this architecture across eleven repos in one day, the hard part wasn't the tooling; it was deciding, per fact, where it lived.

Notice what's absent: no vector database, no embedding pipeline, no framework. Retrieval infrastructure earns its complexity at corpus scale — thousands of documents, not dozens. For a working portfolio's worth of knowledge, files, structure, and one authority rule beat a pipeline you can't inspect.

How you know it's working

The system has no dashboard, but it has tells. The first is that your prompts get shorter — "fix the stale dates on the feed" instead of three paragraphs of background — because the background is already there. The second is that agents start declining things: refusing to touch a file the danger-zone list protects, flagging that two sources disagree instead of picking one. An agent that pushes back on the basis of your own written rules is the clearest signal the context is actually load-bearing. The third tell is the one I watch for in reviews: corrections stop repeating. If you're fixing the same class of mistake every week, that's not a model problem — it's a lesson that never got written down.

Context engineering for autonomous agents

The layers above assume a human in the loop who can catch a misread. The real exam is the agent running at 2am with nobody watching — because unattended agents can't ask clarifying questions. Whatever context they start with is all the context they get.

Three rules I hold my scheduled jobs to. Inject the volatile: anything time- or run-dependent (the date, the job's mode) is stamped into the prompt by the runner, never inferred. Write permissions down: each job's prompt states what it may write and where —my autonomous agents write to an inbox folder and their own space, and nothing else — a rule that exists in a file, not in my hopes. Ground rules over cleverness: the standing rule "never assert a business detail from memory; ground it in a file or an API" does more for unattended reliability than any model upgrade I've adopted.

How I build and orchestrate the agents themselves is a separate post coming later this month — here, the point is narrower: autonomy doesn't reduce the need for context engineering. It removes the safety net that was hiding the gaps.

FAQ

What is context engineering? The practice of deliberately designing what an AI model sees before it works: always-on instructions, on-demand knowledge, authoritative facts, accumulated memory, and injected runtime context. It treats the model's environment — not the individual prompt — as the thing you engineer.

What is the difference between prompt engineering and context engineering? Prompt engineering optimizes a single request's phrasing. Context engineering builds the standing environment around every request. If you keep re-explaining the same facts in prompts, you've hit prompt engineering's ceiling and the fix is architectural.

Why is context engineering important? Because models fill gaps with confident plausibility. Without engineered context you get fabricated facts, drifting duplicates, bloated instructions the model skims, and sessions that restart from zero. With it, the same model behaves like a briefed colleague instead of a talented stranger.

How do you do context engineering? Start small and in order: a one-page always-on instructions file, one authoritative facts file, one packaged skill for the knowledge you keep re-explaining, and a lessons file that accumulates corrections. Scale to shared libraries and runtime injection only when multiple repos or unattended agents demand it.

More field notes like this: subscribe to the RSS feed, or start with what I'm building.