Paperclip

Paperclip is for the person who thinks in headcount rather than tickets. It takes agents you already run, Claude Code, Codex, Gemini, Cursor, OpenClaw, Hermes, Pi, even a shell script behind an adapter, and puts them on an org chart where work flows down and reports flow up. The trait that decides it is governance: you approve, agents execute, and the UI looks like a company, not a terminal.

You need several agents with distinct jobs to justify it. Pick it if you do. Pick Gas Town if the job is one repository and a merge queue, and Claude Code alone if it is one agent.

The risk is unattended execution. Agents wake on scheduled heartbeats and on events like assignment or a mention, which means the system is designed to act while nobody is watching, and there is no container layer; whatever the adapter can do on the host, it does. A misconfigured heartbeat is a loop that starts at 3 a.m.

Run it on a machine you can unplug. What it does right: the board-approval workflow with review stages puts a human sign-off in front of execution, and the README's line is that nothing ships without it.

The documented mechanisms. 1. Scheduling: agents run on heartbeats and on events, and delegation moves down the hierarchy, so a manager agent assigns rather than executes. 2. Atomic execution: a task is claimed once, so two agents cannot pick up the same issue. 3. Persistent state across reboots. 4. Import and export of a whole company with secret scrubbing, which is a reproducibility feature nobody asked for and everyone will use.

No benchmark is published; the unit of work is an issue, not a patch, so none would apply. The observation: it is a workflow engine wearing an org chart, and the org chart is the interface, not the mechanism.

A corporation exists, Paperclip Labs, Inc., which is more than most projects here can say. The product is free and MIT, the repository has 79,958 stars, and the roadmap lists cloud deployments as in progress, so the revenue line is a hosted control plane that is not yet on sale. That is a plausible sequence, provided the round lasts until it ships.

Moat: the company model itself; once a team has agents on an org chart with budgets and history, moving them is a reorg. Likely acquirer: a work-management vendor, Atlassian or Linear, that wants agents as employees. Position: long, small.

The demo is a CEO agent delegating to a team. Procurement liked one thing immediately: monthly budgets per agent with hard stops, overspend pausing the agent and cancelling queued work, and token cost tracked by company, agent, project, goal and provider. That is a finance report I can hand over. What is missing is everything else: no SSO, no audit export named, no support line, and a Node.js 24.11 or newer requirement on whatever hosts it.

Sixty engineers would share one deployment, which is the right shape. It does not touch CI. Approved with conditions: a single hosted instance, SSO behind a proxy, and a retention review.

MIT, Node and React, and I can run it in Docker on a box in the closet. The adapter surface is the good part: besides the named agents there is a bash adapter and an HTTP or webhook adapter, and the README's rule is that if it can receive a heartbeat it is hired, so my own scripts and my local-model agent qualify without anyone's blessing.

The MCP gateway is marked completed on the roadmap, though the config for it is thinner than I would like. No model settings of its own, which is correct for a control plane. Forkable, readable, mine if I want it.