An introduction to Paperclip

Most agent tooling answers "how do I run an agent". Paperclip answers a question that only appears afterwards: how do I manage eleven of them without losing track of what they are doing and what they are costing me.

It is an open-source, MIT-licensed, self-hosted Node.js server with a React UI, and the organising metaphor is a company. Agents get an org chart, roles, reporting lines, budgets, audit trails and governance controls.

The layer it occupies

Paperclip does not run the agent loop and it is not a model provider. It sits above whatever agents you already use, coordinating them.

It ships adapters for Claude Code, Codex, Gemini CLI, Cursor, Pi, OpenCode and OpenClaw. It is model-agnostic at the orchestration layer — the model is decided by the adapter and the agent configuration, not by Paperclip.

So the mental model is: you already have agents that work. Paperclip gives them an employer.

What the org-chart framing buys you

• Roles and reporting lines. Agents pass work to one another within a hierarchy rather than each running in isolation.
• Budgets. Cost tracked per agent against a central objective. If you have ever discovered a runaway loop via an invoice, the appeal is immediate.
• Audit trails. A record of what was done and by which agent — which is the difference between "the AI did something" and a reconstructable account.
• One dashboard. Planning, execution and reporting in one system rather than across several terminals.

The honest summary of the value: it is observability and governance for a fleet, packaged in a metaphor non-engineers can follow. That second half matters more than it sounds — an org chart is a thing a business owner can reason about without a tutorial.

Where the metaphor helps and where it misleads

It helps because org charts encode exactly the things a multi-agent system needs: who does what, who reviews whom, what each is allowed to spend, what happened.

It misleads in one specific way, and the "zero-human company" framing that follows the project around makes it worse. An org chart of agents is not a company, because the agents have no accountability. If a human employee makes a bad call, there is a person who owns it. If an agent does, the accountability sits with whoever configured it — which is you, regardless of how many boxes the chart has.

When it earns its place

Straightforwardly worth it when you are running several agents concurrently on related work and you have lost track of what they are doing or what they cost. That is a real and increasingly common problem, and Paperclip addresses it directly.

Also worth it when non-engineers need visibility. The org-chart UI communicates state to a business owner far better than a terminal does.

Not worth it for one or two agents. The coordination layer costs more than the coordination is worth at that scale, and you will spend your time configuring Paperclip rather than doing the work. This is the same judgement as picking a framework: adopt it for a constraint you can name.

Practicalities

Self-hosted, no account required, MIT-licensed. Being able to run it entirely on your own infrastructure matters here, because a system that coordinates agents sees everything those agents do — that is a lot of concentrated visibility to hand to a third party.

Two things to think about before adopting:

• It becomes a dependency. Once work routes through Paperclip, it is in the critical path. Self-hosting means that is your uptime problem.
• Budgets need testing. Cost controls are only useful if they actually stop a runaway. Verify the limit triggers before you rely on it, with a deliberately wasteful agent and a small ceiling.

Source and documentation are at github.com/paperclipai/paperclip.