Article
The formula that settled the argument this year is short: an agent is a model plus a harness. The model supplies the reasoning and is rented by the token from whoever trains the best one this quarter. The harness is everything around it: which tools it can call, what it is allowed to see, how it is stopped, what gets logged, and how anyone knows whether it is working. The model is the part people demo. The harness is the part that decides whether the agent reaches production.
Most agents do not. They demo well, get a budget, and stall somewhere between the prototype and the security review, because the prototype had no answer to the questions the review asks. Those questions are all harness questions.
What a harness contains
The tool loop. The agent proposes an action, the harness executes it, the result goes back to the model, repeat. This loop is where you enforce everything. A model cannot call a tool the harness does not expose, and it cannot exceed a step limit the harness counts.
Permissions. Read widely, write narrowly. A support agent can read every ticket and only reply to the one it was given. Every irreversible action goes through a person until the evaluation results say it does not need to. This is a policy in the harness, not a hope in the prompt.
Context management. The model sees what the harness puts in front of it. That means deciding what to retrieve, what to summarise, what to drop when the conversation gets long, and what never to include, such as a customer's card number that happens to be in the record. Prompt engineering became context engineering when people noticed this was the real lever.
Observability. Every step logged with its inputs, outputs, cost, and latency, in a form a person can read afterwards. When an agent does something odd, the question is "why", and only a log answers it.
Stop conditions. A step limit, a cost limit, a time limit, and a list of outcomes that mean "hand this to a person". Agents without stop conditions do not fail loudly; they loop quietly and expensively.
Evaluation. A set of real tasks with pass criteria, run on every change to the prompt, the tools, or the model. Without it, a model upgrade is a gamble and a prompt tweak is a superstition.
Why it is the part you own
Models are interchangeable in a way harnesses are not. A well-built harness let several of our clients swap models this year in an afternoon, because the tools, permissions, evaluation set, and logs did not care which model was on the other end. The reverse is also true: a weak harness makes every model look unreliable, because nothing constrains what it does with its mistakes.
This is why we treat the harness as the deliverable on agent work. The model is a line in a config file. The harness is the system.
Where to start
If you have an agent prototype, build the harness around it in this order: stop conditions, then logging, then permissions, then the evaluation set. Each takes days, not weeks, and each one turns a class of failure from "discovered by a customer" into "caught by a test". The AI Integration workflow is that order, written down with timings.