--- title: "Context Engineering Techniques for AI Agents: Which One to Use" url: "https://atlan.com/know/ai-agent/context-engineering/context-engineering-techniques-ai-agents/" description: "Atlan's guide to context engineering techniques for AI agents: diagnose failures, choose the right fix, and know when source context is the real problem." author: "Karthik Pasupathy" author_role: "Contributing Writer — AI Context & Agents" published: "2026-07-13" updated: "2026-07-13T00:00:00.000Z" --- --- ## How do teams choose the right context engineering technique? Choosing a context engineering technique starts with knowing where the context broke. Getting this right means answering a few questions in sequence: what the agent is doing wrong, why the underlying context is breaking, which technique to apply first, how techniques combine safely, and whether the real issue sits upstream in the source context itself. In an enterprise agent workflow, the visible problem can look deceptively similar. A support agent forgets the refund state from a previous step. A revenue agent retrieves five plausible definitions of the same metric. A policy agent has the right clause in its context window, but still ignores the exception. A data agent answers from a glossary term that was correct last quarter but wrong today. Each of those problems calls for one of [the four context engineering strategies](https://atlan.com/know/four-context-engineering-strategies/) to address it. Write keeps information available when the agent needs a persistent task state, choosing between the context window and a context store for where that state lives. Select decides which sources should enter the window when retrieval is noisy. Compress reduces context only after decisive facts have been structured and are safe to shrink. Isolation separates contexts when domains, tools, or agents collide, the same failure mode behind [multi-agent memory silos](https://atlan.com/know/multi-agent-memory-silos/). And when none of those context window management fixes work, the problem is usually the source context itself. This is where [Atlan's context layer](https://atlan.com/know/agent-context-layer/) becomes helpful. Context engineering strategies such as Write, Select, Compress, and Isolate can improve the way context moves through an agent workflow. But, they do not certify whether the underlying business context is correct. Enterprise agents also need current definitions, approved sources, policy context, lineage, ownership, and enough structure for the model to use that context consistently. That is also why the choice of technique cannot stop at "What does Write or Select mean?" It has to ask what part of the context system is failing: state, retrieval, ordering, compression, scoping, or the source itself. That is the practical difference between [context engineering for AI agents](https://atlan.com/know/context-engineering-for-ai-agents/) and a narrower [context engineering vs prompt engineering](https://atlan.com/know/context-engineering-vs-prompt-engineering/) debate. [Anthropic's 2025 guide](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) treats context engineering as full context-state management, while [Mei et al.'s 2025 survey](https://arxiv.org/abs/2507.13334) maps the term across retrieval, processing, management, memory, tools, and multi-agent systems. [Google](https://cloud.google.com/discover/ai-context-engineering) and [IBM](https://www.ibm.com/think/topics/context-engineering) also point in the same direction: the work goes beyond prompt wording, and the fix depends on which part of the context flow is breaking. The best place to start is the behavior you can see: forgetting, noisy retrieval, buried facts, slow runs, inconsistent answers, or wrong definitions. From there, diagnose the context issue behind the symptom, then map it to the context engineering technique that is most likely to fix it. --- ## Which symptom maps to which context engineering technique? The table below shows what each symptom usually means, what is likely causing it, which context engineering technique to try, and how to confirm the fix worked. | Symptom you're seeing | Likely cause | Technique to reach for | How to verify it worked | | :---- | :---- | :---- | :---- | | The agent forgets earlier steps mid-task | State lost from the window, which is one reason [why AI agents forget](https://atlan.com/know/why-ai-agents-forget/) | Write to a scratchpad or external store | Re-run the multi-step task and confirm the state that survives across steps | | Answers degrade as you add data sources | Too much irrelevant context, or [context distraction](https://atlan.com/know/context-distraction/) | Select tighter sources and focus on [reducing context noise](https://atlan.com/know/ai-agent/ai-agent-context/how-to-reduce-context-noise-ai-agents/) | Run the same question set before and after the retrieval changes | | The right data is in context, but the answer is wrong | Key facts are buried, and the [lost-in-the-middle problem](https://atlan.com/know/llm/lost-in-the-middle-problem/) | Reposition and structure first, then compress | Move the key facts, re-test failing questions, and compare accuracy | | Slow or expensive runs | Oversized context per call | Compress, prune, and use [context caching](https://atlan.com/know/context-caching/) for repeated stable context | Measure tokens, latency, accuracy, and [how much context is enough](https://atlan.com/know/how-much-context-is-enough/) | | Inconsistent answers across runs | Unscoped or colliding context | Isolate by domain, task, or sub-agent | Repeat the same prompt and track answer variance | | Hallucinations on edge cases | Missing approved context, not just a window issue | Escalate to the governed source context | Test against an edge-case suite and inspect retrieved sources | | Confidently wrong definition, such as "revenue" | Wrong or conflicting source of truth | Move beyond window techniques into [context versioning for AI agents](https://atlan.com/know/ai-agent/context-versioning-for-ai-agents/) | Re-run the task and confirm whether each agent uses the same approved definition | The pattern is straightforward: match the symptom to the context problem before choosing the technique. Once you know the right technique, the next step is to decide the order in which to apply it, because applying the right fix too early or in the wrong order might create new problems. --- The 7 Shifts Reshaping the Data Stack See why AI-first teams are rebuilding their data stack around governed context instead of the old catalog-first model, and what that means for how you architect agent context in 2026. Download the 2026 Report --- ## What is the right order for applying context fixes? The order in which we apply context engineering techniques matters because each technique changes the context the next one has to work with. Here are a few pointers on how to use context engineering techniques in the right order: 1. **Select before you compress:** Choose the right sources and sections before deciding what to shrink and what to carry forward. If retrieval brings back noisy sources, summarizing those sources yields shorter noise; so fix retrieval quality, reranking, filters, and source eligibility before shrinking the payload. 2. **Reposition before you summarize:** If the right data is present but the answer is still wrong, the key fact may be buried. Move it closer to the decision point, label it clearly, remove distractors, and re-test before using [context compression](https://atlan.com/know/context-compression/). 3. **Isolate before you scale:** If different domains collide, separate the context by task, domain, or agent role before adding more agents. If you are working with multiple agents, see Atlan's guide to [context engineering for multi-agent systems](https://atlan.com/know/context-engineering/context-engineering-for-multi-agents/). 4. **Govern before you persist:** If the agent writes notes from a bad definition, memory only makes the wrong answer durable. Pair Write with review, ownership, and versioning, the same discipline behind choosing a sound [agent memory architecture](https://atlan.com/know/how-to-choose-ai-agent-memory-architecture/). The sequence matters because each fix changes the next decision. Selection tells you what is safe to compress. Repositioning indicates whether the model can use the fact once it becomes visible. Isolation tells you whether the issue is a domain collision. Re-test the original failure after each change before adding another technique. --- ## How should teams combine techniques without making failures worse? Production agents often need more than one context engineering technique. The key is to combine them with a clear purpose, so one technique does not undo or weaken another. Use these combinations when the first fix is stable: | Scenario | Useful combination | What to watch before combining them | | :---- | :---- | :---- | | The agent [forgets the state across many steps](https://atlan.com/know/ai-agent/how-agents-forget-and-how-to-fix-it/) | Write + Select | Save only the task state, decisions, and source references that the next step needs. Do not let memory become a dumping ground for every intermediate note. | | Retrieval brings back too much similar content | Select + Compress | Choose approved sources and sections first. Then compress repeated background, examples, or boilerplate without shrinking the decisive definition or exception. | | The same stable context is used in every run | Compress + Cache | Cache context that is frequently used and rarely changes, such as stable instructions or approved definitions. Refresh it when the source, owner, or version changes. | | One agent mixes context from different domains | Isolate + shared source context | Separate the domain work so each agent gets a cleaner window. Keep shared definitions, policies, and owners consistent across those agents. | | The agent misses policy exceptions or edge cases | Select + governed source context | Retrieval should point to approved exception docs, policy notes, and lineage. Broad keyword matches can still miss the rule that changes the answer. | As the table shows, combining techniques can be useful. But it also creates risk when teams do not decide what must survive. Memory can preserve bad context. Pruning can remove the exception that changes the answer. Compression can make a weak retrieval set look cleaner than it is. That is why [context pruning](https://atlan.com/know/ai-agent/ai-agent-context/how-to-implement-context-pruning-ai-agents/) should come after the team knows which facts are safe to remove. A pricing exception, an approved definition, a policy owner, or a source version is not background noise. It is often the reason the answer is correct. Before adding a second technique, name what the first technique is protecting. Select protects relevance. Compress protects usable space. Writing protects continuity. Isolation protects the scope. Governed source context protects meaning. The practical goal of [context window management](https://atlan.com/know/ai-agent/ai-agent-context/how-to-implement-context-window-management-ai-agents/) is simple: hold the right evidence at the right moment. A smaller window is a side effect, not the target. Teams get there by deciding [how to structure the context for LLM applications](https://atlan.com/know/how-to-structure-context-for-llm-applications/) before deciding what to remove, compress, cache, or persist. --- ## What if the right data is present, but the answer is still wrong? Sometimes the agent has the right data, but the model cannot tell which part should drive the answer. Liu et al.'s [Lost in the Middle](https://aclanthology.org/2024.tacl-1.9/) paper in TACL 2024 found that long-context performance is often strongest when relevant information appears near the beginning or end of the input, and weaker when the same information appears in the middle. Chroma's [2025 context rot report](https://www.trychroma.com/research/context-rot) tested 18 LLMs and found that models became less reliable as input length grew, even on controlled tasks, a pattern consistent with broader research on [LLM context window limitations](https://atlan.com/know/llm-context-window-limitations/). That creates a specific diagnostic rule: if the right data is present but ignored, restructure before you compress. * **Move decisive facts closer to the question:** Definitions, constraints, and exceptions should appear near the decision step. * **Label the role of each fact:** "Authoritative definition" beats a paragraph that merely mentions the term. * **Separate evidence from background:** Do not bury approval rules between examples and narrative text. * **Shrink distractors first:** Remove adjacent content that appears similar but is unnecessary. * **Retest the same failures:** Use the exact prompts that exposed the miss. If accuracy increases after repositioning, the failure was not due to a missed retrieval. It was a weak context presentation. --- ## When do context techniques hit the source-of-truth wall? Every context engineering technique has a ceiling, and no [context engineering tool](https://atlan.com/know/context-engineering/context-engineering-tools-for-ai-agents/) changes that. If the source is wrong, the window can only present the wrong context at every run. This is the failure that matters most in enterprise AI. The agent confidently answers a revenue question, but one source defines revenue by invoiced amount, another by recognized revenue, and a third excludes a new product line. Select can retrieve one of them. Compress can summarize them. Isolation can keep each department separate. None of those techniques decides which definition is approved. That is the source-of-truth wall. You have hit it when: * **The same term is resolved differently across agents:** "Customer," "ARR," "active account," or "net revenue" depends on the workflow. * **The retrieved source is current but not authoritative:** The document exists, but it is not the approved definition. * **The agent cites real context and still answers incorrectly:** the failure is not a hallucination in the usual sense. It is [context poisoning](https://atlan.com/know/context-poisoning/) by a legitimate but misleading context. * **Fixes decay as business context changes:** A working retrieval or compression rule breaks after a change to a schema, policy, owner, or metric. At that point, the fix shifts from optimizing the prompt window to streamlining the [context layer](https://atlan.com/know/what-is-context-layer/): establishing governed definitions, lineage, policy context, ownership, version history, and delivery paths that agents can trust. That is also where [context drift](https://atlan.com/know/context-drift-ai-agents/) matters. The source context can drift before the model runs. A glossary term ages, a lineage path breaks, a policy changes, or a dashboard metric gets renamed. If agents keep retrieving the old context, better selection logic only makes the stale context easier to find. --- Check Your Context Maturity Run a quick self-assessment to see where your team's context practices stand today, and what to fix first before scaling more agents on top of an ungoverned context layer. Take the Assessment --- ## How does Atlan help in choosing the right context technique? Atlan helps teams make the source context reliable before agents retrieve, compress, isolate, or persist it. Write, Select, Compress, and Isolate stay exactly as they are. What changes is what they draw from: governed context instead of loose documents, stale notes, or conflicting definitions. | Technique limitations | What teams need | How Atlan supports it | | :---- | :---- | :---- | | Select retrieves from a bad source | Approved source context | Enterprise Data Graph with glossary terms, lineage, ownership, policies, and quality signals | | Compression drops decisive facts | Structured context, not flatter text | [Context Repos](https://atlan.com/know/ai-agent/context-repository-for-ai-agents/) and **[MCP Server](https://atlan.com/mcp-server/)**-delivered context with definitions, exceptions, source versions, and task labels | | Isolation creates multiple definitions | Shared meaning across domains | Certified context that agents can reuse across tools and workflows | | Write persists unreviewed knowledge | Governed updates | **[Context Engineering Studio](https://atlan.com/context-engineering-studio/)** evals, reviews workflows, and versioned context, the same governance model covered in [AI agent memory governance](https://atlan.com/know/ai-agent-memory-governance/) | | Teams cannot prove the fix worked | Repeatable tests | Golden questions, traces, drift signals, and [context quality testing for AI agents](https://atlan.com/know/ai-agent/context-quality-testing-for-ai-agents/) | The operating model is the same: context techniques manage what happens within the agent workflow, while the context layer ensures the underlying business meaning is trustworthy. Teams need both because a well-managed window still fails when the definition, policy, owner, lineage, or source version is wrong. --- ## How can teams verify whether a context engineering technique worked? Do not judge a context technique by one clean answer. Judge it by the failure set that broke the agent before. The verification loop is: 1. Capture the failing prompts, tool traces, retrieved sources, output, and expected answer. 2. Apply one context technique at a time. 3. Re-run the same eval set. 4. Compare accuracy, variance, token cost, latency, source freshness, and citation quality. 5. Keep the trace so the next context change can be tested against the same baseline. Use this matrix to decide what evidence to capture before and after the fix: | Context change | Evidence to capture before the fix | What should improve after the re-run | | :---- | :---- | :---- | | Writing task state | Steps completed, saved notes, source references, and where the agent lost state | The agent resumes from the saved state without re-asking or inventing progress | | Tightening retrieval | Retrieved sources, source rank, source freshness, and answer accuracy | Fewer irrelevant sources appear, and answers improve on the same question set | | Repositioning buried facts | Location of the decisive fact, nearby distractors, and the failing answer | The agent uses the decisive fact after ordering, labeling, or restructuring changes | | Compressing context | Token count, latency, removed content, and factual recall | Cost drops without losing definitions, exceptions, policy rules, or source references | | Isolating scope | Agent role, domain boundaries, tools used, and run-to-run variance | Answers stay consistent inside the scoped domain without leaking unrelated context | | Governing source context | Approved definition, owner, version, lineage, and retrieved source | The same approved definition appears across agents and workflows | [Context drift detection](https://atlan.com/know/context-drift-detection/) belongs in the same loop. A fix that works today can fail when the underlying source changes. The mature pattern is continuous: test the technique, monitor the context, and re-run evals when source context changes. This is where practitioners move from prompt tinkering to context operations. --- Is Your Data Estate Agent-Ready? Answer a short set of questions to see how ready your governed context is for the AI agents your team is about to put into production. Check Your Readiness --- ## Start with the symptom, end at the source Start with the symptom. Pick the smallest technique that targets the likely cause: Write for lost state, Select for noisy retrieval, repositioning for buried facts, Compress for cost, Isolate for collisions. Prove the change with evals, then look upstream. The order matters. Select and structure the context before compressing it. Isolate domains before adding more agents. Govern context before letting agents persist it. When teams combine techniques, they should decide which definitions, exceptions, policies, owners, lineage, and source versions must survive. The final check is evidence. Re-run the same failed task, inspect the traces, and watch for context drift. If the agent still fails because the underlying business context is stale, conflicting, or unapproved, stop tuning the window and fix the context layer. Book a Demo --- ## FAQs about context engineering techniques for AI agents ### 1. Which context engineering technique should I use first? Use the technique that matches the symptom. If the agent forgets earlier steps, start with Write. If answers degrade when you add sources, start with Select. If the right fact is present but ignored, restructure the context before compressing it. ### 2. My agent forgets mid-task. Which technique fits? Use Write. Persist task state, intermediate decisions, and required source references outside the context window so the agent can retrieve them later. Keep the written state small and reviewed, because persisting bad context makes the next step worse. ### 3. Why did adding more data make my agent worse? More data often lowers the signal-to-noise ratio. The agent may retrieve loosely related documents, conflicting definitions, or redundant background that competes with the decisive fact. Tighten the selection before you compress the larger payload. ### 4. What should I do if the right data is in context but the answer is wrong? Treat it as a presentation and ordering problem first. Move the decisive fact closer to the task, label it as authoritative, and remove nearby distractors. Then re-run the exact prompts that failed before. ### 5. Can I use all four techniques together? Yes, but sequence matters. Select the right sources, structure the decisive facts, compress only after relevance is clear, and isolate domains when context collides. Test each change so one technique does not hide another failure. ### 6. When do context engineering techniques stop working? They stop working when the source of truth is wrong or conflicting. If "revenue" has multiple unapproved definitions, no amount of compression or pruning decides which one the agent should trust. The fix is a governed, versioned context. --- ## Sources 1. Liu et al., "Lost in the Middle: How Language Models Use Long Contexts," TACL 2024. https://aclanthology.org/2024.tacl-1.9/ 2. Chroma, "Context Rot: How Increasing Input Tokens Impacts LLM Performance," 2025. https://www.trychroma.com/research/context-rot 3. Anthropic, "Effective Context Engineering for AI Agents," 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 4. Mei et al., "A Survey of Context Engineering for Large Language Models," arXiv, 2025. https://arxiv.org/abs/2507.13334 5. Google Cloud, "AI Context Engineering," 2026. https://cloud.google.com/discover/ai-context-engineering 6. IBM, "What Is Context Engineering?," 2026. https://www.ibm.com/think/topics/context-engineering