Agent Harness

The environment an AI coding agent operates inside: file access, shell, editor and rules.

An agent harness is the scaffolding around an AI model that turns it from a chat box into a coworker. It gives the model tools to read your repository, edit files, run commands, execute tests and open pull requests, plus the guardrails that keep those actions safe. The harness, not the model, decides what the agent can touch.

Why it matters to an indie builder: this is the layer where coding agents actually differ. Claude Code, Cursor, Codex, Cline and OpenCode all call similar models, so the real comparison is harness quality: how well they plan across files, how they handle permissions, how recoverable their mistakes are. Picking a harness is a workflow decision, not a model decision.

A concrete example: you ask for a feature that touches five files. A weak harness edits each file in isolation and breaks imports between them. A good one loads the relevant modules first, plans the change set, runs your test suite after editing, and reverts itself when tests fail. Same prompt, same model, very different outcome.

Common mistakes: running an agent with write access to everything on day one (start it in a branch with a clear task), letting it install dependencies without review (supply-chain risk is real), and treating agent output as reviewed code. The teams getting value treat the agent like a fast junior dev: tight tasks, tests as the referee, human eyes on the diff before merge. Langfuse and other tracing tools help here, because you can see exactly what the agent did step by step when something goes wrong.

If you are choosing one today, compare them on three axes: context management (how much of your repo the agent can reason over), permission model (what it can do without asking), and recoverability (how easily you undo a bad change). The agent-harness category page on IndieBoot lists the current field side by side.