Paperclip is the management layer people reach for when they already run OpenClaw, Hermes, Claude, Cursor, or a pile of custom workers and have lost track of who is doing what and what it costs. Nimbus is the finished product those operators log into: one shared workspace for a job, specialist teams, official playbooks, and a record of what shipped.

Paperclip is multiplayer for agents. Nimbus is multiplayer for departments and the people in them. The insight behind Paperclip is correct. Multi-agent chaos is an organisation-design problem, not a prompting problem. If you have lived through “we have twelve automations, three chat bots, and a coding agent fleet,” Paperclip feels like relief. Someone finally named the org chart. Relief is not a workplace. An org chart of agents is a start. A signed-off outcome in a workstream is the product those agents would work in, not the scheduler that wakes them.

Paperclip is an open-source app to manage AI agents for work. You define a goal, “hire” agents into roles, set monthly budgets, and run work through tickets. Agents wake on a schedule and stop when they hit the budget. The code is public; you can run it yourself. It works with many agents — the site lists Claude, Codex, Gemini, Cursor, Hermes, OpenClaw, and others. If a worker can receive a heartbeat, it can be hired. CrewAI and MetaGPT are the research-and-builder names for that orchestration category. Paperclip is that category as a product you hire into.

Words you’ll hear

Paperclip. An open-source app to manage AI agents for work. You define a goal, “hire” agents into roles, set monthly budgets, and run work through tickets. Agents wake on a schedule and stop when they hit the budget. The code is public; you can run it yourself.
Orchestration. Coordinating several agents. CrewAI and MetaGPT are the research-and-builder names for that category. Paperclip is that category as a product you hire into.
Agent budget. Cap the worker, warn at 80%, pause at 100%. Necessary cost control. Not the same as stopping a bad write.
Workstream. In Nimbus, a shared workspace for one job — the ticket a non-engineer can actually run.
Agent teams. AI specialists grouped like departments: finance, go-to-market, ops. You are not wiring a cluster of other people’s bots on day one.
Wiki. Official playbooks those teams must respect.
Write-back. Changing a live system. Paperclip’s FAQ is frank: it governs what agents do to Paperclip (hiring, strategy). Your agents are your own, and you secure them however you want.
Lifecycle Graph. What ran, who approved, and what changed — so next quarter’s team does not relitigate the exception from Slack archaeology.

Why the difference matters

The limitation is structural. Paperclip assumes you bring the employees (the agents), the tools, the memory, and the identity story. That is honest. It is also why a scheduler is not the product your board logs into. You still need a place work is grounded, a place writes are gated, and a place the company remembers.

A worker that hits its budget and stops is a cost control. A worker that hits production with the wrong SKU is an incident. Nimbus also caps spend so a long-running job cannot silently burn the month (metered in NTUs — work credits). The extra loop is change control: which system a write hits, who signs, where the artefact is stored. See governance. Cap-at-100% is necessary. It is not the same as stopping a bad write.

Paperclip does not replace a knowledge layer. Each hired agent may remember differently — Hermes how-to notes here, OpenClaw files there, a folder nobody owns. Different agents will each tell you a different last quarter. Nimbus ships wiki plus connectors plus the Lifecycle Graph so execution has one place to read from and a gated place to write to. Paperclip’s FAQ is frank: it governs what agents do to Paperclip (hiring, strategy). Your agents are your own, and you secure them however you want. That frankness is a virtue. It is also the gap. Write-back into Salesforce is not Paperclip’s job unless you built it into the workers you hired.

Speed of new agents is exactly why a scheduler appears. It is also why a scheduler is not the office. A staff rota does not replace the workplace. It only says who is on shift. OpenClaw and Hermes are employees. Paperclip is the org chart. Nimbus is the company plus the office. Buying all three still does not give you a Lifecycle Graph unless Nimbus (or something like it) is in the stack.

