KS Knowledge Sidekickknowledge for agentic AI
Engineering discipline

Context engineering: designing what the agent sees

Context windows are a knowledge-delivery problem. The agent only knows what you put in front of it for this turn, in this order, with this structure. Context engineering is the discipline of choosing that slice deliberately instead of hoping the model makes sense of whatever you dump in.

Back to home · Contact

Direct answer

What is context engineering?

Context engineering is the practice of deliberately designing what an agent sees in its context window: which facts, which instructions, which state, which examples, and in what order and structure. The context window is the agent's working knowledge for that turn, so the choice of what goes in it is a knowledge decision, not a formatting preference. Good context engineering tends to mean better behavior, lower cost, and fewer confident mistakes than "put everything in and hope."

Why context is the place where knowledge meets action

The model reasons. The context is what it reasons over.

For a given turn, an agent does not reach back into the entire universe of things it could know. It works with what is in its context: the prompt, the retrieved knowledge, the current state, the prior turns, the instructions, and the examples. That working set is the agent's reality for that decision.

This is why context is where the knowledge layer becomes practical. A knowledge system can be well-organized and still fail if the slice you hand the agent is wrong: missing the one fact that matters, burying it under ten pages of less relevant text, or presenting it in an order that leads the agent to focus on the wrong thing first.

Context engineering is the bridge between "we have knowledge" and "the agent can act on it for this task."

A simple way to see it

A useful mental model is a pipeline with four stages. Each stage is a place where knowledge can be improved or lost.

Knowledge sources
(corporate docs, tools, state, memory, user input)
   |
   v
[ Select ]  ->  which knowledge is relevant for THIS task
   |
   v
[ Shape ]   ->  ordering, chunking, summaries, structure
   |
   v
[ Scope ]   ->  permissions, privacy, what is allowed in
   |
   v
Context window  ->  what the agent actually sees this turn

The four verbs are the point. Select is about relevance: not everything in the knowledge layer belongs in this turn's context. Shape is about presentation: how the knowledge is arranged so the agent can use it. Scope is about permission and privacy: what is allowed in, especially for personal or sensitive knowledge. The context window is the result, not the starting point.

Patterns worth knowing

These are recurring ways teams engineer context. They are not a standard; they are common patterns worth recognizing.

Relevance-first retrieval

Put the most relevant knowledge in first, not all of it in random order.

Problem
A large body of knowledge is available, but most of it is irrelevant to this turn.
Pattern
Retrieve and rank by relevance, then place the most decision-relevant items nearest the point of use. Keep the rest out unless it is needed.
When
When the knowledge base is larger than the context you can afford and the task is focused.

Structured context layout

Arrange context into labeled parts so the agent can find what it needs.

Problem
A flat wall of text makes it easy for the agent to miss the one fact that matters.
Pattern
Separate instructions, current state, retrieved knowledge, and examples into clearly labeled sections. Use structure to signal importance, not just volume.
When
Whenever the context mixes different kinds of information.

Slicing by task, not by source

Build context around the task, not around where the knowledge happens to live.

Problem
Pulling "everything from the wiki" or "everything from the ticket system" produces too much of the wrong thing.
Pattern
Start from the task and decide what knowledge it needs, then pull from whichever source holds it. The source is secondary to the need.
When
When multiple sources are relevant and a source-first pull would be noisy.

Explicit scoping and redaction

Do not put knowledge into context unless the agent is allowed to see it for this task.

Problem
A retrieval system returns knowledge that is technically findable but not appropriate for this user, this agent, or this task.
Pattern
Apply permission and privacy scoping before content reaches the context window. Redact or exclude what should not be there, especially for personal or sensitive knowledge.
When
Whenever knowledge is sensitive, user-specific, or subject to access rules.

Context budgeting

Treat context as a budget, not a hobby.

Problem
Long contexts raise cost and can dilute signal, but teams often treat the window as something to fill.
Pattern
Decide what the task actually needs, measure the cost of what you include, and prefer the smaller context that still answers the task well.
When
Whenever cost, latency, or signal quality matter.

Anti-patterns

  • Dump everything and pray. If you put all available knowledge in, the relevant fact is still there, but it is harder to use and more expensive to process.
  • Context as storage. The context window is not the place to keep knowledge for later. It is the place to present the knowledge needed now. Long-term knowledge belongs in the knowledge layer, not in the prompt.
  • Ordering as an afterthought. The order in which knowledge arrives matters. Leading with the wrong thing can set the agent's attention in the wrong direction.
  • Ignoring scope until it is a problem. Permission and privacy scoping added late is usually awkward. Scoping is a design decision, not a patch.

Where to go next

Frequently asked questions

Context engineering is the practice of deliberately designing what an agent sees in its context: which facts, which instructions, which state, which examples, and in what order and structure. The context window is the agent's working knowledge for that turn, so the choice of what goes in it is a knowledge decision, not a formatting preference.

Because the context window is where the agent gets the knowledge it acts on for that turn. If the right knowledge is missing, buried, or arranged badly, the agent will reason over the wrong thing. Ordering, chunking, scoping, and prioritizing are knowledge problems: they determine which knowledge the agent actually has in front of it.

No. More context is not the same as better context. A longer context can bury the relevant fact, increase noise, and raise cost. The job is usually to get the right knowledge in front of the agent, not to fill the window. In many cases a smaller, better-chosen context outperforms a larger, less-curated one.

The knowledge layer is where the system knows what is true, current, owned, and allowed. Context engineering is how that knowledge is delivered to the agent for a given task. A strong knowledge layer gives you something worth putting in context. Context engineering is the discipline of putting the right slice of it in front of the agent at the right time.

Sources and further reading

  1. Retrieval-Augmented Generation for Large Language Models: A Survey — surveys retrieval, generation, and augmentation in RA-LLMs, including iterative and adaptive retrieval patterns relevant to context construction. arxiv.org/abs/2312.10997
  2. Cost-Aware Query Routing in RAG: Empirical Analysis of Retrieval Depth Tradeoffs — discusses the tradeoff between retrieval depth, token cost, and quality, which is the cost face of context engineering. arxiv.org/abs/2606.02581
  3. Cost-Aware Retrieval-Augmentation Reasoning Models with Adaptive Retrieval Depth — discusses token latency and the cost of generated vs. retrieved tokens in retrieval-augmented reasoning. arxiv.org/abs/2510.15719