MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

An assistant preparing a client briefing does not need every document the company has ever stored. It needs the right account, the current objective, relevant evidence and the rules governing its work. Context engineering is the practical task of deciding what information should be available at each step, and keeping that information useful as the task develops.

The term can sound more specialized than the problem. A person joining a project also needs a concise brief, reliable records and a clear assignment. Giving them an enormous unorganized folder is not the same as giving them useful context. An AI application needs deliberate information selection too, with different technical constraints and failure modes.

Begin with the task’s evidence needs

Suppose a fictional customer-success manager requests a renewal-risk briefing. The assistant may need the renewal date, recent support incidents, agreed success criteria and the latest account notes. It probably does not need the full history of every marketing campaign sent to the customer.

List the decisions the briefing must support. For each, identify the evidence required and the authoritative source. This turns context selection into a task-specific design exercise. “Include all customer information” is a weak requirement because it neither prioritizes relevant facts nor tells the system how to handle conflicts.

Anthropic’s context-engineering guidance describes context as the information available during model inference and emphasizes curating it. The business implication is straightforward: context quality depends on relevance and organization, not merely on the volume an application can pass to a model.

Separate instructions from evidence

The application’s operating instructions should be distinguishable from customer emails, search results and document text. A support ticket may contain requests from a customer, but that does not give its contents authority to change the assistant’s access rules or task scope.

Make provenance visible. A structured tool result can identify the system, record and timestamp associated with a fact. A retrieved passage can carry a document title and location. A user instruction can remain explicitly labeled as such. This helps both the agent and the reviewing human understand why a piece of information is present.

OWASP’s prompt-injection guidance addresses the risk of external content influencing model behavior. Clear separation is one part of a defensive design, not a complete solution. Application-enforced permissions remain necessary even when the context is neatly organized.

Retrieve details when they become relevant

A renewal briefing can start with a compact account summary and stable identifiers for deeper lookups. If a recent incident appears important, the assistant can fetch the relevant ticket history. This avoids putting every possible detail into the initial request while preserving a path to the underlying evidence.

The tradeoff is additional retrieval work. A system that fetches too little may repeatedly search for basic facts or miss an important pattern. A system that fetches too much may bury the useful information. Compare these approaches using representative tasks rather than assuming that smaller context is always better.

The OpenAI retrieval guide documents searching indexed data and returning relevant chunks with source information. Those mechanisms can support selective evidence gathering. They do not decide which account facts a renewal manager considers material; that judgment must be reflected in the task design.

Summarize completed work without erasing uncertainty

As a task grows, the application may need to condense earlier material. A useful summary records what was established, which sources support it and what remains unresolved. A polished narrative that removes contradictions can make the next step worse by hiding the very issue that needs attention.

For the account example, preserve the difference between “support says the incident is resolved” and “the customer confirmed the incident is resolved.” Preserve pending approvals and failed lookups. If the assistant could not access the contract, the summary should not imply that contractual terms were reviewed.

Keep references to detailed artifacts rather than copying every artifact into every step. A later stage can retrieve the original when necessary. This design also helps a human reviewer inspect the basis for a recommendation instead of relying on a compressed account of the evidence.

Avoid accidental context inheritance

A reusable agent may work on several customers, projects or users. Decide what information can carry between tasks. General operating instructions may be shared; confidential account details should remain scoped. A convenience feature that reuses a prior conversation can create a cross-task disclosure if identity and project boundaries are weak.

Review the context assembled at the start of a run, not just the prompt template. Tool results, saved summaries, retrieved documents and remembered preferences may all add information. The effective context can differ substantially from the instruction text an engineer sees in a configuration file.

Run a context-quality review

• Relevance: does each major item support a decision in the current task?
• Authority: can the system distinguish operating instructions from source content?
• Provenance: are important claims connected to identifiable sources?
• Freshness: are time-sensitive facts current enough for the proposed action?
• Coverage: which important facts are absent or inaccessible?
• Isolation: does any information belong to another user or project?

Use failed examples to improve this review. If the assistant repeatedly misses a contract condition, determine whether the condition was omitted, buried or misinterpreted. Those are different problems with different remedies. Adding another emphatic instruction may not address any of them.

Make the result measurable

Test context changes against the same tasks and acceptance criteria. Track missing evidence, unsupported claims and unnecessary retrieval, alongside latency and cost. A smaller request is only an improvement if it still supports the work reliably.

Context engineering is an ongoing editorial and systems discipline. Someone must decide what matters, preserve where it came from and remove what no longer belongs. That work makes an agent easier to steer and easier to review, without pretending that a large context window can replace a clear objective or a trustworthy source.

Sources and further reading

Anthropic: Effective context engineering for AI agents. Context curation concepts; published September 2025.

OWASP: Prompt Injection. External-content trust risks; 2025 edition checked October 2026.

OpenAI: Retrieval. Selective retrieval and source-bearing results; checked October 2026.