What is the difference between context engineering and prompt engineering?

Prompt engineering shapes the instructions you write — wording, examples, output format, role framing. Context engineering designs the entire information payload the model sees on each call: which documents are retrieved, what memory is injected, which tool results are included, how history is compacted, and what is deliberately excluded. Prompt engineering is authoring the question; context engineering is architecting everything surrounding it. As agents grew long-running in 2026, context engineering became the larger share of the work.

When should I fine-tune instead of using context?

Fine-tune when you need consistent behaviour, format or domain style that instructions cannot reliably produce, and you have enough high-quality examples — typically hundreds to thousands. Fine-tuning teaches behaviour well and facts poorly. If the requirement is that the model knows current or proprietary information, retrieval is correct and fine-tuning is wrong, because retraining is the only way to update a baked-in fact.

Which should I try first?

Prompt engineering, then context engineering, then fine-tuning. The order reflects cost and reversibility. Prompt changes take minutes and are free. Context changes take days and cost engineering time plus tokens. Fine-tuning takes weeks, costs training and hosting, and creates a versioned artefact you must maintain and re-run whenever the base model changes. Most teams that fine-tune early discover their real problem was a context problem.

Does a large context window remove the need for context engineering?

No, it makes it more important. A 1M-token window means you can send everything, not that you should. You pay for every token on every call, latency scales with input, and attention quality degrades unevenly across very long inputs. Larger windows raise the cost of lazy context assembly rather than eliminating the discipline.

Quick Answer

Context Engineering vs Prompt Engineering vs Fine-Tuning

Published: September 1, 2026

The Short Answer

Three levers, three different jobs:

Prompt engineering — what you say to the model. Instructions, examples, formatting, role.
Context engineering — what the model sees. Retrieved documents, memory, tool output, compacted history, and everything deliberately left out.
Fine-tuning — what the model is. Weights adjusted through additional training.

They are not competing approaches. They are layers, and there is a correct order to apply them.

Last verified: September 1, 2026.

Side by Side

	Prompt engineering	Context engineering	Fine-tuning
Changes	Instructions	Information payload	Model weights
Time to first result	Minutes	Days	Weeks
Marginal cost	Free	Tokens + engineering	Training + hosting
Good at	Format, tone, task framing	Facts, freshness, scale	Consistent behaviour, style
Bad at	Knowledge the model lacks	Deeply ingrained habits	Facts, freshness
Updating it	Edit text	Update the corpus	Retrain
Portable across models	Mostly	Yes	No
Fails by	Ambiguity	Wrong retrieval, overflow	Overfitting, staleness

The two cells worth memorising are in the fine-tuning column: facts and freshness. A fact trained into weights can only be changed by training again. That single property decides most real architecture questions.

Prompt Engineering: Cheapest, Still Underrated

Prompt engineering acquired an unearned reputation as a 2023 concern that “real” systems outgrew. In practice it remains the highest-return-per-hour lever available, because it is free and instant.

What it reliably fixes:

Output format — schemas, JSON shape, structure
Task decomposition — asking for reasoning steps before conclusions
Tone and register
Ambiguity — most “the model got it wrong” failures are underspecified instructions
Scope boundaries — stating what not to do

What it cannot fix: the model not knowing something. No amount of rewording surfaces a fact that was never available.

The discipline is unglamorous. Write the instruction, test on real inputs, find the failure, tighten the instruction. Teams frequently skip to expensive solutions before exhausting a lever that costs nothing.

Context Engineering: Where the Work Moved

As systems became agentic and long-running through 2026, the dominant engineering problem stopped being what do I ask and became what does the model have in front of it when I ask.

Context engineering covers:

Retrieval selection. Which documents, chunked how, ranked by what. Retrieval quality caps answer quality — a model reasoning over the wrong three chunks produces a confident wrong answer.

Memory injection. Which durable facts about the user, project or prior decisions get included. Too little forces re-briefing every session; too much crowds out the task and risks propagating stale state.

Tool result handling. Agents generate large volumes of tool output. Raw inclusion overflows the window within a few turns. Summarising, truncating and discarding are design decisions with real consequences.

History compaction. Long-running sessions must decide what to keep verbatim, what to summarise, and what to drop.

Deliberate exclusion. The most underrated part. Every irrelevant token costs money, adds latency, and competes for attention.

The long-context trap

Frontier models now commonly ship 1M-token windows — Claude Opus 5, GLM-5.3, DeepSeek V4, and others. This makes context engineering more important, not less.

Three reasons:

Cost is linear and recurring. At Claude Opus 5’s $5 per million input tokens, a filled 1M-token context costs $5 per call before a single output token. Multiply by an agent’s turn count.

Latency scales with input. Long prompts are slow prompts, and agent loops multiply the penalty.

Attention is uneven. Retrieval quality across very long inputs degrades in ways that are hard to predict and easy to miss in testing.

A big window is permission to include what matters, not an excuse to include everything.

Fine-Tuning: Behaviour, Not Knowledge

Fine-tuning adjusts weights on your examples. It is the only lever that changes what the model fundamentally is, and it is the one most often reached for prematurely.

Good reasons to fine-tune:

A consistent output format that instructions produce only ~90% of the time and you need ~99%
A domain voice or house style that is hard to specify but easy to demonstrate
A narrow, high-volume, repetitive task where a smaller fine-tuned model beats a larger general one on cost and latency
Latency or cost targets a frontier model cannot hit

Bad reasons — the common ones:

“The model doesn’t know our products.” That is retrieval. Fine-tuned facts go stale and require retraining to correct.
“We want it to sound like us.” Often achievable with a good system prompt and three examples. Try that first.
“Our data is proprietary.” Proprietary data belongs in a retrieval corpus you control, not baked into weights.

The hidden costs are what surprise teams: you now own a versioned artefact. When the base model updates — and in 2026 that happens every few weeks — your tuned variant does not automatically inherit the improvement. You maintain, re-evaluate and periodically re-run training. You have traded a configuration problem for a lifecycle problem.

The Order, and Why

1. Prompt engineering. Free, instant, reversible. Exhaust it.

2. Context engineering. Add retrieval when the failure is missing knowledge. Add memory when the failure is lost continuity. Trim aggressively when the failure is cost or latency.

3. Fine-tuning. Only when you can state precisely what behaviour instructions failed to produce, and you have the examples to demonstrate it.

The diagnostic question that routes correctly almost every time:

Is the model failing because it lacks information, or because it lacks a habit?

Lacks information → context engineering. Retrieval, memory, better tool output.

Lacks a habit → prompt engineering first, fine-tuning if instructions genuinely cannot get there.

Teams that fine-tune first usually discover, expensively, that they had an information problem wearing a behaviour costume.

In Practice: All Three

Production systems in 2026 typically use every layer:

A carefully written system prompt establishing role, constraints and output contract
Retrieval over current documentation and proprietary data
Persistent memory for user and project continuity, with an inspection surface
Compaction to keep long agent sessions inside budget
Occasionally, a fine-tuned small model for one high-volume narrow step

The frontier model handles reasoning. Context supplies the facts. Prompts set the contract. Fine-tuning, where it appears at all, handles the one thing the others could not.