The Elastic Loop · Part three

Harness

When you let an agent work on its own, it needs a way to find information, try things, inspect the result, and correct mistakes. It also needs limits on what it can do and a way to hand decisions back to you.

A small mint loop braced at the center of a much larger scaffold ring-cage of black and silver struts, with miniature figures building and tightening the surrounding frame

A is the software around the model that makes this possible: the execution loop, tools, context management, and controls. If you use an agent that can read files, run a program, and keep working from the result, you’re already using one. Your team supplies much of what makes that harness useful in a particular setting, from access to the codebase to the checks and review arrangements around it.

Harness engineering includes the way your team designs and improves these conditions across technical systems. A check in the delivery pipeline or an independent reviewing agent can contribute from outside the agent’s runtime. Product and domain experts supply knowledge that this technical environment must make usable.

Four questions about the same change

Consider the dashboard from Loops, which helps a support team decide which cases need attention. An agent has built a new version. I’d want four kinds of judgment brought to it:

Responsibility	Question	A concern in the dashboard
Engineering and architecture	Is it correct?	The priority calculation works, and the change fits the surrounding system.
Product and domain	Is it right?	People can find the case that needs their attention and understand why.
Security and compliance	Is it allowed?	People can see only the case information they’re entitled to access.
Operations	Does it hold up in production?	A delayed data feed is visible, so an old priority order doesn’t look current.

These responsibilities can overlap or sit with the same person. Each brings knowledge the agent needs before it builds, criteria for inspecting what it produces, and reasons to intervene along the way. The Roles chapter looks at who contributes that judgment.

The kind of knowledge tells you little about how to check it. A domain rule can be precise enough for an automated test. An architecture question can require a discussion about trade-offs. For each concern, decide what evidence would settle it and how to obtain that evidence.

Give the agent the reasons it needs

For the dashboard, “sort cases by priority” leaves a lot to guess. What makes a case urgent? How should the view handle incomplete information? Which users may see the underlying details? The agent needs the relevant rules, examples, and constraints, along with enough information to run the application and its checks.

It also needs to understand decisions that the implementation alone cannot reliably explain. Suppose the team chose a deterministic priority rule so support staff could explain the order to customers. The code can show how that rule works. A short decision record can explain why it was chosen, which alternatives were considered, and under what conditions the team would reconsider it. Without those reasons, an agent asked to improve the dashboard might replace a deliberate choice with something that appears more sophisticated.

Make this material easy to find when the task needs it. A short project guide can point to the current priority rule, the decision record, representative cases, and the commands that run the checks. Keep one authoritative copy of each rule, name who maintains it, and give the agent a way to notice when sources disagree. If the priority policy is unresolved, that is a question to bring back to the team.

The same applies to the standards that make the dashboard fit your product. Provide examples of the project’s coding conventions, explain the architectural boundaries, and make approved visual components and brand assets available. A plausible generic solution can still miss all three. That is a concrete form of the team can assess against its own requirements.

The amount of material an agent reads has a cost. Reading every document at the start of every task spends time and tokens, and leaves less room for the work itself. Start with enough orientation to find the relevant detail, then retrieve that detail as needed. Searchable files, a knowledge base, or a retrieval service can all serve this purpose. Judge the arrangement by whether it delivers the right information at the right time, at a cost the task can afford.

Make corrections cheap enough to repeat

is quick, inexpensive feedback from checks built into the agent’s workflow. When the agent tries to save a code change as a commit, a pre-commit hook can automatically check the project’s coding rules. If a variable name breaks those rules, the hook rejects the commit and reports the problem. The agent corrects the name; its next commit attempt triggers the check again. The workflow supplies the feedback as the agent works.

The same principle applies to building a program. Before an agent can try a program written in Go or Rust, it has to build a runnable version. If that fails, the build tool reports what is wrong. The agent has to correct the problem before it can try the program. Choosing tools that work this way gives the agent feedback at a step it already needs to take.

Teams can encode some architecture rules in the same way. An architecture fitness test is an automated check of a property the system should preserve. It might detect that one part of the application now depends on another part it must remain separate from. Run the check automatically when the agent builds the application. If it quickly reports the offending dependency, the agent can correct it during implementation.

The same approach can help with brand requirements. A check triggered when the agent saves an interface file can identify colors outside the approved palette and show which colors are allowed. The agent can correct the interface immediately. Whether the overall design suits the product still needs review.

Some product requirements also allow quick checks. Once the team has agreed a priority rule, representative cases can reveal whether the dashboard follows it. A small model-based check might assess whether the view explains the reason for priority, using a compact , a written set of quality criteria. Evaluate that check against examples people have reviewed and measure its cost. Attach it to a step such as updating the dashboard preview. It supplies backpressure only if it is useful, quick, and inexpensive enough to repeat during the work. More extensive assessment belongs at a review gate. Grading explains how to evaluate both.

