Context Engineering

• Context as a budget

  Treat context as a limited budget rather than “more is always better.”

• Context rot & lost-in-the-middle

  Understand context rot, distraction, conflicting context, lost-in-the-middle, and token/cost growth.

• Inspecting what actually enters

  Inspect what actually enters the model’s window and identify which parts are useful versus noise.

• Allocating the budget

  Allocate rough budgets across instructions, conversation history, retrieval, memory, tools, and working state.

Outcome · Diagnose when model degradation is really a context-management problem.

• Assembling the window deliberately

  Assemble instructions + conversation history + retrieved knowledge + memory + tool definitions/results + application state deliberately.

• Always present, retrieved, or excluded

  Decide what should be always present, dynamically retrieved, summarized, or excluded.

• Prioritising what matters

  Prioritize information based on relevance, importance, recency, and reliability.

• Ordering so sources stay distinguishable

  Order and structure context so instructions, evidence, memory, and user data remain clearly distinguishable.

• Cutting redundant & stale context

  Avoid redundant, stale, contradictory, or irrelevant context.

Outcome · Construct the smallest useful context for the current model decision.

• Summarizing history without losing goals

  Summarize growing conversation history while preserving goals, constraints, decisions, and unresolved work.

• Compacting large tool outputs

  Compact large tool outputs before feeding them back into the model.

• Rolling & hierarchical summaries

  Apply rolling summaries and hierarchical summarization for long-running tasks.

• Preserving exact structured data

  Preserve exact structured information separately when summarization could lose important details.

• Reduction vs information loss

  Understand the trade-off between context reduction and information loss.

Outcome · Reduce context size without losing task-critical information.

• Scratchpads, files & external stores

  Move information outside the active window using scratchpads, files, databases, memory stores, task state, and working notes.

• Active context vs stored context

  Distinguish active context from information that can be stored externally and retrieved later.

• Persisting plans & progress

  Persist plans, completed steps, decisions, intermediate results, and important facts across long-running tasks.

• Note-taking agents

  Build note-taking agents that write useful information externally and recall it when required.

• Remembering vs freeing space

  Understand the distinction between memory for remembering and offloading for freeing context space.

Outcome · Build systems that do not require the entire task history to remain inside the model’s context.

• Why big windows do not solve it

  Understand why large context windows do not eliminate context-engineering problems.

• Managing lost-in-the-middle

  Manage lost-in-the-middle using better positioning, selective retrieval, and context restructuring.

• Stuffing vs retrieval vs summarization

  Compare full-context stuffing, retrieval-over-history, summarization, hierarchical context, and selective loading.

• More context or better context

  Decide when to give the model more context versus retrieve only the relevant parts.

Outcome · Choose an appropriate strategy for very long documents, conversations, and agent runs.

• Tool definitions compete for space

  Understand that tool definitions and tool results also compete for context-window space.

• Exposing only relevant tools

  Dynamically expose only the tools relevant to the current task where possible.

• Filtering large tool outputs

  Summarize or filter large API/search/database outputs before returning them to the model.

• Keeping full results externally

  Keep full tool results externally and retrieve details again when required.

• Stopping observation build-up

  Prevent long agent loops from accumulating unnecessary observations and tool output.

Outcome · Keep tool-heavy agents coherent without letting their action history overwhelm the context.

• The cost of resending static context

  Understand how repeatedly sending large static contexts affects cost and latency.

• Structuring for cache hits

  Structure stable instructions and reusable context to benefit from prompt/context caching where supported.

• Stable context vs changing state

  Separate stable context from rapidly changing task state.

• Cutting redundant tokens

  Reduce redundant tokens while preserving useful information.

• Measuring cache utilization

  Measure token usage, cache utilization, latency, and cost rather than optimizing blindly.

Outcome · Make large-context applications more efficient without sacrificing quality.

The agent harness

• What an agent harness is

  Understand the harness as everything around the model that turns it into a working agent: the loop, system prompt, tool set, context management, state, permissions, and the environment it acts in.

• Harness problems vs model problems

  Recognize that the same model can succeed or fail on the same task depending on its harness, and that many agent failures are harness problems rather than model problems.

• Designing the agent loop

  Design the agent loop: how model calls and tool calls alternate, how results and errors are fed back, and when to stop using step, time, and token limits.

• What the harness enforces

  Decide what the harness enforces versus what the model decides: fixed workflow steps, permission checks, human approval for risky actions, and safe defaults.

Harnesses for long-running work

• Work across many context windows

  Structure work that spans many context windows: an initial run that sets up the environment, plan, and task list, and later runs that read progress notes, complete one task at a time, and record what changed.

• Durable artifacts as the source of truth

  Use durable artifacts as the source of truth between runs, such as progress files, task lists, git commits, and tests, rather than conversation history.

• Self-run feedback loops

  Give the agent feedback loops it can run itself, such as tests, linters, type checks, and end-to-end checks, so it verifies work before marking it done.

• An environment agents can read

  Make the environment legible to the agent: short instruction files (such as AGENTS.md), a clear project structure, and documentation written to be read by agents.

• Sub-agents for isolated context

  Use sub-agents to give focused subtasks a fresh, isolated context and return only condensed results.

Outcome · Design a harness that keeps an agent productive and on track across long tasks that no single context window can hold.