Paperclip AI

Verified 7 November 2026: this review checks the live documentation and official repository. The evaluation uses documented behavior and worked workflow examples, rather than a hands-on deployment or measured productivity test.

What Is Paperclip AI?

Paperclip is an open-source server and browser dashboard for organizing AI agents around shared work: who owns a task, which goal it serves, what it may spend, and who reviews it. A Node.js backend and React interface sit above the agent runtimes that execute the work. The official application repository is paperclipai/paperclip, linked by the project's website and documentation. Paperclip supplies coordination, permissions, records and scheduling; the connected agents supply their tools and model access. It is neither a language model nor a finished business, and its company metaphor does not establish that a company can operate without people. This review concerns the orchestration project at paperclip.ing, distinct from the unrelated Paperclip Inc. and the paperclip-maximizer thought experiment.

Paperclip AI Alternatives: Who Should Use What

Paperclip fits a founder or technical operator who already has useful agents and now needs to coordinate their assignments, spending and review. If the underlying agent cannot reliably complete a bounded task, an org chart adds another system to debug.

The choice turns on the problem you need to solve. The comparison below separates the products by their operating role; they can also work together.

This is a capability comparison, not a claim that one product has outperformed the others in a benchmark. The evaluation criteria are handoff visibility, permission boundaries, spend visibility and recovery when work stalls. A tool earns its place when it improves those things for your workflow.

Give Paperclip the weekend if you routinely move instructions and results between separate agent sessions, lose track of the owner of a blocked task, or want a common review process across different runtimes. A founder coordinating implementation and documentation, or an operator running a recurring research-and-review process, has a specific problem for it to solve.

Wait if your expectation is to name a company, appoint an AI CEO and leave. Also wait if nobody can maintain the host, inspect credentials or evaluate the output. For a single coding task, keep using your existing coding agent until a recurring coordination problem appears.

Paperclip vs OpenClaw

OpenClaw is the better starting point when the immediate need is an assistant you can message from places such as Telegram or Slack. Its official overview documents a self-hosted gateway, tool use, scheduled automation and multi-agent routing. It already handles more than a single chat session, so agent count alone is a poor reason to add another platform.

Choose Paperclip when the missing piece is a work system shared across runtimes: an accountable queue, budgets and review stages. You can keep OpenClaw as an executing agent beneath it. That adds a management layer and another connection to operate; it does not make OpenClaw's own configuration disappear. Our OpenClaw review covers the assistant-side decision.

When Hermes Agent Is the Better Starting Point

Hermes Agent, built by Nous Research, is a better starting point when continuity is your problem: an agent should remember useful context and reuse procedures across recurring work. Its official repository documents persistent memory, skills that can be created and refined during use, scheduling and subagent delegation.

For an operator preparing recurring research briefs, that may be enough. Inspect the remembered context and saved procedures before relying on them. Add Paperclip when the briefs become part of a wider process with separate owners, approvals and spending controls. Paperclip also documents a local Hermes adapter, so choosing Hermes now does not exclude adding coordination later. Our Hermes Agent review examines that starting point in more depth.

Roles and Tickets Make Handoffs Inspectable

Paperclip's strongest everyday capability is keeping delegated work attached to an owner and a record. A founder can inspect the task, its discussion and its output instead of reconstructing what happened from separate terminal conversations.

Consider a small software business improving its customer export feature. The founder's goal is a usable export, not a collection of code changes. A useful task says which records belong in the export, how permissions should work, what an empty result should do, and what evidence the reviewer needs.

The working sequence is concrete:

1. Give an implementing agent a task tied to the product goal and project.
2. Require it to attach the change and evidence of the relevant checks.
3. Route the completed work to a reviewer with those same acceptance conditions.
4. Return specific failures to the implementer, keeping the discussion on the task.
5. Have the responsible person accept the result before the release proceeds.

Paperclip provides the task and handoff machinery. Your agent still has to understand the request, make the change and produce credible evidence. A neat task board cannot establish that the exported data is correct.

The issue workflow documentation describes checkout before execution, with a conflict response when another run owns the issue. That addresses duplicate claims on the same task. It does not mean separate tasks can safely edit the same files: execution workspaces and repository practices remain a separate concern.

The organization guide explains the reporting tree: each non-CEO agent has a manager, delegation moves down it, and blockers can move up it. For the export workflow, a manager could split implementation and documentation into separate tasks. You do not need to invent departments before those separate responsibilities exist.

Start with the smallest team that exposes a useful handoff. Giving every agent a senior title creates no extra expertise. A role becomes useful when its instructions say what it owns, what it must return and when it should escalate.

