What is context engineering? The skill replacing prompt engineering

Context engineering is the discipline of curating everything an AI model sees when it acts: system instructions, documents, tool definitions, conversation history, and memory. Where prompt engineering optimizes one instruction, context engineering manages the whole information environment across many steps, deciding what enters the model’s limited attention and what stays out.

It matters because model quality stopped being the bottleneck for agents. What fails in practice is the context, stale documents, bloated histories, and missing state, not the model’s reasoning.

You have already felt the problem, even if you never named it. You tell a coding agent on Monday that the product has one pricing tier. By Wednesday, deep in a long session, it ships a three-tier pricing page. The model did not get worse; the decision scrolled out of its view. Context engineering exists to stop exactly that.

The term went mainstream in 2025 when Andrej Karpathy described filling the context window with exactly the right information as a delicate art and science, and Anthropic’s engineering team framed context as a finite resource with diminishing returns. Both were naming the same shift: as AI systems moved from single answers to long-running agents, the work moved from writing clever prompts to architecting information flow.

This guide covers how context engineering differs from prompt engineering, the four pillars practitioners use, why agents lose the plot, and how a multi-agent pipeline shares one context in production. To see the production version first, look at how a five-stage agent pipeline carries context from idea to deploy.

What is context engineering?

Context engineering is the practice of designing what information a model has available at each step of a task: which instructions, which documents, which tools, which history, and which memory. The goal is the smallest set of high-signal tokens that makes the next action likely to be correct.

The definition has three load-bearing parts:

• It is about selection, not phrasing. A perfectly worded prompt cannot rescue a model that is missing the requirements document, and a plain prompt works fine when the right context is present.
• It operates per step. An agent that researches, then writes, then tests needs different context at each phase, and the engineering is in the transitions.
• It is a budget problem. A context window is finite, and models do not attend to all of it equally; research on long-context behavior consistently shows retrieval quality degrading as windows fill, with relevant facts in the middle of long inputs getting missed. Every token you include spends attention that other tokens no longer get.

A concrete example makes it plain. Ask a model to “write the onboarding flow” cold and you get a generic flow. Give the same model the product’s PRD section on onboarding, the design tokens, the existing route map, and a note on what was already decided, and the same prompt produces the flow for your product.

Nothing about the instruction changed. Everything about the context did. That gap, generic versus grounded, is the entire discipline in miniature.

How is context engineering different from prompt engineering?

Prompt engineering optimizes a single instruction for a single response. Context engineering architects the full information state across a session or system: what gets written to memory, retrieved into the window, compressed out, and isolated per agent. Prompting is one technique inside it, roughly as SQL tuning relates to database design.

The shift tracks the shift in what we build. When AI meant a chat box, the prompt was the product, so prompt craft mattered most. Agents changed the shape of the problem: an AI agent runs for many steps, calls tools, accumulates history, and hands work to other agents.

Across that lifetime, the prompt is a small fraction of what the model sees. The instruction stays constant; the context churns on every step. So the leverage moved to whoever controls the churn.

Prompt engineering did not die. System prompts still reward precision, and a sloppy instruction still produces sloppy output. It got demoted from the whole job to the first line item.

What are the four pillars of context engineering?

The widely used framing, popularized by the LangChain team, groups every technique into four pillars: write context to storage outside the window, select the right context back in, compress what must stay, and isolate context between components. Every production pattern, from scratchpads to sub-agents, is one of these four moves.

1. Write. Persist information outside the context window so it survives the session: scratchpads, decision logs, project wikis, memory files. Agents that write down what they learned and decided can be resumed, audited, and corrected. Agents that keep state only in the window lose it at the first compaction.

2. Select. Pull the right information in at the right moment. This is where retrieval-augmented generation lives, along with simpler moves that often beat it: loading the relevant spec section instead of the whole document, fetching current facts through tools rather than trusting training data, and standard interfaces like the Model Context Protocol for reaching external systems. Selection quality is measured by signal density, not volume.

3. Compress. Fit what matters into the budget. Summarize completed phases, prune dead tool output, and compact conversation history into decisions-plus-open-questions. Good compression is lossy on ceremony and lossless on commitments: what was decided, what was rejected, what remains open.

4. Isolate. Split context across components so each model call sees only what its job needs. Sub-agents are the canonical form: a research agent carries search results, a coding agent carries the spec and the codebase, and neither drowns in the other’s material. Isolation is the pillar that turns context engineering from a session skill into an architecture skill.

The pillars compound. A pipeline that writes decisions to a shared wiki, selects per-task slices of it, compresses finished stages into briefs, and isolates specialists per stage will outperform a single agent with a giant window on every axis that matters: cost, accuracy, and auditability.

Why do AI agents lose the plot?

Agents lose the plot because context degrades over long sessions: windows fill with low-signal tool output, early decisions scroll out or get buried, summaries silently drop commitments, and models attend unevenly across long inputs. The result is an agent that contradicts hour-one decisions in hour three, not because it is dumb, but because the decision is no longer effectively in view.

Watch it happen in a single afternoon. Hour one, you and the agent agree on a constraint. Hour two, forty tool calls append their output to the window.

Hour three, the agent proposes a design that violates the hour-one constraint. When you object, it apologizes and agrees, because the constraint was in the transcript all along. It just was not where the model was looking. This is also why vibe coding sessions drift as they grow: intent that lives only in scrollback decays the same way.

The specific failure modes are worth naming, because each has a different fix:

