Markdown

What is Context Engineering and why is it pivotal for production-grade apps

RenderedSource

What is Context Engineering and why is it pivotal for production-grade apps

import MindMap from ’../../components/MindMap.astro’;

Why context engineering matters

Every enterprise team building agentic AI eventually faces the same challenge: giving an LLM the right information at the right time. Evaluations, quality metrics, and user expectations for agentic systems have increased, turning this into a production-ready business application rather than a one-off demo. System prompts, tool selection, tool trajectories, memory, observability, and other runtime decisions all depend on the context the application assembles for each step.

Context engineering is the discipline of curating what fills an LLM agent’s context window at each step of its task, rather than what prompt you write once at the start. As agents move from single-turn chat to multi-step and multi-agent systems, this becomes a primary engineering challenge in most production systems — and it’s pivotal for any production-grade app, since the context an agent sees at each step is what separates a reliable system from a demo.

Context engineering, in simple terms, is about providing the right context based on the request. When we are prompting LLMs in agentic applications or agentic systems, their behavior, the quality of the response, the actions they take, and the suggestions they give are all dependent on the context. If you don’t provide the right context, the LLM can hallucinate or produce the kind of response you don’t want.

If you are mapping this into a real delivery roadmap, the same patterns show up in Java and Python AI engineer learning paths, agentic AI framework coverage, and the broader 2026 technology trend landscape.

Why is context engineering a differentiator compared to “prompt engineering” in the solution architecture

Prompt engineering has matured through techniques such as zero-shot prompting, few-shot prompting, chain-of-thought reasoning, meta-prompting, and more. While it helps to solve part of the system design, it does not address the contextual data problem at the heart of the agentic system.

Context engineering solves the core challenge of providing enough relevant data to avoid hallucinations and related quality issues. Across a trajectory that may run to hundreds of tool calls, teams need to decide what information belongs in the context window, what should be summarized, what should be compressed, what should be pulled from MCP tools, and what should never have been added at all.

Andrej Karpathy’s framing is the one practitioners keep reaching for: the LLM is the CPU, the context window is RAM, and context engineering is the operating system’s job of deciding what fits. It’s a useful model because it makes the constraint concrete as RAM is finite, and what you page in and out determines whether the program runs correctly.

Remember a simple formula to elevate the solution architecture:

Holistic State of an Agent = System Instructions/Prompt + Tools + Memory Data + State + Knowledge / Context + User Query

System Instructions or System Prompt: The core rules, behavioral guidelines, and formatting requirements.
Tools: The definitions, signatures, and schemas that tell the model what functions it can call, covering MCP or non-MCP Tools.
Memory Data: Persistent information from previous sessions or long-term external storage with short-term and long-term memory data.
State: The dynamic status of the environment, the user’s progress, or internal variables in a multi-agent system.
Knowledge or Context: External facts retrieved dynamically via RAG or structured knowledge graphs.
User Query: The specific, immediate request currently being processed.

Five ways context degrades and what are typical symptoms

The Five Context Failure Modes

Failure Mode	What Happens	Typical Symptom
Context Rot	Performance declines as tokens accumulate, even within the stated limit, due to the model’s finite “attention budget”.	Recall Degradation: Reduced precision for information retrieval and long-range reasoning.
Context Poisoning	A hallucination or error enters the context and is subsequently treated as ground truth for all future steps.	Cascading Failures: Compounding mistakes where the agent trusts its “poisoned” context over external corrections.
Context Distraction	Accumulated history overshadows the model’s underlying training and logical reasoning.	Pattern Repetition: Agent favors repeating past actions from its history rather than synthesizing a new plan (observed at >100K tokens).
Context Confusion	Too much irrelevant or superfluous material — frequently bloated tool definitions — impairs the model’s ability to select correct actions.	Benchmark Failure: A system (e.g., Llama 3.1 8B) passes with 19 tools but fails with 46 due to overlapping descriptions.
Context Clash	Contradictory information exists in different parts of the context, often due to parallel processing.	Inconsistent Assumptions: Parallel subagents make incompatible decisions (e.g., different UI styles) that an orchestrator cannot reconcile.

