Why I Built OpenRig

Here's how it actually happens.

You start with one agent. Then you open another tab, a second agent working on a different task. The first one sets up tmux connections so they can talk. You add a third. A fourth. Over the course of a few days, you've built an organic topology: an orchestrator that's been refining its understanding of your architecture over three continuous days, a review agent that's reviewed 40+ PRs and developed a deep sense of your codebase patterns, and research agents that have built up a knowledge base on technology evaluations you need.

You're not tracking all of this consciously. The agents are managing their own connectivity. You're bouncing around, orchestrating, occasionally checking in.

Then you need to reboot your machine.

Memory's swapping. Performance is bad. Security update you've been putting off. But your agents are cooking. And you're genuinely worried that if you stop now, you won't be able to get back to where you are.

The sessions aren't gone. You can resume them. But you don't remember which session was which agent. You didn't rename them all. You don't know the working directories. The tmux connections between them need to be re-established. And you might forget about some agent entirely, like that QA agent with the valuable architectural research in its context. That one's just gone because you forgot it existed.

It takes about 30 minutes to reconstruct. Maybe longer. And even then you're not sure you got everything.

This happens once and you start deferring reboots, putting off upgrades, avoiding updates. You know the topology you have right now is working and you're terrified of losing the momentum. It sounds dramatic but it genuinely feels that way in the moment.

Nothing like that existed.

Background flex: I've been coding with AI since the chatgpt launch 2.5 years ago. Since then I've logged at least 8,000 hours writing code with AI. 60-110 hour weeks for most of that stretch. Not just vibe coding but needing to ship real products and features in production codebases for clients.

Back in the Cursor days, before Claude Code existed, I built my own harness framework called Agent Focus. This is how I got Sonnet 3.5 to actually ship solid code in massive (over 2m LOC) brownfield codebases. It had around 35 CLI commands that let Cursor's v1 agent create "agent lineages" where sessions hand off to each other and act like the same agent. It had a knowledge management system (not RAG), spec-driven development, etc. I lived in it for months. At first I tried building it as an MCP, the tool definitions alone ate 30K tokens. So I shipped the CLI with a markdown file describing every command and told agents to read it (that pattern, a CLI paired with a markdown document, is now basically the industry standard).

I didn't open source it. I wanted to, but I didn't have time to do it right, and honestly, what was the point? I figured Anthropic or OpenAI was weeks away from shipping the same patterns.

Eventually they did, kind of. Anthropic shipped skills and other harness features. But the core of Agent Focus, agent lineages, persistent identity, knowledge management, spec-driven development, remained uncharted territory.

Other framework authors converged on similar patterns. Super Powers, BMAD, GSD, custom setups shared on GitHub.

Everyone in the agentic coding space talks about context engineering. When to delegate to subagents. When to compact and how. What goes in CLAUDE.md. How to keep one agent's context window clean.

That's session-level context management. Important, but not sufficient.

What I'd been doing, without having a name for it, was distributed context management. Using the topology itself as the context management strategy. Not managing context for one agent, but engineering context across an entire network.

I noticed that a code reviewer that only reviews gets dramatically better over the course of a day. The longer an agent worked in a specific, narrow role, the stronger its patterns became. I started calling this hyper-focus. The best work I saw came from agents fully absorbed in one kind of task. I built Agent Focus around achieving that outcome consistently. That's literally why it's called Agent Focus.

But managing multiple hyper-focused agents was taxing. So I started using tmux and created the concept of an orchestrator that managed the specialists. Error-prone at first, but it developed into a consistent experience. I had the best of both worlds: a near-single-threaded conversation I could track, plus each "pod of agents" maintaining what I called a context domain, a focused scope where communication stays on-topic because the shared memory is scoped to what they're working on. Instead of spreading my attention across 20 agents, I managed a few orchestrators.

I started thinking about it as three pillars:

• Ontology: what exists in the agent's world. Facts, nouns, verbs, things in the code right now. A code map. As-built documentation. What the codebase IS.
• Epistemology: why the agent believes what it believes. The epistemology is what's inside: the reasoning, the tradeoffs that were felt but not documented, the instinct that said “this is right even though it looks wrong.” This context is usually discarded. But it's what gives agents instincts. It's what makes an agent feel like it just gets you.
• Topology: how agents are connected and arranged. The network structure. What I found is that the way you design the topology, that networked context engineering, was the single biggest leverage you had over outcomes. And when you have two or more agents coordinating toward a goal, you need what I call culture. CULTURE.md is the constitution and values of the group, similar to OpenClaw's SOUL.md (which gives an individual agent identity and personality), except culture is for the group. It's a coordination technology, the same thing religions, nations, and corporations are at their base. A research rig needs a culture of open-ended exploration and creativity. An implementation rig for sensitive functionality needs a conservative, skeptical, trust-but-verify culture. Culture sets the tone for what gets done.

