The Model Org Chart: Staffing AI Coding Agents by Role

Somewhere around the third model subscription, I noticed I had stopped choosing a best model. I was staffing.

That is the short answer to the question I get most often about my development setup: which model should I use? Wrong question. The setups that actually ship software do not run on one model. They run on a small org chart of them, each holding a role matched to its strengths, including at least one model from a rival vendor. Here is the structure I run every day, why each seat exists, and how the cross-vendor seat gets wired in.

Why is "which model is best" the wrong question?

Because it assumes the job is one job. Building software with agents is at least four different jobs, and they fail in different ways.

Deciding what to build fails through shallow thinking. Coordinating the work fails through lost context. Doing the work fails through volume: small mistakes multiplied across many files. Reviewing the work fails through agreement, when the reviewer shares the author's blind spots.

A model that is spectacular at one of those can be mediocre at another, and more importantly, the economics are different. You want your most expensive, most deliberate model making a handful of decisions per day. You want your cheapest competent model making hundreds. Put your best model on everything and you get slow, expensive work. Put your cheapest on everything and you get fast, wrong work.

Good engineering managers already know this. Nobody staffs a team by hiring five copies of the best person they ever met. They hire against roles. The same logic, applied to models, is what made my setup click.

What does each seat on the model org chart own?

Here is the current staffing at my studio, using Anthropic's Claude family plus OpenAI's Codex. The names will rotate as the labs ship. The roles will not.

The architect gets the messy problem before anyone touches code. I bring it the ambiguous version: here is the situation, here is what I think I want, argue with me. It is called rarely, maybe a few times a week, and I want it opinionated. Its output is a plan a PM can execute, not code.

The project manager is the seat people underrate. It holds the plan, splits it into tasks, dispatches them to workers, reads what comes back, and decides what is actually done. Its value is less raw intelligence than continuity: one place where the full state of the work lives. When people complain that agents lose the thread on long projects, they are usually describing a missing PM seat, not a dumb worker.

The workers run in parallel and do the bulk of the labor. Fast, cheap enough to run several at once, and right most of the time when the task was scoped tightly. The discipline I have learned: when a task comes back wrong, blame the PM layer first. Nine times out of ten the ticket was vague, and a vaguely-briefed worker produces confident, well-formatted, wrong work at speed.

The outside reviewer is the seat most people never fill, and it is the one this post is really about.

Why put a rival vendor's model on the team?

Because two models from the same family nod along at the same blind spots.

Models trained by the same lab, on overlapping data, with similar preference tuning, tend to find the same things suspicious and the same things fine. Ask one Claude to review another Claude's diff and the review is useful, but it is a sibling reading a sibling. Ask Codex, trained by a different lab with different instincts, and it disagrees in different places. Sometimes it flags something real that the whole Claude side of the house sailed past. Sometimes it is wrong in an interesting way that tells me my prompt was ambiguous.

The point is not that Codex is better. On my work it usually is not. The point is that its errors are less correlated with my main stack's errors, and review value lives in that decorrelation. It is the same reason a second human reviewer from another team catches things your teammate does not: not smarter, differently blind.

How does Codex actually plug into Claude Code?

Through an open-source plugin OpenAI ships for exactly this: codex-plugin-cc. It connects the Codex CLI into Claude Code as a set of slash commands, so the cross-vendor seat lives inside the same session as everyone else instead of in a separate window you have to babysit.

The pieces, in the order you meet them:

• /codex:setup checks the wiring: that the Codex CLI is installed and authenticated, and lets you toggle an optional review gate that runs Codex over your work when a session stops.
• /codex:review is the everyday command. It hands your current diff to Codex for a read-only review. There is an adversarial variant whose whole job is to attack the change rather than summarize it.
• /codex:task delegates real work: describe a task and Codex goes off and does it while Claude keeps working. It runs read-only unless you explicitly pass a write flag.
• /codex:transfer uploads the whole session transcript to a Codex thread when you want the second opinion to have full context, not just the diff.

Two cautions from running it in production, because this is the part vendor documentation soft-pedals. First, the write mode runs without approval prompts inside its sandbox, which is the point, but it means you use it on a branch, never on main. Second, everything you send crosses to another provider. My rule is simple: my own repos are fine, anything covered by a client agreement never goes through it. Before installing, I also read the plugin source. It has no runtime dependencies and makes no network calls of its own; it talks to the local CLI over local sockets. That is the level of diligence any tool that can edit your files deserves.

When is a model org chart overkill?

Honest answer: often. A one-file fix does not need an architect, a PM, two workers, and an outside reviewer. It needs one competent model and thirty seconds. I still do plenty of work in a single session with a single model, and so should you.

The structure earns its cost when the work crosses a threshold: multiple repos, multiple days, or consequences you cannot easily undo. That is the point where a single context window starts silently dropping things, and where a wrong-but-confident change gets expensive. It is also where the agent orchestration methodology matters more than any individual model choice, because the failures stop being intelligence failures and start being coordination failures.

The other prerequisite is that you have already learned what good output looks like by working slowly yourself. A PM who has never done the work cannot spot a plausible-looking wrong answer, and that applies to the human at the top of this org chart too.

What should you actually do with this?

Three things, in increasing order of commitment.

If you use one model for everything, split one role out first. The cheapest win is separating planning from doing: make the expensive model write the plan, make a cheaper one execute it, and notice how much better the cheap model performs with a tight brief.

If you already run multiple agents, add the seat you are probably missing: the cross-vendor reviewer. The plugin makes that a ten-minute setup, and the first time it catches something your main stack blessed, the argument settles itself.

And if you are staring at a wall of model benchmarks trying to pick a winner, stop. Ask the manager's questions instead. Best at what? Next to whom? I learned that one hiring people, years before any of these models existed. The org chart came before the models did.

If you want help designing this kind of structure around your own team's work, that is what we do.