For content work, the same pattern might be researcher, writer and reviewer. Keep the source material with the research task and make verification part of acceptance. For support work, begin with classification and draft responses; the person who owns customer communication should decide when the workflow is ready to send anything.

The payoff is an inspectable delegation process. If work stalls, you can ask whether it lacks an assignee, a credential, a clear requirement or a decision. Those are different problems, and they deserve different fixes.

Runtime Choice and Installation Determine What Can Execute

Paperclip connects to agent runtimes through adapters, the components that start an agent, pass its task context and collect results. A runtime is the software that lets a model use tools and carry out work. A model supplies the reasoning and generated text inside that runtime.

That distinction explains why a successful Paperclip install can still leave an agent unable to work. The chosen runtime must exist where it will execute, its authentication must work, and it must be able to reach the required files or services.

Supported Runtimes and Models

Paperclip's adapter inventory documents selectable local adapters for Anthropic Claude Code, OpenAI Codex, Google Gemini CLI, Cursor Agent CLI, OpenCode, Pi, Hermes Agent, Grok Build and Kimi Code. There are also references for Cursor Cloud and Hermes Gateway. Custom commands and HTTP services have generic integration paths.

OpenClaw Gateway, Process and HTTP are an important exception to the ordinary setup experience: their runtime support is functional, but the agent configuration picker marks them Coming soon. API or import routes are available; OpenClaw has an invite flow. Do not interpret the label as either universal availability in the interface or a complete absence of support.

The current docs also describe Paperclip Runner, an experimental native execution route. Existing direct adapters remain separate and are not migrated just by enabling it. The control-plane description remains useful, but it would be too absolute to say Paperclip contains no execution infrastructure of its own.

Model support follows the chosen route and credentials:

• Claude through Claude Code: the Claude adapter reference supports a model ID, discovers models from the configured API where possible, and falls back to a built-in list. The runtime and account must support the selected Claude model.
• OpenAI models through Codex: the Codex adapter reference passes the model choice through to the CLI. Leaving it unset lets the CLI choose its default; a manually entered ID is not a guarantee that the connected account can use it.
• Multiple providers and local endpoints: the model connector catalog covers Anthropic, OpenAI, OpenRouter, xAI and compatible custom or local endpoints through supported harnesses. OpenCode uses an explicit provider/model selection; its installed opencode models command lists available options.

Gemini, Grok and Kimi support likewise comes through their respective runtime routes. Paperclip does not supply one universally interchangeable model menu. Choose the runtime you already understand, then check the selected model with that adapter's environment test. A local model endpoint must support the required API and agent behavior; compatibility is more than a URL field.

For the export-feature example, using your familiar coding runtime removes a variable from the trial. Adding an unfamiliar model, an unfamiliar execution host and a new management system at the same time makes a failed run harder to diagnose.

Configure Your Paperclip AI Agent

Paperclip's local path is the sensible starting point for a weekend evaluation. With the required Node.js version installed, the official onboarding command is:

npx paperclipai@latest onboard --yes

Run it as a normal user. The installation guide warns against a root or administrator shell because the default embedded PostgreSQL database refuses that execution mode. Onboarding creates local state under ~/.paperclip/ and starts the browser interface at http://localhost:3100.

Follow the guided first-agent path: create the company, configure its first agent and inspect the initial strategy approval. Choose the adapter, connect supported credentials, select the working model and run Test your agent. Treat this as an environment check; a successful connection is not a quality evaluation of your business workflow.

Before assigning meaningful work, confirm the working directory, initial budget policy and review owner. Use a repository or account whose access matches the task. Give the agent a specific deliverable, not a broad revenue target, so its first output has an objective acceptance test.

Where Paperclip Is Hosted

Paperclip can run on your own computer, in Docker or on a server you operate. Its deployment reference separates local trusted mode from authenticated private-network and authenticated public deployments. Local trusted mode is loopback-only and has no human login; sharing the instance calls for the appropriate authenticated configuration.

The database reference supports embedded PostgreSQL, a separate local database and hosted PostgreSQL. For Docker, the official Compose path is shown in the FAQ below. Preserve the data volume: an application container that starts successfully with empty state is not a recovered organization.

A server becomes useful when scheduled work must continue while your laptop is asleep. It also makes uptime, updates, backups and credentials your operating responsibilities. Third-party hosting exists: Hostinger's managed deployment guide describes its managed Paperclip offering separately from its VPS option. The official repository currently advertises a Paperclip Cloud waitlist; that is not evidence of a generally available first-party hosting plan.

