Context Engineering vs Fine-Tuning
The choice between them is one of the most consequential in building an AI system, and it is often framed as a competition when it is really a division of labor. The two techniques answer different questions. Context engineering answers what should the model know for this specific request, and it answers it fresh every time by building the window. Fine-tuning answers how should the model behave in general, and it answers it once by adjusting the weights so the behavior is intrinsic. Confusing the two, trying to fine-tune in knowledge that changes, or trying to prompt in a behavior that needs to be reliable on every call, is the source of much wasted effort, so the first job is to see clearly which layer a given need belongs to.
What Each One Actually Changes
Context engineering operates entirely at inference time and leaves the model untouched. On each request it assembles the system instructions, retrieved knowledge, memory, and tool results into the window, so the model has what it needs for that call, and on the next request it assembles a different window. Nothing about the model changes, only its input does, which means the knowledge you supply is as current as your data and can differ per user and per request. This is the mechanism described across the context engineering guide, and its defining property is that the model's knowledge for a request is a runtime decision, not a fixed property.
Fine-tuning changes the weights themselves by continuing the model's training on a curated dataset of examples. The result is a modified model that has internalized whatever the examples demonstrated, a tone, a format, a domain style, a way of structuring answers, so that it produces that behavior by default without being told each time. The change is baked in and static: the fine-tuned model carries the behavior everywhere, but it also carries whatever the training data taught as of when you trained, and updating it means training again. Fine-tuning shifts effort to a training phase up front in exchange for a model that behaves the way you want without spending window space on instructions.
Context engineering changes the model's input at runtime and leaves the weights alone, so the knowledge is current and per-request. Fine-tuning changes the weights through training, so a behavior becomes intrinsic and default. One adjusts what the model sees, the other adjusts what the model is.
When to Use Context Engineering
Reach for context engineering whenever the thing you need to supply is knowledge, especially knowledge that changes. Facts about your products, your policies, your users, and your live data all belong in the window, because they update constantly and the model must ground its answers on the current version rather than a snapshot frozen into weights. Anything that must be accurate and current, a price, an inventory count, a user's latest preference, is a context problem, because fine-tuning would encode a value that is stale the moment the data moves. Context is also the answer when behavior must vary per user or per request, since the window can carry different facts for different callers while the weights cannot.
Context engineering also wins on iteration speed and cost of change. Adjusting what enters the window is a code and data change you can ship in minutes, while fine-tuning is a training run with data preparation, evaluation, and deployment behind it. When requirements are still moving, which they almost always are early on, the ability to change behavior by changing the prompt and the retrieval rather than by retraining is a large practical advantage. This is why the standard advice is to exhaust context engineering first: it is faster to build, cheaper to change, and it handles the large category of needs that come down to giving the model the right information. The related comparison in context engineering vs RAG covers how retrieval fits within this runtime approach.
When to Use Fine-Tuning
Fine-tuning earns its cost when you need a fixed behavior, format, or style applied reliably on every call, and prompting for it is either unreliable or too expensive in tokens. If a model must always output a specific structured format, always adopt a particular voice, or always follow a domain convention that takes many instructions and examples to describe, fine-tuning can bake that in so it happens by default, freeing the window and improving consistency. It also helps when a task requires a skill the base model performs poorly and no amount of context reliably fixes, such as a specialized classification or a narrow generation task where training on many examples raises the floor in a way instructions cannot.
The economics can favor fine-tuning at scale. Instructions and few-shot examples that ride in the window on every request cost tokens on every request, and for a high-volume application those tokens add up. Fine-tuning that same behavior into the weights removes those tokens from the window permanently, which can lower per-call cost and latency enough to pay back the training investment. The trade is that you give up the flexibility to change the behavior cheaply, so fine-tuning fits behaviors that are stable, a format you will use for a long time, not requirements still in flux. When the behavior is settled and the volume is high, moving it from the window into the weights is the optimization that context engineering alone cannot make.
Use context engineering for knowledge that changes, facts that must be current, and behavior that varies per request, and because it is faster and cheaper to change. Use fine-tuning for a stable behavior, format, or style you want intrinsic and default, especially at high volume where in-window instructions cost tokens on every call.
They Combine Rather Than Compete
The strongest systems use both, each for what it does best. Fine-tuning sets the model's default behavior, the format it produces and the voice it uses, so those do not have to be re-specified in the window on every call. Context engineering then supplies the live knowledge for each request on top of that fine-tuned base, grounding the model's answers on current facts. A fine-tuned model still cannot know your user's latest order or today's inventory, that knowledge has to enter through the window, so even a heavily fine-tuned system needs context engineering for anything current. Conversely, a context-rich system can still benefit from fine-tuning the base behavior so its windows spend fewer tokens on formatting instructions. The two layers stack, they do not exclude each other.
Seeing them as layers also clarifies the sequencing for a new project. Start with context engineering, because it is faster to build and covers most needs, and get the system working by supplying the right knowledge through the window. Only after the behavior requirements have stabilized, and only for the stable parts, consider fine-tuning to move a settled behavior out of the window and into the weights as an optimization. Fine-tuning first, before you understand what the system needs, tends to bake in the wrong thing and force expensive retraining as requirements clarify. Context first, fine-tune the stable parts later, is the sequence that avoids that waste.
Where Memory Fits
Memory belongs firmly on the context engineering side of this line, and understanding why sharpens the whole distinction. The facts a system accumulates about a user or a task, what they told you, what an agent learned, which claims have been confirmed or contradicted, are exactly the kind of changing knowledge that must not be frozen into weights. Fine-tuning cannot hold a fact that was learned yesterday and might be corrected tomorrow, but a memory layer can store it, update it, and select it back into the window when relevant. Adaptive Recall serves this role, keeping accumulated facts outside the model with confidence scores that track how well supported each one is, so the current, corroborated version is what enters the window rather than a stale training snapshot.
This is why a memory layer and fine-tuning are complements rather than alternatives. Fine-tuning can make a model reliably behave like a helpful assistant in your domain, but it cannot make the model remember a specific user across sessions, that is a runtime knowledge problem that only a memory layer feeding the context window solves. A system that fine-tunes its base behavior and uses memory for its evolving knowledge gets the best of both: consistent behavior baked into the weights and current, personalized knowledge assembled into the window. The persistence side of this is developed across the AI memory pillar, and the relationship between memory and the broader discipline is covered in whether memory is part of context engineering.