Five context management strategies and why they help to solve common context challenges

Based on experience in handling context challenges in the applications built and the industry experts from the leading companies - Manus, Anthropic, LangGraph, Devin - these five strategies map cleanly to address common context challenges to build production-grade agentic applications:

AI Agent Context Engineering Strategies

Strategy	Core Idea	Best For	Key Risk	Observed In
Offload (Write)	Save information to external storage (file systems, databases, or state objects) and retrieve it via lightweight references.	Long-horizon tasks, persistent cross-session memory, and handling bulky payloads like PDFs or large datasets.	Findability & Overhead: Requires the agent to learn when to write and adds retrieval latency; information must be well-organized to be retrievable.	Manus file system (ultimate context); Claude Code’s `CLAUDE.md` and memory tool; Anthropic’s “Think” tool (scratchpad).
Reduce (Compress)	Summarization: Distill history into key decisions. Clearing: Surgically remove bulky, re-fetchable tool results while keeping the call record.	Managing in-session token growth when conversations get long or tool outputs bloat the window.	Irreversible Information Loss: Summaries are lossy; obscure but critical specifics (e.g., table cells) may be discarded.	Claude Code auto-compact; Anthropic’s `clear_tool_uses` primitive; Cognition’s fine-tuned summarizer.
Retrieve (Select)	Pull only the most relevant data or tools into the window “just-in-time” rather than pre-loading everything.	Large knowledge bases, dynamic codebases, and systems with massive (>30) tool sets.	Retrieval Quality: Semantic search can be unreliable as corpuses grow; latency increases as the agent “hunts” for data.	Tool RAG (selecting tools based on query); Windsurf’s hybrid AST/grep/embedding retrieval; Claude Code’s just-in-time grep/glob.
Isolate (Quarantine)	Split tasks and context across parallel subagents or isolated sandboxes to keep individual windows clean.	Breadth-first research, parallelizable exploration, and isolating “dirty” tool outputs (e.g., audio/images).	Context Clash: Subagents working in parallel may make incompatible decisions or operate on conflicting assumptions.	Anthropic’s Multi-agent Researcher; HuggingFace CodeAgent (sandbox isolation); LangGraph DeepAgent.
Cache (Stable Prefix)	Maintain a stable prefix (system prompts, tool definitions) to leverage server-side caching for cost and latency gains.	Repeated instructions, multi-turn agents, and cost-sensitive production systems.	Prefix Instability: Minor changes (like timestamps in prompts) or non-deterministic serialization (JSON key order) invalidate the cache.	Manus KV-cache discipline (mask-don’t-remove tools); Anthropic and Google Gemini prompt/context caching.

There is no silver bullet to solve a context engineering challenge, and to be honest, enterprise context itself is needed to recommend any suitable context engineering design approach. For example, what works for a financial application, where PII and a client’s accurate financial data play a pivotal role, might not work for an agentic commerce application.

Choosing a strategy: thresholds, not a single recipe

While strategy selection depends on organizational context, the problem domain, agentic system, and the designated task, these two core lenses help to make the right architectural/design decision (don’t forget ADR and document that in your enterprise decisions catalog):

Lens 1: Context Size (The Technical Benchmark)

Context size maps directly to the architectural limitations of transformers, specifically the finite attention budget. The thresholds you identified are corroborated as established starting points for mitigating specific failure modes:

Under 10K (Simple Caching): Sufficient because the “Lost-in-the-Middle” phenomenon and recall degradation are minimal at this scale.
10K–50K (Compression): Necessary to combat Context Rot by distilling history into high-signal summaries before the n2 attention relationship becomes too thin.
50K–100K (Offloading): Essential to prevent Context Distraction, where models begin favoring the accumulated history over original reasoning.
Beyond 100K (Agent Isolation): Recommended because single-agent windows at this scale suffer from Context Poisoning and extreme latency; isolation keeps working memory lean and reliable.

