Agent harnesses
Future Talk #5 — Agent harnesses (Claude, Codex, OpenCode)
The model is not the product anymore — the loop around it is
In earlier Future Talk posts I wrote about agents as a coming wave: software that acts on our behalf, not just answers questions. That wave is no longer speculative. What changed is not only model quality, but the harness — the CLI, IDE, and runtime that give a model tools, memory, permissions, and a place to work.
A harness is the difference between a chat window and an agent that can read a repo, run tests, open a PR, and recover from failure. Claude Code, Codex, and OpenCode are three answers to the same question: how do you put a strong model inside a disciplined work loop?
What a harness actually provides
Strip away branding and most agent products share a small set of concerns:
- Context assembly — what files, diffs, docs, and history the model sees this turn.
- Tools — shell, editor, browser, MCP servers, issue trackers.
- Policy — what it may touch, what needs approval, what is read-only.
- Persistence — session state, memory, skills, and project rules.
- Verification — tests, linters, builds, and human review before anything ships.
The model proposes. The harness constrains, observes, and often refuses on your behalf. That refusal layer is not a bug; it is how agentic work stays useful instead of chaotic.
Three styles: Claude, Codex, OpenCode
I am not ranking them as winners. I am mapping shapes of the same idea.
Claude Code leans into a coding agent that lives next to your tree: deep repo awareness, long sessions, and a strong bias toward multi-step engineering work. It feels closest to “pair programmer with a terminal.”
Codex (as an agent surface, not only the old model name) emphasizes structured coding tasks and integration into a development workflow — generate, iterate, check. It is the OpenAI-shaped bet that agents should be native to how software is already built and reviewed.
OpenCode sits in the open-source harness space: swap models, own the loop, and avoid locking your workflow to a single vendor’s UI. That matters if you care about portability of process, not just portability of prompts.
Different vendors. Same architecture problem: model + tools + policy + feedback.
Skills, rules, and the rise of “agent UX”
Harnesses are becoming programmable. Project rules (AGENTS.md and friends), skills, hooks, and MCP tools are turning “prompting” into something closer to configuration of a junior engineer.
That has second-order effects:
- Your repo becomes part of the product. Conventions that lived in people’s heads now need to be written down so agents can follow them.
- Reusable skills beat one-off prompts. The valuable artifact is the procedure, not the chat transcript.
- Preview and verification matter more. An agent that can edit fast must also fail closed against tests and review.
This is why “agent harnesses” belong in a Future Talk series. They are not a feature checklist. They are a new layer of software — between human intent and machine action.
What I am watching next
A few questions that will separate toys from infrastructure:
- Can the harness stay small? Bloated agents that do everything poorly lose to focused loops that do one job well.
- Will open harnesses keep pace? If OpenCode-class tools remain competitive, teams can treat models as interchangeable backends.
- Who owns the audit trail? Enterprises will demand clear logs of tool calls, approvals, and what changed — not just a final diff.
- How much agency do we actually want by default? Autonomy without a verification harness is just expensive randomness.
Closing
Future Talk #2 imagined swarms of agents representing people and systems. Harnesses are how that idea becomes daily practice for builders: not AGI, not magic, but repeatable agency wrapped around imperfect models.
The interesting competition is no longer only “which model is smarter?” It is “which harness makes the model trustworthy enough to leave running in my repo?”
… to be continued as I learn more by building with these tools.