Context engineering

Context engineering is the work of building a small, current job packet for an AI task. The packet can include the request, the relevant record, written rules, a useful example, allowed tools, and decisions carried from earlier steps. The goal is not to send everything the firm owns. Chroma tested 18 language models in July 2025 and found that performance became less reliable as inputs grew, even on controlled tasks. A 2023 long-context study found that adding 50 documents instead of 20 improved open-domain answers by only about 1% to 1.5% for two tested models. For a service firm, context engineering means choosing what the model needs, removing stale or conflicting material, and testing whether the finished workflow 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.

Take “draft a renewal proposal.” That sentence is the prompt. The AI still needs the current client record, approved rates, the firm’s proposal pattern, rules for public claims, and access to the source documents behind the account history. It also needs a clear path for missing facts. If the answer depends on an unknown renewal date, the system should ask instead of guess.

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 cannot recover a renewal date that lives only in an inbox. It cannot tell which of two rate sheets is current unless the firm marks one as authoritative. The instruction matters. The operating information sets its ceiling.

What belongs in the job packet?

A useful packet carries only what this piece of work needs. Five parts cover most service tasks.

Part	Proposal example	Failure when missing
Current task and record	Renewal goal, client status, dates, open issues	The proposal solves the wrong problem or uses old facts
Written rules	Approved rates, claims policy, required sections	The draft breaks a house rule nobody stated
Strong example	One accepted proposal with notes on why it worked	The output copies a generic pattern
Allowed tools	CRM read, document search, pricing lookup	The AI guesses instead of checking the source
Decision history	Scope choices, rejected options, unresolved questions	The work reopens settled choices or repeats a dead end

These parts do not need to live in one document. A short instruction can point to an approved rate table. 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 shows the same pattern at a much larger scale. The agent works across more than 3,500 internal users, 600 petabytes of data, and 70,000 datasets. Its context includes table usage, notes from people, meaning inferred from code, institutional knowledge, memory, and runtime information. That scale is unusual. The design lesson is familiar: a schema gives a field a name, while a person or code may still need to explain what the field means and when it is 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 “Lost in the Middle” paper found a related problem. Models often used relevant information best when it appeared near the start or end of a long input. Performance fell when the same information 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.

Selection is the operating answer. Ten current client records can help. Ten current records mixed with ninety old exports can bury the answer among plausible distractors. A large window creates room. Context engineering decides what earns that room.

This is why “upload the whole drive” is a poor production plan. Duplicate policies can disagree. Old examples can teach a retired format. A long tool result can crowd out the goal. An invented fact from an earlier step can survive into later work and look like established history.

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 hybrid approach. Some information arrives at the start, while the agent uses search or other tools to retrieve detail as needed. For long tasks, Anthropic recommends shortening context and keeping structured notes. Preserve decisions, unresolved issues, and current state. Drop 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 split applies outside software. A delivery agent needs the firm’s review rules from the start. It can fetch a client record when it reaches the client-specific step. If two records disagree, the conflict belongs in the packet as unresolved. Quietly choosing one turns a source problem into a polished business error.

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.

Each part has a different failure. Retrieval can return the wrong document. Memory can preserve an outdated choice. A skill can carry an old procedure. A tool can expose overlapping actions that confuse the agent. OpenAI says its data agent became more reliable after the team restricted and combined tools with overlapping functions. Adding another source or tool helps only when the system knows when to use it.

Who owns context engineering?

The process owner owns what is true and which exceptions matter. The implementation owner makes that knowledge available to the AI, records what the system used, and maintains the tests. Neither role can do the whole job alone.

Start with one repeated deliverable, such as a weekly client status report. 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 the cases whenever the prompt, source map, tool, model, or workflow changes.

The source map needs maintenance. A price change updates the rate source. A new service changes the example set. A recurring mistake becomes an eval case. A policy change removes the retired rule instead of leaving both versions available.

Context engineering becomes operating work here. In a franchise network’s delivery data, managers often carry the judgment half of their role in memory after tracking work is automated. The firm has not turned that judgment into a record another person or system can use. Context engineering can select written knowledge. It cannot select knowledge nobody wrote down in a usable form.

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 the firm has a source of truth and someone owns the process end to end. Context engineering cannot recover judgment nobody documented, reconcile records nobody maintains, or make an uncheckable high-consequence task safe. If a capable new employee could not find the current rule, record, example, and exception path, the AI cannot either.