Paperclip

The first wave of agent dashboards mostly answered a simple question: what are my agents doing right now?

That was useful. It was also incomplete.

Once you have several agents working across projects, the harder questions are organizational. Which goal does this task serve? Who owns it? Which agent is allowed to act? What did the run cost? Who approved the plan? What happens when two agents reach for the same work?

Paperclip is an open-source, self-hosted attempt to answer those questions. It looks like a work-management app, but its real job is to provide a control plane above a team of AI agents.

That distinction is what makes Paperclip more interesting than another Kanban board.

The Product in One Sentence

Paperclip organizes agent runtimes as a company.

You create a company, define goals, group work into projects, add agents with roles and reporting lines, and assign issues. Agents wake on schedules or events, check out work, operate through their own runtime, and report activity back to Paperclip.

Paperclip does not try to be the model, the coding assistant, or the general-purpose agent. It sits above those systems.

The project makes the distinction directly: if OpenClaw is an employee, Paperclip is the company. That framing holds up. OpenClaw, Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Pi, Hermes, shell processes, and HTTP services can all be connected through built-in or external adapters. Each runtime still does its own work. Paperclip provides shared structure around it.

That structure includes:

• company and project goals
• an org chart with roles and reporting lines
• issues, comments, plans, dependencies, and approvals
• scheduled and event-driven agent heartbeats
• budgets and cost tracking
• run history, activity records, and audit trails
• workspace and secret configuration
• multiple companies in one deployment

This is a more ambitious product than a task board. It is trying to be the operating layer for a mixed team of agents.

What the Hands-On Test Showed

I tested the current stable release, v2026.722.0, in an isolated temporary environment.

The advertised quickstart worked:

npx paperclipai onboard --yes

On a machine with Node.js 20 or newer, that command configured a local instance, started an embedded PostgreSQL database, and served the application on loopback. I disabled telemetry for the test and did not provide a model or agent credential.

From there I created a temporary company, added a company-level goal, created a project tied to that goal, opened a high-priority issue, and added a comment. The issue readback preserved its project and goal context, and the activity feed recorded the company, goal, project, issue, and comment creation under the local board user.

That sounds basic because the test was deliberately small. It still revealed the product's central strength: the work objects are connected instead of merely placed on a board.

The issue was not just a card named “Compare dashboard and harness roles.” It carried an identifier, priority, project, goal, responsible user, execution state, workspace fields, blocker relationships, and an audit trail. Paperclip had already created a managed project directory even though I had not connected a repository.

I did not connect a paid model provider or run a live agent during this review. That means I verified installation, information structure, API behavior, and activity recording—not long-running autonomy, cost accuracy across providers, or recovery from a real failed agent run.

That boundary matters. Paperclip can make agent work more legible. It cannot make an unreliable agent reliable by surrounding it with an org chart.

Where Paperclip Adds Real Value

Paperclip is strongest when you already have capable agents and the coordination layer is becoming the problem.

Work has a reason, not just a status

Most task boards can tell you that an issue is in progress. Paperclip can attach that issue to a project and trace the project back to a goal.

Agents receive that ancestry as context. The intent is to prevent a team from completing isolated tasks while losing the reason those tasks exist.

This is the practical version of giving an AI a bounded job. The published note What It Means for AI to Have a Job describes roles in terms of inputs, tools, authority, review points, and failure behavior. Paperclip turns several of those ideas into product objects.

Multiple runtimes can share one operating model

An agent harness decides how an agent reasons, uses tools, and executes a run. Paperclip coordinates work across harnesses.

That matters if one team uses Codex for a repository, Hermes Agent for another workflow, OpenClaw for ongoing operations, and a simple HTTP service for a narrow task. Paperclip can treat them as different employees inside the same company instead of forcing every job into one runtime.

The adapter choice affects the experience. Native ACP-capable adapters can provide structured progress, tool calls, and status events. CLI adapters expose what their command-line stream provides. Generic process and HTTP adapters may show mostly raw output. “Bring your own agent” is real, but the depth of visibility depends on what that agent can report.

Coordination is enforced, not implied

Paperclip documents atomic issue checkout and execution locks. That is not glamorous, but it is the kind of detail multi-agent systems need. Two agents should not silently perform the same expensive or destructive task because they saw the same card.

Budgets, pause controls, approval stages, and scoped agent configuration add more boundaries. The system also distinguishes the board user from agent identities in its activity records.

