VocalFuse is a Fuse Intelligence product.

CONTEXT ENGINEERING

Context Engineering: Control What Your AI Agent Sees

Context engineering is the discipline of deciding what goes into an AI agent's context window — and what stays out. The term Andrej Karpathy crystallized in 2025 has become the core skill of agentic work in 2026, because the same agent gets dramatically better or worse depending on what it reads each turn. Learn the four failure modes, the six fixes, and the copy-paste file layout, then run your agents in VibeFuse — the free widget-based harness with named sessions that keep context lean by design.

See the file layout Get the free harness

What is context engineering?

Context engineering is the craft of filling an agent's context window with exactly the information the next step needs — no more, no less. The definition that stuck is Andrej Karpathy's from mid-2025: "the delicate art and science of filling the context window with just the right information for the next step." Anthropic's version says the same thing from the engineering side: finding the smallest possible set of high-signal tokens that maximize the likelihood of the outcome you want.

The distinction from prompt engineering matters. Prompt engineering is about how you phrase one request. Context engineering is about everything the model sees across a whole session: instruction files, tool definitions and results, retrieved documents, and the accumulated conversation history. A perfect prompt inside a bloated context produces mediocre output; a plain prompt inside a surgically curated context often produces good output. That is why the discipline became one of the six subsystems of harness engineering in 2026 — the context layer is the one practitioners treat as the core problem. It is also the reason AGENTS.md-style files matter: our AGENTS.md template is written context — the highest-value tokens in the window, loaded every session on every tool.

The practical premise: most agent failures are context failures, not capability failures. An agent that guesses your test command, invents conventions nobody uses, or "fixes" a bug by deleting working code is not failing at reasoning — it is working from the wrong context.

The four ways context fails

Drew Breunig's widely-cited taxonomy — grounded in the Gemini 2.5 technical report's own "context poisoning" language and a Databricks long-context study — gives the field a shared vocabulary for why longer contexts make agents worse, not better:

1. Context poisoning

A hallucination or error enters the context and gets referenced repeatedly. DeepMind watched a Gemini 2.5 game-playing agent fixate on impossible goals because misinformation about the game state poisoned its goals section — and it kept repeating behaviors in pursuit of a goal that could not be met.

2. Context distraction

The context grows so large that the model over-focuses on accumulated history and neglects what it learned in training. Databricks measured correctness falling around 32k tokens even for Llama 3.1 405B — models misbehave long before the window is full. Practitioners call the everyday version "context rot."

3. Context confusion

Superfluous content influences the response. In one study, Llama 3.1 8B failed a benchmark when handed 46 tools but passed with 19 — the failure was irrelevant options pulling the model off task, not a context-window limit.

4. Context clash

Parts of the context disagree — an old instruction still in the window contradicts the new one. This is the nastiest variant: the bad content isn't irrelevant, it directly conflicts with the rest of the prompt and degrades reasoning.

Every fix below maps onto one of these four. If you only remember one thing: the model reads the start and end of a long context far more reliably than the middle, so anything important buried mid-window is effectively invisible.

The six fixes (write, select, compress, isolate)

