Before you start
The example needs Python 3.10 or newer, pip install openai-agents and an OPENAI_API_KEY in your shell, as the Agents SDK README says. The idea works the same with any model or SDK. If context windows are new to you, start with what a context window is, which shows one filling up turn by turn.
Context, in this course, means the tokens a model reads before it writes its next reply. Everything below is about which tokens those are and who put them there.
Follow one value from your code to the model
Pick one fact and watch where it travels. In the Agents SDK example below, the user's name and ID sit in a Python object that your code holds. The model learns the name only when it calls a tool that returns it.
The code is copied from the SDK's context management page, with its annotation markers removed. The comment under print is the output the docs show for it.
import asyncio
from dataclasses import dataclass
from agents import Agent, RunContextWrapper, Runner
from agents.decorators import tool
@dataclass
class UserInfo:
name: str
uid: int
@tool
async def fetch_user_age(wrapper: RunContextWrapper[UserInfo]) -> str:
"""Fetch the age of the user. Call this function to get user's age information."""
return f"The user {wrapper.context.name} is 47 years old"
async def main():
user_info = UserInfo(name="John", uid=123)
agent = Agent[UserInfo](
name="Assistant",
tools=[fetch_user_age],
)
result = await Runner.run(
starting_agent=agent,
input="What is the age of the user?",
context=user_info,
)
print(result.final_output)
# The user John is 47 years old.
if __name__ == "__main__":
asyncio.run(main())- Install the SDK with
pip install openai-agentsand exportOPENAI_API_KEY. - Save the example as
context_demo.pyand runpython context_demo.py. - Find
user_info. It goes toRunner.runascontext=, and the docs state that this object is not sent to the LLM. Your tools, hooks and callbacks read it throughRunContextWrapper. - Find where the name enters the model's view.
fetch_user_agereadswrapper.context.nameand returns a sentence, and that tool result joins the history the model reads on its next call.
What fills the context on each call
The SDK docs put the rule in one line: when the model is called, the only data it can see is the conversation history. A fact reaches it by one of four routes. It goes in the agent's instructions, in the input you pass to Runner.run, in the result of a function tool, or through retrieval and web search.
Instructions can be a function instead of a string. The snippet from the SDK's agents page writes the user's name into the system prompt on every call, which suits a fact the model always needs, such as a name or today's date. It uses a UserContext type of your own, like UserInfo above.
Anthropic's context engineering guide sorts the same material by kind: system prompts, tools, examples and message history, plus the files, tool results and notes an agent pulls in while it works. The table joins the two views.
from agents import Agent, RunContextWrapper
def dynamic_instructions(context: RunContextWrapper[UserContext], agent: Agent[UserContext]) -> str:
return f"The user's name is {context.context.name}. Help them with their questions."
agent = Agent[UserContext](
name="Triage agent",
instructions=dynamic_instructions,
)| Part of the context | Who adds it | How it changes during a run |
|---|---|---|
| System prompt (instructions) | You, as a string or a function | Fixed, or rebuilt from your data on each call |
| Tool definitions | You, and every MCP server you connect | Sent with every request, used or not |
| Examples | You, inside the prompt | Fixed unless you swap them per task |
| Message history | The user and the model | One more turn each round |
| Tool results, files and search results | Your tools, when the model calls them | Grow fastest, and stay in the history once added |
| Memory and notes | The agent, through a file or a memory tool | Read back when a step needs them |
Tool definitions fill the window before anyone types
Each tool's name, description and input schema travel with the request. Anthropic's advanced tool use post of 24 November 2025 added up five common MCP servers: 58 tools came to about 55K tokens before the conversation started. Jira alone adds about 17K more. Inside Anthropic, the post says, tool definitions had reached 134K tokens before the team optimized them.
For a task that touches only GitHub, the Slack tools are 21K tokens the model reads and never uses. The fixes come later in this path. Tools for AI agents covers fewer, larger tools, and just-in-time context covers loading a tool or a file only when a step calls for it. Start by counting what you send today.
Source: Anthropic Engineering: Introducing advanced tool use on the Claude Developer Platform (read November 6, 2026)
How it differs from prompt engineering
Prompt engineering is the work of writing and ordering instructions, mostly in the system prompt. Context engineering includes that and the rest of the request, and it never finishes. Anthropic's guide calls it iterative: the choosing happens again each time something is passed to the model.
The guide's working rule is to keep only tokens that carry signal for the outcome you want. For the system prompt, that means the right altitude: specific enough to steer, without hard-coded if-else rules for every case. For examples, a few varied, typical ones beat a long list of edge cases. For tools, the guide's test is blunt. If a human engineer can't say for sure which tool fits a situation, the agent won't do better.
Length brings its own problem. A model recalls information less accurately as its context grows, which context rot, the next lesson, measures. Compaction and notes in agent memory keep a long task going after the window fills. Neither helps a request that was badly chosen to begin with.
Tobi Lütke, Andrej Karpathy and Dex Horthy on owning the context
The name caught on in June 2025. Tobi Lütke, Shopify's chief executive, wrote on 19 June that he preferred context engineering to prompt engineering because it names the core skill better. Six days later Andrej Karpathy, a founding member of OpenAI, agreed and listed what goes in: task descriptions and explanations, few-shot examples, RAG, related data, tools, state and history, and compacting. Too little and the model lacks what it needs. Too much or too irrelevant, and costs can rise while performance falls.
Dex Horthy of HumanLayer had made the case earlier in 12-factor agents, a guide on GitHub that, by its own account, came out about two months before the term spread. Its third factor, own your context window, says the standard message format is optional. It packs the whole run into one user message of tagged events, so a resolved error can be dropped and a tool result trimmed to what the next step needs. The Agents SDK builds the messages for you. A loop you write yourself can take that route.
Anthropic posted its guide on X on 30 September 2025, pitched at developers who know prompt engineering and now build agents.
the art of providing all the context for the task to be plausibly solvable by the LLM

