Prompt Engineering vs Context Engineering vs Harness Engineering

Start with the message: role, instructions, examples, and output format assembled into one prompt. When answers still drift because the model lacks the right docs, history, or tool results, move up to context engineering — curating a finite window every turn.

When a single call is not enough — you need tools, sub-agents, and “try again until checks pass” — you are doing harness engineering. Harnesses reuse prompt and context skills inside an automated gather → compose → act → verify loop. For prompt craft basics (zero-shot, few-shot, chain-of-thought), see the companion guide on prompt engineering for developers.

Prompt engineering composes ingredients into one request: role (“senior engineer”), context snippets, instructions, few-shot examples, and a format (JSON schema, bullet rules). You send that block to the LLM, read the response, then refine the weakest ingredient — clearer constraints, better examples, tighter schema.

This layer shines for chat UIs, IDE assistants, and one-shot transforms where the user (or you) can iterate. It fails silently when the model never saw the right private data, or when “good enough” requires tools and automated checks you are not running.

Context engineering treats the context window as a finite budget. Each step you gather candidates: user query, system prompt, retrieved docs, tool outputs, memory, prior turns. A curator selects, compresses, and drops chunks until the window is full of high-signal tokens — not every log line you ever logged.

After inference, new outputs become context for the next step. This is the heart of solid RAG and agent turns: retrieval quality, summarization of old history, and ruthless dropping of noise. A perfect prompt with a polluted window still hallucinates confidently.

A harness wraps prompt and context work in a product loop. Inside the box: gather (context engineering), compose (prompt engineering), act (LLM plus tools or sub-agents), and verify (unit tests, schemas, LLM-as-judge). Pass → final response. Fail → retry with updated context — re-run gather → act → verify.

This is how coding agents, research agents, and reliable copilots behave. The model is not the product; the machine around it is. Harness engineering owns timeouts, tool allowlists, budgets, observability, and stopping conditions — not just clever wording.

If quality fails on a single clear task with all facts in view, fix the prompt. If the model lacks docs, history, or tool results — or the window is noisy — fix context. If the job needs tools, specialists, and automatic retries until checks pass, invest in a harness.

Most production systems eventually need all three. Ship prompt skill first, add retrieval/memory discipline next, then harden a harness only where wrong answers are expensive. Interview and design discussions reward this vocabulary: message vs memory vs machine.