OPEN SOURCE DEEP DIVE
Paperclip: run a company with a team of AI agents
Open-source orchestration for teams of AI agents: a Node.js server and React UI where you bring your own agents, set goals, and track work and spend from one dashboard. It looks like a task manager; underneath sit org charts, budgets, governance, goal alignment and agent coordination. It manages business goals, not pull requests. MIT, self-hostable.
What it is
Paperclip states its position in one line: "If OpenClaw is an employee, Paperclip is the company." It is a Node.js server and React UI that orchestrates a team of AI agents to run a business. You bring your own agents, assign goals, and track work and cost from one dashboard. It has more than 81,000 stars, is MIT-licensed, open source and self-hosted, and requires no Paperclip account.
The project names its own dissonance: it looks like a task manager, and underneath sit org charts, budgets, governance, goal alignment and agent coordination. The unit it manages is a business goal, not a pull request. The three-step flow is blunt - define the goal (their example: build the number one AI note-taking app to $1M MRR), hire the team (CEO, CTO, engineers, designers, marketers, any bot, any provider), approve and run (review strategy, set budgets, hit go, monitor from the dashboard).
Four pillars: what it believes an agent organisation needs
The structure is not a feature list, it is a claim about why agent organisations fail to produce. Four pillars, each aimed at a different role.
Agentic Task Manager (everyone, daily): declare intent, agents work, you verify the output - tasks, approvals and review gates, auditable routines and workflows, with verification from diffs, screenshots and tests. Org Chart for Agents (managers): a mixed human and agent org chart, responsibilities, delegation and specialisation, governance over who can do what, scoped secrets and company boundaries. Agent Employee Training (enablers): Skill Studio with shared org-wide skills, evals and saved test runs, active learning loops and quality metrics, performance reviews for agents. Agentic OS (IT and platform): a cross-provider runtime for any model and any agent, sandboxing, integrations and MCP servers, SSO/GRC/RBAC and cost controls, data privacy and internal trace collection.
Two of these deserve attention: "performance reviews for agents" and "evals with saved test runs". Most orchestration tools stop at getting agents running and leave "is this agent any good" to human intuition. Paperclip promotes evaluation and quality metrics to a first-class module, which is the same question this site's Harness line cares about - a capability claim needs falsifiable evidence, not a narrative.
Under the hood is a control plane: twelve systems
The ASCII architecture diagram in the README lists twelve subsystems, and reading them in order is the quickest way to see this is not a wrapper: Identity and Access (two deployment modes, board users, agent API keys, short-lived run JWTs, company memberships, invite flows, OpenClaw onboarding, every mutating request traced to an actor); Work and Tasks (issues carrying company/project/goal/parent links, atomic checkout with execution locks, first-class blocker dependencies, comments, documents, attachments, work products, labels, inbox state); Heartbeat Execution (a DB-backed wakeup queue with coalescing, budget checks, workspace resolution, secret injection, skill loading and adapter invocation, where runs produce structured logs, cost events, session state and audit trails, and orphaned runs recover automatically); Org Chart and Agents (roles, titles, reporting lines, permissions, budgets, with adapters for Claude Code, Codex, CLI agents such as Cursor/Gemini/bash, HTTP/webhook bots such as OpenClaw, and external adapter plugins); Workspaces and Runtime (project workspaces, isolated execution workspaces as git worktrees and operator branches, runtime services such as dev servers and preview URLs); Governance and Approvals (board approval workflows, execution policies with review/approval stages, decision tracking, budget hard-stops, agent pause/resume/terminate, full audit logging); Budget and Cost Control (token and cost tracking by company, agent, project, goal, issue, provider and model, scoped policies with warning thresholds and hard stops, overspend pausing agents and cancelling queued work); Routines and Schedules (recurring tasks with cron, webhook and API triggers, concurrency and catch-up policies, each execution creating a tracked issue and waking the assigned agent); Plugins (instance-wide plugin system with out-of-process workers, capability-gated host services, job scheduling, tool exposure and UI contributions); Secrets and Storage (instance and company secrets, encrypted local storage, provider-backed object storage, attachments, work products); Activity and Events (mutating actions, heartbeat state changes, cost events, approvals, comments and work products recorded as durable activity); Company Portability (export and import of whole organisations with secret scrubbing and collision handling).
Three of these are the genuinely hard engineering, and the project singles them out itself. Atomic execution: task checkout and budget enforcement are atomic, so there is no double-work and no runaway spend. Persistent agent state: agents resume the same task context across heartbeats instead of restarting from scratch. Governance with rollback: approval gates are enforced, config changes are revisioned, and bad changes roll back safely. Add goal-aware execution - tasks carry full goal ancestry, so an agent sees the "why" and not just a title.
The bar for being hired: receive a heartbeat
Its definition of an agent is deliberately wide: if it can receive a heartbeat, it is hired. Multi-organisation isolation is real rather than nominal - every entity is company-scoped, so one deployment runs many companies with separate data and audit trails. Mobile clients can monitor and manage.
The install path has three rungs worth recording. npx paperclipai test-drive spins an isolated throwaway instance that already has a CEO agent: it stays in the foreground, never installs a service or creates a first task, opens the browser only after setup succeeds, and accepts --harness codex or opencode with a --model override. The managed path is curl -fsSLO https://paperclip.ing/install.sh, verify with sha256sum -c, then run it - that installs a managed CLI under ~/.paperclip/cli and starts interactive onboarding, and can register Paperclip as a background service on supported Linux and macOS. The manual path is git clone, pnpm install, pnpm dev, with the API on localhost:3100 and an embedded PostgreSQL created automatically. Requirements are Node.js 24.11+ and pnpm 9.15+. The quick path defaults to trusted local loopback mode; authenticated or private mode needs an explicit --bind lan or --bind tailnet.
One piece of honesty is worth naming: the README states that the checksum is served from the same origin as the script, so it detects transfer or publishing mistakes but is not an independent source - use a release-tag or commit-pinned GitHub copy when you need one. It also does not dodge its own boundaries: not a chatbot, not an agent framework, not a workflow builder, not a prompt manager, not a single-agent tool, not a code review tool - and it says outright that with one agent you probably do not need it, while with twenty you definitely do. Bring-your-own-ticket-system is still on the roadmap.
Where it sits in agientry
It shares the orchestration layer with herdr, Orca and Multica but sits one level above all of them: herdr is a resident terminal runtime, Orca is an ADE that owns working directories and branches, Multica turns the workflow into issues on a board, and Paperclip turns a team of agents into a company with an org chart, budgets and governance. The four stack - Orca or herdr runs agents underneath, Multica or Paperclip assigns work on top.
We have not benchmarked or reproduced Paperclip. "An agent company produces real business results" is a falsifiable claim that nobody has yet backed with controlled evidence, so its star count tells us this is a specimen the layer has to carry, not that it works. Capability level is graded as needing reproduction.