Screenshots of X's own embeds of the posts, taken on 5 and 6 November 2026, with the time in UTC. The Anthropic embed leaves out the link that ends the post. Select one to open the post on X.
Common mistakes
- Rewriting the system prompt again and again when the wrong answer comes from a stale tool result further down the history.
- Connecting every MCP server you use anywhere, so tool definitions crowd out the task.
- Assuming the model knows something because your code knows it. The SDK's
contextobject never reaches the model. - Returning a whole file or web page as a tool result when the step needs a few lines of it.
- Reading a bigger context window as permission to send more.
Try it yourself
- Remove
fetch_user_agefromtools=[...]and ask the same question. Where could the name come from now? - Give the agent the docs'
dynamic_instructions, typed forUserInfo, with no tool, and ask for the user's name. - Write down every part of one request your own agent sends, with a rough token count for each, and mark what the current step does not use.
Check yourself
In the Agents SDK example, how does the user's name reach the model?
Show answer
C. Through the result of the tool it calls The context object stays in your code, and the name enters the history only as the sentence fetch_user_age returns.
Which part of an agent's context goes with every request even when the step does not use it?
Show answer
A. Tool definitions Every connected tool's name, description and schema travel with each call, which is how 58 tools reached about 55K tokens.
What does Anthropic's guide tell you to aim for when you choose context?
Show answer
D. The smallest set of high-signal tokens that makes the result likely Its working rule is the smallest set of high-signal tokens that maximizes the likelihood of the outcome you want.
How does context engineering differ from prompt engineering?
Show answer
B. It chooses the whole request again on each call, not only the instructions Prompt engineering writes instructions, while context engineering curates everything the model sees each time it is called.
Frequently asked questions
What is context engineering in AI?
It is the part of building with a model that decides what the model reads before it answers. In a support agent, that means choosing which policy pages, earlier messages and account fields go into each call, and leaving the rest out.
Is context engineering just a new name for prompt engineering?
For a single chat prompt the two overlap, since instructions are most of what gets sent. An agent that calls tools turn after turn builds most of its input from tool results and history, which no prompt template controls.
Is RAG part of context engineering?
Yes, as one route in. Retrieval fetches documents that match a query and adds them to the request. Context engineering also decides the instructions, tools and history around them, and when to leave the retrieved text out. The RAG course on Mindket Learn builds the retrieval step.
How many tools should an AI agent have?
OpenAI's function-calling guide gives a soft number: aim for fewer than 20 functions available at the start of a turn. Anthropic's guide warns that a bloated tool set with overlapping jobs makes the choice ambiguous, and its advanced tool use post counts about 55K tokens for 58 tools. Keep the set small enough that a person could pick the right tool for each step.
Sources
- Anthropic Engineering: Effective context engineering for AI agents https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Anthropic Engineering: Introducing advanced tool use on the Claude Developer Platform https://www.anthropic.com/engineering/advanced-tool-use
- OpenAI API docs: Function calling https://developers.openai.com/api/docs/guides/function-calling
- OpenAI Agents SDK docs on GitHub: Context management https://github.com/openai/openai-agents-python/blob/main/docs/context.md
- OpenAI Agents SDK docs on GitHub: Agents (dynamic instructions) https://github.com/openai/openai-agents-python/blob/main/docs/agents.md
- GitHub: openai/openai-agents-python README https://github.com/openai/openai-agents-python
- GitHub: 12-factor agents, factor 3, own your context window https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-03-own-your-context-window.md
- X: Tobi Lütke on the term context engineering https://x.com/tobi/status/1935533422589399127
- X: Andrej Karpathy on context engineering https://x.com/karpathy/status/1937902205765607626
- X: Anthropic shares its context engineering guide https://x.com/AnthropicAI/status/1973098580060631341
- YouTube (AI Engineer): 12-Factor Agents, Dex Horthy, HumanLayer https://www.youtube.com/watch?v=8kMaTybvDUw