Build checks into steps the agent already takes, such as saving files, building, or committing. They run frequently, so their cost in time, tokens, and context has to stay low. Return the failing case and enough detail to investigate it. Keep routine success messages brief, while retaining evidence of what ran. Watch the cost of the feedback itself: a check that takes longer than the work or returns pages of irrelevant detail can consume the time and context needed to act on it.

A document containing acceptance criteria provides context. Running a check against those criteria can produce backpressure. A permission boundary limits an action. These mechanisms often work together; knowing what each contributes helps you find what is missing when a run goes wrong.

Combine automated checks with review gates

A gate controls whether work may proceed to a particular action or stage. The team defines the conditions for passing it, who or what evaluates them, and when to escalate. Reviews can be performed by people, agents, or both.

Give deterministic checks the work they can reliably settle. A code-style checker applies the project’s coding rules; a complexity checker flags code that exceeds agreed limits. Repeating those checks through a reviewing agent adds time and cost. The reviewer should use their results and investigate questions the checks cannot answer.

For the dashboard, a security reviewer might discover that one request lets a user read another team’s support case. The code can pass style, type, and complexity checks while missing the permission check required for that request. Finding the defect requires understanding who may access which data and how that rule applies along the request’s path through the application. The reviewer’s finding may point to a single line of code. An architecture reviewer might instead question whether a service boundary fits the domain or whether the proposed design creates an operational problem. The reviewer investigates what the existing checks leave unresolved, at whatever level of detail the task requires.

A separate reviewer has an explicit job: challenge the proposed result, look for ways it could fail, and support each finding with evidence. It can question assumptions the implementing agent carried through its work. Research on self-correction has found that models can catch errors presented as someone else’s work while overlooking the same errors in their own output. Future models may assess their own work just as well. For now, I’d use independent review where the additional mistakes it catches justify its cost.

Run these agent reviews at a review gate. They consume too much time, computation, and context to repeat at the frequency of backpressure during implementation. Their feedback loop is review, findings, revision, and another review. During revision, the implementing agent continues to use the quick checks to correct its work.

Make the two work together. Give the reviewer the intended behavior, relevant constraints, the change itself, and the results of the automated checks. Let its findings determine what needs correction or a decision. When a finding can be captured in a reliable automated test, add that test. The missing permission check can then become a regression case that helps detect the same defect in later changes. Run the checks again after revisions, and have the reviewer assess whether the findings have been resolved and whether the revisions introduce other problems.

A fast test can also be a condition for passing a gate. For example, the same checks that guide the agent during implementation may have to pass before its change can be merged. The reviewing agent contributes the assessment those passing checks leave open.

Know what enforces a rule

The distinction between a behavioral harness and a structural harness concerns enforcement. Behavioral guidance tells the agent how it should work. Structural controls enforce a boundary through mechanisms the agent cannot change or bypass with its available access.

An instructions file might say, “Ask before sending a customer notification.” That helps the agent understand the intended workflow. Enforcement requires the sending tool or service to refuse the action until the required approval exists. A check that reports a duplicate notification after it has been sent detects the problem too late to prevent it. To enforce a frequency limit, the service has to check before sending, including when two attempts arrive together.

The same question applies to automated checks and reviewers. A required check is a dependable gate only if the agent cannot disable it, change the acceptance rule, or take another route around it. The team can authorize a reviewing agent to accept work within defined limits and refer other cases to a person. Its access, criteria, and place in the workflow determine how independent it really is. The agent producing the work must not be able to change the gate’s acceptance rules or waive a rejection.

Structural controls protect the boundaries you actually enforce. A sandbox may restrict access to production while allowing the agent to make a large, difficult change in its own workspace. That change still needs inspection. Use isolation to limit consequences, and choose the amount of delegated work so the result remains reviewable.

Make the result inspectable

You or the reviewer authorized by your team eventually has to decide whether to accept what the agent produced. The time and attention needed to make that decision are the verification cost. As you delegate more work, that cost can become the limit on how much you can handle.

For the dashboard, I’d want a working preview with representative cases, a short explanation of the changed behavior, the checks that ran, and any unresolved questions. I’d also want to change the inputs myself. A recording of the happy path would leave me with plenty still to find out.

Self-inspection and presentation help in different ways. When the agent opens the dashboard and discovers that the urgent case is hidden on a small screen, it has found a defect it can correct. A quick check automatically triggered on each preview update can supply backpressure. A screenshot or recording gives a reviewer evidence to inspect. Producing a demonstration can do both, because the agent has to exercise the result while assembling it.

