The agent is the strength. The harness is the control.

24 September 2026 · by Amady

<p class="lead">Why dev teams need a harness, not just an agent</p>

We've all tried an agent.

We gave it a task. It wrote code. Sometimes good, sometimes not.

Then we tried to put it in a real team. And that's when everything got complicated.

Who launched what? On which repository? With what access? Did anyone review it? Did the tests run? Is the result stored somewhere, or did it vanish with the session?

Nobody asked these questions two years ago. Today, they're blocking entire teams.

The model is no longer the problem

For two years, the race was about the model. The fastest, the most accurate, the largest context, the cheapest. Every month brought its share of announcements.

Today, the question has changed.

Models are roughly on par. Not perfectly: there are differences, sensitivities, strengths. But for 90% of development tasks, any mid-range model gets the job done.

What makes the difference is no longer what writes the code. It's what surrounds it.

What can it read? What can it modify? Which tools can it use? Who decides what is allowed? Where are the results kept? Who can see them? Who can stop it?

A model with no answer to these questions is not an agent. It's a text generator that touches files.

The word: harness

The word exists, but it's rarely used. It comes from the world of horses.

A harness doesn't create the horse's strength. It channels it, directs it, controls it. It turns raw power into a usable team. Without a harness, a horse remains a horse: powerful, unpredictable, useless for pulling a plow or a carriage. With a harness, it becomes an engine.

In AI, a harness is exactly the same thing.

It's everything that turns a model into a usable agent:

The tools it can call (files, shell, APIs, web search)
The memory it can keep (session, context, history)
The permissions it must ask for (before writing, before deleting)
The loops that keep it working (until the task is done)
The guardrails that stop it (turn limits, spending caps, prohibitions)

Claude Code has its harness. Copilot has its harness. Cursor has its harness. Every agent CLI has its own, more or less rich, more or less open, more or less documented.

That's why the same model can be unusable in one tool and excellent in another. The model doesn't change. The harness does.

But none of these harnesses is a team harness

This is where the problem begins.

Your agent CLI's harness works for you. It knows your machine, your files, your session. It is designed for a single user, on a single workstation, on a single task at a time.

Which means it doesn't know:

Who else is working on the same repository
That a colleague has already launched a review on the same MR
That a scheduled agent should run on one machine, not five
That a result should be shared with the team
That two people shouldn't pay twice for the same work

These questions aren't technical. They're organizational. And no individual harness answers them, because that isn't its job. It isn't even within its scope.

This is where teams break down.

We've all seen the scene: three developers, three agent sessions open, three reviews launched on the same MR because nobody knew the others had done it. Three AI calls billed. Three comments posted on the merge request. Three different reports, with three different grades.

Or worse: a scheduled agent running on three machines at once, three times a day, consuming three times the planned budget. Nobody notices until the end of the month.

Or again: a developer who has used up their quota and waits until tomorrow, while a colleague next to them still has three weeks of headroom. But nothing circulates, because sessions are tied to a machine, not to a team.

These problems aren't new. They're just invisible as long as you work alone. They become blocking as soon as there are three of you.

What a team harness must do

A team harness is the layer that answers the questions an individual harness ignores. It doesn't replace the CLI's harness: it frames it, secures it, coordinates it.

Concretely, it answers five questions:

1. Who executes?

An automatic review should only run in one place. A scheduled agent should have a designated executor. Otherwise, five machines left on produce the same work five times, the same bill five times, the same comment on the MR five times.

A team harness keeps a registry of executions. It knows what is running, where, and by whom. It prevents duplicates. It lets a blocked machine hand over to another.

2. Who validates?

No automatic merge. No unreviewed push. Agents prepare, humans decide.

This rule must not be a marketing promise. It must be enforced by the code. An agent must not be able to push, even if asked to. It must not be able to post a comment, even if its prompt says so. The guarantee must be structural, not declarative.

A team harness is what makes this guarantee possible.

3. Where are the results?

Sessions, reports, rules, verifiers live somewhere. Not in a terminal that disappears when you close the window. Not in a local file nobody can find three weeks later.

A team harness keeps results in a known place. Accessible to those who need them. Versioned so you can reread an earlier review, compare two passes, understand what changed.

4. What circulates?

Review rules, verifiers, agent profiles, domain maps: these are the team's products. They are meant to be shared. A code map costs hours of agent time to produce; rebuilding it on six machines means paying six times for six slightly different answers.

But sessions, drafts, personal todos, the questions you ask yourself: these are work traces. They aren't meant to circulate by default. Everyone decides what goes out.

A team harness makes the distinction. It shares what should be shared, it keeps private what should stay private. And it asks, every time, before circulating anything.

5. What never leaves?

API tokens, absolute paths, secrets, session identifiers. Each machine keeps its own access. The work circulates, not the credentials.

This rule must be verified automatically, not left to everyone's discipline. A secret committed to a shared repository is a lost secret. The tool must refuse, at the source, what must not leave.