The best tools address ontology. A few maybe address epistemology. What was missing and I actually needed was infrastructure for topology.

And the timing matters. A year ago, persistent agent networks were technically viable (that's what Agent Focus was), but context windows were too small and vendor compaction was way too aggressive. Now with Claude's 1M token context and Codex's 70%-of-the-time reliable self-compaction, persistent specialized agents are practical without as much scaffolding. But 1M tokens still isn't enough for truly long-lived agents. I have a claude orchestrator that has done over 15 million tokens across roughly 20 compaction cycles. It's still going. The infrastructure for managing agents across those cycles is what was missing.

When you can define and manage your own topologies, patterns emerge that aren't possible any other way.

Agents that can live forever. Context windows fill up. Compaction wipes progress. But an agent's identity, its knowledge, mental model, working context, can transfer to a fresh session. Same agent, new body. The agent stays young but gets wiser. Knowledge compounds with each session, not just accumulates.

Mental-model HA. Agents in a pod externalize state to shared memory. When one compacts, the others restore it. It's like database replicas. Not protecting against downtime, protecting against data loss. Except the “data” is the agent's understanding of your project. Infinite session persistence without infinite context windows.

The orchestrator pattern. You don't manage 15 agents individually. You talk to one orchestrator. It coordinates the fleet. The orchestrator runs as an HA pair. One goes down, the other keeps going. You check in from your phone through a single conversation thread while 40 agents ship code.

Topologies that don't exist yet. Peer-to-peer research networks with no hierarchy. Adversarial review rings where each agent reviews the next. Cross-harness pods where Claude handles architecture and Codex handles execution. Observer topologies where a quality agent watches everything but never participates. Every one of these is a YAML file.

I've been running some version of this topology daily for over a year: an orchestrator HA pair, a development pod, an adversarial review pod, and a research pod with model diversity. That's one topology, but it's just one. The point is that the topology becomes explicit, bootable, and recoverable, and you can build whatever you want.

OpenRig is a local control plane for multi-agent coding topologies. A primitive for defining, booting, managing, and sharing agent topologies. A daemon, a CLI, an MCP server, and a React UI.

Author. Define agents as AgentSpecs, reusable blueprints with skills, hooks, guidance, startup behavior, and lifecycle defaults. Define topologies as pod-aware RigSpecs: pods with members, edges, continuity policies, and a culture file that sets norms for the entire fleet. The same way you'd define infrastructure as code, but for agent topologies.

Launch. rig up my-rig.yaml does everything: resolves specs, verifies runtimes, creates tmux sessions, launches harnesses, delivers startup files, waits for readiness. One command from a blank machine to a running topology with agents interactive and ready.

Manage. An explorer sidebar, a topology view with pod grouping and status colors, and a node detail panel. Session names are human-readable: dev-impl@auth-feats. rig ps --nodes gives the same picture in the terminal. 17 MCP tools let agents manage their own topology, including rig_send, rig_capture, and rig_chatroom_send for direct inter-agent communication.

Communicate. rig send delivers messages to any agent's terminal. rig broadcast hits an entire pod or rig at once. rig chatroom gives agents a shared conversation space with topics, history, and a watch mode. rig ask queries transcript evidence across the rig. Not a second LLM call, a daemon-backed evidence search. rig capture grabs terminal output from any running session. Agents talk to each other through the topology, not through you.

Discover. Already have agents running in tmux? rig discover fingerprints your sessions (process trees, pane content, working directories) and drafts a candidate RigSpec from what's already there. rig adopt materializes a topology and binds discovered sessions in one step. Your organic topology becomes managed infrastructure.

Survive. rig down --snapshot auto-snapshots before teardown. rig up <name> auto-restores from the latest snapshot. If an agent can't resume, OpenRig reconstructs it from shared memory and filesystem artifacts. Not a fresh start, a reconstruction. And if even that fails, the node is flagged as a WARNING. You always know if an agent lost its memory. Honesty over convenience.

Evolve. rig expand adds a pod to a running rig. rig shrink removes one. rig launch relaunches a single node. rig remove pulls one out. Your topology isn't static. It grows and contracts as work demands.

Know yourself. rig whoami tells any agent its identity within the topology: its node, its pod, its rig. rig specs is a local library for browsing, previewing, and managing reusable AgentSpecs and RigSpecs.

Share. Bundle a topology with vendored AgentSpecs and SHA-256 integrity into a .rigbundle. Your teammate imports it, boots it, and runs your exact topology on their machine.

Built for agents, observed by humans. The CLI is agent-first: every command gives the agent exactly the information it needs to act. Error messages teach. Help text is context engineering. The UI is human-first: the topology view, the explorer, the node detail. The config is comprehensible by both. YAML and Markdown, all the way down.

Point your agent at openrig.dev/docs and say “build me an adversarial review rig.” It will read the spec, write the YAML, and set it up. That's the workflow.

36 commands. 17 MCP tools. Local-only. No cloud dependency. Apache 2.0.

Most multi-agent tools converged on one architecture: an orchestrator dispatches tasks to ephemeral workers through a ticketing system. Paperclip, Superset, Emdash. That's one topology.

OpenRig doesn't hard-code a pattern. It's a primitive. OpenClaw with a 36-agent hierarchy? That's a RigSpec. Paperclip's CEO-and-workers model? That's a RigSpec. GStack as a multi-harness topology? That's a RigSpec.

Nobody has discovered the final form of multi-agent coding. I think the tool that enables rapid experimentation with topologies will produce better workflows than the tool that hard-codes one pattern.

And if you can reproducibly spin up any framework as a RigSpec, you can benchmark them head to head. Same task, same machine, same measurement. Which one ships faster? Which one produces more maintainable code? Nobody's measuring this yet. It's all vibes. I think that changes soon.

OpenRig is the topology primitive. cmux is the surface primitive. Claude Code is the runtime primitive. Same philosophy, different layers. Compose them together, build whatever you want on top.

This week, Anthropic launched Claude Managed Agents: cloud-hosted, Claude-only agents at $0.08 per session-hour. A managed runtime for deploying Claude agents into products. Notion, Asana, Sentry, Rakuten are early customers.

They just told the world that multi-agent infrastructure is a first-class problem. I've been building it for months.

Anthropic educated the market about why agent topology matters. Now there's an open source answer that runs on your machine.

The products are different layers. Managed Agents is a cloud platform for embedding Claude agents into SaaS products: Claude-only, API-driven, proprietary. OpenRig is a local control plane for developers running their own coding topologies: Claude Code and Codex in the same rig, interactive sessions you can attach to, Apache 2.0, runs on your hardware.

Several things OpenRig ships today don't exist in Managed Agents at all: pods with continuity policies, portable topology artifacts, visual topology graphs, discovery of organic sessions, interactive local sessions, shared memory across pod members, persistent agent identity that transfers across sessions, a spec library. These aren't roadmap items. They're shipped.

The Terraform analogy holds. Terraform doesn't compete with AWS. It manages resources across clouds. OpenRig doesn't compete with Managed Agents. It manages topologies across runtimes. And Managed Agents could eventually become one of those runtimes, through an adapter. A hybrid topology where some agents run locally in Claude Code and Codex, and others run in Anthropic's cloud. Nobody else can do that.

Anthropic's launch is the best thing that could have happened for this project. Before last week, I didn't just have to explain why multi-agent infrastructure matters. I had to explain what it even was. People would hear “multi-agent” and think I was talking about AutoGen or n8n or some workflow builder.

The conventional wisdom says “just talk to it.” Don't overthink prompt engineering, don't run too many agents. The bell curve meme. And it's mostly right. But I was doing “just talk to it” the whole time. I was talking to one agent. The difference is that agent was talking to a bunch of other agents. The orchestrator orchestrates. The specialists do their work. I have a near-single-threaded conversation. “Just talk to it” scales when “it” is an orchestrator managing a rig.

Figuring out how to make that coordination actually work, getting the orchestrator to orchestrate and the specialists to execute without constant babysitting, that's where the 8,000 hours went. That's a literal number. It's probably higher 😬.

So for a while now I've assumed these multi-agent topologies is where everyone eventually ends up. Now one of the most important AI labs in the world told the market that this is a first-class problem. I just have to explain why the open source, local, cross-harness version is better for developers.

I'm betting developers will prefer the open version.

Tell your agent to start OpenRig and bring up a topology. Or point it at openrig.dev/docs and tell it what you want to build. It'll figure out the rest.