For OpenClaw, the gateway adapter guide describes a WebSocket connection and device pairing. Its manual flow starts with Generate OpenClaw Invite Prompt in company settings, then pasting the prompt into OpenClaw's main chat. Use that documented route rather than assuming the ordinary adapter picker can configure it.

Governance Works Where You Configure It

Paperclip provides meaningful governance, but each control governs a particular operation. Approving a hire, accepting a finished task and authorizing an external tool call are separate decisions.

Start with organization changes. The approval guide documents requests for new agents and CEO strategy, along with budget-related approvals. When reviewing a hire, open the full request: the short summary does not show all the runtime configuration, spending allowance and reporting details.

For the export workflow, a new reviewer should have a defined job and the access to inspect the implementation. Approving an extra agent because the CEO requested one is insufficient. Establish what additional evidence that reviewer should produce and who will resolve a disagreement.

Task execution policies can then enforce review or approval before completion. When configured, an agent's attempt to mark work done is intercepted and routed through the required stages. A review that requests changes returns work to the implementer. Choose a human participant where human acceptance is required; an agent reviewer is still another agent.

In the export example, set the required evidence before execution: a sample file, checks for access restrictions, and the behavior of an empty export. The reviewer should return a specific defect and the expected behavior. “Please improve this” is likely to generate another vague iteration.

External actions need their own configuration. Paperclip's connectors offer Allowed, Ask first and Off settings for actions through its tool gateway. Use Ask first for a release action that should wait on a person, or Off when that agent should never perform it. Keep task acceptance separate from authority to publish a change.

Here is the practical distinction: a review stage can keep a task from being marked complete, but that does not establish that every tool used during the task needed permission. Conversely, approving an external action says nothing about whether the result meets the original requirement. The limitations below explain the defaults and shell exception that make this distinction consequential.

Use pause, reassignment and termination when work needs intervention. Treat a configuration rollback as a way to restore configuration, not as a promise to undo an email, a deleted record or a deployment. The person operating the workflow still owns the response to its external effects.

Routines Make Recurring Work Auditable

Paperclip can turn recurring work into a task with an owner and history, which is more useful than a collection of agents waking up to ask whether there is anything to do. The current heartbeats and routines guide recommends event-driven wakeups for ordinary assignments and leaves interval heartbeats off by default.

A heartbeat is an execution opportunity: the agent wakes, reads its assigned context and acts. An assignment, comment or routine can cause that wakeup. A timer is useful when something genuinely needs polling; it is not a requirement for keeping an agent available.

For the software founder, a recurring release-readiness digest is a good candidate. Ask the agent to identify unfinished work, unresolved review comments and missing evidence, then return a report for inspection. Do not begin with a routine whose success requires releasing every change it finds.

An illustrative calculation shows why timers deserve restraint: 5 agents on a 5-minute interval create 60 potential timer wakeups in an hour, before cooldown or coalescing behavior. That is scheduling arithmetic, not a token-cost estimate or measured workload. If there is no new work, activity can become something you pay to inspect.

The operator's responsibility is to decide what should trigger work and what happens after downtime. A weekly report might reasonably skip an obsolete window; a record-processing job may need an explicit catch-up policy. “Keep running” is not a sufficient specification for either.

What Paperclip Costs

Paperclip's MIT-licensed software costs $0; you pay the model and hosting bills, not Paperclip for the self-hosted license.

Paperclip's operating bill depends on the selected model access, how much the agents execute and where the system runs. Connected services may add their own charges. There is no universal monthly figure that can honestly represent a founder's deployment, and an AI subscription does not make the host or every external tool free.

The budget setup guide documents a default warning at 80% and a hard stop at 100%. Company and agent budgets use calendar months in UTC; project budgets default to lifetime limits. Keep both organization and per-agent limits, so one worker cannot consume the entire allowance unchecked.

Enforcement depends on recorded spend. Work already running and delayed usage reports can move the actual bill past the configured amount. Unpriced usage and pending accounting can also hold new work; a blank or unknown cost is not evidence that execution was free.

For the trial, record spending alongside accepted outputs and your review time. A cheaper run that needs repeated correction can be the worse choice. There is no cost-per-accepted-result measurement in this review because no production workload was exercised; that is the number your bounded trial should establish.

Limitations That Can Derail the Weekend

Paperclip's limitations are most consequential at the boundary between what its dashboard controls and what the executing agent can do. These are configuration and operating issues you should resolve before expanding the workflow.