• Context dilution. Every tool call appends output, most of it ceremony. After dozens of calls, the signal-to-noise ratio collapses and the model starts pattern-matching on noise. Fix: prune and compress tool results aggressively.
• Decision decay. A constraint agreed early (“no external auth provider”) sits thousands of tokens back, behind more recent and more vivid text. The model weights recent tokens; the constraint effectively fades. Fix: write decisions to durable storage and re-select them into every relevant step.
• Compaction loss. Automatic summarization keeps narrative and drops specifics, and the specifics were the point. Fix: structured compaction that explicitly preserves decisions, constraints, and open questions.
• Poisoned context. One hallucinated “fact” enters the window, gets treated as ground truth, and every subsequent step builds on it. Fix: ground claims in sources at the moment they enter context, not after.
• Cross-tool amnesia. The plan lives in one tool, the code in another, the feedback in a third, and no context follows the work between them. This one is architectural: no amount of prompting fixes information that was never connected.

Notice that every fix is a write, select, compress, or isolate move. The failure modes are what the pillars are for.

How do multi-agent systems share context?

Production multi-agent systems share context through a persistent store that outlives any single agent’s window, plus strict rules about what each agent reads and writes. No agent sees everything; every agent sees the current truth for its job. The shared store, not the individual prompts, is what makes ten agents behave like one team.

This is where context engineering stops being advice and becomes architecture, so it is worth describing a real system. ProductOS runs ten specialized agents, Orchestrator, Ideation, Research, PRD, Architect, Design, Design System, Fullstack Builder, QA, and Deploy, across five stages. The context design looks like this:

• One project wiki as shared memory. The Orchestrator maintains a clean project wiki and reads memory across every agent, so a constraint agreed during ideation is still binding when code is written days later. That is the write pillar, institutionalized.
• Artifacts as compressed context. Each stage emits a compact artifact: a concept brief, sourced research findings, a PRD written section by section, DESIGN.md with the locked design tokens. Downstream agents consume the artifact, not the upstream transcript. Compression is built into the pipeline’s shape.
• Isolation by specialty. The Research Agent carries search results and logged sources; the Fullstack Builder carries the PRD, the tokens, and the codebase; the QA Agent carries the preview URL and the critical flows. Each context window stays dense with exactly its own material.
• Grounding at the boundary. Research claims enter shared context with clickable sources attached, and the PRD Agent is required to ground every section in prior-stage artifacts rather than inventing. Poisoned-context prevention, applied where content enters, not after it spreads.

The economics justify the effort. Anthropic’s engineering write-up on its multi-agent research system reported agents consuming several times the tokens of a chat session, with multi-agent systems consuming an order of magnitude more.

At that burn rate, context curation is not hygiene; it is the cost model and the quality model at once. This architecture is also what makes running agents in production tractable: shared, inspectable context is what you debug when a run goes wrong.

What does good context engineering look like in practice?

In practice it looks like unglamorous editorial discipline: maintained project documents, per-task context slices, ruthless pruning, and grounded inputs. The craft is deciding what the model does not see. Teams that treat context as a curated product get consistent agents; teams that treat it as an append-only log get drift.

Habits that transfer to any stack, whether you run one coding agent or a full pipeline:

• Maintain a spec as the anchor document. The highest-value item in any build agent’s context is a current requirements document. This is why context engineering and spec-driven development are converging into one practice: the spec is engineered context.
• Slice context per task. Load the section, not the binder. Relevance beats completeness in long-context conditions, so retrieval should return the three paragraphs that matter, not the whole wiki.
• Keep a decision log and re-inject it. A ten-line list of decisions and non-goals, prepended to every working session, prevents most decision decay for near-zero token cost.
• Prune tool output before it accumulates. Keep conclusions, drop transcripts. A summarized test run is worth more than 400 lines of runner output.
• Ground facts on entry. Anything numeric or factual enters context with a source attached, so later steps inherit evidence rather than assertion.

What goes into one well-built context?

Make it concrete with a single task: an agent implementing “add CSV export to the reports page”. A curated context for that task holds five things:

• The system instructions and coding standards, unchanged from every other task.
• The spec section covering reports and exports, a few hundred tokens, not the 40-page document.
• The decision log: ten lines, including “exports run server-side” and “no new dependencies without approval”.
• The three source files the change touches, fetched by name, not the whole repository.
• The most recent QA verdict on the reports page, so known issues are not reintroduced.

Everything else, old transcripts, other features’ specs, resolved bug threads, stays out. The window ends up mostly signal, and the agent behaves like someone who read the brief instead of someone who wandered the archive. If you do not have that anchor spec yet, generate a structured PRD free and start every agent session from it.

How ProductOS does it

ProductOS treats context engineering as the product’s core architecture rather than a user skill. Ten specialized agents share one project context across Ideate, Discover, Define, Design, and Develop, with the Orchestrator maintaining the project wiki and cross-stage memory so nothing agreed in one stage is forgotten in the next.

Each stage compresses its work into the next stage’s input:

• The Research Agent logs findings with clickable sources.
• The PRD Agent writes the spec section by section behind an outline gate.
• The Design System Agent emits DESIGN.md as the canonical token brief.
• The Fullstack Builder consumes the PRD and tokens inside an isolated cloud sandbox with a live preview.

Model routing is BYOK and multi-provider, with no model hardcoded, so the context architecture stays constant as models change underneath it. Shipped products in the showcase, SOLEN, Orbit, StudioFlow, Lumen Notes, came through this shared-context pipeline end to end. You can see the full architecture on the platform page.

Frequently asked questions

Engineer the context, not just the prompt

The teams whose agents stay coherent from idea to deploy are the ones treating context as architecture. See what that looks like when it is built into the system itself: go deeper on how the platform keeps ten agents on one shared context, or start building free and let the pipeline carry the context for you.