Short answer: Prompt engineering crafts instructions and wording. Context engineering decides the full set of material the model sees, of which the prompt is only one part.
A clever prompt still fails if the wrong memories, tools, or documents fill the window. Context engineering owns selection and assembly across all sources. Prompting sits inside that larger job, not beside it as the same discipline.
Of the six pillars covered in the last chapter, prompting is the one most people already have some intuition for, since crafting a good prompt is often the very first thing anyone does when working with a language model. That familiarity makes it tempting to assume prompting and context engineering are basically the same discipline wearing two different names. They’re not, and understanding exactly where the line falls between them clears up a genuinely common source of confusion.
What Does Prompt Engineering Actually Control?
Prompt engineering is about how instructions are phrased and structured to get the best possible output from whatever content is already sitting in the context window. This includes choosing clear wording, adding illustrative examples, asking the model to reason step by step, and structuring instructions so the model understands exactly what kind of output is expected. All of these techniques operate entirely on the instruction layer, refining how a request is communicated.
What prompt engineering does not control is which facts, documents, or history actually made it into the context window in the first place. A prompt can ask a model to synthesize an answer from the provided sources, but it has no ability to conjure sources that were never supplied. The technique governs interpretation of what’s there, not the presence of what’s there.
What Does Context Engineering Control That Prompt Engineering Cannot?
Context engineering is the broader discipline of deciding what actually gets fed into the model at all, retrieved documents, memory, tool results, and the live conversation, before any question of phrasing even becomes relevant. It’s the architecture surrounding the model, not the specific wording used to instruct it. A well-engineered context supplies the model with exactly the right material for a given task; prompt engineering then determines how effectively the model is instructed to use that material.
This is why context engineering is properly understood as the larger container, with prompt engineering as one specific technique operating inside it, rather than the two being separate, equally-scoped disciplines competing for the same territory.
Why Can’t a Clever Prompt Compensate for Missing or Wrong Context?
No instruction, however carefully worded, can supply information that was never included in the first place. Asking a model to “answer using only the provided context” is a genuinely useful prompting technique for reducing hallucination, but it only works if the provided context actually contains what’s needed to answer correctly. If the retrieval step upstream failed to surface the relevant fact, the most sophisticated prompt in the world produces either a confident wrong answer or an unhelpful refusal, neither of which the prompt itself is capable of fixing.
This dependency runs in only one direction. Good context with a mediocre prompt often still produces a usable answer, since the model has real material to work with even if the instructions asking it to use that material aren’t especially polished. A brilliant prompt paired with missing or irrelevant context has nothing to salvage, no matter how well it’s written.
Does This Mean Prompt Engineering Doesn’t Matter Once Context Is Handled Well?
It still matters, just as a distinct and later concern. Even genuinely well-assembled context can be squandered by unclear instructions: a model handed exactly the right retrieved facts can still misuse them if it isn’t told clearly whether to summarize, extract, compare, or answer strictly from what’s given. Prompting is the final layer that determines whether good context actually gets converted into a good response, which is precisely why it belongs inside the broader context-engineering discipline rather than being dismissed as secondary to it.
The practical implication is sequencing, not priority. Getting context right has to happen before prompting can do useful work, but once context is right, careful prompting is what actually realizes its value in the final response.
How Does Weaviate Engram Fit Into This Distinction?
Weaviate Engram operates entirely on the context side of this line, supplying the retrieved, reconciled memory that becomes part of what a prompt then instructs the model to use. Engram has no role in how a prompt is phrased, that decision belongs to the application built around it. Consider an immigration paperwork assistant helping applicants prepare visa documentation, where getting both context and prompting right matters for a genuinely high-stakes task:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"Applicant's previous visa was denied due to insufficient proof of ties to their home country; this time they've gathered a property deed and an employment continuation letter to address that specific concern.",
user_id="applicant-7734",
)
This memory is retrieved and placed into context ahead of a new request:
relevant_history = client.memories.search(
query="What issues came up with this applicant's previous visa application?",
user_id="applicant-7734",
retrieval_config=HybridRetrieval(limit=5),
)
Retrieving this memory is entirely a context-engineering decision, made before any prompt is written. What happens next is where prompt engineering takes over: the application’s prompt might instruct the model to specifically verify that the applicant’s new documentation directly addresses the prior denial reason, rather than just generically reviewing the new paperwork in isolation. A poorly phrased prompt, even with this exact context supplied, might miss that connection entirely and just summarize the new documents without checking them against what actually caused the earlier rejection. A well-phrased prompt working from the same context catches precisely the connection that matters most for this applicant. Neither the context nor the prompt alone would have produced that careful, connected review, each pillar contributed something the other structurally could not.
Context engineering and prompt engineering describe two different layers of getting a model to behave well. There’s a third, closely related distinction worth drawing out just as carefully: how context engineering as a whole discipline relates to memory engineering specifically, given that memory is only one of the six pillars covered so far. Our next chapter, What is the difference between context engineering and memory engineering?, takes up exactly that distinction.