Gateway Approval Does Not Constrain the Workspace Shell

Paperclip's action-permission documentation states that active actions on a normal new connection start Allowed, including writes and destructive actions. Change the connection's Permissions settings explicitly; do not assume connecting a service creates an approval requirement.

The same page documents the shell exception: per-action policy governs the tool gateway, not commands executed in an agent's workspace. In particular, shell Git and gh using a bound GitHub identity are outside per-tool Ask-first controls.

For the export workflow, making a gateway write action Ask first does not establish that a coding agent's separate shell credentials cannot push a change. Scope the workspace and credentials as well as the gateway policy. A task instruction saying “ask first” is guidance, not a substitute for those settings.

Runtime settings also matter. The OpenCode adapter reference documents dangerouslySkipPermissions enabled by default for unattended runs, replacing permission rules in a temporary configuration with allow behavior. If you need the runtime's existing rules honored, review that setting before the first run.

A New Agent May Have No Budget Policy

Paperclip's detailed costs guide says the app's agent setup flow does not create a budget policy. An absent agent budget card is therefore not a small display omission: you need to establish the cap through the supported CLI or API path before editing its card in Audit → Budgets.

A second sharp edge is the amount 0, which turns a budget policy off. It does not mean “permit no spending.” Inspect the resulting policy and its enforcement status, rather than judging protection from the number alone.

For a new company without an organization card, the documentation also directs you to the API for the initial cap. This is a practical setup step that interrupts the otherwise straightforward browser onboarding. Do it before increasing agent activity.

Review Escalation Needs a Responsible Human

Paperclip's execution-policy reference documents a default cap of 3 consecutive agent-requested revision rounds before escalation to a person. It uses the task's responsibleUserId, falling back to createdByUserId.

If neither human identity exists, the work keeps returning to the implementer. The counter can rise without producing the human handoff you expected. This matters for automatically created tasks and integrations: confirm that a responsible person is recorded, not merely that an agent occupies the approver role.

For the founder's pilot, deliberately inspect the owner of an agent-created follow-up task. If reviewer and implementer disagree over an impossible requirement, someone must be able to narrow the scope. Adding more reviewers does not resolve a contradictory acceptance condition.

Evidence Quality Varies by Adapter

Paperclip's transcript is only as informative as the runtime output and usage metadata it receives. Generic Process and HTTP adapters expose plain output; richer adapters can supply structured tool events and session state. The adapter inventory also notes native Cursor and Grok routes without authoritative per-run cost totals.

A central dashboard therefore does not imply equally complete evidence for every worker. During the trial, check whether the selected route shows the artifact, errors, model usage and session continuity you need. A confident “done” message is inadequate if you cannot inspect the result.

You Still Operate the System

Paperclip adds a server, database, adapters and credentials to maintain. Local execution is convenient, but a sleeping laptop or stopped foreground process is unavailable for scheduled work. Remote hosting improves availability only if someone maintains it.

Keep the installed version and its documentation aligned, preserve database and secret state, and understand which runtime credentials are available on the execution host. Company-scoped records are useful organization boundaries; do not treat them as proof that arbitrary executing processes are isolated from one another.

The operating burden is justified when coordination has become a recurring cost. For an occasional request to a single capable agent, the same burden is a reason to wait.

Paperclip AI Review Verdict

Paperclip deserves a bounded trial when you have working agents and need clearer ownership, controlled handoffs and a shared view of spending. It is premature when you are still trying to make the underlying agent useful or expect the platform to make business judgments on your behalf.

The decision rule: keep Paperclip if the same recurring workflow becomes easier to assign, inspect and recover, with acceptable results and a known human owner. Stop the trial if you spend more effort maintaining agent roles and approval queues than the workflow previously required.

For Monday, use the customer-export change or an equally bounded task in your own business. Begin with a familiar runtime, a narrow workspace and explicit acceptance criteria. Configure a positive spending cap, restrict write access, and record the responsible human before allowing delegation.

Then evaluate the handoff, not the spectacle:

• Can you identify who owns the next action without asking every agent?
• Does the reviewer receive the evidence needed to accept or reject the result?
• Do the required approval settings cover the actual execution path?
• Can you explain a pause or failure from the task history and spending records?
• Is the accepted result worth its model usage, review effort and maintenance?

A successful demo shows agents doing things. A useful deployment gives you enough evidence to decide whether those things should count as completed work. That is the standard Paperclip should meet before you give it a wider role.

FAQ

Use the AI business workflow audit checklist to choose the first workflow worth delegating.