Draft:Context Engineering
Where to get help
How to improve a draft
You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Editor resources
|
This draft appears to contain text generated by a large language model (such as ChatGPT). You cannot use LLMs to generate article content.
Declined by Seawolf35 5 months ago.LLM-generated pages with certain obvious signs of being machine generated may be deleted without notice. These tools are prone to specific issues that violate our policies:
Instead, only summarize in your own words a range of independent, reliable, published sources that discuss the subject. See the advice page on large language models for more information. |
Context engineering is an emerging area of practice in artificial intelligence concerned with how information is selected, organized, and maintained for large language models (LLMs) and other AI systems during output generation.[1][2] The term is broader than prompt engineering, which focuses mainly on the wording of individual instructions or queries.[1] Context engineering addresses the wider set of decisions involved in assembling, retrieving, structuring, and updating the information an AI system can access at inference time.[2][3]
Practically speaking, this includes system instructions, retrieved documents, tool descriptions, conversation history, and various kinds of metadata - all of which shape how a model behaves.[2][4] These elements are treated as levers for improving reliability, factual grounding, and behavioral consistency in production AI systems.[2][4] One way to frame the distinction is that prompt engineering asks what to say to a model, whereas context engineering asks what the model is able to know when it generates a response.[1][2]
The topic has gained prominence alongside the spread of AI agents and complex agentic workflows.[2][3] In those settings, performance tends to depend less on any single prompt and more on how the full context window is constructed and updated over multiple steps.[2][3] A widely repeated observation among practitioners is that the quality and composition of context can be as consequential as the underlying model architecture itself.[2]
Background
[edit]From prompt engineering to context engineering
[edit]Prompt engineering became a widespread practice in the early 2020s, largely in response to the public availability of large language models beginning with GPT-3 in 2020 and ChatGPT in 2022.[5] During this period, developers focused on carefully worded queries and instructions to steer model behavior, relying heavily on trial-and-error iteration.[5] The discipline produced a body of techniques - few-shot examples, chain-of-thought prompting, role assignment - that proved genuinely useful for single-turn tasks.
The limits of that approach became more visible as applications grew more complex. Multi-step agent workflows that run across extended sessions require capabilities that go well beyond prompt crafting: dynamic retrieval of external knowledge, state management across turns, coordination of tool calls, and ongoing updates to contextual information.[2][3] Keeping all of that working together is not primarily a writing problem. It is closer to a systems problem.
By around 2025, practitioners and researchers had begun using "context engineering" as a label for this broader set of challenges.[2][3] The term appears in writing form from teams at Anthropic, Shopify, LangChain, Weaviate, and others, as well as in academic work surveying emerging practices around LLM context management.[2][3][6][4]Its adoption reflects a shift in where practitioners believe the hard problems actually live.
Relationship to prompt engineering
[edit]Context engineering is generally considered a superset of prompt engineering.[1][7] Prompt engineering concerns itself with how instructions and examples are composed inside a prompt. Context engineering covers the wider range of decisions about what information enters the model's context window at all - how it's formatted, ordered, retrieved, and maintained over time.[1][2][7]
In practice, the two aren't neatly separated. A well-crafted system prompt is both a prompt engineering object and a context engineering decision. The distinction becomes clearer at the level of systems design: building a RAG pipeline, managing token budgets across lengthy sessions, or determining what an agent should remember from one step to the next are context engineering concerns in a way that optimizing instruction phrasing is not.
Core components
[edit]Writers discussing context engineering commonly organize the subject into several related areas, each corresponding to a different part of the context that can be shaped or controlled.[2][4]
System instructions
[edit]System instructions form the base layer of behavioral guidance for an AI system - defining its role, setting constraints, establishing tone, and specifying operating parameters.[2] In enterprise deployments, these instructions frequently encode organizational policies, compliance requirements, brand voice guidelines, and role-specific behavioral expectations.[2][7]
Because system instructions persist across an entire session, they function more like a configuration layers than a single message. A well-designed system instruction set can be reused across thousands of interactions. A poorly designed one can cause consistent, hard-to-diagnose problems at scale. This is part of why system instructions quality receives its own attention in context engineering discussions, separate from prompt design.
Retrieved knowledge (RAG)
[edit]Retrieval-augmented generation (RAG) is one of the most widely discussed techniques within context engineering.[2][4] In a RAG system, relevant documents, records or other data are retrieved from external stores and inserted into the model's context at inference time. The design decisions involved are substantial: chunking strategies, embedding methods, retrieval ranking, reranking, and the formatting of retrieved text before it reaches the model all affect the quality of the final output.[2][4]
A common failure mode in RAG systems is retrieving documents that are technically relevant by keyword or semantic similarity but poorly suited to the actual reasoning task. Context engineering in this area involves not just retrieval but also curation, thinking carefully about what the model actually needs to see, in what form, and in what order.
Memory systems
[edit]AI agents that interact with users or systems over multiple steps rely on some form of memory.[3][4] Short-term memory typically refers to state maintained within a single session, which might include prior conversation turns, intermediate results, or working notes. Longer-term memory involves stores that persist across sessions and may hold information from earlier interactions or from institutional knowledge bases.[3][4]
The governance of memory, what gets saved, when it is retrieved, how it is summarized or compressed over time, is itself a context engineering problem. Naively appending everything to the context window produces rapidly diminishing returns as the volume or irrelevant or outdated information grows. More principled approaches involve explicit policies for what counts as worth retaining and for how memory representations are updated.
Tool definitions
[edit]In agentic architectures, models are often given access to external tools: APIs, database queries, code execution environments, file systems, and so on.[2] How these tools are described in the context has a direct influence on how and when the model decides to use them. Ambiguous or poorly scoped tool descriptions lead to unpredictable tool selection behavior. Context engineering in this area focuses on writing clear schemas, precise descriptions, and appropriate usage examples that reduce the space of plausible misinterpretations.[2]
Context management and token budgeting
[edit]LLMs operate within a bounded context window, which creates pressure to decide what information is retained, compressed, or discarded as interactions proceed.[1][3] Techniques include summarizing earlier conversation turns, relevance scoring to deprioritize less applicable material, deduplication to remove near-identical text, and token budgeting strategies that ensure critical information remains visible when the model needs it.[1][3]
Token budget management becomes especially important in long-horizon agent tasks, where a session might involve dozens of tool calls and large volumes of retrieved text. Getting the composition of the context window right at each step is roughly analogous to memory management in software engineering—with the added complication that the "program" is a probabilistic model whose behavior is sensitive to the ordering and framing of what it can see.
Provenance and observability
[edit]In production deployments, context engineering also involves keeping track of exactly which contextual elements contributed to a given model output.[7] This can include tagging, versioning, and logging context configurations so that behavior can be audited, reproduced, or tested after changes to the surrounding system.[7]
Without some form of provenance tracking, debugging misbehaving AI systems becomes very difficult. When a model produces an unexpected output, it is rarely obvious whether the problem lies in the prompt, the retrieved context, the tool definitions, the memory state, or the underlying model. Observability infrastructure that records what the model was shown, and in what form, helps answer that question.
Tacit and institutional knowledge
[edit]A strand of context engineering writing with particular relevance to enterprise use focuses on tacit knowledge—the informal judgment, norms, conventions, and expertise that exist within an organization but are typically not written down in any formal documentation.[8] Research on organizational knowledge has long suggested that a large proportion of what employees know is tacit in this sense, which makes it difficult to expose to AI systems that depend primarily on structured text.[8]
The practical consequence is that AI systems trained or configured only on documented sources inherit a narrow and often unrepresentative picture of how an organization actually operates. Expert judgment about which customers warrant exceptions, how to handle unusual compliance scenarios, or what a particular client relationship requires tends not to appear in policy manuals.
Some commercial platforms address this by collecting tacit knowledge more systematically—through structured interviews with subject-matter experts, analysis of internal communications, observation of workflows, and post-hoc capture of decision rationales—and converting these inputs into reusable context assets that can be supplied to AI systems at scale.[8] The goal is to give models access to the working logic of an organization, not just its formal documentation.
Context graphs
[edit]A context graph has been described as a structured, queryable record of decision traces accumulated over time by AI agent systems operating inside enterprise workflows.[9] The term was popularized by investors at Foundation Capital in late 2025, who argued that such graphs could underpin significant new software platforms in the enterprise market.[9] In early 2026, a Gartner research note characterized context graphs as a new layer of infrastructure for agentic systems, comparing them to an evolution of knowledge graphs designed specifically to support model performance, grounding, decision logic, workflows, and state management.[10]
The core argument is a contrast with traditional systems of record. CRM and ERP platforms track the current state of business entities—a customer's contact information, an order's status, an account balance. Context graphs, by contrast, are intended to record decision lineage: the exceptions that were granted, the precedents that were applied, the cross-system reasoning that led to a particular outcome, and the people or systems that approved each step.[9] They capture not just what happened but how decisions were reached.
This distinction matters for enterprise AI in a specific way. Human workers handle ambiguous or novel cases by drawing on accumulated institutional memory—informal knowledge of how similar situations were resolved, which policies have been applied loosely in practice, whose judgment is trusted on which questions. AI agents lack that history by default. Providing decision traces through a context graph is one proposed mechanism for giving agents access to a functional equivalent.[9][11]
Building a context graph typically involves configuring the AI orchestration layer to write a structured record at each decision point, capturing inputs considered, policies checked, exceptions granted, and approvals received.[9] Over time, this forms a searchable collection of precedents that is intended to make agent behavior more predictable and audits easier to conduct.[9][10]
Context drift
[edit]Context drift refers to the gradual divergence between an AI system's behavior and an organization's current norms, which occurs when the context data and instructions supplied to the system are not updated to reflect changes in policy, terminology, or operational expectations.[11] The phenomenon is subtle: a model working from instructions written eighteen months ago may produce outputs that are technically coherent but increasingly out of step with how the organization currently operates.
This is not a hypothetical concern in long-running enterprise deployments. Regulatory language changes. Products are renamed. Client relationships evolve. Internal policies get revised. None of these changes automatically propagate into the context artifacts—system instructions, retrieved knowledge stores, role definitions—that AI systems depend on. Without active monitoring, the gap between what the system was configured to do and what the organization now requires tends to widen silently.
Managing context drift has been proposed as a distinct area of work within context engineering.[2][11]Efforts in this area include proposals to define open protocols—DriftWatch is one example that has been discussed publicly—that would give organizations shared methods for tracking semantic fidelity and monitoring behavior over time in agentic systems.[11]
Applications
[edit]Context engineering techniques have been described across several domains where consistency and reliability are viewed as especially important.[2][4]
Regulated industries
[edit]Financial services, insurance, and pharmaceutical companies have been among the earlier adopters of systematic context engineering.[2][11] In these sectors, AI systems are expected to apply regulatory constraints, required compliance language, and documentation requirements in a consistent and auditable way. Context engineering provides a mechanism for embedding those requirements at the instruction layer rather than relying on model behavior alone. This matters because compliance obligations change, and the context layer needs active governance to stay current.
Enterprise AI agents
[edit]Large organizations deploying internal AI assistants and agents face a version of the tacit knowledge problem at scale.[2] A generic model has no knowledge of an organization's specific policies, its internal terminology, its relationship history with particular clients, or the informal rules that have accumulated over years of operation. Context engineering is the primary means by which that gap gets bridged—through system instructions, curated knowledge bases, and role-specific behavioral guidance.
Customer-facing AI
[edit]Customer support and sales applications rely on context engineering to manage personalization, knowledge grounding, and behavioral constraints.[2][4] The challenges here are somewhat different from internal enterprise applications: the population of users is larger and more varied, and the consequences of behavioral inconsistency are more immediately visible. Getting retrieved knowledge right—so the model draws on current product information, accurate policies, and the relevant history of a customer relationship—is a significant operational problem in this area.
Software development agents
[edit]Coding agents make use of context engineering to organize and surface relevant information from code repositories, documentation, test artifacts, and architectural guidelines across multi-step development workflows.[4] As these agents take on longer-horizon tasks—writing, reviewing, debugging, and refactoring across multiple files and sessions—the challenge of constructing and maintaining a useful context window becomes increasingly consequential for output quality.
Platforms and tools
[edit]A number of software projects and specifications appear in discussions of context engineering as supporting infrastructure.[2][3][4]
LangChain and LangGraph are open-source frameworks for building agentic LLM applications. Both include tooling for managing context and orchestrating multi-step workflows.[3]
LlamaIndex is a data framework oriented toward retrieving and inserting context into LLM applications, with particular depth in document indexing and query workflows.[4]
Weaviate is a vector database supporting embedding-based retrieval of contextual information for use in RAG systems.[4]
meetsynthia.ai is a context management platform that applies preflight governance at the instruction layer—assembling and validating institutional knowledge, compliance constraints, and behavioral rules before model inference.[8] The company received investment from Squirro, a Swiss enterprise AI vendor, in 2024.[8]
The Model Context Protocol (MCP) is an open standard introduced by Anthropic for connecting AI models to external tools, data systems, and other context sources through a common interface.[2][7]
Academic research
[edit]In July 2025, a team of researchers published A Survey of Context Engineering for Large Language Models (arXiv:2507.13334), a review of more than 1,400 research papers that proposed a taxonomy of components and system designs relevant to the field.[6] The authors treated context engineering as an emerging academic discipline with its own research questions, while situating it in relation to prompt engineering and longer-standing work in natural language processing.[6]
References
[edit][1] Schmid, P. (2025). "The New Skill in AI is Not Prompting, It's Context Engineering." "https://www.philschmid.de/context-engineering"
[2] Anthropic Engineering. (2025). "Effective Context Engineering for AI Agents." https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[3] LangChain. (2025). "The Rise of Context Engineering." https://blog.langchain.com/the-rise-of-context-engineering/
[4] Brown, T. et al. (2020). "Language Models are Few-Shot Learners." Advances in Neural Information Processing Systems, 33.
[5] Mei, L. et al. (2025). "A Survey of Context Engineering for Large Language Models." arXiv:2507.13334.
[6] Weaviate. (2025). "Context Engineering: LLM Memory and Retrieval for AI Agents." https://weaviate.io/blog/context-engineering
[7] Prompt Engineering Guide. (2025). "Context Engineering Guide." https://www.promptingguide.ai/guides/context-engineering-guide
[8] "Squirro invests in second company in two months." Startupticker.ch, September 10, 2024. https://www.startupticker.ch/en/news/squirro-invests-in-second-company-in-two-months
[9] Gupta, J. and Garg, A. (2025). "AI's Trillion-Dollar Opportunity: Context Graphs." Foundation Capital. https://foundationcapital.com/context-graphs-ais-trillion-dollar-opportunity/
[10] Miclaus, R. and Coshow, T. (2026). "Emerging Tech: AI Vendor Race: The New Essential Infrastructure for Agentic Systems: How Context Graphs Are Solving AI's Institutional Memory Problem." Gartner. ID G00846665. February 13, 2026.
[11] Verma, A. (2025). "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027." Gartner Newsroom.
- ^ a b c d e f g Schmid, Philipp (2025-06-30). "The New Skill in AI is Not Prompting, It's Context Engineering". www.philschmid.de. Retrieved 2026-02-24.
- ^ a b c d e f g h i j k l m n o p q r s t u v w x y z "Effective context engineering for AI agents". www.anthropic.com. Retrieved 2026-02-24.
- ^ a b c d e f g h i j k l "The rise of "context engineering"". LangChain Blog. 2025-06-23. Retrieved 2026-02-24.
- ^ a b c d e f g h i j k l m n "Context Engineering - LLM Memory and Retrieval for AI Agents | Weaviate". weaviate.io. 2025-12-09. Retrieved 2026-02-24.
- ^ a b Brown, Tom B.; Mann, Benjamin; Ryder, Nick; Subbiah, Melanie; Kaplan, Jared; Dhariwal, Prafulla; Neelakantan, Arvind; Shyam, Pranav; Sastry, Girish; Askell, Amanda; Agarwal, Sandhini; Herbert-Voss, Ariel; Krueger, Gretchen; Henighan, Tom; Child, Rewon (2020-12-06). "Language models are few-shot learners". Proceedings of the 34th International Conference on Neural Information Processing Systems. NIPS '20. Red Hook, NY, USA: Curran Associates Inc.: 1877–1901. ISBN 978-1-7138-2954-6.
- ^ a b c Mei, Lingrui; Yao, Jiayu; Ge, Yuyao; Wang, Yiwei; Bi, Baolong; Cai, Yujun; Liu, Jiazhi; Li, Mingyu; Li, Zhong-Zhi (2025-07-21). "A Survey of Context Engineering for Large Language Models". arXiv:2507.13334 [cs.CL].
- ^ a b c d e f "Context Engineering Guide – Nextra". www.promptingguide.ai. Retrieved 2026-02-24.
- ^ a b c d e "Squirro invests in second company in two months".
- ^ a b c d e f Garg, Jaya Gupta, Ashu (2025-12-22). "AI's trillion-dollar opportunity: Context graphs". Foundation Capital. Retrieved 2026-02-24.
{{cite web}}: CS1 maint: multiple names: authors list (link) - ^ a b "Gartner Login". www.gartner.com. Retrieved 2026-02-24.
- ^ a b c d e "Gartner: Over 40% of Agentic AI Projects Will Be Canceled by End 2027". Gartner. Retrieved 2026-02-25.

LLM-generated pages with certain obvious signs of being machine generated may be deleted without notice.
These tools are prone to specific issues that violate our policies:
Instead, only summarize in your own words a range of independent, reliable, published sources that discuss the subject.
See the advice page on large language models for more information.