What are the six pillars of context engineering?

Calling context engineering a single discipline makes it sound simpler than it actually is in practice. It’s really a system built from several distinct, interdependent pieces, each responsible for a different part of getting the right information in front of a model at the right moment. Understanding these pieces individually, and more importantly how they depend on each other, is what turns context engineering from a vague principle into something an actual system can be built around.

What Are the Six Pieces, and Why Treat Them Separately?

The six pillars are agents, query augmentation, retrieval, prompting, memory, and tools. Each one answers a different question: agents decide what to do and orchestrate the rest; query augmentation refines what a person actually asked into something the rest of the system can act on; retrieval pulls relevant external knowledge into reach; prompting instructs the model on how to use what it’s been given; memory preserves continuity across time; and tools let the system act in the world rather than just reason about it.

Treating these as separate pieces rather than one undifferentiated blob matters because each one fails in its own distinct way, and a failure in one doesn’t announce itself the same way a failure in another does. A system that gets memory right but retrieval wrong looks different, and needs a different fix, than one that gets retrieval right but has weak prompting. Diagnosing and improving a system requires being able to point at which specific pillar is actually underperforming.

How Does an Agent Sit at the Center of All the Other Pillars?

An agent is both a user of context and an architect of it. It draws on retrieved knowledge, memory, and tool results to reason about a task, but it also actively decides what to retrieve, what to remember, and which tools to call in the first place. This dual role is why agents sit conceptually at the center of the other five pillars rather than alongside them as a seventh, equal piece: the agent is the thing making the moment-to-moment decisions about how the other five get used.

In a single-agent system, one agent handles this orchestration directly. In a multi-agent system, this responsibility gets distributed across several specialized agents, each handling a narrower slice of the overall context-management problem, but the underlying role, deciding what information flows where, remains the same regardless of how many agents are actually doing it.

Why Does Query Augmentation Matter Before Anything Else Can Work Well?

Query augmentation is the process of taking a person’s actual, often messy input and refining it into something the rest of the system can use effectively. Real requests rarely arrive as clean, complete sentences, they’re incomplete, ambiguous, or phrased in a way that works fine for a human listener but poorly for a retrieval system or a downstream tool call. No amount of sophisticated retrieval or careful prompting can compensate for a request the system fundamentally misunderstood at the very first step.

This is also where a subtler challenge shows up: different parts of a system need the same underlying request phrased differently. What works well as a natural-language question for an LLM to reason over isn’t necessarily the same shape a database query or a memory search needs. Query augmentation bridges that gap, translating one input into whatever form each downstream consumer actually requires.

How Do Retrieval, Prompting, and Tools Work Together as the Operational Layer?

Retrieval supplies external knowledge the model doesn’t already have, prompting instructs the model on exactly how to use whatever’s been supplied, and tools let the system reach beyond pure reasoning into actual real-world action. These three depend on each other in a strict chain: retrieval that pulls in irrelevant or noisy material wastes whatever careful prompting follows it, and even flawless prompting over perfect retrieval accomplishes nothing if the task actually requires an action, like checking a live record or submitting a request, that only a tool call can perform.

This chain also runs in reverse when something breaks. A confused or incorrect response is often first blamed on the model itself, when the real fault sits further upstream, in retrieval that surfaced the wrong material, or in a tool that returned an unexpected result the prompt never anticipated handling.

Where Does Memory Fit Relative to the Other Five Pillars?

Memory is what lets the other five pillars operate with continuity rather than starting fresh on every single call. Without it, an agent’s orchestration decisions, a query’s refinement, and a tool’s results all vanish the moment one call ends, forcing every subsequent call to rebuild that same understanding from nothing. Memory is what carries the value produced by the other pillars forward, rather than letting each call’s work evaporate the instant it’s produced.

This is exactly why the earlier chapters of this knowledge base focused so heavily on memory specifically, and why Weaviate Engram exists as a dedicated service for it: memory isn’t just one pillar among six of equal weight, it’s the pillar responsible for making everything else’s output durable rather than disposable.

How Does Weaviate Engram Function Within This Six-Pillar System?

Weaviate Engram provides the memory pillar specifically, while the other five pillars, agent orchestration, query augmentation, retrieval, prompting, and tool use, are typically handled by the surrounding application and agent framework built around it. Consider a financial-audit compliance assistant reviewing control evidence submitted by different departments, where all six pillars have to work together for the system to actually function:

from engram import EngramClient

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

client.memories.add(
    "The finance department has historically submitted incomplete evidence for the segregation-of-duties control, missing approval timestamps in two of the last three quarters.",
    properties={"control_id": "SOX-404-12"},
)

When an auditor later asks a vague question, “how’s finance doing on their controls,” the agent pillar has to recognize this needs refinement before anything useful can happen. Query augmentation turns that vague request into something specific enough to actually search for, and the retrieval pillar then pulls the relevant memory:

relevant_history = client.memories.search(
    query="What compliance issues has the finance department had with control evidence submissions?",
    properties={"control_id": "SOX-404-12"},
    retrieval_config=HybridRetrieval(limit=5),
)

Once retrieved, the prompting pillar shapes how the model uses this history, instructing it to flag a recurring pattern rather than treating each quarter’s submission as an isolated event, and the tools pillar might let the agent actually pull the current quarter’s submitted evidence from a document system to check whether the same gap has recurred. Memory, supplied here by Engram, is what makes the finance department’s history available to check against in the first place, rather than every audit period starting with no awareness of what came before. Each pillar contributes something the others structurally cannot, and the audit conversation only works as well as the weakest pillar in that particular chain.

Understanding these six pillars as distinct pieces clarifies what each one is responsible for. One distinction, though, deserves more direct treatment than a passing mention, since it’s commonly and understandably confused: the difference between context engineering as a whole and the narrower discipline of prompt engineering specifically. Our next chapter, What is the difference between context engineering and prompt engineering?, takes up exactly that distinction in more depth.