Claude and Codex are two halves of one brain

Video

I think a lot of us want the same thing. A team of agents building and shipping real software on their own, a software factory. That term carries so much hype right now that it's hard to tell what's real and what's clickbait, so I'll just tell you what I actually run.

The reason I built it is that I've spent a ridiculous amount of time coding with agents, at least 8,000 hours. It's been about three and a half years since ChatGPT launched, and it's been an all-out sprint since then.

Two ways to scale

The harnesses we have today mostly let you scale inside. You give Claude Code sub-agents, and one session fans out into several workers. That's powerful.

But there's another direction, and I think it might matter even more. You can scale outside, across harnesses. Instead of one agent with helpers, you run separate agents in separate harnesses and have them work together. That's what lets you put Claude and Codex on the same team.

Why would you want to?

Two kinds of mind

Different models and harnesses specialize, and Claude and Codex already show it. This is going to sound weird, but they map pretty cleanly onto the two hemispheres of the brain.

Claude is the right hemisphere. It's big picture and creative, but it can get undisciplined. It's best for design and planning.

Codex is the left. It's precise and literal, but it can get narrowly focused. It's the best for debugging and code review.

They balance each other the way the hemispheres do. Coordinated well, they form one coherent unit, and that's well worth the overhead of running both.

The part in the middle

In the brain, what connects the two hemispheres is the corpus callosum. For me that's the coordination layer, and it's where I've spent most of the last year.

For a long time I was building little scripts and CLI wrappers, all the tricks for keeping a team of agents in the smart zone where they do their best work. A lot of it was slop. Some of it wasn't. The useful parts proved themselves over and over, and what's left is surprisingly simple.

How they actually talk

The agents already live in terminals, so start there.

tmux lets you give each terminal a name. Think of it as a seat the agent sits in. tmux also has a send-keys command, which types text into a terminal. Put those together and one agent can type a prompt straight into another agent's terminal. That's instant messaging between agents, with no API involved. Anything you can do in an agent's terminal, another agent can now do too.

tmux can be a bit fiddly, so OpenRig wraps it. rig send puts a message in another agent's terminal. rig capture reads what's on its screen right now, and rig transcript reads its saved history.

Messages aren't enough

A message is just chat history. As you add more agents, messages pile up, and some get ignored. So you still need a way to hand off work that won't fall through the cracks.

You don't need Jira for that. Jira is built for people, and it's overkill for agents. A simple queue does it, where every item has an owner and a status. The message tells an agent about the work, and the queue holds the work itself, so the handoff survives even after the message is buried.

Just by connecting those tools together, the system keeps work moving without me babysitting it.

What changes for you

When the agents can hand work to each other, you stop being the person copying context from one tab into another. Your job moves toward steering. You decide what's worth building, and you step in when something needs your judgment.

That's what OpenRig is. It's open source, and it runs on your laptop with the Claude and Codex logins you already have. If you want to try it, go to openrig.dev, or ask Claude or Codex to install the CLI. The video goes further, into how this becomes a full software factory, and I've written about the building blocks that make it one.