You give an agent a clear task and watch it fail. It calls a tool with the wrong arguments, gets back an error message that explains nothing, tries the same call again, and burns the rest of the run. Your first instinct is to blame the thinking. A bigger model, maybe. A better prompt. But go back over the sequence and look for the reasoning mistake: there isn’t one. The agent could not tell what the tool wanted, and nothing afterwards told it. What failed was the room, not the mind working inside it.

You change the tank, not the fish

A fish hangs listless near the surface. A beginner goes out and buys a different fish. Someone who has kept an aquarium for years tests the water first, because the fish is almost never the variable you can change and the tank almost always is. Warmth, filtration, what is dissolved in there that should not be. That is where the problem lives, so that is where the fix goes.

Harness engineering takes the same position on agents. You hold the model and the coding agent fixed, treating them as a sealed unit you are not going to open, and you work the two things around them: the context, meaning what the agent knows, and the tools, meaning what it can do. Rather than fine-tune a model on your company’s code review standards, you write those standards where the agent will read them, hand it the linters, and leave past reviews documented beside them. Same model. Different tank.

That lever is easy to underestimate. One published system, Life-Harness, changed only the environment around the model, four layers of it, without touching a single weight. It improved 116 of 126 model-environment combinations across 18 different backbones, an average relative gain of 88.5%. Much of what looked like agents not being clever enough was interface mismatch instead.

The tank has three residents, not one

Accept that the environment is the product and a harder question shows up: better for whom. An aquarium serves three parties at once. The fish that lives in it, the person who watches it from the sofa, and the person who reaches in every fortnight with a siphon. A dense planted layout can suit the fish, look wonderful, and be miserable to clean.

Harness design has exactly those three. Agent experience is how easily the model can work out what to do, which comes down to whether the context is clear, the tools are decent, and an action reports back what it did. User experience is whether the finished output solves the problem of the person who asked for it. Developer experience is how easy the thing is to build, debug and extend for whoever maintains it. The three pull against each other, and buying one often means selling another.

The Confucius SDK makes such a trade in the open. It puts the agent inside the container, which gives whoever develops it a rebuild in about thirty seconds and one layer to debug instead of two, at the cost of separating the agent from the sandbox. Declared, not stumbled into. That is the habit worth copying. Not that a choice works better, but which of the three it works better for, and what the other two paid.

This already has a name and a literature

The research has started organising itself the same way. Work on coding agents gets filed by the runtime piece it changes, planning, memory, tool use, verification, orchestration, rather than lumped under the model. That lets you say which component caused an improvement, and it forces one variable at a time. Otherwise you credit the model for a gain that really came from a retrieval step.

The tank itself gets tuned experimentally too. Independent proposers try variants in isolated worktrees, candidates go through traces, evaluations and canary runs, and a held-out set checks that the win generalises. Regression gates and cost limits reject the variant that improves one number while quietly costing reliability. It is the design side of the boundary drawn in The Loop Is the Product, and it is a job with none of the glamour and most of the leverage. The model is not the system. The tank is.