Skip to main content
Paperclip is a monorepo with four main layers.

Stack Overview

Technology Stack

Repository Structure

Request Flow

When a heartbeat fires:
  1. Trigger — Scheduler, manual invoke, or event (assignment, mention) triggers a heartbeat
  2. Adapter invocation — Server calls the configured adapter’s execute() function
  3. Agent process — Adapter spawns the agent (e.g. Claude Code CLI) with Paperclip env vars and a prompt
  4. Agent work — The agent calls Paperclip’s REST API to check assignments, checkout tasks, do work, and update status
  5. Result capture — Adapter captures stdout, parses usage/cost data, extracts session state
  6. Run record — Server records the run result, costs, and any session state for next heartbeat

Adapter Model

Adapters are the bridge between Paperclip and agent runtimes. Each adapter is a package with three modules:
  • Server moduleexecute() function that spawns/calls the agent, plus environment diagnostics
  • UI module — stdout parser for the run viewer, config form fields for agent creation
  • CLI module — terminal formatter for paperclipai run --watch
Built-in adapters: claude_local, codex_local, process, http. You can create custom adapters for any runtime.

Key Design Decisions

  • Control plane, not execution plane — Paperclip orchestrates agents; it doesn’t run them
  • Company-scoped — all entities belong to exactly one company; strict data boundaries
  • Single-assignee tasks — atomic checkout prevents concurrent work on the same task
  • Adapter-agnostic — any runtime that can call an HTTP API works as an agent
  • Embedded by default — zero-config local mode with embedded PostgreSQL