Three years ago "coding agent" meant an autocomplete plugin. Now it means a runtime that reads your repository, plans edits, runs tests and opens a pull request, and the interesting differences between products live in the runtime — the harness — not in the model they happen to call.

The category moved into the open this week: Earendil shipped Pi 1.0 as a "hardened, minimal, extensible agent harness", DeepSeek published a harness built around the idea that everything is a plugin, and Offrun positions itself as one workspace to manage every coding agent. Choosing between them is an architecture decision, so evaluate the architecture, not the demo.

01What a coding agent harness actually does

The model cannot read your files or run your tests. The harness does that and feeds the results back. In practice it owns four responsibilities:

• Context assembly — which files, diffs, logs and instructions enter the prompt, and what gets summarised or dropped when the window fills.
• Tool execution — the shell commands, file edits, searches and network calls the model can request.
• Permission enforcement — which of those calls run automatically, which need approval, and which are forbidden.
• Session state — what survives between turns, between sessions and between machines.

Everything else is packaging. When two harnesses feel drastically different on the same model, one of these four is why.

02The current options, honestly compared

The plugin-first designs are the most interesting and the hardest to assess, because once a harness loads third-party extensions, those extensions inherit its permissions. A plugin model is a supply-chain decision as much as a feature.

A plugin runs with the harness's permissions

An extension that can read files, run shell commands or call the network extends the blast radius of every model mistake. Treat the plugin registry like a dependency tree, not a theme store.

03Decide with seven questions

1. Which model can it run? If the answer is one vendor only, you are choosing a model, not a harness. Portability matters most over a two-year horizon.
2. How does it manage context? Ask how it handles a 200k-line monorepo: does it index, retrieve, summarise or blindly truncate?
3. What is the permission model? Prefer per-tool, per-path and per-command rules over a single "allow everything" switch.
4. Can it be sandboxed? Containers, read-only mounts and network egress rules turn an incident into an inconvenience.
5. Where does session state live? Local files, a hosted service, or your own database — this decides your data posture.
6. How do you review its work? A harness that produces reviewable diffs and logs fits a team; one that writes directly to the branch does not.
7. What does extension cost? Count the plugins you will actually need before you commit to a plugin-first design.

04Self-host it without handing over the repository

The deployment shape matters as much as the feature list. A defensible baseline:

• Run the harness inside a container with the repository mounted read-write and nothing else mounted at all.
• Deny network egress by default, then allowlist the model endpoint and the package registries you actually use.
• Keep credentials out of the container; inject short-lived tokens at call time if the agent needs them.
• Require approval for git push, package installs and anything that deletes files.
• Capture the full transcript so a reviewer can see every command that ran, not only the final diff.

# Shape of a restrictive agent policy: specific paths, explicit denies first.
permissions:
  read: ["src/**", "tests/**", "docs/**"]
  write: ["src/**", "tests/**"]
  shell:
    allow: ["pnpm test", "pnpm lint", "git diff", "git status"]
    deny: ["git push", "rm -rf", "curl"]
  network: ["api.example.internal"]

Deny rules belong above allow rules, because a pattern like pnpm * would otherwise swallow pnpm publish. This configuration is ordinary YAML or JSON, so format and validate it like any other config in your repository.

05Point it at a model you control

Model-agnostic harnesses earn their keep here. A harness that speaks the OpenAI-compatible chat API can point at a hosted model today and a llama-server instance on localhost tomorrow, without changing the agent workflow. If you run a local endpoint, remember that a smaller model needs more scaffolding: tighter context, more explicit tool descriptions and a stricter review step.

The reverse also holds. The biggest model in the world will not rescue a harness that dumps the entire repository into every prompt, because context quality beats context quantity in almost every real task.

06Evaluate on a real task in one hour

Skip the vendor demo and give every candidate the same job: a non-trivial bug in your own repository with a test that reproduces it. Score four things.

The harness that wins is usually the one with the fewest surprises, not the one that finished fastest on a curated task.

07Common mistakes and fixes

The honest summary: the harness is now the product. Pick the one whose permission model, context strategy and extension surface you can live with, then verify it on your own worst repository rather than the vendor's best demo.