Model choice decides what a task might be capable of. The harness decides whether it gets done.

Capability sitting idle

A capable model with no defined tools cannot act, only describe what it would do if it could. Give it every tool available without deciding which ones the task actually needs, and it can act, just not safely: an agent asked to update a scheduling record that can also delete the calendar it reads from is one ambiguous instruction away from doing the second thing while attempting the first. Neither failure is a model problem. Both are the working environment around the model, built badly or not built at all.

We have said elsewhere that the instruction, what the model can see, the environment it acts in, and the loop that decides when it retries or stops are well understood in outline. This page is what that sentence means in practice: the actual decisions a working environment requires, and the judgement that separates a harness built to the task from one built by default.

What a harness holds

Four decisions define the environment a model works inside for one task. None of them is the model.

Tool accessWhat the task can reach, named explicitly

A written list of the systems and actions available for this task, derived from what the task actually requires rather than from what is technically connected. An agent drafting a maintenance report needs read access to the asset history and write access to a draft folder; it does not need write access to the live schedule, even where that access already exists in the surrounding estate.

Context supplyWhat the model starts from, and how it gets there

The documents, records and prior conversation loaded into the task before it begins, retrieved from the systems where the relevant knowledge already lives rather than pasted in by hand each time. A task started cold, with the model inferring context it was never given, produces confident answers built on guesses that look identical to answers built on evidence.

Subagent structureWhether this task is one agent or a small set of scoped ones

Some tasks are cleaner as a single agent working straight through. Others split usefully into a small number of narrower agents inside the same task, one drafting, one checking against source material, one formatting the output, each with its own tool list and none of them touching what the others do not need. This is a decision about one task's internal shape, not the standing multi-agent organisation covered separately below.

Escalation pathWhat happens when the agent is out of its depth

A defined point at which the task stops and hands to a named person, rather than the agent guessing past the edge of what it was given to work with. A silent agent that produces its best attempt regardless of confidence is a worse design than one that says plainly it has reached the edge of what it can determine.

Sizing it to the task

More of any of the four is not automatically better. Extra tool access is extra surface for a wrong action to do more damage. Extra context is extra material the model has to weigh, and past a certain point it starts diluting the relevant part rather than reinforcing it. Extra subagents add hand-off points, and every hand-off is a place meaning can be lost. The right size is decided by the task, not by what happens to be available.

Build the harness out when

The task genuinely spans distinct kinds of work that benefit from separate scrutiny, such as drafting and independently checking the same output; the systems involved are numerous or sensitive enough that a single broad tool list would be a governance problem on its own; or the task runs unattended for long enough that a defined stop condition is doing real work rather than a formality.

Keep it lean when

One agent, a short and specific tool list, and clearly supplied context already produce a result the task needs checked once rather than twice; splitting it into several agents would add hand-off points without adding a genuine second kind of scrutiny; or the task is short enough that a person reviewing the whole output costs less than building and maintaining the extra structure.

One task, not an organisation

Splitting one task into a handful of scoped subagents is a different decision from running several agents as a standing team or a task force across an operation. A task's internal structure is fixed for as long as the task takes: a drafting agent and a checking agent exist because this piece of work benefits from separate scrutiny, and they stand down when it is done. An organisation of agents is a different kind of commitment, permanent roles, hand-offs between specialisms that persist across many tasks, and evidence graded and carried as work moves between them over time.

Where an operation has reached the second kind of question, designing the organisation your AI works inside is the relevant method. This page is the layer underneath it: get the environment right for one task first, because an organisation built from badly harnessed agents inherits every one of their weaknesses at scale, just spread across more of them.

The pattern is not staying in code

Coding tools were the first place this discipline had to be built properly, because a coding agent with the wrong tool access can do visible, immediate damage to a real codebase, and one with too little context produces work nobody can use. The same discipline is now visibly moving into broader office work. OpenAI launched ChatGPT Work in July 2026 as an agent that gathers context from a user’s connected apps and files, breaks a stated goal into steps, and stays on a project for hours before returning finished documents, according to OpenAI’s own announcement. Cursor is reportedly developing a comparable general-purpose office agent, internally codenamed Sand, rolled out to its own staff before any public release, with whether and when it reaches customers still unconfirmed as of this writing, according to reporting on the internal rollout. Neither development changes the underlying decisions this page describes. They confirm that the same tool-access, context-supply and escalation questions a coding harness had to answer are now the questions every serious agent for general work has to answer too, whichever vendor is asking them.