Keep the evidence connected to the result being reviewed. Identify the version and scenarios it covers, and make the result available for further inspection. A polished demonstration can omit the difficult cases as easily as a rough one. Agreed criteria, trusted examples, and known bad examples give the reviewer a basis for challenging what they see.

Keep what the work teaches you

Feedback can correct the current attempt and improve future ones. is useful feedback preserved in a plan, a test, a decision record, or instructions that later work will use.

Suppose the dashboard broadly follows the corporate design but still feels inconsistent: spacing varies between screens, components are used with slightly different dimensions, typography shifts across contexts, and similar interactions are implemented in different ways. There may be an approved component library, but no sufficiently complete or enforceable design system for the agent to apply directly. Instead, it has to infer missing rules from scattered examples, existing screens, documentation, and local conventions. I’d inspect the trace, the record of the agent’s steps, including tool calls and their results. It might show that the agent followed a link in the project guide to an obsolete example, copied spacing from an isolated screen, or inferred a layout rule from a component that was never intended as a general pattern. Correcting that link and making the relevant usage guidance more explicit gives the next run a better starting point. A check for unsupported styling can also catch deviations while the agent works, but it should account not only for invented colors or controls, but also for inconsistent spacing, sizing, typography, and interaction patterns. If the trace doesn’t show which examples or rules the agent relied on, you’ll need more evidence before deciding whether the problem is an implementation error, incomplete documentation, or the absence of a design system that can serve both as a source of context and as a verifier.

Agent memory and skills, reusable instructions for carrying out a task, are places to retain this learning. Repeated failed commands, missing setup steps, and unnecessary retries show where those instructions need attention. An agent can propose a correction, and straightforward repairs can be delegated within agreed limits. Changes to acceptance criteria, permissions, or policy need review by whoever owns them.

Check the revised guidance and mechanisms on representative tasks, including cases that worked before. Keep the criteria independent of the agent proposing the change, and retain the version actually used. A saved correction preserves feedback. Evidence of better results on later comparable work supports a claim that the system improved.

Keep the active guidance small enough to use and current enough to trust. Preserve the reasons for rejected alternatives in decision records and retrieve them when relevant. An alternative rejected because a requirement changed may be useful later. Remove obsolete guidance when its reason has gone away.

Measure the effect of harness changes

There is evidence that changes around a model can improve results substantially. In February 2026, LangChain reported an increase from 52.8% to 66.5% on Terminal-Bench 2.0 while keeping GPT-5.2-Codex fixed. Its changes included guidance and mechanisms for verification, context delivery, and managing the time available. That result supports investing in the surrounding setup. How much it helps your work still needs to be measured on your tasks.

Harness Learning Enables Generalizable Test-Time Adaptation tests whether a model can learn to improve another model’s working setup. One model attempts reasoning and question-answering tasks. A second model uses feedback from those attempts to revise the harness code. The researchers found that this ability to revise the setup also helped on tasks it had not seen before. The models themselves stayed unchanged during those later tasks.

The experiments cover bounded research tasks. A team would need to evaluate the approach on its own work before relying on it. Costs need comparison too: the approaches in the question-answering experiment used different amounts of computation and feedback, even when they made the same number of proposals.

Retire a workaround when the evidence supports it

Some mechanisms compensate for limitations in a particular model or tool. In a talk on harness evolution, Jediah Katz describes logging when these temporary aids intervene and using the records to propose removals. That gives a team candidates to investigate.

Suppose you added a reminder that sends the agent to the approved component examples before it changes the dashboard. The reminder helped an earlier model that repeatedly invented its own controls. After a model change, it may add delay and context without improving the result. Compare the new model on representative tasks with and without the reminder, keeping the acceptance criteria and independent review unchanged. Include tasks that previously needed the reminder, and examine quality, correction effort, and total cost.

A reminder that rarely fires may be redundant, or the task mix may simply have changed. Check that the record captures its use and that the comparison covers the original problem. If quality holds and the saving is worthwhile, remove the reminder through the team’s release process. Keep the previous configuration so you can restore it if later work gets worse.

The approved components and the reasons for using them remain product context. Runtime reliability, permissions, and required checks have their own purposes. Evaluate each mechanism against the job it performs. Similar benchmark scores alone leave questions about cost and operating behavior unanswered.

The team needs time and budget to carry out these improvements. In the Factory chapter, the same slop example continues across many tasks: how to find recurring problems, decide what to invest in, and evaluate whether later work improves. Harness engineering supplies the technical changes. The team’s operating model makes their evaluation and maintenance a regular responsibility.