You probably don't need another agent harness

A harness is the code around a model. It is the loop that reads files, runs commands, asks for permission, keeps context and decides when to stop. I have written about what a harness is before. When people ask me whether they should build their own, my answer these days is: probably not. Orchestrate the ones that already exist.

The harness is not where you win

Anthropic, OpenAI, Cursor, Google and xAI all ship coding agents: Claude Code, Codex, Cursor's agent, Antigravity and Grok Build. These companies are heavily invested in their tools, and they tune each harness to their own models.

If I build my own harness, I compete with all of them on their home ground. I also take on the dull parts that nobody sees: tool calls, sandboxing, permission prompts, context limits and retries. Each new model release can then make some of that work obsolete, and I am back to catching up.

The part that is actually mine is different. It is how I plan work, which checks must pass, when an agent may merge, and which agent gets which task. That is orchestration. It sits above the harness, and it is where my own judgement adds something.

What orchestration looks like: T3 Code

T3 Code, from Theo Browne and the T3 team, is a good example of the idea. Its README calls it an "agent harness control surface". It does not try to be another agent. It controls the agents you already use: Claude Code, Codex, Cursor, Grok Build, OpenCode and Google Antigravity.

The setup tells you a lot about the design. You install each provider's own CLI and log in with it, for example codex login, claude auth login, agent login, grok login or opencode auth login. T3 Code then drives those tools and gives you one place to work with all of them. In the README's words, it works with your subscriptions on those tools.

This means the labs keep improving the harnesses, and the orchestrator benefits without doing that work itself. When Claude Code or Codex gets better, the tool that drives them gets better too.

What about the terms?

This is usually the first question, and it deserves a careful answer rather than a confident one.

Take Anthropic, because its Claude Code legal and compliance page is explicit. Subscription login through OAuth is meant for ordinary use of Claude Code and Anthropic's own apps. Third parties may not offer Claude.ai login in their apps, and may not route requests through Free, Pro or Max credentials for their users. Products that embed the Agent SDK should use API keys. The Claude Code binary must not be modified, and usage must not be resold or intermediated.

The same page also says this does not prevent an end user from signing in to the unmodified Claude Code binary with their own subscription.

So the most I would say is this. Drive the official CLIs, unmodified, logged in as yourself, for your own use. Do not proxy anyone else's subscription and do not resell usage. Terms vary by provider and they change, so read each provider's terms yourself, especially if you plan to build something for other people. None of this is legal advice.

Worried about depending on it? Fork it

The fair worry about any orchestrator is that you now depend on someone else's software, and their priorities may drift from yours. T3 Code addresses that directly. It is MIT licensed, and the README says: "If we ever go the wrong direction, we want you to have everything you need to fork".

That changes the risk. If it stops fitting the way I work, I can fork it, remove what I do not need and carry on. I do not have to start again from nothing, and I keep the parts that already work.

Or build a small one yourself

An orchestrator is a much smaller job than a harness. It starts sessions, passes a task in, reads events back, keeps track of state and decides what happens next. The hard agent work stays inside Claude Code, Codex or whichever tool you drive.

T3 Code is a useful reference for how to put one together. Its server depends on the Claude Agent SDK, and it has packages for the Codex app server and for the Agent Client Protocol. It even drives fx as one of its providers.

If you would rather write your own, Vercel has two pieces I would start with. fx, from Vercel Labs, is an open-source coding agent shipped as one small native binary, and it is built to be embedded: scripts call it with fx ask (add --json for machine-readable output), editors connect to it over the Agent Client Protocol, and JavaScript apps can run the same agent core through libfx with their own tools. It signs in with Vercel AI Gateway or a ChatGPT or Grok subscription. For the parts where you call models directly, such as planning or routing steps, the Vercel AI SDK is a sensible choice.

Whichever way you go, keep the layer thin. The moment your orchestrator starts reimplementing tool calls or permission prompts, you are back to building a harness.

My own rules live in astack, one plugin built for several agent clients. That only works because I do not own the harness. I own the instructions and the gates, and the harnesses do the rest. The checks I care about are in quality gates for AI-written code.

What I would do

1. Start with the harnesses you already pay for, and log in with their official CLIs.
2. Try an existing orchestrator such as T3 Code before you write anything.
3. If it does not fit, fork it, or write a thin layer with fx and the AI SDK.
4. Put your effort into plans, rules and checks, not into another agent loop.
5. Read the terms for each provider you drive, and keep to your own account.

The labs will keep making better harnesses. I would rather use them than compete with them.