What is context engineering?

The previous Part worked out, in careful detail, what memory is made of, the different shapes information can take and how each one should be stored. None of that answers a separate, equally practical question: at any given moment, while a model is actually generating a response, what should be sitting in front of it. Having a well-organized memory store doesn’t automatically mean the right pieces of it end up where the model can see them at the right time. That’s the discipline this new Part is about, and it has a name: context engineering.

What Does Context Engineering Actually Mean?

Context engineering is the discipline of deciding, for every single call made to a model, exactly what information gets placed into its context window, in what form, and in what order. A context window is finite, so every one of these decisions is really a decision about what to leave out just as much as what to include. Context engineering treats that window as a scarce resource that has to be actively managed, rather than a bucket that can simply be filled with everything potentially relevant and left for the model to sort through.

This framing matters because it shifts the central question away from “how do we get the model more information” and toward “how do we get the model exactly the information it needs for this specific step, and nothing that will crowd that out.” Those are very different design problems, and only the second one scales to systems that run for a long time or handle complex, multi-step tasks.

How Is Context Engineering Different From Prompt Engineering?

Prompt engineering is about how instructions are phrased, choosing wording, structure, and technique to get better output from whatever content is already in the context window. Context engineering is about what actually ends up in that window in the first place, deciding which facts, which retrieved documents, which prior conversation history, and which tool results get included before any phrasing decision even comes into play.

The two disciplines aren’t competitors, they operate on different layers of the same problem. A beautifully phrased prompt built on top of the wrong context still produces a wrong or ungrounded answer, because no amount of clever wording can supply information that was never made available in the first place. Conversely, perfectly assembled context wasted by vague or confusing instructions won’t be used well either. Getting one right without the other still produces a system that underperforms.

How Is Context Engineering Different From Memory?

Memory, as covered throughout the previous Part, is about what gets stored and how it’s organized once it’s persisted outside the model. Context engineering is about the separate, downstream decision of which of those stored things actually get pulled into a specific call’s context window right now, and how they get combined with everything else that call needs, retrieved documents, tool outputs, system instructions, and the live conversation itself.

Memory answers “what do we know and how is it kept current.” Context engineering answers “given everything we could possibly include, what should this particular call actually see.” A system can have excellent, well-organized memory and still perform poorly if the context engineering layer sitting on top of it makes poor decisions about what to surface, in what quantity, and in what order.

Why Can’t Simply Using a Bigger Context Window Replace This Discipline Entirely?

A bigger window raises the ceiling on how much could theoretically be included, but it doesn’t solve the underlying problem, because model performance doesn’t scale cleanly with window size. Long, cluttered context tends to degrade a model’s ability to reason accurately over everything within it, an effect that shows up regardless of how technically large the window’s stated limit is. Beyond that, every additional token included costs something in latency and expense, paid again on every single call, whether or not that token turned out to matter for the response actually produced.

This means the temptation to just include more, reasoning that a bigger window makes careful curation unnecessary, actively works against the goal rather than sidestepping it. A context window overflowing with tangentially related material isn’t a safety net, it’s a liability that dilutes the signal the model actually needs to reason well.

How Does Weaviate Engram Fit Into a Context-Engineering Approach?

Weaviate Engram is the memory layer this Part builds on top of, the source of well-organized, reconciled facts, but context engineering is the separate discipline of deciding how much of what Engram stores actually gets surfaced for any specific call. Consider a scientific literature-review assistant helping a researcher track findings across dozens of papers on a narrow topic, where the underlying memory store might hold far more than any single question needs:

from engram import EngramClient

client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])

client.memories.add(
    "This researcher is focused on CRISPR delivery mechanisms for neurological tissue; particularly skeptical of lipid nanoparticle approaches due to blood-brain barrier concerns raised in three papers reviewed so far.",
    user_id="researcher-5510",
)

Over months of use, this researcher’s memory accumulates dozens of similar facts, spanning different subtopics, methodologies, and papers reviewed along the way. A context-engineering-aware retrieval step doesn’t simply dump everything stored for this researcher into every new call, it retrieves only what’s relevant to the current question:

relevant_context = client.memories.search(
    query="What has this researcher already concluded about viral vector delivery methods?",
    user_id="researcher-5510",
    retrieval_config=HybridRetrieval(limit=5),
)

Limiting the search to a handful of the most relevant memories, rather than retrieving everything ever stored about this researcher, is itself a context-engineering decision, made independently of how the memory was stored or organized in the first place. Engram’s search API supplies the raw material, well-organized and reconciled, but deciding how much of it belongs in this specific call, and combining it correctly with whatever else that call needs, is the layer of judgment this new Part is entirely about.

Context engineering, as a discipline, is built from several distinct, interdependent pieces working together rather than one single technique. Our next chapter, What are the six pillars of context engineering?, breaks that discipline down into its component parts.