Lens 2: Deployment Shape (The Economic Benchmark)

Deployment shape addresses the “100:1 Rule”, which states that for every 1 token an agent generates, it typically processes 100 tokens of input, making context the dominant cost factor in production.

Low-Reuse (Retrieval Wins): Correct for few-query scenarios because it avoids the “preprocessing” latency and token cost of generating summaries.
High-Reuse (Compression Wins): Correct for multi-turn agents where the same context is reused many times. The initial cost of summarization is amortized, potentially cutting token costs by more than half.
The 25% Rule: Choosing between these based on the “Efficiency Frontier” typically results in a 25% token reduction at equivalent performance, which is a major victory for production scaling.

A phased approach for continuous and evolving maturity for context management

Define the enterprise-specific journey aligned towards an incremental approach to evolve context management engineering practices highlighted below:

Measure first: Log token usage, cache hit rate, and failure patterns per interaction before optimizing anything. Note that context problems are not evident until you have the observability (tracing, logs with token usage data available).
Take the Quick Wins: Sharpen tool descriptions so similar tools are distinguishable, retain failed attempts in context instead of hiding them, and add baseline production guardrails. These typically are quick wins and yield larger benefits without much of an overall refactoring.
Build the infrastructure: Add dynamic tool retrieval once you’re past roughly 15–20 tools (it varies as per agentic system), make compression reversible (store the URL/file path, not the entire page or content), and trigger auto-summarization before the window is full rather than after.
Reach for multi-agent isolation, and choose judiciously: Multi-agent systems are a real capability lift for parallelizable, breadth-first work, but as no architecture change comes without a trade-off, the trade-off is complexity and cost multiplier. Use it judiciously when the complexity justifies the cost and manageability trade-off.

The implication for architecture reviews (ADRs)

To conclude, Context engineering is not a prompt-writing skill you delegate to whoever is closest to the model call. It’s an architectural decision with the same weight as choosing a vector data store or an AI model: what state lives where, what gets recomputed versus retrieved, and what the failure mode looks like when the budget is exceeded. Continuous measurement and experimentation yield the best results with documented architecture and design choices based on your agentic system’s requirements.

Key Questions

Q1) What is context engineering?

Context engineering means actively managing an agent’s working memory throughout a workflow. It is the practice of deciding what information occupies an LLM agent’s context window at each step of a task through techniques such as offloading, compression, retrieval, isolation, and caching.

Q2) How is context engineering different from prompt engineering?

Prompt engineering optimizes the wording of a single instruction for a single response. Context engineering manages an evolving window across a multi-step, tool-using trajectory, deciding what to keep, summarize, retrieve, or discard at every step.

Q3) Why can’t you just use a larger context window instead?

Transformer attention scales abruptly with token count, so a larger window doesn’t remove the problem and also increases complexity. Longer, unmanaged context also causes context rot, where model performance degrades as irrelevant or stale tokens accumulate, independent of the window’s stated limit.

Q4) What’s the difference between context and memory in an agent system?

Context is expensive, limited, immediate, and volatile working memory. Long-term memory such as a file system, database, or vector store is comparatively cheap and persistent but requires an explicit retrieval step to bring information back into context. Conflating the two is a common root cause of context rot and confusion.

Context engineering: how prompt engineering, the context window, and an LLM agent relate, with the five failure modes and the offload/reduce/retrieve/isolate/cache strategies that manage them

Mindmap for Exploration