Role by role: an engineer running OpenClaw, Hermes, and a coding fleet will feel Paperclip as relief — budgets, tickets, a heartbeat. A Head of Ops should not be asked to assemble that roster on day one; they need a product they can log into. Finance cares that a pause-at-budget is not a pause-at-bad-journal. Security inherits whatever each hired agent can already do; Paperclip does not secure them for you. A COO comparing open source versus a hosted product is choosing which lock they can staff: Paperclip reduces vendor lock-in and increases ops lock-in. Most companies can complete a vendor review. Few can run a round-the-clock agent operations desk.

If you are committed to those workers and only need orchestration, Paperclip is in-category. If you are not building an OS, do not start with the scheduler. Treat the workers as prototypes. Recreate the jobs as Nimbus workstreams and agent teams. Leave the old bots as personal tools without production credentials. Do not lift-and-shift tickets. Lift-and-shift the operating loop.

When Paperclip is a better fit

Choose Paperclip when you are committed to OpenClaw, Hermes, or custom workers, you have people to operate them, and you only need orchestration. Choose it as a research scheduler in a lab. Choose it if your company is building an agent OS and you need that scheduler while you build the rest.

If you are not building an OS, do not start with the scheduler. A staff rota does not replace the office. It only says who is on shift.

Paperclip’s value shows up when you have several different workers to coordinate. Nimbus’s value shows up at one team that must touch production systems safely. You do not need Paperclip if you only have one agent. You might still need Nimbus.

Do not put a second org chart on top of Nimbus. Nimbus already assigns work to agent teams. Two budgets and two sources of truth is a support nightmare. If you migrate, migrate jobs, not tickets.

How this shows up in Nimbus

Nimbus is the application layer a Head of Ops opens without assembling a roster of third-party bots on day one.

You attach connectors under a read-only default. Humans release writes. You get specialist teams and a canvas, then you attach systems. See agent teams and workstreams. Spend is capped in NTUs so a long-running job cannot silently burn the month — and the write still waits for a signer.

Start at the overview.

Questions people actually ask

Is Nimbus “Paperclip with a nicer screen”?

No. The overlap is control: roles, budgets, assignment. The product is the work loop and the graph. A ticket router does not give you official playbooks or a read-only-default CRM connector.

Can Paperclip orchestrate Nimbus?

Unnatural. Nimbus already assigns work to agent teams. A second org chart on top is two budgets, two sources of truth, and a support nightmare.

Open source vs a hosted product — which lock-in is worse?

Paperclip reduces vendor lock-in and increases ops lock-in: you staff the bots. Nimbus is the reverse. Pick the lock you can actually staff. Most companies can complete a vendor review. Few can run a round-the-clock agent operations desk.

Do we need Paperclip if we only have one agent?

No. Paperclip’s value shows up when you have several different workers to coordinate. Nimbus’s value shows up at one team that must touch production systems safely.

How does Paperclip relate to OpenClaw and Hermes?

OpenClaw and Hermes are employees. Paperclip is the org chart. Nimbus is the company plus the office. See Nimbus vs OpenClaw and Nimbus vs Hermes. Buying all three still does not give you a Lifecycle Graph.

Can we migrate from Paperclip to Nimbus?

Treat the workers as prototypes. Recreate the jobs as Nimbus workstreams and agent teams. Leave the old bots as personal tools without production credentials. Do not lift-and-shift tickets. Lift-and-shift the operating loop.

Does a budget cap replace write-back governance?

No. A worker that hits its budget and stops is a cost control. A worker that hits production with the wrong SKU is an incident. Caps are necessary. They do not quote a field change or name a signer.

Who should run Paperclip if we keep it?

Whoever already operates the bots — usually engineering. Do not hand a Head of Ops a scheduler and call it a workplace. If operators need to finish a job, they need Nimbus. If engineers need to wake a fleet, they may still want Paperclip in the lab, off production credentials.

What is multi-agent AI, What is an AI workstream, and Nimbus vs OpenClaw.

Nimbus vs Paperclip: An Org Chart for Other People’s Bots, or a Product a COO Can Log Into?