These controls do not remove the need for sandboxes, careful tool permissions, or human review. They give those controls a place in the operating model.

Paperclip Versus a Kanban Inside an Agent

Some agent products now include task boards. Hermes Agent ships with a Kanban-style interface. OpenClaw can connect to external work systems and coordinate persistent agents. Coding tools increasingly expose parallel sessions, plans, and worktrees.

If one of those systems already holds all of your work, adding Paperclip may create another layer to maintain.

The case for Paperclip becomes stronger when the board is not the point.

A harness-owned Kanban usually helps organize work for that harness. Paperclip is designed to manage several harnesses, represent reporting relationships, enforce budgets and approvals, and keep company-level context outside any one agent session.

That makes it closer to an agent operations console than a prettier ticket list.

The tradeoff is complexity. Paperclip has companies, goals, projects, agents, issues, heartbeats, adapters, workspaces, secrets, policies, plugins, and deployment modes. Those pieces create leverage for a real multi-agent operation. They are overhead for someone who wants one coding agent to finish one repository task.

Paperclip's own documentation is candid on this point: if you have one agent, you probably do not need it.

Setup Paths

The easiest path is the npm quickstart. By default it creates a trusted local deployment bound to loopback, with no human login required. That is appropriate for a single operator testing on one machine.

Paperclip also supports authenticated private deployment for a LAN, VPN, or tailnet, and authenticated public deployment for cloud hosting. Storage can remain local or move to external services. The embedded database removes friction for evaluation, while an external PostgreSQL database is available for a more durable deployment.

There are two broad ways to connect agents:

1. Let Paperclip invoke the runtime. Local adapters can start supported command-line agents for a heartbeat and collect their output.
2. Connect an agent that already runs elsewhere. Gateway, HTTP, invite, and plugin paths let an existing service join the company without making Paperclip its underlying harness.

That second path is important for OpenClaw and Hermes deployments that already have identity, tools, memory, or messaging configured. Paperclip can coordinate them without pretending to replace them.

The setup is still operator work. Remote gateways need reachable URLs, authentication, pairing or invite flows, and careful secret handling. A dashboard does not erase networking.

Costs, License, and Project Pace

Paperclip is MIT licensed and developed in public, self-hosted, and does not require a Paperclip account for the local quickstart. The stable npm package I tested was 2026.722.0, matching the latest stable GitHub release from July 22, 2026.

The repository is moving quickly. New commits were landing on the day of this review, and the npm registry already exposed August 8 canary builds beyond the stable release.

That pace is encouraging and cautionary.

It means integrations and missing pieces are improving quickly. It also means screenshots, adapter behavior, configuration options, and roadmap claims can age quickly. For a production deployment, I would pin a stable version, read the release notes, back up the database, and test upgrades before letting an unattended agent team depend on them.

Self-hosted does not mean cost-free. You still pay for the machine, database or storage if externalized, model usage, agent-provider subscriptions, and the human time required to review and maintain the system. Paperclip's budget controls can make those costs more visible; they do not eliminate them.

Telemetry is enabled by default in the stable quickstart. The project says it excludes prompts, issue content, file paths, secrets, and personal information, and it documents several ways to disable telemetry. Operators with strict privacy requirements should verify those settings rather than assume a self-hosted product sends nothing.

Who Should Use It

Paperclip is worth a serious look if:

• you run several agents or several agent runtimes
• agents work on recurring or delegated tasks without constant supervision
• goals, budgets, approvals, and audit history are becoming harder to track
• you want a self-hosted control plane instead of a hosted SaaS account
• you are willing to operate the coordination system itself

It is probably too much if:

• you have one agent and a small task list
• your existing project tracker already provides enough visibility
• you want a system that invents a reliable organization automatically
• you do not want to manage credentials, networking, upgrades, and backups

The “zero-human company” language around Paperclip is provocative, but it is not the most useful way to judge the product today. The valuable part is not removing humans from a company. It is making agent work easier for humans to structure, inspect, constrain, and interrupt.

The Bottom Line

Paperclip is not another agent wearing a management costume.

It is infrastructure for the moment when a collection of agents starts to look like an organization—and inherits organizational problems.

The product gives that organization goals, roles, work queues, budgets, approvals, and records. Its best feature is not the board. It is the connective tissue between intent, assignment, execution, and review.

For one agent, that is unnecessary machinery.

For a mixed team of agents that already does real work, it may be the missing layer.