Part 1
The era of prompt engineering
When the only thing you controlled was the wording of one message.
When language models first reached the public, the entire interface was a single empty text box. Whatever you typed was everything the model had to go on — so the wording of that one message decided everything. A whole craft grew around it: phrase the question precisely, give an example of the answer you want, tell the model to “act as” an expert. Job titles appeared. Courses were sold.
It was a real skill, but a narrow surface. However clever the phrasing, prompt engineering only ever shaped one thing: the words in one message, for one answer. The moment AI systems became more than a text box deep, the craft had to grow with them.
In one sentence: prompt engineering is the craft of wording a single request so the model gives its best possible answer.
Part 2
The era of context engineering
The next realisation: the model never sees just your message. It sees a context window — one big package of text that also holds its standing instructions, the conversation so far, documents fetched from a knowledge base, the customer’s history, the results of earlier steps. Everything in that window shapes the answer, no matter who put it there.
So teams stopped polishing single sentences and started designing the whole package: what should the model see at this moment? What must it not see? In what order, and in how much detail? That work is context engineering — deciding what the model gets to look at before it says a word. Your prompt didn’t disappear; it became one ingredient among many.
Part 3
The era of harness engineering
Then came agents. Once a model is given a goal and starts acting in steps — searching, reading documents, updating systems — no single prompt, and no hand-picked context, can carry it. At every step the package of information has to be assembled fresh, by software, faster than any human could curate it. Someone has to design the whole system the model works inside: its instructions, its tools, its memory, its guardrails, and the loop that ties them together.
That surrounding system has a name — the harness — and building it well is where most of the real work now happens. Notice that nothing was thrown away along the way: the harness assembles the context, and the context contains the prompts. Each era swallowed the previous one whole. The skills didn’t get replaced; they got embedded in something bigger.
Part 4
What to remember
-
01
The craft kept moving outward: from the wording of one message, to everything the model sees, to the whole system it works inside.
-
02
Prompting didn’t disappear — it became one layer inside the context, inside the harness. Each era contains the last.
-
03
Each step moved the work away from clever tricks and towards deliberate design: of information, of behaviour, of limits.
-
04
When an AI product gets dramatically better without a new model, the improvement almost always happened in the outer layers.
For business & service designers
Each era moved the work
closer to design
This reads like a technical history, but look again: it is the story of a design surface growing. At first the only thing anyone could shape was a sentence. Then it was information — what a system knows about a customer at a given moment. Now it is behaviour: what a service actor can do, what it remembers, when it must hand over to a person.
We have been here before. Those are exactly the questions business and service design asks of any channel, any touchpoint, any front-line role. Each era of this evolution reached for a craft designers already practise.
- Prompt engineering → copy & conversation design
- Wording one interaction so it lands well — precise, on-brand, right for the moment. We have called this microcopy and tone-of-voice work for years.
- Context engineering → information architecture
- Deciding what the system should know about the customer at each moment of the journey — and what it must not. That is research, journey mapping and information architecture, applied to a context window.
- Harness engineering → service design
- Capabilities, policies, memory, handoffs — the behaviour of a whole actor in the service. Designing how an actor behaves across a journey is the definition of our discipline.
- The pattern → our craft, new material
- Every time the engineering surface grew, it grew towards questions designers already know how to answer. The material is new; the questions are not.
What will we do in the future?
The same answer as everywhere on this site: much of what we already do, applied to a new material. Four ways to put this evolution to work:
-
Retire “prompt tricks” as the AI skill
Being good with AI no longer means knowing magic words. It means being able to reason about what a system sees, does and refuses — update your own toolkit, and your team’s, accordingly.
-
Ask what the model sees
At any step of a journey that touches an agent, ask what is in its context window. Does it know what the customer already said one touchpoint ago? Context is what continuity feels like from the inside.
-
Read the harness as a blueprint
Instructions, tools, memory and guardrails are a new layer of the service blueprint. If we can draw a line of visibility, we can draw a harness — and critique it.
-
Join the era we are actually in
The interesting conversations have moved from “how do we phrase this prompt?” to “how should this agent behave?”. Knowing the vocabulary of all three eras is what buys a seat in that room.
The question to take with you
The engineers moved from the prompt to the whole system.
Have we moved with them?