Agent harnesses: which instructions to remove and which boundaries to strengthen

A harness turns a model into an agent by organising tools, context, state, execution, and verification. The model can be replaced while the surrounding machinery remains a separate engineering concern. A better model therefore leaves an open question: which parts of that machinery are still necessary?

The words-and-walls metaphor separates two responsibilities. Words are prompts, rules, and skill files that compensate for particular model weaknesses. An upgrade may make some instructions unnecessary without reducing quality; past usefulness does not establish present value. Walls are sandboxes, access restrictions, and deterministic action checks. A more capable model can still take an unauthorised action, so those boundaries remain necessary. The direction is less step-by-step prescription inside a task, with a stronger perimeter around execution.

The story starts with alternating reasoning and action inside a prompt, then moves to interfaces designed for agents. Packaged products add tools, sandboxes, and hooks. Harness engineering emerges as a discipline, while execution becomes part of vendor platforms. These stages coexist: older prompting techniques and local tools continue working alongside newer infrastructure.

Three shifts matter. Function calling, structured responses, tool search, and context compaction move into models or APIs. Restrictions previously expressed as instructions become runtime controls. The execution loop moves from a laptop to the cloud. What remains on the client is access to its particular state: files, editors, browsers, and applications. An architecture decision must identify where that boundary lies and who controls state and access on either side.

Products increasingly share a vocabulary: tools, sessions, memory, subagents, permissions, and evaluation. Protocols support compatibility: MCP connects agents to tools, A2A connects agents to other agents, and ACP connects agents to editors. Yet matching feature names do not imply matching behaviour. Products differ in protection defaults, supported models, execution location, memory, and verification. A sandbox, an action classifier, and a human approval prompt perform different jobs.

Polomodov describes three product perspectives. An all-in-one platform combines models, editors, command-line tools, cloud execution, and code review. A standalone coding agent offers a narrower tool. A building block lets teams assemble a system through APIs, SDKs, and eventually a managed runtime. A large organisation may need its own infrastructure; a product team may prefer ready-made execution. The suggestion that standalone agents will become a niche is the author's hypothesis about the market.

The minimal mini-SWE-agent illustrates how much a model can accomplish with bash and a small harness. That reflects stronger models and saturation of a particular benchmark. Successful coding, however, does not justify delegating authorisation to the model. Models do not reliably separate instructions from data, and probabilistic action classifiers can miss harmful behaviour. Repeated attack attempts make even a small miss rate consequential.

The talk identifies several failure classes: secrets within reach, repository configuration executed before trust checks, sandbox vulnerabilities, and approvals detached from the concrete action. Even nominally read-only access can change state when a server performs writes through GET requests. Protection therefore has layers: a classifier evaluates actions within a restricted environment, sandboxes and hooks enforce boundaries, and credentials remain outside the agent's machine. This reduces risk without guaranteeing absolute protection. The controls themselves also need scrutiny.

Harness benefits depend on the comparison. Replacing a weak harness with a strong one can improve success substantially. Two strong harnesses may achieve similar results while differing in execution cost. A model paired with a harness designed for it can be more economical. Context, memory, permissions, and completion criteria tend to outlast instructions compensating for a particular model version.

The practical test is ablation: remove one component and measure the change. Fix the model and reasoning setting, select representative tasks from real failures, and keep the environment consistent. Use external verification rather than the agent's account of its own success; preferably go beyond assessment by another model alone. Repeat runs to expose variation, then compare success and the cost of an accepted result. A component with no measurable benefit becomes a candidate for removal. Accumulated instructions become hypotheses to revisit after significant updates.

Success on one attempt, at least one success across several attempts, and success on every repeated run are different properties. More attempts can improve the chance of eventually finding an answer without demonstrating dependable autonomous execution. Routine work requires consistent results, particularly where checking an output is harder than running tests against code.

Cheaper tokens do not necessarily reduce an organisation's spending: context, call counts, and delegated workload can all grow. Context management and caching affect the cost per successful task. The next question is the effect on development itself. More code changes do not automatically mean more value; time and engineers' understanding of the result matter too. Polomodov highlights cognitive debt. Asked about task prices across harnesses, he recommends choosing a common benchmark first. Prices from isolated comparisons cannot serve as a universal task tariff.

The talk anticipates wider adoption of agents with their own cloud machines and further movement of action checks to providers. Agent identity and competition on the cost of successful work are two further bets. These remain developments to watch: the existence of hosted products does not establish how much real work has moved to them.

Start with the harness you already operate. Record the problem each component addresses and the change that should trigger another test. After a model upgrade, revisit compensating instructions, repeat the relevant tasks, and compare the cost of success. Test access restrictions as properties of executable code. A useful harness must be possible to simplify while preserving the conditions for safe, verifiable work.