Make the Harness Fit the Work

A coding-agent harness is not a neutral window around a model. It decides which tools the model can use, how much of a repository it can see, when instructions enter context, where permissions interrupt execution, how concurrent work is isolated, and what evidence appears before the agent declares a task complete.

Those decisions create a workflow. Installing a popular harness therefore means adopting more than an interface. It means adopting someone else’s answers about autonomy, interruption, context, verification, and review.

That can be a useful starting point, but it should not be the end of the design. The best agent workflow is unlikely to arrive intact from another developer’s configuration because their work does not have the same boundaries, failure costs, repositories, or demands on attention. The durable advantage comes from owning the development loop and making each harness fit it.

The Harness Is Part Of The Coding System

Model comparisons encourage us to attribute most agent behavior to the model. The model matters, but it does not act on a repository directly. It acts through commands, observations, context management, permission rules, and feedback chosen by the harness.

The SWE-agent study demonstrated how much that surrounding interface can matter. Using the same GPT-4 Turbo model on 300 SWE-bench Lite tasks, its complete agent-computer interface resolved 18% of issues compared with 11% for a shell-oriented agent. Removing its custom editor reduced resolution to 10.3%. Removing lint feedback reduced it to 15%, while replacing a bounded 100-line file view with the entire file reduced it to 12.7%.

Those results do not establish one ideal interface for every model or repository. They establish the more important point that the interface changes the capability of the complete system. Search, editing, observation size, error feedback, and context history were not conveniences around the model. They changed what the model could accomplish.

The same principle applies to everyday agentic development. An agent with a formatter after every edit behaves differently from one that encounters formatting only in CI. An agent working in an isolated worktree can be allowed to range farther than one sharing a checkout with unfinished human work. An agent that must show a passing focused test before returning has a different definition of done from one that stops after producing a plausible patch.

Own The Loop Before Choosing The Features

Harness customization becomes decorative when it begins with a list of features. Hooks, skills, subagents, MCP servers, permissions, notifications, and status displays can all be useful, but none says what the development loop is meant to protect.

The stable loop is simpler:

1. State a bounded outcome
2. Load relevant context
3. Execute within explicit permissions
4. Verify against repository evidence
5. Return a reviewable result
6. Preserve only decisions that must survive

The implementation can change while those requirements remain. One harness may use a specialist agent where another uses a command. One may enforce an operation with a lifecycle hook where another relies on a wrapper script. One may create worktrees itself while another calls a local issue tool. Feature parity matters less than preserving the workflow guarantees that made the feature useful.

I built issues around this distinction. A task has a bounded outcome, an owner, and a location. Work can begin in an isolated worktree, and a handoff records what changed, what remains, and which decisions must survive the session. None of those ideas requires one particular model or harness. The tool gives different agents a shared operational boundary instead of expecting every conversation to reconstruct the same workflow.

Start with the transition that should be reliable, then use the harness mechanisms available to produce it.

A Portable Skill Is Not Portable Behavior

Skills make the difference between files and behavior especially visible. The Agent Skills specification defines a portable directory containing metadata, instructions, and optional scripts, references, and assets. Calling the resulting skill portable can still mean three different things:

Package portability

Another harness recognizes the directory, metadata, and files.

Content portability

The instructions, references, and scripts can enter the model's working context.

Behavioral portability

The complete system selects and applies the skill in a way that produces an acceptably similar result.

The specification standardizes the first, and compatible loading mechanisms can support the second. It does not define equivalent execution across agent implementations; even its allowed-tools field is experimental and may vary by implementation. The third is an observed property of the complete system. It depends on when the skill is selected, how instructions are prioritized, which model interprets them, what tools are available, where permissions intervene, and how completion is verified.

A skill is therefore not reusable code in the ordinary sense. Code has defined semantics inside a compatible runtime. A skill influences a probabilistic system operating through a harness. Two harnesses can accept the same skill package while producing materially different development behavior.

Installation is not the acceptance test. The useful questions are behavioral: Was the skill selected for a representative task? Did the agent retrieve the necessary references without flooding context? Did it follow the non-obvious constraints? Did it run the required verification and return something a developer could review? A portable file is valuable, but only the resulting behavior tells us whether the workflow traveled with it.

This suggests a practical split. Stable project knowledge and intent belong in the portable skill. Harness-specific discovery, enforcement, permissions, hooks, and integration belong in a thin adapter around it. Moving to another harness then means rebuilding that adapter and evaluating the behavior, not assuming that copying the directory completed the migration.

Personal Automation Has A Different Cost Now

Developers have always modified their environments. In a 1991 study, Wendy Mackay followed the customization behavior of 51 people using a Unix software environment over four months. The study describes the basic cost directly: time spent customizing is time not spent on the work at hand, so many people leave available customization unused.

