Running teams of AI agents with Paperclip

Paperclip is an open-source control plane for AI agents. It sets agents up like the staff of a company: each one has a title, a manager and a job description, and the work arrives as issues. The code is on GitHub under the MIT license, published by Paperclip Labs since March 2026.

What fascinates me is the daily use. I hand Paperclip standing work, above all the upkeep of data, and it keeps that work going without me starting each job. I steer the agents remotely: from a laptop or a phone I read their issues, assign new tasks and answer their requests for approval.

A control plane, not an agent

Paperclip runs no model itself. It holds the org chart, the goals, the issues, the approvals and the costs, and it wakes an agent when work waits. The agent runs through an adapter. The repository lists adapters for Claude, Codex, Cursor, OpenClaw, Bash scripts and any HTTP service. Paperclip is a Node.js application with a PostgreSQL database. It runs on a laptop, in Docker or on a server, and one installation can hold several companies with their data kept apart.

The org chart

Every agent has a title, a manager and a scope. Humans sit in the same chart, so a task can go to a person or to an agent along the same reporting lines. A chief agent breaks a goal into issues and delegates them to its team, and each issue traces back to the goal it serves. Permissions and secrets belong to one company, and the org chart decides who may assign work to whom.

Issues and the audit log

Work lives in issues. An issue records the conversation, the tool calls of the agent and the result. The audit log is append-only: no entry can be edited or deleted. When an agent reports a number, I can follow the trace back to the query that produced it.

Heartbeats and routines

An agent does not run all the time. Paperclip wakes it with a heartbeat, the agent checks its queue, does the work and goes back to sleep. Routines add recurring work. A routine fires on a cron schedule, on a webhook or through the API, and each run opens a tracked issue for its agent. This makes Paperclip a fit for data work that never ends. A check or an import that comes back every week runs as a routine, and a failed run shows up as an issue.

Approvals and budgets

Decisions stay with people. The board approves new agents, can override a strategy, and can pause or terminate any agent. An agent can also stop and ask for approval on its own issue; it continues only after a person accepts. Each agent can have a monthly budget, and when it reaches the limit, it stops.

Remote administration

The web interface works on a phone. Paperclip also has an API, a command-line tool and an MCP server, so an assistant such as Claude can read and write issues on my behalf. That is how I assign a task or approve a step when I am away from my desk.

Skills and plugins

A skill is a set of instructions and tools that an agent loads for one kind of job. Paperclip versions skills, shares them across a company and tests them with evals. Plugins run as separate processes and extend the installation, for example with connectors to outside services.

How teams use it

Paperclip names no reference customers on its site. Its solution pages describe five uses:

• Engineering: agents work on issues, run QA with tests and screenshots, and keep the codebase healthy.
• Support: agents triage requests, draft answers from the documentation and escalate hard cases.
• Sales and marketing: research agents watch markets and content agents draft material behind an approval gate.
• Operations: weekly reports, invoice chasing, data hygiene and vendor follow-ups run as routines, and people see only the exceptions.
• Finance: agents produce scheduled reports under hard budget caps.

The Paperclip team runs the development of Paperclip on Paperclip. The repository passed 90,000 stars on GitHub in its first seven months.

What a control plane does not do

Paperclip organizes the work. The agents still execute it with their own permissions. The German consultancy P-CATION writes that a control plane “does not replace the security model of the connected agents, data sources, and tools” (P-CATION, April 23, 2026). Four rules come from my own work with it:

• A script that only reads the data checks every report, and the report carries the numbers of the script.
• Long jobs run detached and get polled, because a single run of an agent has a time limit.
• One agent has one job in flight.
• The setup enforces the rules that matter: agents work on a development system, production branches are protected, and a step into production waits for my approval.

The open question is which decisions can leave my queue without a loss of quality, and how to measure that.

An agent team keeps the data of an information platform current

In one of my client projects, a team of agents on Paperclip keeps the data of an information platform current. The agents manage themselves: a data chief hands each task to an idle agent of its team or creates a new one. They update the client’s records and reorganize them when the data model changes. Recurring updates run as routines, and each run is documented in its own issue.

Virtual organizations, autonomous agents and MCP are part of my research.