Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system.
Made by builders.
For builders.
In Part 4, we looked at the Tools — the set of functions the model can call.
But there's still one big open question hanging over every turn of the Loop: what does the model actually see when the Loop calls it?
The answer is: whatever the harness put in the payload.
That payload — the entire package of instructions, history, retrieved documents, tool definitions, and everything else — is called the Context.
Some readers know this territory under an older name: prompt engineering.
That name isn't wrong, but it's narrow.
A prompt sounds like something you write once and ship.
The reality of running an agent is that the payload changes every turn, and designing what goes in it is an ongoing discipline.
Hence the newer, more accurate term: context engineering.
What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop Part 4: The Tool Layer Context Engineering ← You are here Part 6: The Filesystem & Environment Part 7: The Memory Layer Part 8: Observability Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what the Context actually is, why every turn forces you to answer "what should the model know right now?" from scratch, and the three moving pieces (system prompt, history, retrieval) that make up a well-designed context.
Let's get started. 📚 Want to go deeper than the articles?
While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code.
Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers.
Both are optional — the series stands on its own.
But if you want the full studio-quality version, that's where it lives.
What The Context Is The Context is everything fed into the model on a given API call.
All of it.
Concretely, on any single turn, the payload sent to the model typically includes: The system prompt — the model's persona and instructions The conversation history — the messages exchanged so far Any retrieved documents relevant to the current turn The tool definitions — what tools the model can call, and how Prior tool results — from calls the model made earlier Any attached files or images Anything else the harness thinks the model needs to know right now That entire package goes over the wire.
The model reads all of it.
Then it produces one response.
Then, on the next iteration of the Loop, the harness assembles a new package — probably with the previous response added, maybe with new tool results appended, maybe with different retrieved content — and sends that.
Every turn is a new context.
Every turn.
Why The Context Exists Because the model is stateless.
We noted this back in Part 1: every API call is independent on the model's side.
Nothing persists between calls unless something outside the model puts it there.
Which means the question "what should the model know right now?" turns into a very different question: "What do we put in the context?" And that question has to be answered on every single turn.
There is no shortcut.
You can't tell the model "remember what I said five minutes ago." You can't say "reference the file we discussed earlier." Every relevant thing — every fact, every prior message, every result, every document — has to physically be in the payload for the current call, or the model doesn't know about it.
This is why context engineering is arguably the deepest engineering discipline in the whole harness.
Deciding what to include, what to compress, what to leave out, and when — that's t