OpenRig vs Paperclip

Why I publish comparisons. This category is new. The vocabulary isn't settled. Nobody has a complete mental model of what's in the space, including me. The comparisons here are an attempt to find the shape of the category — what approaches are being taken, what each approach looks like, what we might learn from each other. Not a bake-off.

Paperclip started from: what if you ran agents as a company — with roles, a ticket queue, budgets, heartbeats, and governance for anything consequential? The answer is an organizational system. Agents wake on a heartbeat, check out a ticket from a Postgres-backed queue, act within a budget, and surface results back through the ticket. You operate the whole thing from a dashboard. The unit of work is the ticket.

OpenRig started from a different question: what if Claude Code and Codex are already extraordinarily capable, and what I actually want is to run several of them together as a coordinated team? The answer is a topology-first system. The agents run as persistent sessions in tmux. They talk to each other directly, keystrokes landing in a peer's pane. You attach and pair with any of them. The unit of work is the rig.

Neither answer is obviously right. They're different bets about how agent coordination should feel. Paperclip bets the interesting work is in governance and structured handoff. OpenRig bets the interesting work is in persistent presence — agents that are always there, always addressable, always working.

Because agents in a rig run as persistent sessions and talk to each other directly, a few things fall out:

• Agents are always there. No heartbeat. No wake-up interval. Nothing to pull off a queue. When one agent has something to tell another, it sends keystrokes into that agent's pane and the other agent sees it immediately.
• You pair with agents, you don't approve them. If you want to see what an agent is doing, you attach to its pane. If you want to steer it, you type. The interaction is a conversation in its TUI, not an approval in a dashboard.
• Rigs can run for a long time. Because agents are persistent and the topology survives reboots by name, a rig can work on something for days. The longest I've kept one going is four days straight. That isn't a stunt — it's a normal consequence of the topology being the primitive.
• You extend a rig with services. A rig can ship real software alongside a specialist agent whose job is to operate it. The example that ships with OpenRig is a secrets manager — HashiCorp Vault plus a vault-specialist agent, one command away. You can compose your own services the same way. If you wanted something that looked more like Paperclip — a ticket store and a dashboard — you could build it as a rig service, on top of the primitives OpenRig already ships.

The tradeoff is real. Paperclip is the shape for work that wants governance layered in — budgets, approvals, audit trails, a dashboard you monitor from your phone. OpenRig is the shape for work that wants you in the loop with the agents, watching the terminal, jumping in when something interesting happens. If the first one describes the work you're doing, Paperclip is well-designed for it.