Breunig's follow-up "How to Fix Your Context" and LangChain's agent-focused write-up group the remedies into two compatible lists. The six techniques: tool loadout (expose only relevant tools — overlapping descriptions cause tool-selection confusion), context quarantine (isolate subtasks in their own threads so a specialist never sees the main thread's noise), pruning (delete stale or irrelevant content mid-session), summarization (boil down accrued history into a condensed summary), offloading (store state outside the window via files or a scratchpad tool), and plain RAG (retrieve just the relevant facts on demand).

LangChain's four-bucket version — write, select, compress, isolate — maps cleanly onto the tools you already run. Writing means persisting decisions outside the window: Claude Code writes plans to disk and keeps a todo list; rules files like AGENTS.md are written context. Selecting means just-in-time retrieval: Claude Code never reads a codebase upfront — it globs for paths, greps for references, and reads only the matching file, and keeps references instead of copies. Compressing is summarization and trimming; you have seen it fire when Claude Code condenses a long session while preserving architectural decisions. Isolating is quarantine — subagents with their own windows, and MCP tool descriptions kept short so the model isn't parsing fifty definitions every turn.

Source trail: Drew Breunig, "How Long Contexts Fail" (June 22, 2025) and "How to Fix Your Context" (June 26, 2025); LangChain, "Context Engineering for Agents"; Gemini 2.5 technical report (context poisoning); Databricks long-context study (distraction ceiling); LangChain how_to_fix_your_context repo implementing all six techniques in notebooks.

The 2026 context file layout (copy-paste structure)

The winning layout in 2026 is three layers: one AGENTS.md as the cross-tool base, tool-native scoped rules on top, and a per-feature spec file for anything multi-step. The split question is always the same: what must the agent hold in every session goes in the always-loaded file; what only matters sometimes goes in a path-scoped rule, a skill, or a spec that loads on demand. 

repo/
├── AGENTS.md            # layer 1: cross-tool base (Claude Code, Codex, Cursor, Copilot...)
│                          always loaded — keep under ~150 lines
├── CLAUDE.md            # layer 2: tool-native overrides (Claude Code hooks, permissions)
├── .cursor/rules/       # layer 2: path-scoped rules (a rule with paths: loads only for matches)
├── .claude/skills/      # layer 3: lazy-loaded skills (description first; body only when needed)
└── specs/001-feature/   # layer 3: per-feature spec file for anything multi-step

Base layer: what never changes

Commands, conventions, boundaries, "done" criteria — the decisions every agent needs every session. Write once in AGENTS.md; our AGENTS.md template fills it in for you.

Scoped layer: what is conditional

Per-language style, deploy rules, frontend conventions. Path-scoped rules are the context-budget knob most setups never touch — a rule with a paths: field only loads when the agent touches matching files.

On-demand layer: what is rare

Multi-step feature work goes in a spec file the agent reads when it starts that feature (spec-driven development), not in an always-loaded file every other task pays for.

Context engineering in VibeFuse: the harness does half the work

Most context techniques above are runtime decisions — and that makes them harness decisions. VibeFuse is the first ever free widget-based AI harness, and it implements the isolation and offloading fixes structurally: every agent CLI (Claude Code, Codex, Gemini, Cursor Agent, Qwen) runs as its own widget with its own context on one canvas, so a specialist subagent never inherits the main thread's noise; named sessions persist your layout per repo, so the right tools, terminals, and files load with the session instead of accreting across months of chat history; and skills load lazily from the marketplace instead of every definition riding along.

Going deeper: read harness engineering for the full loop, AGENTS.md template for the always-loaded layer, spec-driven development for the on-demand spec layer, and agentic engineering for the orchestration discipline on top. Compare tools in best vibe coding tools or see VibeFuse as a Claude Code GUI.

  • ✓ One widget per agent — quarantine built in
  • ✓ Named per-repo sessions
  • ✓ MCP + Skill Seekers
  • ✓ 80% creator payouts
Run agents with clean context Browse the marketplace

Explore VibeFuse & harness guides

Context engineering FAQ

What is context engineering?

Context engineering is the discipline of deciding what goes into an AI agent's context window — and what stays out. Andrej Karpathy's definition: "the delicate art and science of filling the context window with just the right information for the next step." Unlike prompt engineering (how you phrase one request), context engineering manages everything the model sees across a session: instruction files, tool definitions, retrieved documents, and conversation history.

What are the four context failure modes?

Drew Breunig's taxonomy: context poisoning (a hallucination enters the context and gets referenced repeatedly — documented in the Gemini 2.5 technical report), context distraction (the context grows so large the model over-focuses on it and neglects training — correctness falls around 32k tokens per a Databricks study), context confusion (superfluous content degrades the response — Llama 3.1 8B failed with 46 tools but passed with 19), and context clash (parts of the context directly contradict each other).

How is context engineering different from prompt engineering?

Prompt engineering crafts how you phrase a single request. Context engineering manages the whole token budget across an entire session — instructions, tool results, retrieval, and history. A perfect prompt in a bloated context produces mediocre output; an ordinary prompt in a curated context often produces good output, because most agent failures are context failures rather than capability failures.

What are the main context engineering techniques?

Six, per Drew Breunig's "How to Fix Your Context": RAG (retrieve just the relevant facts), tool loadout (expose only relevant tools), context quarantine (isolate subtasks in their own threads), context pruning (delete stale content), context summarization (condense accrued history), and context offloading (store state outside the window). LangChain groups the same remedies as write, select, compress, and isolate.

What files make up context engineering for coding agents?

The 2026 winning layout is three layers: one AGENTS.md at the repo root as the cross-tool base (always loaded, under ~150 lines), tool-native scoped rules on top (CLAUDE.md for Claude Code, path-scoped .cursor/rules for Cursor), and on-demand context — per-feature spec files and lazily-loaded skills — for anything multi-step or rarely needed. Always-loaded context is a per-turn tax; put only what every session needs there.

Why does context rot make agents worse over long sessions?

Models retrieve information from the start and end of a long context far more reliably than from the middle, so as history accretes, important instructions buried mid-window stop landing. Cost also scales with tokens even when attention doesn't. The fixes are structural: write state outside the window (files, todos), compress with summarization, prune stale content, and isolate subtasks — which is why agent harnesses with fresh named sessions outperform one endless chat thread.