If you use several coding or operations agents, the hardest problem quickly becomes coordination. Work lives in separate terminals, state disappears between sessions, budgets are difficult to compare, and nobody can see which task is actually blocked.
Paperclip is an open-source coordination and governance layer for external agent runtimes. Its company metaphor is useful: roles, reporting chains, goals, tasks, approvals, budgets, adapters, and heartbeats. It does not create an autonomous, zero-employee company. Humans still define the mission, grant access, approve consequential changes, and own the result.
Use the current Paperclip documentation and official repository for installation, license, runtime versions, and service configuration. Those details change. I removed the old five-minute setup and roadmap claims rather than publish stale commands.
The features that matter
1. Roles and reporting chains
Each agent gets a responsibility, instructions, and a supervisor. The structure helps route decisions; it does not grant expertise. Keep job descriptions narrow enough that a reviewer can tell when an agent acted outside them.
2. Goal alignment
Company goals connect projects and tasks to an outcome. A good task explains why it matters, but also names non-goals and prohibited actions. Agents should not reinterpret the company mission to make a local task easier.
3. Heartbeats
Agents wake on configured schedules, look for work, perform bounded tasks, and stop between heartbeats. This lifecycle is easier to observe than a process running forever. Set retry limits and make an empty queue a normal outcome.
4. Budgets
Budgets make intended spend visible and can constrain work. They are not a universal promise that every provider charge stops instantly. Test how the current adapter reports usage, what happens near a limit, and how delayed provider accounting is handled.
5. Persistent tasks and discussions
Work is represented as tasks with threaded context. This creates an inspectable record of assignments and decisions. Do not claim every external tool call is traced unless you have verified the exact adapter and logging path.
6. Runtime adapters
Paperclip coordinates external agents rather than replacing them. Different runtimes have different authentication, tool access, state, and cost semantics. An adapter is a boundary to test, not proof of equivalence.
7. Multiple companies
One installation can organize more than one company context. Treat separation as an application feature whose data and authorization behavior must be verified. Do not promise perfect isolation or audit completeness without deployment-specific evidence.
8. Human governance
Hiring agents, changing strategy, increasing budgets, and approving consequential actions belong to a human control plane. Versioned configuration helps review changes, but the rollback and incident path still needs testing.
A safe first setup
Follow the current repository instructions and pin the version you deploy. Start with a local development instance and non-sensitive data.
Create one company and one narrow goal. Add an operator agent with read-only repository access. Give it a discovery task that produces a report—not a code change. Review its work, permission attempts, event history, and cost reporting.
Then add one specialist and one approval-gated implementation task. Require tests and a separate review before integration. Practice pausing both agents and revoking their credentials.
The right mental model
Paperclip can make ownership, state, spend, and approvals visible across agents. That is valuable. The dashboard is not the company, and the agents are not employees.
Think of it as an operating console for delegated software processes. Give those processes less access than a person, make their work inspectable, and expand the organization only when a smaller version has earned trust.
