Running a company of AI agents with Paperclip

In May and June 2026 I set up part of a client’s information platform like a company whose staff are AI agents. The tool is Paperclip, an open-source control plane for AI agents under the MIT license. This post describes the setup and four lessons from the first jobs. I apply them to every agent I work with today.

What Paperclip does

Paperclip is the control plane and runs no agent itself. It keeps the org chart, the goals, the issues and the approvals, it can cap the monthly cost of each agent, and it wakes an agent with a heartbeat when work waits. The agent then runs through an adapter. In this setup every agent is a Claude Code process on the project’s server, next to Paperclip and its PostgreSQL database.

The org chart

I set the company up between May 29 and June 10, 2026. The roles were final on June 3: a CEO agent, three chiefs for data, technology and marketing, and an engineer under the technology chief. Every agent has a first name, and the name of a new agent starts with the first letter of its chief.

There is one delegation rule: a chief never executes. One task goes to one agent. The chief assigns an idle agent of its team or creates a new one, and it never assigns to a busy one, so ten tasks mean ten agents. Each code agent works in its own git worktree on one feature branch per issue, commits under its own name and opens a merge request for me. With this rule no agent is booked twice, and every task has a clean workspace.

The gate before production

The development environment is autonomous. Every change in production needs my confirmation. An agent that wants to touch production puts a confirmation card on its issue and stops. If I accept, Paperclip wakes the agent and it continues. If I reject, I have to give a reason, and the agent stays asleep. I answer these cards from a phone browser, each time anew.

For code the gate holds even if an agent ignores it. The production branches are protected, so an agent’s key cannot push to them.

The first job, and a report that was wrong

On June 3, 2026 the agents took their first job from development to production: assign each of 1,832 records of one city to its district. One agent did the work on the development system, raised the confirmation, and ran production after my approval. 1,831 records got a district, which is 99.95 percent. The last one lies outside every district boundary.

The work was correct and the report was wrong. The agent reported 10,481 records and 17.9 percent coverage, because it had counted the whole metropolitan area. Since then a read-only verifier script measures the result against the city only and exits with an error for any other area. The agent copies the numbers of the script into its report word for word. If my number differs from the agent’s, mine wins and the agent runs again.

A run and a task have separate clocks

A run has a hard ceiling of about 240 seconds. I raised the timeout of the agents to 600 seconds, and the ceiling stayed. About half of the runs of those days ended as “timed out” while the task went on. The cause of the longest delay was small. A configuration file ended the script without a message, the agent got no database credentials, and it spent run after run on a query that takes 0.3 seconds. Long jobs now run detached and get polled, or they become child issues.

One job in flight per agent

On June 10 a chief assigned five jobs to one agent. The agent ran five imports in parallel, in one worktree and against one development database. The delegation rule forbade this, and the chief broke it. I moved the jobs to one per agent and wrote the limit down a second time: one job in flight per agent.

Rules in prose do not bind an agent

The agents on Paperclip start with permission checks bypassed, so the hooks that block dangerous commands in my coding sessions do not fire there. Production is protected by the setup. Agents are dispatched to the development system only, the scripts check their environment themselves, the production branches are protected, and the confirmation card waits for me. Paperclip also cannot resume a terminated agent, so I never terminate one.

What I use today

Paperclip still runs on the project’s server and holds the issues of the platform. In June 2026 I put an OAuth gateway, built with FastMCP, in front of its MCP server, because that server speaks stdio only. Since then Claude on my phone reads and writes the issues. I switched the scheduled rollout of June off on September 6, 2026. The coding now runs in parallel sessions of Claude Code and Codex in one repository, each in its own worktree, under hooks that block the dangerous commands.

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

Virtual organizations are one of my topics at the Claude Hacker House workshops. My research notes are on Virtual organizations of autonomous agents, and the rules for coding agents are on AI agents under the same rules as humans.