Suppose a coding model often announces completion immediately after editing a file. We add an external procedure: run a check after editing, and return failures for another repair. The system improves considerably. Later, after further training, the model checks, investigates, and retries on its own. The original procedure remains, but its role has changed. Understanding harness engineering requires accounting for that change in the model.
A harness is the working system built around a model. It connects tasks, context, tools, and execution environments so that successive model calls advance a shared objective. This includes execution work such as starting processes and saving files, as well as behavioral guidance such as arranging steps, prompting checks, and supplying experience. Both kinds often live in the same framework, yet model development can give them very different futures.
Capability gaps become targets for a repeatable process
Model improvement can increasingly be organized around concrete goals. Familiarity with a domain calls for relevant material; mastery of a procedure calls for good demonstrations; better choices in complex tasks call for environments that support execution, feedback, and evaluation. Developers gain methods for cultivating capabilities, turning today’s weaknesses into specific targets for the next round of work.
The surrounding system is valuable here. A procedure can supply a checking sequence the model cannot yet organize; people can supply experience, tools, or demonstrations for unfamiliar problems. With that support, the system can complete previously difficult tasks and generate better records of the process: what was visible, why an action was taken, and what the environment returned. Practices that once lived only in human experience or framework logic acquire examples from which a model can learn.
Selected and prepared for training, these trajectories give the model a chance to learn the practices within them. SWE-Gym combines repositories, executable environments, tests, and tasks to train software engineering agents, and releases agent trajectories. An execution environment both supports present work and supplies material for later model improvement. Better working conditions can help produce better models.
Product use can keep this process moving. Failures reveal new tasks and conditions; adding them to evaluation and diagnosing them identifies where to intervene. Improved systems and expert guidance produce better execution traces for the model to learn from. One route improves working conditions; the other changes the model’s future choices. They continually meet in real tasks. The harness changes with them: some practices have been learned, while new tasks require new support.
The example below follows “locate, edit, then check” through three stages. As you switch, observe who decides the steps and which facilities remain outside the model. The middle stage is common: a model can already do most of the work and needs only experience it can consult when relevant. Capability can migrate incrementally.
A fixed procedure schedules reading, editing, and checking; failures are returned for repair.
Complete the current step.
The system supplies the sequence.
A skill records useful diagnostic paths and checking criteria.
Read the skill when relevant, then organize the steps.
Experience remains available; decisions move into the model.
Supply the goal and the current project's constraints.
Locate, edit, check, and adapt after a failure.
Step-by-step reminders can shrink. Running the check still needs an environment.
Execution → selected trajectories → training → next model
Conceptual stages, not measurements of particular models. An independently required acceptance check still belongs in the system.Separate the two responsibilities inside a harness
Calling everything “the framework” quickly leads to a debate over whether it should grow thicker or thinner as models improve. Both can happen. A model initially needs extensive behavioral guidance; later, working independently for hours creates greater demands on state recovery, resource isolation, and scheduling. Changes in code volume obscure the shift in responsibility. Separating runtime infrastructure from capability support makes that shift visible.
Runtime infrastructure makes work actually happen under the system’s contracts. A model call is one step within it. Something must accept tasks, persist state, dispatch tools, await results, resume execution, and release resources. File access, the authority under which an action runs, and delivery gates also need concrete enforcement points. These responsibilities remain even if the model always makes the right judgment.
| Runtime infrastructure | What it actually owns |
|---|---|
| Tasks and scheduling | Task identifiers, event ordering, asynchronous waits, concurrency, cancellation, and timeouts |
| Execution environments | Files, processes, browsers, dependencies, temporary resources, and environment retention or reconstruction |
| Authority and isolation | Sandboxes, tool authorization, credentials, network egress, and boundaries between users and tasks |
| State and recovery | Durable records, checkpoints, action receipts, retries and idempotency, and artifact storage |
| Constraints and observation | Parameter validation, resource budgets, delivery gates, action logs, and preservation of source and trust information |
Capability support gives the current model better conditions for the current job. It addresses gaps between task demands and model performance: documents supply unfamiliar business knowledge, cases and workflows support unreliable judgments, and existing tools perform recurring precise operations. It also arranges context so relevant material appears when useful. Because this responsibility concerns doing the work better, it must be reassessed as tasks and models change.
| Capability support | What it supplies |
|---|---|
| Knowledge and context | Domain descriptions, current facts, retrieval references, and material relevant to the current step |
| Experience and memory | Previous cases, failure causes, applicability conditions, and reusable judgments |
| Methods and workflows | Suggested decomposition, checking sequences, continuation of long tasks, and additional attempts and selection when useful |
| Specialized tools | Verified calculations, transformations, queries, and operations packaged as callable actions |
These tables describe responsibilities, not folders that can be cleanly separated by name. A tool has both sides: its curve-alignment algorithm supplies capability, while authorization and cleanup belong to runtime infrastructure. Context compaction does too. The system can track input limits and preserve original records; deciding how to summarize without losing essential state involves learnable judgment. The useful separation is between decisions that can change independently.
- Prior training：Pretraining · mid-training · post-training
- Task and current context：Goals · facts · constraints
- Model：Interpret the situation; choose an action
- Capability support：Knowledge · experience · methods · tools
- Runtime and task environment：Execution · state · authority · recovery
- Actual outcome：Artifacts · state changes · traces
Runtime facilities enforce contracts; capability support helps the model choose well. Both serve the same task but change differently as the model improves.
Why can the same checking step remain—or disappear?
Return to the coding task. When an early model often skips verification, a system may force tests after every edit. That code is making a decision on the model’s behalf. Once the model can select checks appropriate to a change, the old workflow may instead trigger expensive verification for a wording edit. Removing the reminder returns a learned judgment to the model and removes work that existed to compensate for a particular weakness.
If the team requires every release to pass a particular acceptance suite, however, that check represents an external commitment. The model’s confidence cannot revoke it. The executor still needs to establish that the released revision matches the accepted result. The first kind of check concerns the model’s competence; the second concerns fulfillment of a system contract. They may initially share an implementation, revealing their different futures only as the model improves.
A practical test is to make two substitutions: Would this step still be needed with a model that always chose the right next action? Would its requirements change for a different user or organization? The first question exposes capability compensation; the second reveals authority, business rules, and organizational commitments. Then remove a reminder in evaluation and observe changes in success, cost, and failure types. Its continued usefulness is a question about current performance.
This shift is already visible in engineering practice. Anthropic’s Managed Agents architecture article describes context resets introduced for an older model that became unnecessary with a stronger one, and separates sessions, harnesses, and sandboxes into replaceable parts. Here, interface contracts can stay stable while internal guidance changes with the model.
As the boundary moves, engineering moves forward
Capability support will not all disappear neatly. Current maintenance records, one company’s conventions, and a user’s newly changed preference belong naturally in the task context. A precise, reliable program remains worth reusing even if the model could rewrite it. Training is well placed to absorb understanding and practices useful across tasks, while external systems retain fresh facts, local agreements, and executable capabilities. Internalization changes the division of work; a bare model is not the end goal.
The background that matters most to my understanding of harness engineering is that cultivating capability is becoming a process we can keep advancing. Establish working conditions in a domain, use external support to produce effective practices, and let training absorb what transfers. Runtime infrastructure supports a larger scale of work; capability support moves toward unresolved problems. Designing a harness requires seeing both today’s responsibilities and tomorrow’s possible transfers, so a temporary accommodation does not become an imagined permanent structure of intelligence.