Plan first, then route: orchestrating an AI SDLC across agent harnesses

A harness is not a strategy

A harness is the software around a model. It runs the loop that reads files, executes commands, asks for permission, holds context and decides when a task is finished. Anthropic ships Claude Code. OpenAI ships Codex, which is available as a CLI, an IDE extension and a cloud service. Each vendor tunes its harness for its own models.

For most companies that is a good reason not to build one in house. A home-grown agent loop has to compete with the vendors on their own ground, and it inherits the unglamorous work of sandboxing, permissions and retries. The layer a company genuinely owns sits above the harness. It covers how work is planned, which checks must pass before a merge, who or what is allowed to merge, and which tool is given which task.

Harnesses behave differently

Give the same task to two harnesses and the work that comes back is noticeably different. In our experience the differences are consistent enough to plan around, and we route work accordingly.

Our preference for implementation is Claude Code running Claude Opus 5.5. Anthropic released Opus 5.5 on 22 September 2026 and describes it as "built for long-running agentic coding and knowledge work". Once a plan has been agreed and the job is to carry it out over many steps, that is the quality we want.

For review we prefer a model from a different lab. OpenAI recommends GPT-6.1 Sol for complex coding and agentic work in Codex. Its Max setting gives the model more time to reason, and OpenAI's own guidance is to keep Max for the hardest problems because it is slower and uses more of your allowance. We think a review of a large or risky change qualifies. Codex can also run without an interactive session through codex exec, so a review step fits naturally into a pipeline.

We should be clear that these are working preferences. They are not benchmark results, and we expect them to change. Anthropic alone has shipped five Opus releases since February 2026, the latest being Opus 5.5 in September. At that pace, routing is better written down as policy than left to individual habit, because policy can be updated in one place.

A second opinion from somewhere else

An agent reviewing its own output tends to carry the assumptions it used to write it. A separate model, given only the plan and the diff, has no attachment to the approach that was taken. Human teams avoid having an author approve their own pull request for much the same reason.

Agent review does not remove the need for people. What it changes is where their attention goes. Engineers can spend less time on routine diffs and more on the points where the two agents disagree, which in our experience is often where the real risk lies.

Where the effort should go

When we help a team shape its AI SDLC, most of the effort goes into planning, since everything downstream depends on it. A plan that agents can work from usefully contains:

• Scope and done criteria. What changes, what must stay untouched, and how anyone will know the work is complete.
• A route. Which harness and model handle each step, at what reasoning setting, and the reason for the choice.
• Gates. Tests, static checks and an independent review that must pass before anything merges.
• A way back. The last known good state each step can return to if a check fails.
• Instructions kept in the repository. Repository rules written once can be picked up on every run. Codex, for instance, reads AGENTS.md files before it starts work, and other harnesses have their own conventions.

A plan of this kind is quick to write and easy to revise. Code produced without one usually costs more to correct later.

Governance includes the routing

Several harnesses bring several sets of terms, data-handling commitments and credentials. Anthropic's Claude Code documentation, for example, distinguishes subscription sign-in, intended for ordinary use, from API keys for anyone building products or services on top of it, and it does not allow usage to be resold or intermediated. OpenAI and other vendors set their own rules, and they are worth reading closely. Before agents work on production code, someone should know which accounts they run under, what data they can reach and who is accountable for what they merge.

We treat this as part of the plan itself. The routing table records which tool handles which work and under which agreement, and the review gate leaves a record that can be audited later.

What changes for the business

The benefits seldom show up in a single week. They come from agent work becoming predictable.

Expensive reasoning gets spent on review and on genuinely hard problems, while routine edits run on lighter settings. When a better model appears, adopting it is a change to the routing policy, and the team does not have to relearn its process. Reviewers spend their time on disagreements and risk. And because the plan, the rules and the gates belong to the company, it is not tied to any single vendor.

Where the field is going

Vendors are starting to build orchestration into their own tools. Ultra mode in Codex, for example, splits a task across subagents. We expect more of this and think it is a good thing. Some questions will still sit with the company, though: what the work actually is, what counts as finished, how much risk is acceptable and who signs off. Those answers belong in the plan, and a vendor cannot supply them.

How Comonad helps