- Five Failure Modes - Context Rot (performance decay as tokens accumulate) - Context Poisoning (a bad inference compounds) - Context Distraction (history overshadows reasoning) - Context Confusion (too many irrelevant tools/facts) - Context Clash (contradictory context across agents) - Context Is Not Memory - Context: expensive, immediate, volatile - Memory: cheap, persistent, needs retrieval - The 100:1 Rule - Five Strategies - Offload (Write) - Manus file system - Claude Code CLAUDE.md - Reduce (Compress) - Auto-compaction - Cognition's fine-tuned summarizer - Retrieve - RAG - Just-in-time grep/glob - Isolate - Multi-agent subagents - ~15x token cost - Cache - Stable prompt prefix - KV-cache hit rate - Choosing a Strategy - By context size (10K / 50K / 100K thresholds) - By deployment shape (Efficiency Frontier) - Adoption Path - Measure first - Take the low-effort wins - Build the infrastructure - Multi-agent isolation last

References

# What is Context Engineering and why is it pivotal for production-grade apps

import MindMap from '../../components/MindMap.astro';

## Why context engineering matters

Every enterprise team building agentic AI eventually faces the same challenge: giving an LLM the right information at the right time. Evaluations, quality metrics, and user expectations for agentic systems have increased, turning this into a production-ready business application rather than a one-off demo. System prompts, tool selection, tool trajectories, memory, observability, and other runtime decisions all depend on the context the application assembles for each step.

**Context engineering** is the discipline of curating what fills an LLM agent's context window at each step of its task, rather than what prompt you write once at the start. As agents move from single-turn chat to multi-step and multi-agent systems, this becomes a primary engineering challenge in most production systems — and it's pivotal for any production-grade app, since the context an agent sees at each step is what separates a reliable system from a demo.

> _Context engineering, in simple terms, is about providing the right context based on the request. When we are prompting LLMs in agentic applications or agentic systems, their behavior, the quality of the response, the actions they take, and the suggestions they give are all dependent on the context. If you don't provide the right context, the LLM can hallucinate or produce the kind of response you don't want._