Coding agents reduce both costs. They can inspect an unfamiliar configuration surface, adapt an example, write a wrapper, connect an API, diagnose a broken script, and migrate a helper after an upstream change. A workflow improvement no longer needs a large audience or years of use to repay several days of implementation.

That changes the economics of one-user software. A launcher command, handoff helper, status surface, repository script, or harness adapter can remain tightly fitted to one person’s attention and project mix. It does not need general configuration, onboarding, cross-platform support, or a product roadmap to be worthwhile.

This is one consequence of the distinction in Cheap Software Still Needs Product Judgment. A useful piece of software does not automatically deserve to become a product. Agentic coding makes narrow personal tools cheaper while leaving the cost of generalizing, supporting, and maintaining a product largely intact.

The useful return does not come from owning the most elaborate setup. It comes from noticing repeated friction, building the smallest intervention, using it in real work, and deciding whether it reduced enough attention to keep. Each retained improvement can make the next piece of product work and the next workflow improvement easier.

More Configuration Can Make The Agent Worse

The low cost of customization also makes unnecessary configuration cheap. A developer can generate a repository overview, ten skills, several hooks, a hierarchy of subagents, and a dashboard before any repeated failure has shown that the workflow needs them.

A 2026 study, Evaluating AGENTS.md, tested repository context files across several coding-agent and model combinations on SWE-bench Lite and a new 138-task benchmark. The tasks came from Python repositories, and success meant producing a patch that passed the benchmark tests. Within that scope, adding context files did not significantly improve task resolution and increased inference cost by more than 20% on average. The agents generally followed the instructions, explored more, and ran more tests. More compliant activity did not reliably produce more completed tasks.

That result does not make repository guidance useless, and it does not directly evaluate complete skill packages. The benchmark also cannot establish whether context files improve maintainability or compliance with requirements that its tests did not measure. Developer-written files significantly outperformed generated ones, but did not significantly outperform having no context file. The authors recommend retaining non-standard practices that are not already available in ordinary repository documentation. The result imposes a better standard: guidance should change behavior that needs changing, not summarize information the agent could retrieve when it becomes relevant.

The same standard applies to the rest of the harness. A hook that prevents a recurring unsafe action has a job. A worktree rule that isolates concurrent edits has a job. A skill that preserves a non-obvious architecture boundary has a job. Another layer that merely causes the agent to read, reason, and report more has created motion rather than convergence.

Borrow Ideas, Not Entire Workflows

Shared harnesses still matter. Other developers discover useful patterns, and good defaults let people begin without designing a complete agent system. The mistake is treating someone else’s successful flow as evidence that its full shape belongs in every environment.

One developer may want an agent to work independently until focused tests pass. Another may need a question before every schema or interface change. Someone working across many repositories needs different context retention and navigation from someone who stays in one service for months. A flow designed for disposable experiments should not inherit the permissions of one used against production infrastructure.

The transferable unit is often the idea: isolate concurrent work, keep verification close to edits, preserve decisions outside chat, or interrupt before irreversible operations. The local implementation should reflect the actual cost of failure and the way its owner reviews work.

Personalization still needs a boundary:

Personal coordination preference

Customize freely and keep an easy bypass.

Team development contract

Make the rule visible, reproducible, and independent of one person's setup.

Production behavior

Treat it as maintained software with explicit ownership and verification.

A private harness should customize how someone reaches the shared contract. It should not silently redefine that contract. Otherwise personal leverage becomes hidden infrastructure that colleagues cannot reproduce and the team cannot inspect.

Customization Has To Pay For Itself

The old failure mode was spending an afternoon repairing a status line to save a few seconds later. Agents reduce the manual work, but they also make it possible to begin ten speculative improvements without feeling their full cost. Every helper can add another process, state store, permission, notification, dependency, or failure mode.

The return should be measured in convergence rather than customization count: fewer agent turns before a verified result, fewer human corrections, less review time spent reconstructing intent, fewer repeated failures, and less rework after integration. The time spent building and maintaining the harness belongs in the same accounting.

A useful rule is to wait for friction to repeat before automating it. Give the intervention a small budget, require a visible failure mode and an easy bypass, then keep it only if it removes more attention than it consumes. Some helpers should be deleted. Others should remain private. A few will encode a shared requirement clearly enough to become part of the repository or team workflow.

The developers who benefit most will not necessarily have the most customized environments. They will be able to distinguish a product default from a deliberate workflow decision, change the decision when it does not fit, and evaluate the result without mistaking activity for improvement.

Models and harnesses will keep changing. A workflow copied from someone else will change with them. The more durable skill is knowing how work should move from intent to verified result, then making the available harness support that movement instead of reorganizing the work around whatever flow arrived in the box.