Context

Context is the information an AI model can use for the request or workflow step it’s handling now. That includes the task, instructions, earlier messages, approved client records, examples, and information about its tools and their results.

The important part is what the model can actually see. Your renewal workflow can have access to the right file in storage and still send the model an expired rate, so keeping good records and choosing the right ones for the request are two separate jobs.

What counts as context?

Anything the model can use now is context, including instructions, the request, earlier messages still in the conversation, examples, retrieved passages, tool definitions, and tool results. Anthropic’s context-engineering guide defines it as the tokens included when a model produces an answer.

For a renewal proposal, the firm may store the signed agreement in Drive, current rates in a pricing system, account history in the CRM, and an approved proposal as an example. The application may be able to reach all of those, but they help the model only when the workflow selects them and puts the useful parts in the request.

OpenAI’s Agents SDK documentation separates information the application holds from information the model sees. A customer record, a logging tool, or permission data can stay in the application, while the model receives only the fields, passages, or tool results the application sends.

In a demo, someone often builds this packet by hand, opening the current file, pasting the relevant paragraphs, removing the old note, and explaining which price applies. That person did the selection work.

For the workflow to run without them, it needs a way to repeat that selection rather than depend on what they remember to paste.

Prompt, context, and context window

A prompt asks for the job. Context is the prompt plus the other material the model can use. A context window is the capacity for that material and the model’s answer.

For a renewal, “draft the proposal with the approved scope and current rate” is the prompt. Add the scope, rate, account notes, example, and tool results, and you have the context for that step.

That packet needs to fit inside the context window, with room for the answer the model will produce.

The large language model uses learned patterns to generate the answer, while context supplies the information for this client and this task. A stronger model may reason better over that material, but it still can’t read a record the application never sends.

Google’s token documentation says the context window covers input and output tokens, including system instructions, prompt text, history, cached content, tools, and generated output. A larger window gives the workflow more room, but it doesn’t decide which version of the scope or policy is current.

Context, memory, and retrieval

Memory is information saved outside the current request for later use. Retrieval-augmented generation searches outside sources and brings selected evidence into the request. Context is what the model can use after those steps.

Suppose a client approved short weekly reports and you save that preference for later, that’s memory. Searching the client record during the next reporting run is retrieval, and putting the approved preference beside the current metrics makes it context for that run.

Those parts can fail separately, memory can keep an outdated preference, retrieval can return the wrong client’s record, and context can contain both old and current instructions without showing which to trust.

Context engineering is how you select and maintain that information, deciding what enters, what stays out, what gets fetched later, and what carries over from an earlier step. Context is the information itself, while context engineering is the work of keeping the right information available.

Why can more context hurt the answer?

More input gives stale, repeated, or weak material more chances to compete with the fact that matters.

Chroma’s Context Rot report tested 18 models in July 2025 while keeping the task simple and increasing input length. Performance became less reliable in different ways across the models. The order, similarity, and structure of the information also changed the result.

OpenAI’s current model guidance reports that leaner system prompts improved evaluation scores by about 10 to 15 percent in an internal coding-agent sample. Total tokens fell by 41 to 66 percent and cost by 33 to 67 percent.

OpenAI calls those ranges directional and asks teams to test representative work. They’re results from that internal sample, not a saving or quality improvement you can assume for a business.

Long context doesn’t fail in one fixed way either. Google Research’s 2024 positional-attention study found that tested models paid more attention to the beginning and end of long input even when the relevant material was elsewhere.

Its method of adjusting that bias improved tested retrieval-augmented generation by up to 15 percentage points. But a separate 2025 Google study didn’t find the same lost-in-the-middle effect for simple fact retrieval with Gemini 2.5 Flash, including facts near the input limit.

So test the actual job rather than assume a document helps because it fits, or that every long packet fails. Keep the important source easy to identify and test cases where other plausible information sits beside the fact you need.

What makes context safe for client work?

The information needs to be relevant, current, approved, limited to the right client, and traceable to its source. I’d check each of those separately:

• Old facts: if last quarter’s rate sits beside the current one, name the source of truth and when its information expires.
• The wrong client’s information: filter by client and matter before retrieval, so another client’s notes don’t enter the packet.
• Unapproved rules: store the approval state with the document, so a draft policy doesn’t look final.
• Conflicting sources: send the disagreement to a named owner rather than silently choose one.
• Missing sources: record where the information used in the output came from.

Document the process first, because the workflow can’t select a rule that exists only in a manager’s head. Write it down with an owner and an approval state, so the system has both the rule and a way to tell whether it may use it.

The source of truth stays outside the model. Context carries a working copy into the step. When a price, scope, or policy changes, the workflow should fetch the current version instead of keeping yesterday’s copy in a long prompt.

How should a business test context?

Start with one repeated deliverable and five real cases. A renewal workflow might use an ordinary renewal, missing account notes, a recent scope change, two rate sheets that disagree, and a record from the wrong client with a similar name.

Score whether the workflow selected the right source, kept client scope intact, asked when facts were missing, exposed conflicts, and recorded what it used. These checks belong in an eval. Run the same cases when the prompt, source map, retrieval rule, tool, model, or workflow changes.

Get those cases to pass before trying to reduce token count. Then remove repeated instructions, stale examples, and irrelevant tool descriptions one group at a time, rerunning the same eval after each change.

You want the smallest packet that still handles ordinary work and the exceptions that would be expensive to get wrong.

Privacy needs its own check too, because context can contain client information. Retention, training, and access rules depend on the provider, product, account settings, and contract, so check the terms for the exact system before sending that data.

Where does context sit on the Delivery Model Ladder?

Context exists at every stage. It does its main delivery work at Stage 2, Augmented, on the Delivery Model Ladder.

At Stage 1, Enhanced, a person gathers records, pastes useful parts into a chat, checks the answer, and moves it into the next system. The AI improves one person’s work. The context still lives in that person’s judgment.

At Stage 2, a shared workflow retrieves current records, applies client scope, supplies written rules, sends conflicts to a named person, and records the source used. Context becomes part of the delivery system.

At Stage 3, AI-native, shared context is maintained across delivery instead of rebuilt for each task. That is part of what makes a service business AI-native. It also gives an AI employee ongoing access without unlimited authority.

Giving the model information doesn’t establish that the source is approved or that the answer is correct, and it can’t supply knowledge nobody recorded. Before the step goes into real work, list what it may trust, where each item comes from, when it expires, and what happens when sources disagree.