Context engineering is becoming the control plane for AI agents
Larger context windows help, but they do not decide what an agent should remember, retrieve, compress or trust. Long-running reliability increasingly depends on an explicit context-management system.
What is happening?
An AI agent cannot keep everything it sees equally active forever. Instructions, documents, tool results, decisions and past conversations all compete for a limited working window. A larger window delays the problem but does not remove it. Context engineering is the system that chooses what enters the window, what stays in durable storage, what gets summarized, what can be retrieved later and which information is trusted. The safest design keeps a structured task ledger outside the conversation, retrieves only the evidence needed for the current step and treats compaction as a lossy state change that must be tested.
Why this trend is moving
- 01Long-running agents can exceed one context window even when individual model windows are very large.
- 02Tool definitions, search pages, logs, screenshots and intermediate results often consume more context than the user request.
- 03OpenAI and Anthropic now expose native compaction or context-editing mechanisms rather than leaving all state management to application code.
- 04Persistent memory and external workspaces are becoming standard agent primitives across sessions.
- 05Prompt caching is lowering repeated input cost while making prefix design and retention policy more important.
- 06Long-context benchmarks show that fitting information into a window is not the same as reliably using it.
- 07Prompt injection and stale memory make the origin and authority of every context item a security concern.
What this means in practice
- The advertised context length should be treated as a capacity ceiling, not a guarantee of accurate reasoning across every token.
- Active context, durable task state and long-term memory require different write, retrieval and deletion rules.
- Retrieval should combine semantic similarity with source authority, freshness, exact identifiers and contradiction handling.
- Compaction must preserve exact values, approvals, failures, open questions and provenance rather than producing only a fluent narrative.
- Tool schemas and verbose tool results should be loaded progressively instead of occupying the baseline window.
- Prompt caching reduces repeated processing cost but does not make irrelevant or stale context harmless.
- Context evaluation should force updates, contradictions, long histories and compression—not only simple needle retrieval.
What the headline leaves out
This is the practical technical view: how the system is put together, where it can fail, and what a real deployment asks from the team running it.
How it is built
A production context control plane begins by classifying protected instructions, user authority, current task state, retrieved evidence, long-term memory, tool output and untrusted observations. The task contract and typed work ledger live outside the transcript. Documents, prior sessions and artifacts are indexed with source, time, scope, sensitivity and validity metadata. Each subtask retrieves candidates that are reranked for relevance, authority, freshness, diversity and conflict. Tool definitions and detailed outputs are disclosed only when needed. Before the model call, the system reserves output and tool capacity, deduplicates content, orders critical information and applies structured compression when required. Generated actions are validated, while memory and state writes use explicit schemas. Selection, removal, compaction, writeback and final outcome remain traceable for evaluation, correction and replay.
How inference behaves
Context engineering combines state machines, retrieval, reranking, prompt assembly, tool discovery, summarization, caching and memory governance. A context builder starts from the current subtask rather than the full history. It selects protected instructions, recent state and evidence under a token budget. Semantic search may find related text, while metadata and exact lookup enforce user, tenant, version, date and artifact boundaries. Compression converts verbose traces into structured continuation records or references to raw artifacts. Prompt caching reuses stable prefixes but leaves the content logically present. Long-term memory uses controlled writes and just-in-time retrieval rather than automatically replaying every prior conversation.
What the tests can miss
A credible evaluation uses representative long-horizon tasks and records the exact context presented at each step. It measures final task success, critical-evidence recall, false admission, position robustness, provenance, compaction retention, summary fabrication, contradiction preservation, temporal updates, instruction-boundary resistance, tool-context efficiency, caching behavior, recovery and complete cost. Test cases should move evidence to different positions, insert irrelevant material, change earlier facts, force compaction, revoke memories and place malicious instructions inside documents or tool output. Compacted trajectories should be compared with full-history and retrieval-managed baselines.
What deployment involves
Start with a bounded context template and an external task ledger. Add retrieval for document-heavy work, using provenance and freshness filters before semantic ranking. Shape tool results into concise typed outputs with references to full artifacts. Introduce planned compaction at checkpoints and test it for omission, fabrication and status changes. Add long-term memory only after write, correction, expiry and deletion policies exist. Use prompt caching for stable prefixes without confusing cost savings with better reasoning. Canary changes to retrieval, ordering, summarization and memory against recorded long traces.
Where the risks sit
A context window mixes content with different origins and authority. Webpages, email, documents, tool output and prior model summaries can contain indirect prompt injection or false facts. The system should keep policy and user authority in protected channels, label untrusted content, restrict tools and reapply deterministic authorization before actions. Memory writes need provenance and review because malicious or speculative content can persist across sessions. Compaction must preserve source boundaries instead of converting quoted instructions into the agent’s own plan. Cached prefixes, vector stores, files, traces and memory records require retention, access and deletion controls.
What it really costs
Complete context cost includes retrieval, embeddings, indexing, reranking, compression calls, input tokens, cache storage, memory operations, observability, human correction and failed trajectories. A smaller prompt can reduce model cost while increasing retrieval or summarization expense. A larger window can simplify engineering at low volume while increasing latency and repeated input cost. The useful denominator is a verified accepted task completed without losing critical state or admitting unsafe context, not tokens removed or cache hits alone.
What the evidence supports
The trend is established. OpenAI describes automatic compaction for long-running Responses API and Codex agent loops, along with externalized workspace state. Anthropic documents context editing, tool-result clearing, memory files, tool search, programmatic tool calling and prompt caching as distinct controls for context pressure. Google documents million-token contexts and strong simple retrieval while noting that multi-needle performance varies and longer inputs increase latency and cost. Lost in the Middle, RULER, LongBench, InfiniteBench, LongMemEval and newer agent-memory benchmarks show that position, history length, updates and task structure still matter. Prompt-compression research demonstrates useful token reductions but also shows that semantic similarity does not guarantee preservation of reasoning-critical details. The evidence supports active context management as production infrastructure rather than treating the model window as an unlimited transcript.
How it works in practice
A larger context window increases the amount of information a model can receive. It does not decide which instructions, evidence, state, memories and tool results deserve attention. Reliable long-running agents need an explicit context control plane that writes durable state, retrieves selectively, compresses with provenance, isolates untrusted content and measures what was lost or distorted at every transition.
How the parts work together
The headline technology is only one part of the product. Reliability, security and cost are usually decided by the handoffs around it.
- 01
Task contract and context classes
Define the goal, completion state, authority, constraints and information classes. Separate immutable instructions, current task state, retrieved evidence, tool output, user memory and untrusted observations before assembling a prompt.
- 02
Protected instructions and identity
Load system rules, user authority, tenant identity, policy and current environment through protected channels. Version them and keep untrusted documents or webpages from impersonating instructions.
- 03
Durable working state
Store decisions, completed actions, open questions, artifacts, provenance and checkpoints outside the conversation. The transcript remains evidence, not the only database for the task.
- 04
Indexing and retrieval
Represent documents, prior turns, memories and tool artifacts with source, time, scope, sensitivity and validity metadata. Retrieve candidates for the current subtask rather than loading every available item.
- 05
Selection and ordering
Rank candidates by relevance, authority, freshness, diversity and conflict. Deduplicate, preserve dissenting evidence and place critical instructions or evidence where the selected model can use them reliably.
- 06
Compression and tool-result shaping
Replace verbose traces with structured state, extracts, summaries or references. Preserve identifiers, numbers, unresolved conflicts and links back to raw evidence so compressed context remains auditable.
- 07
Execution and controlled writeback
Run the model with an explicit context budget. Validate generated actions, then write durable facts, decisions and artifacts through typed operations rather than allowing free-form conversation to become permanent memory automatically.
- 08
Evaluation, drift and recovery
Measure retrieval, retention, contradiction handling, instruction adherence, token cost and task success across long traces. Replay from checkpoints, compare compacted with uncompacted runs and correct or revoke stale context.
Estimate the limits before the demo
These equations are planning tools rather than substitutes for testing. They help expose a design that is unlikely to fit its hardware, budget, reliability or risk limits.
The usable context budget is smaller than the advertised window
working budget = model window − output reserve − tool reserve − safety margin − fixed instructions The remaining budget must cover the current request, selected evidence, state and recent interaction. Planning against the full advertised window risks truncation or emergency compaction at the worst moment.
- A 128k window may leave much less space after tools, system instructions and expected output are reserved.
- A coding agent should reserve room for patches, test output and recovery messages.
- A multimodal request may consume context through images or audio representations as well as text.
Context quality depends on evidence density, not volume
weighted evidence density = Σ(relevance × authority × freshness) for admitted evidence ÷ active context tokens The expression is a design heuristic, not a universal score. It captures the goal of increasing useful, trustworthy information while removing stale or repetitive tokens that compete for attention.
- Ten copied web pages can be worse than three cited passages that answer the current subtask.
- A current source may deserve more weight than a highly similar but obsolete memory.
- Contradictory authoritative evidence should remain visible instead of being averaged away.
Compaction must be evaluated as a lossy state transition
retention quality = preserved critical facts − inserted false facts − unresolved contradictions lost A shorter summary is not automatically a good summary. The compacted state must preserve the facts, commitments, provenance and open risks needed for future decisions without inventing continuity that never existed.
- A summary that drops an unpassed test can make later work appear complete.
- Changing “proposed” to “approved” is a dangerous state mutation.
- A compacted state should retain links or identifiers for the raw records it represents.
A bigger window does not remove the context problem
Long-context models make it possible to send large repositories, document collections or histories in one request. That is useful. It does not guarantee that the model will identify every relevant fact, resolve conflicts or apply instructions consistently across the full input.
The original Lost in the Middle work showed strong position effects in long inputs. Newer models can perform much better on simple retrieval, and Google has reported strong Gemini results near the context limit. The harder cases remain multi-needle retrieval, multi-hop reasoning, changing facts and tool-heavy trajectories.
The practical question is therefore not “Can the input fit?” It is “What working set gives this model the best chance of making the next correct decision?” Context engineering answers that question continuously as the task changes.
- Treat maximum window length as a capacity limit, not a reliability claim.
- Evaluate the exact model, prompt order and task type.
- Separate simple fact retrieval from synthesis and multi-step reasoning.
- Prefer a smaller high-quality working set when irrelevant material creates interference.
Active context, durable state and long-term memory need different rules
Active context is the information presented to the model for the current inference call. Durable working state records what the process has done and what remains. Long-term memory stores information that may matter in future sessions. A raw transcript contains parts of all three, but it is a poor substitute for explicit structures.
OpenAI and Anthropic now expose compaction or context-editing mechanisms because long agent loops inevitably fill the active window. Anthropic’s memory tool and OpenAI’s agent harnesses also externalize state so work can continue after a context boundary or sandbox restart.
Write policies should decide what becomes durable. User preferences, approved decisions and verified results may deserve persistence. Speculative reasoning, transient tool noise and untrusted webpage instructions usually do not.
- Keep the current plan and completion ledger in typed durable state.
- Store memory with source, time, scope and correction status.
- Require explicit write rules for facts that affect future actions.
- Keep raw traces available for audit without replaying all of them into every prompt.
Similarity alone is not enough to choose context
Vector similarity is useful for finding semantically related material. An agent also needs authority, freshness, task scope, identity and contradiction signals. A highly similar old policy can be more dangerous than a less similar current one.
Retrieval should begin from the current subtask and produce a candidate set. A second stage can rerank, deduplicate and diversify the evidence. Exact identifiers, structured filters and graph relationships often outperform embeddings for account numbers, versions, dates and dependencies.
The retriever should return provenance with the content. The model and any downstream verifier need to know whether a statement came from the user, an approved database, a web page, a prior model summary or an inference.
- Combine semantic search with metadata and exact lookup.
- Prefer authoritative and current records over merely similar text.
- Retrieve conflicting evidence when disagreement matters.
- Track evidence that was considered but rejected for policy or freshness reasons.
Compaction is a controlled state migration
Long-running agents eventually need to remove or compress old material. OpenAI’s Responses API now supports native compaction, while Anthropic supports context editing, tool-result clearing and compaction. These mechanisms create room, but the application still owns the consequences of information loss.
A useful compacted state preserves the task contract, current plan, completed actions, unresolved failures, exact values, file or record identifiers, approvals and provenance. It should distinguish facts from hypotheses and decisions from suggestions.
Compression quality must be tested downstream. A summary that looks fluent may omit the one constraint that determines whether the next action is safe. For consequential workflows, retain references to raw evidence and support rehydration on demand.
- Compact at meaningful checkpoints, not only when the request is about to fail.
- Use structured continuation records instead of one narrative paragraph.
- Preserve negative results and unresolved contradictions.
- Compare compacted and full-history trajectories on the same acceptance tasks.
Tool definitions and results need progressive disclosure
An agent with dozens of tools can spend a large part of its context on schemas it will not use. Repeated search pages, logs, screenshots and command output can dominate the remaining window. More tools and more evidence can therefore reduce rather than improve task performance.
Anthropic’s current guidance separates tool search, programmatic tool calling, prompt caching and context editing because they solve different pressures. Tool search avoids loading every schema. Programmatic execution keeps intermediate values outside the transcript. Context editing removes stale results. Caching lowers repeated processing cost but does not reduce what the model must reason over.
Tool responses should expose a concise result, stable identifiers, provenance and a reference to full output. The agent can request the larger artifact when needed. Error messages should preserve the exact failure and retry state rather than flooding the prompt with unrelated logs.
- Load tool schemas only when the current subtask may need them.
- Return structured extracts and references instead of full payloads by default.
- Keep secrets and irrelevant fields out of model-visible tool output.
- Separate “context removed” from “source deleted” in logs and user controls.
Context assembly must preserve instruction precedence and trust
A context window can contain system rules, user requests, retrieved documents, email, webpages and outputs from other models. They are all tokens to the model, but they should not have the same authority.
Indirect prompt injection exploits this ambiguity by placing instructions inside content the agent was meant to inspect. Context engineering should label origin and trust, isolate untrusted material, restrict tools and reapply deterministic policy before actions. Summaries must not accidentally promote a quoted instruction into the agent’s own plan.
The system should also preserve the initiating user and task when context crosses subagents or sessions. A memory saying that a user approved something last month is not a current authorization for a different consequence.
- Keep policy and user authority outside retrieved content.
- Mark quoted or untrusted instructions as data.
- Do not let summaries erase source boundaries.
- Reconfirm authority when the task, recipient, amount or environment changes.
Prompt caching changes cost, not cognitive load
Prompt caching can avoid recomputing a stable prefix and materially reduce repeated input cost or latency. OpenAI, Anthropic and Google all document caching mechanisms. The model still receives the cached context, and irrelevant cached tokens can still interfere with the task.
Cache layout affects architecture. Stable system instructions and common reference material belong before volatile user turns. Changing an early tool definition or policy can invalidate everything after it. Retention and data-control requirements may also differ between ordinary requests and cached state.
Teams should track cache-hit tokens, invalidation rate, storage lifetime and savings separately from answer quality. A high hit rate does not justify keeping stale or overbroad context.
- Design stable prefixes intentionally.
- Version cached instructions and reference corpora.
- Do not use caching as a substitute for retrieval or compaction.
- Include cached-state retention in privacy and deletion workflows.
Context systems need long-horizon and counterfactual evaluation
A single needle-in-a-haystack test does not represent an agent that must track decisions, updates, failures and tool results over hours. Evaluations should move relevant facts to different positions, introduce contradictions, update earlier information and force compaction or retrieval under a fixed budget.
Measure the context subsystem as well as final task success. Retrieval recall, false admission, provenance accuracy, critical-fact retention, contradiction preservation, instruction-boundary violations and token cost explain why a trajectory succeeded or failed.
Production monitoring should capture which context items were selected, removed, compressed and written back. Sensitive raw content may require protected or sampled logging, but the system still needs enough lineage to reconstruct a harmful action or correct stale memory.
- Evaluate across increasing history length and context pressure.
- Test updates, deletions and abstention, not only recall.
- Inspect compacted state for fabricated or promoted facts.
- Link context metrics to release, rollback and memory-correction decisions.
What a benchmark worth believing should report
A performance number means little unless the workload, system configuration and quality bar are fixed. This is the minimum record a team should keep.
| Metric | How to measure it | Why it matters |
|---|---|---|
| Task success under context pressure | Run representative long-horizon tasks at increasing history, tool-output and evidence volumes. | A system that succeeds only before compaction is not durable. |
| Critical evidence recall | Measure whether all task-essential facts are admitted into the active working set. | Missing one constraint can invalidate the entire trajectory. |
| False admission rate | Count stale, irrelevant, unauthorized or contradictory items admitted as trusted context. | More recall is harmful when noise or poisoned evidence gains influence. |
| Position robustness | Move the same evidence across beginning, middle and end positions and compare performance. | Context order can change model behavior even when content is identical. |
| Provenance accuracy | Verify that claims retain the correct source, time, scope and trust classification after retrieval and compression. | Agents need to distinguish user facts, system records and model inferences. |
| Compaction retention | Score preservation of task contract, exact values, decisions, failures, open questions and artifact identifiers. | A fluent summary can still destroy operational state. |
| Compaction fabrication | Count facts, approvals or completion claims inserted during summarization. | Compression can create false continuity. |
| Contradiction preservation | Test whether conflicting authoritative evidence remains visible until resolved. | Summaries often erase disagreement prematurely. |
| Memory update correctness | Measure temporal updates, correction propagation, deletion and abstention across sessions. | Long-term state must change when reality changes. |
| Instruction-boundary resistance | Inject instructions into documents, tool output and memory, then test policy and tool behavior. | Untrusted context must not acquire system authority. |
| Tool-context efficiency | Track tool-definition tokens, result tokens, deferred tools and expandable artifact references. | Tooling can consume most of the window without improving decisions. |
| Cache effectiveness | Report cache-hit tokens, invalidations, retention, latency and cost without combining them with quality. | Caching is an economic optimization, not evidence of better reasoning. |
| Context cost per accepted task | Include retrieval, reranking, compression, model input, memory operations, review and failed trajectories. | Token reduction can shift cost into another subsystem. |
| Recovery and replay | Resume from checkpoints after truncation, corrupted memory or failed compaction and compare final state. | A production agent must recover when context management itself fails. |
Four sensible deployment patterns
Bounded single-session context
- Where it fits
- Short tasks with a small toolset and little need for durable state.
- What you take on
- Simple and auditable, but unsuitable for long-running or multi-session work.
Retrieval-managed agent
- Where it fits
- Document, support or research tasks where a large corpus can be queried selectively.
- What you take on
- Controls active context size but depends on indexing, reranking and provenance quality.
Compaction plus durable work ledger
- Where it fits
- Long-running coding, operations or analysis tasks that cross context windows.
- What you take on
- Maintains continuity, while compaction errors can mutate task state unless raw evidence remains recoverable.
Tiered context fabric
- Where it fits
- Complex agents using protected instructions, active working memory, artifact stores, long-term memory, subagents and cached prefixes.
- What you take on
- Strongest control and highest engineering, privacy, evaluation and observability burden.
Where projects usually go wrong
Everything that fits is loaded
What you see: Accuracy falls as documents, history and tool output accumulate.
What to do: Use task-specific selection, deduplication and evidence-density thresholds.
Maximum window is treated as concurrency-free capacity
What you see: The system reaches the limit before tool calls or output can complete.
What to do: Reserve output, tool and safety margins and trigger planned compaction earlier.
The transcript becomes the only state store
What you see: A truncated or compacted conversation loses completed work and open failures.
What to do: Maintain a typed external work ledger and artifact registry.
Similarity overrides freshness
What you see: An obsolete policy or preference is retrieved because it resembles the query.
What to do: Combine semantic relevance with version, time, authority and validity filters.
Compaction invents completion
What you see: A proposal, partial result or failed test is summarized as approved or done.
What to do: Use structured summaries, exact status enums and retention/fabrication tests.
Contradictions are averaged away
What you see: A summary chooses one account without preserving unresolved disagreement.
What to do: Store competing claims with provenance and explicit resolution state.
Tool output overwhelms the prompt
What you see: Logs, search pages or API payloads crowd out the task and instructions.
What to do: Return concise structured results with expandable references to raw artifacts.
Tool schemas consume the baseline window
What you see: Most tokens describe tools that are rarely used.
What to do: Use tool discovery, deferred loading or subtask-specific toolsets.
Retrieved instructions gain authority
What you see: A webpage, email or memory redirects the agent or triggers disclosure.
What to do: Label origin, isolate untrusted content and enforce actions through deterministic policy.
Memory writes are automatic and unreviewed
What you see: Speculation or malicious content persists into future sessions.
What to do: Apply typed write policies, provenance, correction and deletion controls.
Caching preserves stale prefixes
What you see: An old policy or tool definition remains cheap to reuse and therefore stays deployed.
What to do: Version caches, monitor invalidation and tie retention to lifecycle governance.
Context optimization is measured only by token reduction
What you see: A shorter prompt costs less but produces more errors or intervention.
What to do: Measure accepted task success, critical-fact retention and complete cost together.
A checklist you can actually use
- Define the task contract and authoritative completion state.
- Classify system instructions, user authority, evidence, memory, tool results and untrusted content separately.
- Reserve output, tool and safety capacity before setting the working-context budget.
- Keep a durable work ledger outside the model transcript.
- Record source, time, scope, sensitivity and validity for retrievable items.
- Combine semantic retrieval with exact identifiers and metadata filters.
- Rerank candidates for authority, freshness, diversity and conflict.
- Deduplicate repeated passages and tool output.
- Preserve contradictory evidence until a defined process resolves it.
- Place critical instructions and current questions deliberately in the assembled context.
- Load tool definitions progressively rather than exposing the entire catalog.
- Return concise tool results with references to raw artifacts.
- Trigger compaction at planned checkpoints before emergency truncation.
- Use structured continuation records with exact statuses and identifiers.
- Retain links from compressed state to the underlying evidence.
- Test compaction for omission, fabrication and status promotion.
- Apply explicit policies to long-term memory writes.
- Support memory correction, deletion, expiry and scope boundaries.
- Treat retrieved or remembered instructions as untrusted data.
- Version cached prefixes and include them in retention controls.
- Evaluate position, history length, updates, contradictions and forced compression.
- Trace selected, removed, compressed and persisted context items.
- Measure complete cost per accepted task, not input-token reduction alone.
Terms worth knowing
- Active context
- The instructions, state and evidence presented to the model for one inference call.
- Context window
- The maximum combined input and output token capacity supported by a model invocation.
- Context engineering
- The design and operation of how instructions, evidence, state, tools and memory are selected and presented to a model.
- Working memory
- Short-lived structured state needed to complete the current task or subtask.
- Long-term memory
- Persisted information intended for retrieval across sessions or future tasks.
- Compaction
- Replacing a larger history with a smaller representation intended to preserve the state needed for continuation.
- Context editing
- Removing or transforming selected historical content before it reaches the model.
- Progressive disclosure
- Loading detailed tools or evidence only when the current task requires them.
- Evidence density
- The proportion and quality of task-relevant, trustworthy information within the active context.
- Provenance
- Metadata showing where information came from, when it was valid and how it was transformed.
- Reranking
- A second selection stage that orders retrieved candidates using richer relevance and policy signals.
- Prompt caching
- Reusing precomputed representations of a stable prompt prefix to reduce repeated processing cost or latency.
- Context poisoning
- Introducing misleading or malicious information that influences later model decisions or memory.
- Rehydration
- Restoring detailed source material from a reference after it was omitted from the active context.
- State promotion
- The dangerous change of a claim from proposed or uncertain into approved, factual or complete during summarization or memory writing.
Primary references and technical starting points
These sources support the architecture, runtime, benchmark and security claims. Vendor capabilities can change, so the article records the distinction between established evidence, measured product behavior and editorial interpretation.
- 01 OpenAI: Responses API computer environment and native compactionopenai.com
- 02 OpenAI: Unrolling the Codex agent loopopenai.com
- 03 OpenAI: The next evolution of the Agents SDKopenai.com
- 04 OpenAI API: Conversation stateplatform.openai.com
- 05 OpenAI API: Prompt cachingplatform.openai.com
- 06 OpenAI API: File searchplatform.openai.com
- 07 OpenAI: New tools for building agentsopenai.com
- 08 OpenAI platform data controlsplatform.openai.com
- 09 OpenAI: Safety and alignment for long-horizon modelsopenai.com
- 10 OpenAI: Dreaming and memory synthesisopenai.com
- 11 Anthropic: Context editingplatform.claude.com
- 12 Anthropic: Manage tool contextplatform.claude.com
- 13 Anthropic: Memory toolplatform.claude.com
- 14 Anthropic: Prompt cachingplatform.claude.com
- 15 Anthropic: Tool use with prompt cachingplatform.claude.com
- 16 Anthropic: Tool searchplatform.claude.com
- 17 Anthropic: Programmatic tool callingplatform.claude.com
- 18 Anthropic: Context windowsplatform.claude.com
- 19 Anthropic: Effective harnesses for long-running agentsanthropic.com
- 20 Anthropic: Building effective agentsanthropic.com
- 21 Google Gemini API: Long contextai.google.dev
- 22 Google Gemini API: Context cachingai.google.dev
- 23 Google Gemini Generate Content: Explicit context cachingai.google.dev
- 24 Google Gemini API: Cached content resourceai.google.dev
- 25 Google Gemini API: Filesai.google.dev
- 26 Google Gemini API: Interactionsai.google.dev
- 27 Google Gemini API: Zero data retentionai.google.dev
- 28 Google Research: Retrieval Quality at Context Limitresearch.google
- 29 Google Research: Found in the Middleresearch.google
- 30 MCP resources specificationmodelcontextprotocol.io
- 31 MCP prompts specificationmodelcontextprotocol.io
- 32 LangGraph memory documentationdocs.langchain.com
- 33 LangGraph persistence documentationdocs.langchain.com
- 34 Lost in the Middleaclanthology.org
- 35 Found in the Middle paperarxiv.org
- 36 Never Lost in the Middlearxiv.org
- 37 Lost in the Middle and In-Betweenarxiv.org
- 38 RULER long-context benchmarkarxiv.org
- 39 LongBench benchmarkarxiv.org
- 40 LongBench v2arxiv.org
- 41 InfiniteBencharxiv.org
- 42 BABILong benchmarkarxiv.org
- 43 NoLiMa long-context benchmarkarxiv.org
- 44 HELMET long-context evaluationarxiv.org
- 45 LooGLE long-context benchmarkarxiv.org
- 46 LongMemEvalarxiv.org
- 47 LongMemEval-V2arxiv.org
- 48 MemGPTarxiv.org
- 49 Generative Agentsarxiv.org
- 50 ReActarxiv.org
- 51 Reflexionarxiv.org
- 52 Retrieval-Augmented Generationarxiv.org
- 53 Self-RAGarxiv.org
- 54 LLMLinguaarxiv.org
- 55 LongLLMLinguaarxiv.org
- 56 LLMLingua-2arxiv.org
- 57 Learning to Compress Prompts with Gist Tokensarxiv.org
- 58 RECOMP retrieval and compressionarxiv.org
- 59 Selective Contextarxiv.org
- 60 AutoCompressorsarxiv.org
- 61 In-context Autoencoderarxiv.org
- 62 ContextCurator for long-horizon agentsarxiv.org
- 63 Latent Context Language Modelsarxiv.org
- 64 What Works for Lost-in-the-Middlearxiv.org
- 65 NIST AI Risk Management Frameworknist.gov
- 66 NIST AI 600-1 Generative AI Profilenist.gov
- 67 OWASP: Prompt Injectiongenai.owasp.org