Context engineering is the design surface

Prompt engineering treats the wording as the thing you adjust. Phrase the request better, add the right words, and the output improves. That works fine for one turn against a chatbot. It stops working as soon as the task is big enough to matter, because the wording is only part of the input. The whole input is the context window: the instructions, the examples, the retrieved material, the earlier turns, and whatever structure you put on top of all of it. Context engineering means treating that entire window as something you design on purpose.

I’ve argued elsewhere for building context systems rather than crafting one-off prompts. This is the how: what stages the work moves through, and what each one leaves behind.

A stage produces an artefact

The risk with “context engineering” is that it stays a vibe. You nod, you agree that context matters, and then you go back to typing paragraphs into a box. The fix is to give the work stages and make each stage produce something you can point at. Anything you can name, you can reuse, review, and hand to someone else.

I teach this as four stages at Lyssna, in workshops on getting real leverage out of models. Define, Discover, Design, Develop. Each one owns a question and leaves an artefact.

The artefacts are the point. If a stage produced nothing you can save, you skipped it, and the model is now guessing at whatever you didn’t write down.

Define: write the success criteria before the prompt

Most bad output traces back to a task nobody specified. “Make this better” has no finish line, so the model invents one, and it won’t be yours. The Define stage forces the criteria out of your head and onto the page: what the output is for, who’s going to read it, and what would make you reject it.

The artefact is small and does a lot of work. A few lines of success criteria let you judge the output rather than just react to it, and they become the thing you paste into every later turn, so the model gets measured against your bar instead of a generic one.

Discover: vocabulary reaches the right part of the model

This is the stage people skip and the one that moves quality most. A model has read an enormous amount; the difficulty is reaching the right part of it. Domain vocabulary is how you do that. Precise terms work like a key. Say “rebase” and “bisect” and you land in the part of the training where careful git work lives. Say “make the history clean” and you get somewhere vaguer. The words you pick decide which regions of the model’s training you’re drawing on.

So Discover is retrieval you do yourself, before any automated retrieval runs. You put together the context pack: the terms of art for this domain, the references that set the standard, and examples of good and bad output. Examples carry more weight than instructions do, and one strong example of the thing you want teaches faster than three paragraphs describing it. The pack is reusable, too. Build it once for a recurring task and every future run starts somewhere sensible.

Design: a framework is a scaffold the model already knows

Frameworks earn their place here. A named framework is a structure the model has seen thousands of times in training, so invoking it gets you the shape for free: the steps, the order, the headings, how the parts relate. You’re pointing at a framework the model already has and asking it to pour this task into that shape.

That’s the whole trick. “Analyse this” is unstructured and so is what comes back. “Run a SWOT, then a risk register, then a recommendation” hands the model three scaffolds and an order to fill them in. The artefact here is the scaffold written down: framework named, output shape fixed, sections decided before the first word gets generated.

Develop: build across turns instead of shooting once

Single-shot prompting asks for the finished thing in one call. That’s fine for small tasks and it fails quietly on large ones, because everything that goes wrong goes wrong at the same time and you can’t tell where. Building across turns separates the failures out. You generate a draft, check it against the success criteria from Define, fix the one thing that’s off, and carry on. Each turn brings the accumulated context with it, so the window gets richer as you go instead of starting cold.

The artefact here is the transcript. A good multi-turn session is worth keeping, because it’s the sequence of moves that produced a result you trusted. Save it and you’ve captured a workflow rather than an answer.

CLAUDE.md is team infrastructure

All four stages produce artefacts, and artefacts are exactly what a context file is for. CLAUDE.md, or whatever your tool calls it, is where the durable parts live: the vocabulary, the success criteria, the frameworks you reach for, the examples of good output. Written once, loaded every session.

That turns a personal trick into shared infrastructure. While the context file lives in your head, the leverage walks out of the building with you. Once it lives in the repo, the team builds on it and improves it, and a new person inherits all of it on day one rather than rediscovering it over six months. That’s where the compounding happens.

Prompt engineering optimises a sentence. Context engineering builds the surface every sentence lands on, and leaves something behind at each stage so the next run starts ahead of the last one.