The model is one API call. The harness is everything else. It's the loop that decides whether to call the model again, the tool schemas it can invoke, the logic that assembles what goes into the context window on every single turn, the truncation and compaction rules that fire when that window fills, the sandbox and permission layer that decides what the agent may touch, the retry behavior when a tool errors, the stopping condition, and the verification step that checks whether the output is actually any good. The term is borrowed from testing, where a test harness is the rig that holds a component and feeds it input. Same idea here: the model is the component, the harness is the rig.
Break it into parts and it gets concrete. The control loop decides when to keep going and when to stop, which sounds trivial until you've watched an agent burn a token budget looping on a tool that returns the same error every time. The tool layer defines what actions exist and, more importantly, how they're described, because the description is the entire interface the model has to your system. Context assembly is the layer that decides, per turn, what the model sees: system prompt, memory, retrieved documents, prior tool results, conversation history. State and checkpointing let a long run survive a crash. The permission layer determines what happens without a human in the loop. Verification closes the circuit by asking whether the code compiled, the tests passed, the JSON parsed.
Here's the part that surprises people: the same model with different harnesses behaves like two different products. Benchmark scores are harness scores as much as model scores, which is why two teams building on the identical model API can ship agents with wildly different reliability. The model sets a ceiling. The harness determines how close you get to it. Teams that plateau usually plateau because they're tuning prompts when the actual constraint is that tool results get truncated at 2,000 characters, or that memory isn't consulted before the agent picks a plan.
Context assembly deserves singling out because it's where harnesses quietly fail. Your harness is making decisions about what the model remembers whether or not you designed those decisions on purpose. Drop the oldest messages? That's a decision. Include all tool output verbatim? Also a decision, and an expensive one. Retrieve from memory only on the first turn? A decision that will cause the agent to forget the user's constraint on turn nine. Every one of these is a context management choice, and the default in most frameworks is whatever the framework author happened to write.
This is where a dedicated memory layer earns its place in the harness. Maximem Synap slots in as that layer for developers, giving the harness a persistent store to read from and write to across runs instead of rebuilding context from scratch each session. Maximem Vity plays the same role from the other direction, acting as a memory harness around AI apps you don't control, so context follows you across ChatGPT, Claude, and Gemini instead of dying with the tab.
Why It Matters
Most of what people call "the agent" is the harness, not the model. That means most of your agent's reliability, cost, and latency are properties you control rather than properties you buy from a model provider. Teams that understand this stop waiting for the next model release to fix their failure rate and start fixing the layer they own, which is usually where the failure actually lives.
Example
Two teams build a coding agent on the same model. Team A sends the file and the request, and takes whatever comes back. Team B's harness retrieves related files, includes the last three failed attempts and their error messages, runs the test suite after every edit, feeds failures back into the loop, and stops after five attempts with a clear report instead of looping forever. Same model, same prompt quality. Team B's agent lands changes that pass CI, and Team A's writes plausible code that doesn't compile.