Context engineering

Context engineering is the work of giving AI the information it needs for the job it’s doing now. Think of a small, current job packet, with the request, relevant records, written rules, a useful example, allowed tools, and decisions from earlier steps.

You don’t need to send everything the firm owns. You need to choose what matters for this task, remove stale material, make conflicts visible, and check whether the workflow actually uses the right facts.

Context engineering and prompt engineering

Prompt engineering writes the request. Context engineering manages everything the AI can use around that request.

“Draft a renewal proposal” is the prompt, but the AI still needs the current client record, approved rates, the firm’s proposal format, rules for public claims, and source documents behind the account history. It also needs to know what to do with a missing fact, so if the renewal date is unknown, it asks rather than guesses.

Anthropic’s September 2025 definition includes system instructions, tools, external data, and message history in context. The prompt says what to do. Context engineering decides what the AI can see, which sources it can fetch, what it should carry from earlier steps, and what should be removed before the next step.

A careful prompt can’t recover a renewal date from an inbox the system can’t reach, or settle which of two rate sheets to trust when the firm hasn’t made that clear. Better wording helps, but you still have to supply the information the job needs.

What belongs in the job packet?

For a proposal, I’d check five parts of the packet:

• The current task and record: the renewal goal, client status, dates, and open issues, so the proposal doesn’t solve the wrong problem with old facts.
• Written rules: approved rates, claims policy, and required sections, so the model knows the standards the draft has to meet.
• A useful example: one accepted proposal with notes on why it worked, rather than leaving the model to copy a generic format.
• Allowed tools: ways to read the CRM, search documents, and look up pricing, so missing facts can be checked rather than guessed.
• Decision history: scope choices, rejected options, and unresolved questions, so the work doesn’t reopen a settled choice or repeat a failed approach.

These parts don’t need to live in one document, a short instruction can point to the approved rate table and a tool can fetch current CRM fields when the task starts. A saved note can carry decisions from an earlier review without copying the whole transcript.

OpenAI’s January 2026 account of its internal data agent describes this at a much larger scale, with more than 3,500 internal users, 600 petabytes of data, and 70,000 datasets. Its context includes how tables are used, notes from people, meaning inferred from code, company knowledge, memory, and information from the current run.

Your firm doesn’t need that scale for the distinction to matter. A field name tells the model what the field is called, but someone or something still needs to explain what it means and when it’s safe to use.

Why does more context sometimes make work worse?

A context window sets how much information a model can receive. It does not promise that the model will use every part equally well.

Chroma’s July 14, 2025 Context Rot report evaluated 18 models, including GPT-4.1, Claude 4, Gemini 2.5, and Qwen3 models. Performance became less reliable as input length increased, even when the tasks stayed simple. The report also found that structure, similarity, and placement changed model behavior.

The earlier 2023 “Lost in the Middle” paper found that tested models often used relevant information best near the start or end of a long input, and did worse when it sat in the middle.

In one open-domain question-answering test, increasing retrieval from 20 documents to 50 improved results by about 1.5% for GPT-3.5-Turbo and about 1% for Claude 1.3. Those results belong to the models and tasks tested, not every long-context model you might use today.

So I’d focus on selection before adding more material. Ten current client records can help, while mixing them with ninety old exports can bury the answer among things that look just as plausible.

That’s why I wouldn’t make “upload the whole drive” the plan for production. Duplicate policies can disagree, old examples can teach a retired format, and a long tool result can push the goal out of the working context.

An invented fact from an earlier step can also survive into later work and start looking like established history, so keep track of where carried-forward information came from.

What loads first, and what gets fetched later?

Stable rules should be available before work starts. Live facts should be fetched close to the step that uses them.

A proposal agent can load the output format, tone rules, claims policy, approval path, and tool descriptions at the start. It should retrieve current client status, today’s rate table, active scope, and recent delivery notes at run time. That split reduces the chance that a saved prompt carries last quarter’s facts into today’s work.

Anthropic describes a mixed approach, loading some information at the start and letting the agent search for more detail when it needs it. For long tasks, it recommends shortening context and keeping structured notes, preserving decisions, unresolved issues, and the current state while dropping repeated tool output and stale conversation.

OpenAI’s February 2026 harness-engineering account calls this “progressive disclosure.” Agents begin with a small, stable map and learn where to find deeper material. OpenAI reports that one large instruction file crowded out the task and relevant documents in its agent-first engineering environment. A map worked better than a manual.

The same approach works outside software, a delivery agent needs the firm’s review rules from the start but can fetch the client record when it reaches that step. If two records disagree, keep the conflict visible as unresolved rather than quietly choose one and turn it into a confident answer.

Context, retrieval, memory, skills, and tools

Context is everything available to the model for the current step. The other terms describe ways information reaches that context.

• Retrieval searches outside sources and brings back relevant evidence.
• Memory saves information from earlier work and makes it available later.
• A skill packages reusable instructions, examples, or scripts for a kind of task.
• A tool lets the AI fetch information or take an action.
• The context window is the capacity around what the model can consider at once.

Context engineering coordinates these parts. It decides whether a policy loads now, a client fact is retrieved later, an old decision stays in memory, a skill applies to this task, and a noisy tool result gets removed before the next step.

These parts can fail in different ways, retrieval can return the wrong document, memory can keep an outdated choice, and a skill can carry an old procedure. Tools with overlapping actions can also leave the agent unsure which one to use.

OpenAI says its data agent became more reliable after the team restricted and combined tools with overlapping functions. So before adding another source or tool, decide when the system should use it.

Who owns context engineering?

The person who owns the process decides which sources and rules to trust and which exceptions matter. The person building the system makes that knowledge available to the AI, records what it used, and keeps the tests current, so they need to work together.

Start with one repeated deliverable, such as a weekly client status report, and pick five real examples, an ordinary week, missing data, a scope change, a client at risk, and two source systems that disagree.

For each case, list the source of truth, required rules, allowed tools, approval point, and expected output. Run those cases whenever the prompt, source map, tool, model, or workflow changes.

That list of sources needs maintenance as the work changes. Update the rate source when prices change, add examples for a new service, turn a recurring mistake into an eval case, and remove retired policies rather than leave both versions for the model to choose from.

In the franchise network’s delivery data I review, managers often still carry the judgment half of their role in memory after tracking work is automated. The firm hasn’t turned that judgment into a record another person or system can use.

That’s where this becomes work for the firm, because context engineering can select written knowledge, but it can’t select a rule nobody recorded.

Where does it sit on the Delivery Model Ladder?

Context engineering belongs mainly at Stage 2, Augmented, on the Delivery Model Ladder. The workflow assembles the right records, rules, examples, and tools for a defined piece of delivery. A person handles named exceptions instead of rebuilding the packet by hand every time.

At Stage 1, Enhanced, a person copies client facts into a chat and pastes the answer into another system. That can improve individual output, but the context lives in personal judgment. At Stage 3, AI-native, the system retrieves current information, keeps decision history, removes stale material, records sources, and tests changes across delivery.

That progression is part of staffing an AI employee. The role needs more than a model and a trigger. It needs a maintained view of the firm that is narrow enough for the current job and current enough to trust.

This assumes your firm has sources it can trust and someone who owns the whole process. If a capable new employee can’t find the current rule, record, example, and way to handle an exception, sort out that information before expecting AI to use it reliably.

Better context also doesn’t make a high-consequence task safe when you have no way to check the result.