You tell me, but I think a lot of us want the same thing. A team of agents building and shipping real software, on their own. In other words, a software factory. Unfortunately, this term carries a lot hype, so it's hard to tell what's real and what's clickbait. But, here's a real deal honest to goodness self-driving software factory. This is a fleet of regular claude code and codex agents working together to do real software development end to end with very little steering.

They run in the terminal so a regular claude subscription will always work. This is OpenRig. Its open source. Its just a daemon, a cli, and a web ui running on your laptop. Whats interesting is the core building blocks for this kind of software factory are deceptively simple. The reason I built this is that I've already spent a ridiculous amount of time coding with agents, at least 8,000 hours. So the math on that is it's been about two and a half years since ChatGPT launched, and it's been an all-out sprint since then.

Today the current harnesses let you scale mostly internally with sub-agents. this is powerful. but scaling externally is maybe even more important, because it lets you team claude with codex or any other agent. different models and harnesses specialize. claude and codex already demonstrate this. this is weird, but they map pretty cleanly onto our model of the left and right brain hemispheres. claude is the right hemisphere: big picture, creative, but can become undisciplined best for design and planning. codex is the left: precise, literal, but can get narrowly focused.

But its the best for debugging and code review. They balance like hemispheres; coordinated well, they form a coherent unit, this is well worth the overhead. That coordination layer, like a corpus collosum in the brain, is where I've focused the bulk of the last year. For a long time I was just building little scripts, CLI wrappers, you know, the tricks to keep teams of agents in the smart zone where they do their best work.

A LOT of it was slop. Some of it wasn't though. The useful stuff proved itself over and over, and eventually these distilled into a core set of primitives. Once those primitives started working together, I realized I wasn't just improving the code these agents could write, I was building a substrate, for a software factory. There's just 4 main primitives. The first one is the rig. The easiest way to understand a rig is to start with one agent.

An agent isn't just a model. It's a model sitting inside a harness, all the tools and memory that let it actually do work. A rig is the harness that wraps a whole team of those agents into one durable nameable thing. A harness for harnesses. Some call this a meta-harness. And because a rig is just a config file, you can run those teams like infrastructure. Almost like Docker, but for agents. If you want to run more than one agent, tyou have to solve coordination.

How do separate agents actually talk to each other? This is simple. Just use tmux. The agents already live in terminals. Tmux lets you assign a handle to each terminal, this is like a named seat the agent sits in. Then theres the send keys command. It lets one agent directly type prompts into the terminal of another agent. Combine these and you get instant messaging between agents. Tmux can be a bit fiddly, So OpenRig wraps this with the rig send command, so it's easy to use.

Theres no api, anything YOU can do in the agent's terminal, another agent can now do it too. rig capture reads another agent's live screen. rig transcript reads its saved history. That gives you the basic backbone: agents now have ergonomic tools to talk to each other. But these messages are ephemeral, they are just chat history. And as you add more and more agents, messages can pile up and can get ignored. So you still need a durable way to send work that won't fall through the cracks.

Not Jira, that's built for humans and overkill for agents. Just a simple queue is all you need, where every item has an owner and a status. Combine rig send with rig queue and thats a reliable handoff between agents that just works. So just connecting these tools together and now the system keeps work moving without me babysitting. The third primitive is workflows. These are for when you need deterministic rails for the work agents do.

A workflow is also a YAML config file. The daemon enforces it. Planner agent writes a spec, it gets routed via the queue to a an agent that implements it, which then get routed to an agent that tests it. The queue carries the work through the pipeline, not you. you dont have to track all this in your head anymore. the agents write these workflows themselves. I realize this isn't the first time you've seen this, what's unique is how simple it is.

Workflows are often paired with a rig watchdog. It's basically the clock. But it can keep agents awake and working for weeks if you want. Think of it like /loop, except it works for both Claude and Codex. The fourth primitive is workspaces. Agents use the filesystem to organize their thoughts over longer time frames. A lot of what we call harness engineering is really workspace engineering. Plugins, skills, steering docs, progress files, in predictable folder locations.

This has become a full on control plane written in markdown. All this can get hectic real quick. Your folder convention sounds trivial but its super important. The wrong shape can guarantee a mess that will confuse your agents and kill your project. The right shape tho keeps their thinking organized and transferable, so a fresh agent can be productive immediately, nothing needed from you. I took this seriously and made this is a simple primitive to make this easy and repeatable.

The first win from thinking this way was the rig scope command. In one move, it creates a ticket thats trackable in the system along with a folder setup to use as a workspace for the slice of work. The Markdown in these folders generates this web ui you can use to check progress and look at proof the work is done right. Super simple, sometimes brittle, but it works. Once you have those primitives, now you just compose them.

The rig is the team. The workspace is where they think. Coordination is how they talk. Workflows make the handoffs deterministic. Put those together, and a self-driving software factory is straightforward. Your job collapses to mostly one thing. Steering. You define a roadmap, hand it off, and watch. Step in when something needs your judgment. This is where the concept of altitude comes in. You decide how much to trust the agents on a given task, and then you manage by exception, which means you stay up high while things are running fine, and you drop all the way down into a terminal the moment you need to.

The level of autonomy becomes a dial you control. It turns out once you have these primitives in place, you can turn that dial one more notch. A few months ago I ran this experiment on OpenRig to see if it could do recursive self improvement. I already had a build rig going, the one that bootstrapped the first version. I then added a dedicated product management rig to write better specs. Then I added a dogfood rig to stress test things 24/7.

Then I just routed the feedback to product management and... the loop closed. It ran this way continuously for a few weeks. Well, it got stuck on rate limits more than a few times, but when those cleared it just resumed and kept going. In RSI mode, you aren't really building software anymore, it's more like you're growing it. I've since dialed it back to mostly self-driving mode. I need better guardrails in place before I do that in a public project, but The github tells the story, currently shipping about as fast as it can without getting my claude account banned.

So what's it actually like to use? Most of the time, you're talking to one agent. The orchestrator. You tell it what you want, it rig scopes the work into missions and slices, writes the specs, and hands the pieces to the right rigs. A build rig builds, the reviewers review, and you get proof at the end. Step in only when something needs you. This Linkpix project is a good example. It was a half-built project, I thought might make a good low stakes demo video so you could see it in action.

It was like the flick of a finger and it built this roadmap and started building. I realize a single claude could have one-shotted this nowadays, but the point is that this project could continue building on its own like this for months. Maybe I'll make a follow up video to show that. So that's the thing I want to make normal. Not just one impressive agent, but a real software team you can run locally on your laptop and scale it into the cloud.

OpenRig is open source. If you want to try it, go to openrig.dev, or tell Claude or Codex to install the CLI.