Harness Engineering: The Next Phase After Prompt and Context Engineering

Another AI buzzword landed on my feed recently: harness engineering. My first reaction to a new term like this is usually skepticism, the AI world mints a new phrase every few months. But this one actually names something real, and I think it's worth tracing how we got here.

Phase one: prompt engineering

When ChatGPT first took off, a whole mini-discipline formed around how you phrased the request itself: give the model a goal, a persona to adopt, a tone, criteria for what "done" looks like. Checklists sprang up everywhere for structuring a prompt well instead of just winging it. That was the entire game for the first year or so, mostly the user prompt, sometimes the system prompt: instructions, background, tone.

Phase two: context engineering

The next shift was about what you fed the model beyond the prompt itself. Instead of relying only on what the model learned during training, you could hand it your own private data at the moment you asked the question, and that cut down on hallucinations significantly. This is where retrieval-augmented generation, RAG, came from: pulling in private records, policies, or reference material so the model answers with the actual facts in front of it rather than whatever it half-remembers from training.

A model knows nothing about your specific customer's history or your internal documentation on its own, but you can make it part of an accurate answer by handing it the right context at inference time. That became its own discipline: what to pull, how to fit it inside a limited context window, and how to do it without burying the model in irrelevant information that pulls it off task.

Phase three: harness engineering

Which brings me to now. Harness engineering is about the environment you build around the model so it can actually operate as an agent, not just answer a single question.

A harness typically includes a tool loop, so the system can keep iterating, calling tools and checking results, until the task is actually finished and not just after one response. It also includes tools and MCP servers, the APIs and resources the model can call out to instead of only reasoning in isolation, and skills: instead of trying to explain every possible scenario in a single prompt, you maintain a directory of skill files, and when a relevant situation comes up, the agent reads the matching one and follows it. Most harnesses also add a memory system, so a long conversation or task doesn't lose track of what happened earlier, sometimes recalling things from well before the current session, plus hooks: small pieces of code that run before or after a tool call, for example to confirm an action should actually happen before it fires.

Here's the part I think people miss: the underlying model is exactly the same in every case. Strip away the harness, and it's still just an LLM that takes a prompt and returns a response. What the harness adds is the scaffolding, the loop, the tools, the skills, the memory, that lets that same plain model carry out something far more sophisticated than a single exchange.

What this looks like in practice

Coding agents like Claude Code and Codex are a clean example: strip away the loop, the tool access, the skill files, and the memory, and what's left underneath is an ordinary model. The harness around it is what turns "answer a question" into "actually get the coding task done."

The same pattern shows up in general-purpose personal agents outside of coding, too. Different domain, same underlying idea: loop, tools, skills, memory, wrapped around a plain model.

Where this leaves us

Building good AI systems today isn't only about picking a better model anymore. It's just as much about building a better harness around it. A well-designed harness is often what turns raw model capability into something that can actually finish a real task, and that's the layer worth paying attention to right now.

Continue the workflow

To connect tooling with daily work, read the agentic engineering stack guide: interfaces, subscriptions and skills and evaluate the choices against your tasks and constraints.