If you are mapping this into a real delivery roadmap, the same patterns show up in [Java and Python AI engineer learning paths](https://vedcraft.com/learning-paths/java-python-developer-to-ai-engineer-learning-path/), [agentic AI framework coverage](https://vedcraft.com/tech-trends/building-intelligent-apps-with-agentic-ai-top-frameworks-to-watch-for-in-2025/), and [the broader 2026 technology trend landscape](https://vedcraft.com/tech-trends/top-ten-technology-trends-for-2026/).

## Why is context engineering a differentiator compared to "prompt engineering" in the solution architecture

Prompt engineering has matured through techniques such as zero-shot prompting, few-shot prompting, chain-of-thought reasoning, meta-prompting, and more. While it helps to solve part of the system design, it does not address the contextual data problem at the heart of the agentic system.

Context engineering solves the core challenge of providing enough relevant data to avoid hallucinations and related quality issues. Across a trajectory that may run to hundreds of tool calls, teams need to decide what information belongs in the context window, what should be summarized, what should be compressed, what should be pulled from MCP tools, and what should never have been added at all.

> Andrej Karpathy's framing is the one practitioners keep reaching for: the LLM is the CPU, the context window is RAM, and context engineering is the operating system's job of deciding what fits. 
It's a useful model because it makes the constraint concrete as RAM is finite, and what you page in and out determines whether the program runs correctly.

Remember a simple formula to elevate the solution architecture:

**Holistic State of an Agent  = System Instructions/Prompt + Tools + Memory Data + State + Knowledge / Context + User Query**

- **System Instructions or System Prompt**: The core rules, behavioral guidelines, and formatting requirements.
- **Tools**: The definitions, signatures, and schemas that tell the model what functions it can call, covering MCP or non-MCP Tools.
- **Memory Data**: Persistent information from previous sessions or long-term external storage with short-term and long-term memory data.
- **State**: The dynamic status of the environment, the user's progress, or internal variables in a multi-agent system.
- **Knowledge or Context**: External facts retrieved dynamically via RAG or structured knowledge graphs.
- **User Query**: The specific, immediate request currently being processed.

## Five ways context degrades and what are typical symptoms

### **The Five Context Failure Modes**

| Failure Mode | What Happens | Typical Symptom |
| :--- | :--- | :--- |
| **Context Rot** | Performance declines as tokens accumulate, even within the stated limit, due to the model's finite "attention budget". | **Recall Degradation**: Reduced precision for information retrieval and long-range reasoning. |
| **Context Poisoning** | A hallucination or error enters the context and is subsequently treated as ground truth for all future steps. | **Cascading Failures**: Compounding mistakes where the agent trusts its "poisoned" context over external corrections. |
| **Context Distraction** | Accumulated history overshadows the model’s underlying training and logical reasoning. | **Pattern Repetition**: Agent favors repeating past actions from its history rather than synthesizing a new plan (observed at >100K tokens). |
| **Context Confusion** | Too much irrelevant or superfluous material — frequently bloated tool definitions — impairs the model's ability to select correct actions. | **Benchmark Failure**: A system (e.g., Llama 3.1 8B) passes with 19 tools but fails with 46 due to overlapping descriptions. |
| **Context Clash** | Contradictory information exists in different parts of the context, often due to parallel processing. | **Inconsistent Assumptions**: Parallel subagents make incompatible decisions (e.g., different UI styles) that an orchestrator cannot reconcile. |

## Five context management strategies and why they help to solve common context challenges

Based on experience in handling context challenges in the applications built and the industry experts from the leading companies - Manus, Anthropic, LangGraph, Devin - these five strategies map cleanly to address common context challenges to build production-grade agentic applications:

### **AI Agent Context Engineering Strategies**

| Strategy | Core Idea | Best For | Key Risk | Observed In |
| :--- | :--- | :--- | :--- | :--- |
| **Offload** (Write) | Save information to external storage (file systems, databases, or state objects) and retrieve it via lightweight references. | Long-horizon tasks, persistent cross-session memory, and handling bulky payloads like PDFs or large datasets. | **Findability & Overhead**: Requires the agent to learn *when* to write and adds retrieval latency; information must be well-organized to be retrievable. | **Manus** file system (ultimate context); **Claude Code’s** `CLAUDE.md` and memory tool; **Anthropic’s** "Think" tool (scratchpad). |
| **Reduce** (Compress) | **Summarization**: Distill history into key decisions. **Clearing**: Surgically remove bulky, re-fetchable tool results while keeping the call record. | Managing in-session token growth when conversations get long or tool outputs bloat the window. | **Irreversible Information Loss**: Summaries are lossy; obscure but critical specifics (e.g., table cells) may be discarded. | **Claude Code** auto-compact; **Anthropic's** `clear_tool_uses` primitive; **Cognition's** fine-tuned summarizer. |
| **Retrieve** (Select) | Pull only the most relevant data or tools into the window "just-in-time" rather than pre-loading everything. | Large knowledge bases, dynamic codebases, and systems with massive (>30) tool sets. | **Retrieval Quality**: Semantic search can be unreliable as corpuses grow; latency increases as the agent "hunts" for data. | **Tool RAG** (selecting tools based on query); **Windsurf's** hybrid AST/grep/embedding retrieval; **Claude Code's** just-in-time grep/glob. |
| **Isolate** (Quarantine) | Split tasks and context across parallel subagents or isolated sandboxes to keep individual windows clean. | Breadth-first research, parallelizable exploration, and isolating "dirty" tool outputs (e.g., audio/images). | **Context Clash**: Subagents working in parallel may make incompatible decisions or operate on conflicting assumptions. | **Anthropic’s** Multi-agent Researcher; **HuggingFace** CodeAgent (sandbox isolation); **LangGraph** DeepAgent. |
| **Cache** (Stable Prefix) | Maintain a stable prefix (system prompts, tool definitions) to leverage server-side caching for cost and latency gains. | Repeated instructions, multi-turn agents, and cost-sensitive production systems. | **Prefix Instability**: Minor changes (like timestamps in prompts) or non-deterministic serialization (JSON key order) invalidate the cache. | **Manus** KV-cache discipline (mask-don't-remove tools); **Anthropic** and **Google Gemini** prompt/context caching. |


> There is no silver bullet to solve a context engineering challenge, and to be honest, enterprise context itself is needed to recommend any suitable context engineering design approach. For example, what works for a financial application, where PII and a client's accurate financial data play a pivotal role, might not work for an agentic commerce application.

## Choosing a strategy: thresholds, not a single recipe

While strategy selection depends on organizational context, the problem domain, agentic system, and the designated task, these two core lenses help to make the right architectural/design decision (don't forget ADR and document that in your enterprise decisions catalog): 

**Lens 1: Context Size (The Technical Benchmark)**

Context size maps directly to the architectural limitations of transformers, specifically the finite attention budget. The thresholds you identified are corroborated as established starting points for mitigating specific failure modes:
- Under 10K (Simple Caching): Sufficient because the "Lost-in-the-Middle" phenomenon and recall degradation are minimal at this scale.
- 10K–50K (Compression): Necessary to combat Context Rot by distilling history into high-signal summaries before the n2 attention relationship becomes too thin.
- 50K–100K (Offloading): Essential to prevent Context Distraction, where models begin favoring the accumulated history over original reasoning.
- Beyond 100K (Agent Isolation): Recommended because single-agent windows at this scale suffer from Context Poisoning and extreme latency; isolation keeps working memory lean and reliable.

**Lens 2: Deployment Shape (The Economic Benchmark)**

Deployment shape addresses the "100:1 Rule", which states that for every 1 token an agent generates, it typically processes 100 tokens of input, making context the dominant cost factor in production.
- Low-Reuse (Retrieval Wins): Correct for few-query scenarios because it avoids the "preprocessing" latency and token cost of generating summaries.
- High-Reuse (Compression Wins): Correct for multi-turn agents where the same context is reused many times. The initial cost of summarization is amortized, potentially cutting token costs by more than half.
- The 25% Rule: Choosing between these based on the "Efficiency Frontier" typically results in a 25% token reduction at equivalent performance, which is a major victory for production scaling.

## A phased approach for continuous and evolving maturity for context management

Define the enterprise-specific journey aligned towards an incremental approach to evolve context management engineering practices highlighted below:

1. Measure first: Log token usage, cache hit rate, and failure patterns per interaction before optimizing anything. Note that context problems are not evident until you have the observability (tracing, logs with token usage data available).
2. Take the Quick Wins: Sharpen tool descriptions so similar tools are distinguishable, retain failed attempts in context instead of hiding them, and add baseline production guardrails. These typically are quick wins and yield larger benefits without much of an overall refactoring.
3. Build the infrastructure: Add dynamic tool retrieval once you're past roughly 15–20 tools (it varies as per agentic system), make compression reversible (store the URL/file path, not the entire page or content), and trigger auto-summarization before the window is full rather than after.
4. Reach for multi-agent isolation, and choose judiciously: Multi-agent systems are a real capability lift for parallelizable, breadth-first work, but as no architecture change comes without a trade-off, the trade-off is complexity and cost multiplier. Use it judiciously when the complexity justifies the cost and manageability trade-off.

<img src="https://vedcraft.com/images/2026/08/context-maturity.png" alt="Context Engineering Maturity Model" class="wide-diagram" />

## The implication for architecture reviews (ADRs)

To conclude, Context engineering is not a prompt-writing skill you delegate to whoever is closest to the model call. It's an architectural decision with the same weight as choosing a vector data store or an AI model: what state lives where, what gets recomputed versus retrieved, and what the failure mode looks like when the budget is exceeded. Continuous measurement and experimentation yield the best results with documented architecture and design choices based on your agentic system's requirements.

## Key Questions

### Q1) What is context engineering?

Context engineering means actively managing an agent's working memory throughout a workflow. It is the practice of deciding what information occupies an LLM agent's context window at each step of a task through techniques such as offloading, compression, retrieval, isolation, and caching.

### Q2) How is context engineering different from prompt engineering?

Prompt engineering optimizes the wording of a single instruction for a single response. Context engineering manages an evolving window across a multi-step, tool-using trajectory, deciding what to keep, summarize, retrieve, or discard at every step.

### Q3) Why can't you just use a larger context window instead?

Transformer attention scales abruptly with token count, so a larger window doesn't remove the problem and also increases complexity. Longer, unmanaged context also causes context rot, where model performance degrades as irrelevant or stale tokens accumulate, independent of the window's stated limit.

### Q4) What's the difference between context and memory in an agent system?

Context is expensive, limited, immediate, and volatile working memory. Long-term memory such as a file system, database, or vector store is comparatively cheap and persistent but requires an explicit retrieval step to bring information back into context. Conflating the two is a common root cause of context rot and confusion.

![Context engineering: how prompt engineering, the context window, and an LLM agent relate, with the five failure modes and the offload/reduce/retrieve/isolate/cache strategies that manage them](https://vedcraft.com/images/2026/08/context-engineering.png)

## Mindmap for Exploration

<MindMap title="Context Engineering" collapseDepth={2}>
- Five Failure Modes
  - Context Rot (performance decay as tokens accumulate)
  - Context Poisoning (a bad inference compounds)
  - Context Distraction (history overshadows reasoning)
  - Context Confusion (too many irrelevant tools/facts)
  - Context Clash (contradictory context across agents)
- Context Is Not Memory
  - Context: expensive, immediate, volatile
  - Memory: cheap, persistent, needs retrieval
  - The 100:1 Rule
- Five Strategies
  - Offload (Write)
    - Manus file system
    - Claude Code CLAUDE.md
  - Reduce (Compress)
    - Auto-compaction
    - Cognition's fine-tuned summarizer
  - Retrieve
    - RAG
    - Just-in-time grep/glob
  - Isolate
    - Multi-agent subagents
    - ~15x token cost
  - Cache
    - Stable prompt prefix
    - KV-cache hit rate
- Choosing a Strategy
  - By context size (10K / 50K / 100K thresholds)
  - By deployment shape (Efficiency Frontier)
- Adoption Path
  - Measure first
  - Take the low-effort wins
  - Build the infrastructure
  - Multi-agent isolation last
</MindMap>

## References

- [How Long Contexts Fail — Drew Breunig](https://www.dbreunig.com/2025/06/26/how-to-fix-your-context.html)
- [Context Engineering for Agents — Lance Martin, LangChain](https://rlancemartin.github.io/2025/06/23/context_engineering/)
- [Effective Context Engineering for AI Agents — Anthropic](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [Don’t Build Multi-Agents — Cognition / Walden Yan](https://cognition.ai/blog/dont-build-multi-agents)
- [Context Engineering for AI Agents: Lessons from Building Manus — Yichao ‘Peak’ Ji](https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus)
- [Common Strategies for Context Management](https://agentic-ai.readthedocs.io/en/latest/ContextEngineering/strategies/)
- [Manus Context Engineering](https://agentic-ai.readthedocs.io/en/latest/ContextEngineering/manus/)
- [Anthropic Multi-Agent Research System](https://agentic-ai.readthedocs.io/en/latest/ContextEngineering/anthropic/)
- [Cognition / Devin: Don’t Build Multi-Agents](https://agentic-ai.readthedocs.io/en/latest/ContextEngineering/devin/)
- [Agent Memory Management](https://agentic-ai.readthedocs.io/en/latest/ContextEngineering/AgentMemory/README.md)
- [Multi-Agent Systems](https://agentic-ai.readthedocs.io/en/latest/Architecture/multi-agent-system/)