Paperclip explained: an operating layer for teams of AI agents
Paperclip explained: an operating layer for teams of AI agents
Map goals, agents, tasks and budgets before giving an autonomous team its first assignment.
What you will learn
- The work it tries to organize
- A heartbeat is a scheduling contract
- Keep the board in control
Before you start
- Node.js and agent runtime basics
- A test company with non-sensitive tasks
Turn the source review into a bounded experiment with stop conditions.
Key takeaways
- Paperclip coordinates external agents rather than replacing them.
- Heartbeats need an explicit reason and outcome.
- Budget and isolation claims need local tests.
The work it tries to organize
Paperclip combines a Node.js server and React UI around companies, goals, roles and work items. The README describes a way to coordinate agents that already exist; it does not provide a new foundation model.
A useful first scenario is a small editorial team: one agent drafts a summary, another checks a source, and a person approves release. That scenario exposes the handoffs that a single chat window hides.
A heartbeat is a scheduling contract
Agents may wake on a schedule or event, inspect work and report a result. The org chart specifies reporting lines, while issues and goals give a reason for each run. Record what caused a wakeup before judging whether its output was useful.
The project advertises budget stops and audit trails. Those are upstream claims until exercised against a real instance. This series inspected a fixed source commit and did not run agents.
Keep the board in control
A person should decide which actions require review, what an agent may spend and which data it may see. Paperclip has approvals and scoped budget policies, but neither setting substitutes for a clear operating rule.
Start with one company and synthetic tasks. Add a second company only after testing company scoping and membership yourself. Do not infer isolation solely from the UI.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Sketch one goal, two agents and a human reviewer.
- 2
Give each agent a task and a spending ceiling.
- 3
List the actions that require approval before any run.
Copy-ready example
Goal: publish one cited brief
Agent A: draft from approved sources
Agent B: verify citations
Board: approve publication
Budget: set before first heartbeatFrequently asked questions
Does Paperclip supply the model?
No. The README describes adapters for agents and model runtimes you bring.
Is a dashboard an approval boundary?
Only if roles and approval routes are configured and tested for your workflow.
Sources
- Paperclip / README.mdSource checked 2026-09-26