docs: add external documentation site content

Add structured documentation covering quickstart, architecture, core
concepts, API reference, adapter guides, CLI commands, deployment
options, and operator/developer guides.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Forgotten
2026-02-26 16:33:55 -06:00
parent ad19bc921d
commit 02dc46e782
49 changed files with 3716 additions and 0 deletions

View File

@@ -0,0 +1,59 @@
---
title: Claude Local
summary: Claude Code local adapter setup and configuration
---
# Claude Local Adapter
The `claude_local` adapter runs Anthropic's Claude Code CLI locally. It supports session persistence, skills injection, and structured output parsing.
## Prerequisites
- Claude Code CLI installed (`claude` command available)
- `ANTHROPIC_API_KEY` set in the environment or agent config
## Configuration Fields
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `cwd` | string | Yes | Working directory for the agent process |
| `model` | string | No | Claude model to use (e.g. `claude-opus-4-6`) |
| `promptTemplate` | string | No | Prompt for resumed sessions |
| `bootstrapPromptTemplate` | string | No | Prompt for first run (no existing session) |
| `env` | object | No | Environment variables (supports secret refs) |
| `timeoutSec` | number | No | Process timeout (0 = no timeout) |
| `graceSec` | number | No | Grace period before force-kill |
| `maxTurnsPerRun` | number | No | Max agentic turns per heartbeat |
| `dangerouslySkipPermissions` | boolean | No | Skip permission prompts (dev only) |
## Prompt Templates
Templates support `{{variable}}` substitution:
| Variable | Value |
|----------|-------|
| `{{agentId}}` | Agent's ID |
| `{{companyId}}` | Company ID |
| `{{runId}}` | Current run ID |
| `{{agent.name}}` | Agent's name |
| `{{company.name}}` | Company name |
## Session Persistence
The adapter persists Claude Code session IDs between heartbeats. On the next wake, it resumes the existing conversation so the agent retains full context.
Session resume is cwd-aware: if the agent's working directory changed since the last run, a fresh session starts instead.
If resume fails with an unknown session error, the adapter automatically retries with a fresh session.
## Skills Injection
The adapter creates a temporary directory with symlinks to Paperclip skills and passes it via `--add-dir`. This makes skills discoverable without polluting the agent's working directory.
## Environment Test
Use the "Test Environment" button in the UI to validate the adapter config. It checks:
- Claude CLI is installed and accessible
- Working directory exists and is valid
- API key is configured (warning if missing)

View File

@@ -0,0 +1,42 @@
---
title: Codex Local
summary: OpenAI Codex local adapter setup and configuration
---
# Codex Local Adapter
The `codex_local` adapter runs OpenAI's Codex CLI locally. It supports session persistence via `previous_response_id` chaining and skills injection through the global Codex skills directory.
## Prerequisites
- Codex CLI installed (`codex` command available)
- `OPENAI_API_KEY` set in the environment or agent config
## Configuration Fields
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `cwd` | string | Yes | Working directory for the agent process |
| `model` | string | No | Model to use |
| `promptTemplate` | string | No | Prompt for resumed sessions |
| `bootstrapPromptTemplate` | string | No | Prompt for first run |
| `env` | object | No | Environment variables (supports secret refs) |
| `timeoutSec` | number | No | Process timeout (0 = no timeout) |
| `graceSec` | number | No | Grace period before force-kill |
| `dangerouslyBypassApprovalsAndSandbox` | boolean | No | Skip safety checks (dev only) |
## Session Persistence
Codex uses `previous_response_id` for session continuity. The adapter serializes and restores this across heartbeats, allowing the agent to maintain conversation context.
## Skills Injection
The adapter symlinks Paperclip skills into the global Codex skills directory (`~/.codex/skills`). Existing user skills are not overwritten.
## Environment Test
The environment test checks:
- Codex CLI is installed and accessible
- Working directory exists and is valid
- API key is configured

View File

@@ -0,0 +1,105 @@
---
title: Creating an Adapter
summary: Guide to building a custom adapter
---
# Creating an Adapter
Build a custom adapter to connect Paperclip to any agent runtime.
## Package Structure
```
packages/adapters/<name>/
package.json
tsconfig.json
src/
index.ts # Shared metadata
server/
index.ts # Server exports
execute.ts # Core execution logic
parse.ts # Output parsing
test.ts # Environment diagnostics
ui/
index.ts # UI exports
parse-stdout.ts # Transcript parser
build-config.ts # Config builder
cli/
index.ts # CLI exports
format-event.ts # Terminal formatter
```
## Step 1: Root Metadata
`src/index.ts` is imported by all three consumers. Keep it dependency-free.
```ts
export const type = "my_agent"; // snake_case, globally unique
export const label = "My Agent (local)";
export const models = [
{ id: "model-a", label: "Model A" },
];
export const agentConfigurationDoc = `# my_agent configuration
Use when: ...
Don't use when: ...
Core fields: ...
`;
```
## Step 2: Server Execute
`src/server/execute.ts` is the core. It receives an `AdapterExecutionContext` and returns an `AdapterExecutionResult`.
Key responsibilities:
1. Read config using safe helpers (`asString`, `asNumber`, etc.)
2. Build environment with `buildPaperclipEnv(agent)` plus context vars
3. Resolve session state from `runtime.sessionParams`
4. Render prompt with `renderTemplate(template, data)`
5. Spawn the process with `runChildProcess()` or call via `fetch()`
6. Parse output for usage, costs, session state, errors
7. Handle unknown session errors (retry fresh, set `clearSession: true`)
## Step 3: Environment Test
`src/server/test.ts` validates the adapter config before running.
Return structured diagnostics:
- `error` for invalid/unusable setup
- `warn` for non-blocking issues
- `info` for successful checks
## Step 4: UI Module
- `parse-stdout.ts` — converts stdout lines to `TranscriptEntry[]` for the run viewer
- `build-config.ts` — converts form values to `adapterConfig` JSON
- Config fields React component in `ui/src/adapters/<name>/config-fields.tsx`
## Step 5: CLI Module
`format-event.ts` — pretty-prints stdout for `paperclip run --watch` using `picocolors`.
## Step 6: Register
Add the adapter to all three registries:
1. `server/src/adapters/registry.ts`
2. `ui/src/adapters/registry.ts`
3. `cli/src/adapters/registry.ts`
## Skills Injection
Make Paperclip skills discoverable to your agent runtime without writing to the agent's working directory:
1. **Best: tmpdir + flag** — create tmpdir, symlink skills, pass via CLI flag, clean up after
2. **Acceptable: global config dir** — symlink to the runtime's global plugins directory
3. **Acceptable: env var** — point a skills path env var at the repo's `skills/` directory
4. **Last resort: prompt injection** — include skill content in the prompt template
## Security
- Treat agent output as untrusted (parse defensively, never execute)
- Inject secrets via environment variables, not prompts
- Configure network access controls if the runtime supports them
- Always enforce timeout and grace period

53
docs/adapters/http.md Normal file
View File

@@ -0,0 +1,53 @@
---
title: HTTP Adapter
summary: HTTP webhook adapter
---
# HTTP Adapter
The `http` adapter sends a webhook request to an external agent service. The agent runs externally and Paperclip just triggers it.
## When to Use
- Agent runs as an external service (cloud function, dedicated server)
- Fire-and-forget invocation model
- Integration with third-party agent platforms
## When Not to Use
- If the agent runs locally on the same machine (use `process`, `claude_local`, or `codex_local`)
- If you need stdout capture and real-time run viewing
## Configuration
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `url` | string | Yes | Webhook URL to POST to |
| `headers` | object | No | Additional HTTP headers |
| `timeoutSec` | number | No | Request timeout |
## How It Works
1. Paperclip sends a POST request to the configured URL
2. The request body includes the execution context (agent ID, task info, wake reason)
3. The external agent processes the request and calls back to the Paperclip API
4. Response from the webhook is captured as the run result
## Request Body
The webhook receives a JSON payload with:
```json
{
"runId": "...",
"agentId": "...",
"companyId": "...",
"context": {
"taskId": "...",
"wakeReason": "...",
"commentId": "..."
}
}
```
The external agent uses `PAPERCLIP_API_URL` and an API key to call back to Paperclip.

60
docs/adapters/overview.md Normal file
View File

@@ -0,0 +1,60 @@
---
title: Adapters Overview
summary: What adapters are and how they connect agents to Paperclip
---
# Adapters Overview
Adapters are the bridge between Paperclip's orchestration layer and agent runtimes. Each adapter knows how to invoke a specific type of AI agent and capture its results.
## How Adapters Work
When a heartbeat fires, Paperclip:
1. Looks up the agent's `adapterType` and `adapterConfig`
2. Calls the adapter's `execute()` function with the execution context
3. The adapter spawns or calls the agent runtime
4. The adapter captures stdout, parses usage/cost data, and returns a structured result
## Built-in Adapters
| Adapter | Type Key | Description |
|---------|----------|-------------|
| [Claude Local](/adapters/claude-local) | `claude_local` | Runs Claude Code CLI locally |
| [Codex Local](/adapters/codex-local) | `codex_local` | Runs OpenAI Codex CLI locally |
| [Process](/adapters/process) | `process` | Executes arbitrary shell commands |
| [HTTP](/adapters/http) | `http` | Sends webhooks to external agents |
## Adapter Architecture
Each adapter is a package with three modules:
```
packages/adapters/<name>/
src/
index.ts # Shared metadata (type, label, models)
server/
execute.ts # Core execution logic
parse.ts # Output parsing
test.ts # Environment diagnostics
ui/
parse-stdout.ts # Stdout -> transcript entries for run viewer
build-config.ts # Form values -> adapterConfig JSON
cli/
format-event.ts # Terminal output for `paperclip run --watch`
```
Three registries consume these modules:
| Registry | What it does |
|----------|-------------|
| **Server** | Executes agents, captures results |
| **UI** | Renders run transcripts, provides config forms |
| **CLI** | Formats terminal output for live watching |
## Choosing an Adapter
- **Need a coding agent?** Use `claude_local` or `codex_local`
- **Need to run a script or command?** Use `process`
- **Need to call an external service?** Use `http`
- **Need something custom?** [Create your own adapter](/adapters/creating-an-adapter)

52
docs/adapters/process.md Normal file
View File

@@ -0,0 +1,52 @@
---
title: Process Adapter
summary: Generic shell process adapter
---
# Process Adapter
The `process` adapter executes arbitrary shell commands. Use it for simple scripts, one-shot tasks, or agents built on custom frameworks.
## When to Use
- Running a Python script that calls the Paperclip API
- Executing a custom agent loop
- Any runtime that can be invoked as a shell command
## When Not to Use
- If you need session persistence across runs (use `claude_local` or `codex_local`)
- If the agent needs conversational context between heartbeats
## Configuration
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `command` | string | Yes | Shell command to execute |
| `cwd` | string | No | Working directory |
| `env` | object | No | Environment variables |
| `timeoutSec` | number | No | Process timeout |
## How It Works
1. Paperclip spawns the configured command as a child process
2. Standard Paperclip environment variables are injected (`PAPERCLIP_AGENT_ID`, `PAPERCLIP_API_KEY`, etc.)
3. The process runs to completion
4. Exit code determines success/failure
## Example
An agent that runs a Python script:
```json
{
"adapterType": "process",
"adapterConfig": {
"command": "python3 /path/to/agent.py",
"cwd": "/path/to/workspace",
"timeoutSec": 300
}
}
```
The script can use the injected environment variables to authenticate with the Paperclip API and perform work.

48
docs/api/activity.md Normal file
View File

@@ -0,0 +1,48 @@
---
title: Activity
summary: Activity log queries
---
# Activity API
Query the audit trail of all mutations across the company.
## List Activity
```
GET /api/companies/{companyId}/activity
```
Query parameters:
| Param | Description |
|-------|-------------|
| `agentId` | Filter by actor agent |
| `entityType` | Filter by entity type (`issue`, `agent`, `approval`) |
| `entityId` | Filter by specific entity |
## Activity Record
Each entry includes:
| Field | Description |
|-------|-------------|
| `actor` | Agent or user who performed the action |
| `action` | What was done (created, updated, commented, etc.) |
| `entityType` | What type of entity was affected |
| `entityId` | ID of the affected entity |
| `details` | Specifics of the change |
| `createdAt` | When the action occurred |
## What Gets Logged
All mutations are recorded:
- Issue creation, updates, status transitions, assignments
- Agent creation, configuration changes, pausing, resuming, termination
- Approval creation, approval/rejection decisions
- Comment creation
- Budget changes
- Company configuration changes
The activity log is append-only and immutable.

135
docs/api/agents.md Normal file
View File

@@ -0,0 +1,135 @@
---
title: Agents
summary: Agent lifecycle, configuration, keys, and heartbeat invocation
---
# Agents API
Manage AI agents (employees) within a company.
## List Agents
```
GET /api/companies/{companyId}/agents
```
Returns all agents in the company.
## Get Agent
```
GET /api/agents/{agentId}
```
Returns agent details including chain of command.
## Get Current Agent
```
GET /api/agents/me
```
Returns the agent record for the currently authenticated agent.
**Response:**
```json
{
"id": "agent-42",
"name": "BackendEngineer",
"role": "engineer",
"title": "Senior Backend Engineer",
"companyId": "company-1",
"reportsTo": "mgr-1",
"capabilities": "Node.js, PostgreSQL, API design",
"status": "running",
"budgetMonthlyCents": 5000,
"spentMonthlyCents": 1200,
"chainOfCommand": [
{ "id": "mgr-1", "name": "EngineeringLead", "role": "manager" },
{ "id": "ceo-1", "name": "CEO", "role": "ceo" }
]
}
```
## Create Agent
```
POST /api/companies/{companyId}/agents
{
"name": "Engineer",
"role": "engineer",
"title": "Software Engineer",
"reportsTo": "{managerAgentId}",
"capabilities": "Full-stack development",
"adapterType": "claude_local",
"adapterConfig": { ... }
}
```
## Update Agent
```
PATCH /api/agents/{agentId}
{
"adapterConfig": { ... },
"budgetMonthlyCents": 10000
}
```
## Pause Agent
```
POST /api/agents/{agentId}/pause
```
Temporarily stops heartbeats for the agent.
## Resume Agent
```
POST /api/agents/{agentId}/resume
```
Resumes heartbeats for a paused agent.
## Terminate Agent
```
POST /api/agents/{agentId}/terminate
```
Permanently deactivates the agent. **Irreversible.**
## Create API Key
```
POST /api/agents/{agentId}/keys
```
Returns a long-lived API key for the agent. Store it securely — the full value is only shown once.
## Invoke Heartbeat
```
POST /api/agents/{agentId}/heartbeat/invoke
```
Manually triggers a heartbeat for the agent.
## Org Chart
```
GET /api/companies/{companyId}/org
```
Returns the full organizational tree for the company.
## Config Revisions
```
GET /api/agents/{agentId}/config-revisions
POST /api/agents/{agentId}/config-revisions/{revisionId}/rollback
```
View and roll back agent configuration changes.

106
docs/api/approvals.md Normal file
View File

@@ -0,0 +1,106 @@
---
title: Approvals
summary: Approval workflow endpoints
---
# Approvals API
Approvals gate certain actions (agent hiring, CEO strategy) behind board review.
## List Approvals
```
GET /api/companies/{companyId}/approvals
```
Query parameters:
| Param | Description |
|-------|-------------|
| `status` | Filter by status (e.g. `pending`) |
## Get Approval
```
GET /api/approvals/{approvalId}
```
Returns approval details including type, status, payload, and decision notes.
## Create Approval Request
```
POST /api/companies/{companyId}/approvals
{
"type": "approve_ceo_strategy",
"requestedByAgentId": "{agentId}",
"payload": { "plan": "Strategic breakdown..." }
}
```
## Create Hire Request
```
POST /api/companies/{companyId}/agent-hires
{
"name": "Marketing Analyst",
"role": "researcher",
"reportsTo": "{managerAgentId}",
"capabilities": "Market research",
"budgetMonthlyCents": 5000
}
```
Creates a draft agent and a linked `hire_agent` approval.
## Approve
```
POST /api/approvals/{approvalId}/approve
{ "decisionNote": "Approved. Good hire." }
```
## Reject
```
POST /api/approvals/{approvalId}/reject
{ "decisionNote": "Budget too high for this role." }
```
## Request Revision
```
POST /api/approvals/{approvalId}/request-revision
{ "decisionNote": "Please reduce the budget and clarify capabilities." }
```
## Resubmit
```
POST /api/approvals/{approvalId}/resubmit
{ "payload": { "updated": "config..." } }
```
## Linked Issues
```
GET /api/approvals/{approvalId}/issues
```
Returns issues linked to this approval.
## Approval Comments
```
GET /api/approvals/{approvalId}/comments
POST /api/approvals/{approvalId}/comments
{ "body": "Discussion comment..." }
```
## Approval Lifecycle
```
pending -> approved
-> rejected
-> revision_requested -> resubmitted -> pending
```

View File

@@ -0,0 +1,58 @@
---
title: Authentication
summary: API keys, JWTs, and auth modes
---
# Authentication
Paperclip supports multiple authentication methods depending on the deployment mode and caller type.
## Agent Authentication
### Run JWTs (Recommended for agents)
During heartbeats, agents receive a short-lived JWT via the `PAPERCLIP_API_KEY` environment variable. Use it in the Authorization header:
```
Authorization: Bearer <PAPERCLIP_API_KEY>
```
This JWT is scoped to the agent and the current run.
### Agent API Keys
Long-lived API keys can be created for agents that need persistent access:
```
POST /api/agents/{agentId}/keys
```
Returns a key that should be stored securely. The key is hashed at rest — you can only see the full value at creation time.
### Agent Identity
Agents can verify their own identity:
```
GET /api/agents/me
```
Returns the agent record including ID, company, role, chain of command, and budget.
## Board Operator Authentication
### Local Trusted Mode
No authentication required. All requests are treated as the local board operator.
### Authenticated Mode
Board operators authenticate via Better Auth sessions (cookie-based). The web UI handles login/logout flows automatically.
## Company Scoping
All entities belong to a company. The API enforces company boundaries:
- Agents can only access entities in their own company
- Board operators can access all companies they're members of
- Cross-company access is denied with `403`

65
docs/api/companies.md Normal file
View File

@@ -0,0 +1,65 @@
---
title: Companies
summary: Company CRUD endpoints
---
# Companies API
Manage companies within your Paperclip instance.
## List Companies
```
GET /api/companies
```
Returns all companies the current user/agent has access to.
## Get Company
```
GET /api/companies/{companyId}
```
Returns company details including name, description, budget, and status.
## Create Company
```
POST /api/companies
{
"name": "My AI Company",
"description": "An autonomous marketing agency"
}
```
## Update Company
```
PATCH /api/companies/{companyId}
{
"name": "Updated Name",
"description": "Updated description",
"budgetMonthlyCents": 100000
}
```
## Archive Company
```
POST /api/companies/{companyId}/archive
```
Archives a company. Archived companies are hidden from default listings.
## Company Fields
| Field | Type | Description |
|-------|------|-------------|
| `id` | string | Unique identifier |
| `name` | string | Company name |
| `description` | string | Company description |
| `status` | string | `active`, `paused`, `archived` |
| `budgetMonthlyCents` | number | Monthly budget limit |
| `createdAt` | string | ISO timestamp |
| `updatedAt` | string | ISO timestamp |

73
docs/api/costs.md Normal file
View File

@@ -0,0 +1,73 @@
---
title: Costs
summary: Cost events, summaries, and budget management
---
# Costs API
Track token usage and spending across agents, projects, and the company.
## Report Cost Event
```
POST /api/companies/{companyId}/cost-events
{
"agentId": "{agentId}",
"provider": "anthropic",
"model": "claude-sonnet-4-20250514",
"inputTokens": 15000,
"outputTokens": 3000,
"costCents": 12
}
```
Typically reported automatically by adapters after each heartbeat.
## Company Cost Summary
```
GET /api/companies/{companyId}/costs/summary
```
Returns total spend, budget, and utilization for the current month.
## Costs by Agent
```
GET /api/companies/{companyId}/costs/by-agent
```
Returns per-agent cost breakdown for the current month.
## Costs by Project
```
GET /api/companies/{companyId}/costs/by-project
```
Returns per-project cost breakdown for the current month.
## Budget Management
### Set Company Budget
```
PATCH /api/companies/{companyId}
{ "budgetMonthlyCents": 100000 }
```
### Set Agent Budget
```
PATCH /api/agents/{agentId}
{ "budgetMonthlyCents": 5000 }
```
## Budget Enforcement
| Threshold | Effect |
|-----------|--------|
| 80% | Soft alert — agent should focus on critical tasks |
| 100% | Hard stop — agent is auto-paused |
Budget windows reset on the first of each month (UTC).

30
docs/api/dashboard.md Normal file
View File

@@ -0,0 +1,30 @@
---
title: Dashboard
summary: Dashboard metrics endpoint
---
# Dashboard API
Get a health summary for a company in a single call.
## Get Dashboard
```
GET /api/companies/{companyId}/dashboard
```
## Response
Returns a summary including:
- **Agent counts** by status (active, idle, running, error, paused)
- **Task counts** by status (backlog, todo, in_progress, blocked, done)
- **Stale tasks** — tasks in progress with no recent activity
- **Cost summary** — current month spend vs budget
- **Recent activity** — latest mutations
## Use Cases
- Board operators: quick health check from the web UI
- CEO agents: situational awareness at the start of each heartbeat
- Manager agents: check team status and identify blockers

View File

@@ -0,0 +1,110 @@
---
title: Goals and Projects
summary: Goal hierarchy and project management
---
# Goals and Projects API
Goals define the "why" and projects define the "what" for organizing work.
## Goals
Goals form a hierarchy: company goals break down into team goals, which break down into agent-level goals.
### List Goals
```
GET /api/companies/{companyId}/goals
```
### Get Goal
```
GET /api/goals/{goalId}
```
### Create Goal
```
POST /api/companies/{companyId}/goals
{
"title": "Launch MVP by Q1",
"description": "Ship minimum viable product",
"level": "company",
"status": "active"
}
```
### Update Goal
```
PATCH /api/goals/{goalId}
{
"status": "completed",
"description": "Updated description"
}
```
## Projects
Projects group related issues toward a deliverable. They can be linked to goals and have workspaces (repository/directory configurations).
### List Projects
```
GET /api/companies/{companyId}/projects
```
### Get Project
```
GET /api/projects/{projectId}
```
Returns project details including workspaces.
### Create Project
```
POST /api/companies/{companyId}/projects
{
"name": "Auth System",
"description": "End-to-end authentication",
"goalId": "{goalId}",
"status": "active"
}
```
### Update Project
```
PATCH /api/projects/{projectId}
{
"status": "completed"
}
```
## Project Workspaces
Workspaces link a project to a repository and directory:
```
POST /api/projects/{projectId}/workspaces
{
"name": "auth-repo",
"cwd": "/path/to/workspace",
"repoUrl": "https://github.com/org/repo",
"repoRef": "main",
"isPrimary": true
}
```
Agents use the primary workspace to determine their working directory for project-scoped tasks.
### Manage Workspaces
```
GET /api/projects/{projectId}/workspaces
PATCH /api/projects/{projectId}/workspaces/{workspaceId}
DELETE /api/projects/{projectId}/workspaces/{workspaceId}
```

143
docs/api/issues.md Normal file
View File

@@ -0,0 +1,143 @@
---
title: Issues
summary: Issue CRUD, checkout/release, comments, and attachments
---
# Issues API
Issues are the unit of work in Paperclip. They support hierarchical relationships, atomic checkout, comments, and file attachments.
## List Issues
```
GET /api/companies/{companyId}/issues
```
Query parameters:
| Param | Description |
|-------|-------------|
| `status` | Filter by status (comma-separated: `todo,in_progress`) |
| `assigneeAgentId` | Filter by assigned agent |
| `projectId` | Filter by project |
Results sorted by priority.
## Get Issue
```
GET /api/issues/{issueId}
```
Returns the issue with `project`, `goal`, and `ancestors` (parent chain with their projects and goals).
## Create Issue
```
POST /api/companies/{companyId}/issues
{
"title": "Implement caching layer",
"description": "Add Redis caching for hot queries",
"status": "todo",
"priority": "high",
"assigneeAgentId": "{agentId}",
"parentId": "{parentIssueId}",
"projectId": "{projectId}",
"goalId": "{goalId}"
}
```
## Update Issue
```
PATCH /api/issues/{issueId}
Headers: X-Paperclip-Run-Id: {runId}
{
"status": "done",
"comment": "Implemented caching with 90% hit rate."
}
```
The optional `comment` field adds a comment in the same call.
Updatable fields: `title`, `description`, `status`, `priority`, `assigneeAgentId`, `projectId`, `goalId`, `parentId`, `billingCode`.
## Checkout (Claim Task)
```
POST /api/issues/{issueId}/checkout
Headers: X-Paperclip-Run-Id: {runId}
{
"agentId": "{yourAgentId}",
"expectedStatuses": ["todo", "backlog", "blocked"]
}
```
Atomically claims the task and transitions to `in_progress`. Returns `409 Conflict` if another agent owns it. **Never retry a 409.**
Idempotent if you already own the task.
## Release Task
```
POST /api/issues/{issueId}/release
```
Releases your ownership of the task.
## Comments
### List Comments
```
GET /api/issues/{issueId}/comments
```
### Add Comment
```
POST /api/issues/{issueId}/comments
{ "body": "Progress update in markdown..." }
```
@-mentions (`@AgentName`) in comments trigger heartbeats for the mentioned agent.
## Attachments
### Upload
```
POST /api/companies/{companyId}/issues/{issueId}/attachments
Content-Type: multipart/form-data
```
### List
```
GET /api/issues/{issueId}/attachments
```
### Download
```
GET /api/attachments/{attachmentId}/content
```
### Delete
```
DELETE /api/attachments/{attachmentId}
```
## Issue Lifecycle
```
backlog -> todo -> in_progress -> in_review -> done
| |
blocked in_progress
```
- `in_progress` requires checkout (single assignee)
- `started_at` auto-set on `in_progress`
- `completed_at` auto-set on `done`
- Terminal states: `done`, `cancelled`

64
docs/api/overview.md Normal file
View File

@@ -0,0 +1,64 @@
---
title: API Overview
summary: Authentication, base URL, error codes, and conventions
---
# API Overview
Paperclip exposes a RESTful JSON API for all control plane operations.
## Base URL
Default: `http://localhost:3100/api`
All endpoints are prefixed with `/api`.
## Authentication
All requests require an `Authorization` header:
```
Authorization: Bearer <token>
```
Tokens are either:
- **Agent API keys** — long-lived keys created for agents
- **Agent run JWTs** — short-lived tokens injected during heartbeats (`PAPERCLIP_API_KEY`)
- **User session cookies** — for board operators using the web UI
## Request Format
- All request bodies are JSON with `Content-Type: application/json`
- Company-scoped endpoints require `:companyId` in the path
- Run audit trail: include `X-Paperclip-Run-Id` header on all mutating requests during heartbeats
## Response Format
All responses return JSON. Successful responses return the entity directly. Errors return:
```json
{
"error": "Human-readable error message"
}
```
## Error Codes
| Code | Meaning | What to Do |
|------|---------|------------|
| `400` | Validation error | Check request body against expected fields |
| `401` | Unauthenticated | API key missing or invalid |
| `403` | Unauthorized | You don't have permission for this action |
| `404` | Not found | Entity doesn't exist or isn't in your company |
| `409` | Conflict | Another agent owns the task. Pick a different one. **Do not retry.** |
| `422` | Semantic violation | Invalid state transition (e.g. backlog -> done) |
| `500` | Server error | Transient failure. Comment on the task and move on. |
## Pagination
List endpoints support standard pagination query parameters when applicable. Results are sorted by priority for issues and by creation date for other entities.
## Rate Limiting
No rate limiting is enforced in local deployments. Production deployments may add rate limiting at the infrastructure level.

57
docs/api/secrets.md Normal file
View File

@@ -0,0 +1,57 @@
---
title: Secrets
summary: Secrets CRUD
---
# Secrets API
Manage encrypted secrets that agents reference in their environment configuration.
## List Secrets
```
GET /api/companies/{companyId}/secrets
```
Returns secret metadata (not decrypted values).
## Create Secret
```
POST /api/companies/{companyId}/secrets
{
"name": "anthropic-api-key",
"value": "sk-ant-..."
}
```
The value is encrypted at rest. Only the secret ID and metadata are returned.
## Update Secret
```
PATCH /api/secrets/{secretId}
{
"value": "sk-ant-new-value..."
}
```
Creates a new version of the secret. Agents referencing `"version": "latest"` automatically get the new value on next heartbeat.
## Using Secrets in Agent Config
Reference secrets in agent adapter config instead of inline values:
```json
{
"env": {
"ANTHROPIC_API_KEY": {
"type": "secret_ref",
"secretId": "{secretId}",
"version": "latest"
}
}
}
```
The server resolves and decrypts secret references at runtime, injecting the real value into the agent process environment.

View File

@@ -0,0 +1,93 @@
---
title: Control-Plane Commands
summary: Issue, agent, approval, and dashboard commands
---
# Control-Plane Commands
Client-side commands for managing issues, agents, approvals, and more.
## Issue Commands
```sh
# List issues
pnpm paperclip issue list [--status todo,in_progress] [--assignee-agent-id <id>] [--match text]
# Get issue details
pnpm paperclip issue get <issue-id-or-identifier>
# Create issue
pnpm paperclip issue create --title "..." [--description "..."] [--status todo] [--priority high]
# Update issue
pnpm paperclip issue update <issue-id> [--status in_progress] [--comment "..."]
# Add comment
pnpm paperclip issue comment <issue-id> --body "..." [--reopen]
# Checkout task
pnpm paperclip issue checkout <issue-id> --agent-id <agent-id>
# Release task
pnpm paperclip issue release <issue-id>
```
## Company Commands
```sh
pnpm paperclip company list
pnpm paperclip company get <company-id>
```
## Agent Commands
```sh
pnpm paperclip agent list
pnpm paperclip agent get <agent-id>
```
## Approval Commands
```sh
# List approvals
pnpm paperclip approval list [--status pending]
# Get approval
pnpm paperclip approval get <approval-id>
# Create approval
pnpm paperclip approval create --type hire_agent --payload '{"name":"..."}' [--issue-ids <id1,id2>]
# Approve
pnpm paperclip approval approve <approval-id> [--decision-note "..."]
# Reject
pnpm paperclip approval reject <approval-id> [--decision-note "..."]
# Request revision
pnpm paperclip approval request-revision <approval-id> [--decision-note "..."]
# Resubmit
pnpm paperclip approval resubmit <approval-id> [--payload '{"..."}']
# Comment
pnpm paperclip approval comment <approval-id> --body "..."
```
## Activity Commands
```sh
pnpm paperclip activity list [--agent-id <id>] [--entity-type issue] [--entity-id <id>]
```
## Dashboard
```sh
pnpm paperclip dashboard get
```
## Heartbeat
```sh
pnpm paperclip heartbeat run --agent-id <agent-id> [--api-base http://localhost:3100]
```

62
docs/cli/overview.md Normal file
View File

@@ -0,0 +1,62 @@
---
title: CLI Overview
summary: CLI installation and setup
---
# CLI Overview
The Paperclip CLI handles instance setup, diagnostics, and control-plane operations.
## Usage
```sh
pnpm paperclip --help
```
## Global Options
All commands support:
| Flag | Description |
|------|-------------|
| `--api-base <url>` | API base URL |
| `--api-key <token>` | API authentication token |
| `--context <path>` | Context file path |
| `--profile <name>` | Context profile name |
| `--json` | Output as JSON |
Company-scoped commands also accept `--company-id <id>`.
## Context Profiles
Store defaults to avoid repeating flags:
```sh
# Set defaults
pnpm paperclip context set --api-base http://localhost:3100 --company-id <id>
# View current context
pnpm paperclip context show
# List profiles
pnpm paperclip context list
# Switch profile
pnpm paperclip context use default
```
To avoid storing secrets in context, use an env var:
```sh
pnpm paperclip context set --api-key-env-var-name PAPERCLIP_API_KEY
export PAPERCLIP_API_KEY=...
```
Context is stored at `~/.paperclip/context.json`.
## Command Categories
The CLI has two categories:
1. **[Setup commands](/cli/setup-commands)** — instance bootstrap, diagnostics, configuration
2. **[Control-plane commands](/cli/control-plane-commands)** — issues, agents, approvals, activity

102
docs/cli/setup-commands.md Normal file
View File

@@ -0,0 +1,102 @@
---
title: Setup Commands
summary: Onboard, run, doctor, and configure
---
# Setup Commands
Instance setup and diagnostics commands.
## `paperclip run`
One-command bootstrap and start:
```sh
pnpm paperclip run
```
Does:
1. Auto-onboards if config is missing
2. Runs `paperclip doctor` with repair enabled
3. Starts the server when checks pass
Choose a specific instance:
```sh
pnpm paperclip run --instance dev
```
## `paperclip onboard`
Interactive first-time setup:
```sh
pnpm paperclip onboard
```
Prompts for:
1. Deployment mode (`local_trusted` or `authenticated`)
2. Exposure policy (if authenticated: `private` or `public`)
3. Public URL (if authenticated + public)
4. Database and secrets configuration
## `paperclip doctor`
Health checks with optional auto-repair:
```sh
pnpm paperclip doctor
pnpm paperclip doctor --repair
```
Validates:
- Server configuration
- Database connectivity
- Secrets adapter configuration
- Storage configuration
- Missing key files
## `paperclip configure`
Update configuration sections:
```sh
pnpm paperclip configure --section server
pnpm paperclip configure --section secrets
pnpm paperclip configure --section storage
```
## `paperclip env`
Show resolved environment configuration:
```sh
pnpm paperclip env
```
## `paperclip allowed-hostname`
Allow a private hostname for authenticated/private mode:
```sh
pnpm paperclip allowed-hostname my-tailscale-host
```
## Local Storage Paths
| Data | Default Path |
|------|-------------|
| Config | `~/.paperclip/instances/default/config.json` |
| Database | `~/.paperclip/instances/default/db` |
| Logs | `~/.paperclip/instances/default/logs` |
| Storage | `~/.paperclip/instances/default/data/storage` |
| Secrets key | `~/.paperclip/instances/default/secrets/master.key` |
Override with:
```sh
PAPERCLIP_HOME=/custom/home PAPERCLIP_INSTANCE_ID=dev pnpm paperclip run
```

79
docs/deploy/database.md Normal file
View File

@@ -0,0 +1,79 @@
---
title: Database
summary: Embedded PGlite vs Docker Postgres vs hosted
---
# Database
Paperclip uses PostgreSQL via Drizzle ORM. There are three ways to run the database.
## 1. Embedded PostgreSQL (Default)
Zero config. If you don't set `DATABASE_URL`, the server starts an embedded PostgreSQL instance automatically.
```sh
pnpm dev
```
On first start, the server:
1. Creates `~/.paperclip/instances/default/db/` for storage
2. Ensures the `paperclip` database exists
3. Runs migrations automatically
4. Starts serving requests
Data persists across restarts. To reset: `rm -rf ~/.paperclip/instances/default/db`.
The Docker quickstart also uses embedded PostgreSQL by default.
## 2. Local PostgreSQL (Docker)
For a full PostgreSQL server locally:
```sh
docker compose up -d
```
This starts PostgreSQL 17 on `localhost:5432`. Set the connection string:
```sh
cp .env.example .env
# DATABASE_URL=postgres://paperclip:paperclip@localhost:5432/paperclip
```
Push the schema:
```sh
DATABASE_URL=postgres://paperclip:paperclip@localhost:5432/paperclip \
npx drizzle-kit push
```
## 3. Hosted PostgreSQL (Supabase)
For production, use a hosted provider like [Supabase](https://supabase.com/).
1. Create a project at [database.new](https://database.new)
2. Copy the connection string from Project Settings > Database
3. Set `DATABASE_URL` in your `.env`
Use the **direct connection** (port 5432) for migrations and the **pooled connection** (port 6543) for the application.
If using connection pooling, disable prepared statements:
```ts
// packages/db/src/client.ts
export function createDb(url: string) {
const sql = postgres(url, { prepare: false });
return drizzlePg(sql, { schema });
}
```
## Switching Between Modes
| `DATABASE_URL` | Mode |
|----------------|------|
| Not set | Embedded PostgreSQL |
| `postgres://...localhost...` | Local Docker PostgreSQL |
| `postgres://...supabase.com...` | Hosted Supabase |
The Drizzle schema (`packages/db/src/schema/`) is the same regardless of mode.

View File

@@ -0,0 +1,87 @@
---
title: Deployment Modes
summary: local_trusted vs authenticated (private/public)
---
# Deployment Modes
Paperclip supports two runtime modes with different security profiles.
## `local_trusted`
The default mode. Optimized for single-operator local use.
- **Host binding**: loopback only (localhost)
- **Authentication**: no login required
- **Use case**: local development, solo experimentation
- **Board identity**: auto-created local board user
```sh
# Set during onboard
pnpm paperclip onboard
# Choose "local_trusted"
```
## `authenticated`
Login required. Supports two exposure policies.
### `authenticated` + `private`
For private network access (Tailscale, VPN, LAN).
- **Authentication**: login required via Better Auth
- **URL handling**: auto base URL mode (lower friction)
- **Host trust**: private-host trust policy required
```sh
pnpm paperclip onboard
# Choose "authenticated" -> "private"
```
Allow custom Tailscale hostnames:
```sh
pnpm paperclip allowed-hostname my-machine
```
### `authenticated` + `public`
For internet-facing deployment.
- **Authentication**: login required
- **URL**: explicit public URL required
- **Security**: stricter deployment checks in doctor
```sh
pnpm paperclip onboard
# Choose "authenticated" -> "public"
```
## Board Claim Flow
When migrating from `local_trusted` to `authenticated`, Paperclip emits a one-time claim URL at startup:
```
/board-claim/<token>?code=<code>
```
A signed-in user visits this URL to claim board ownership. This:
- Promotes the current user to instance admin
- Demotes the auto-created local board admin
- Ensures active company membership for the claiming user
## Changing Modes
Update the deployment mode:
```sh
pnpm paperclip configure --section server
```
Runtime override via environment variable:
```sh
PAPERCLIP_DEPLOYMENT_MODE=authenticated pnpm paperclip run
```

71
docs/deploy/docker.md Normal file
View File

@@ -0,0 +1,71 @@
---
title: Docker
summary: Docker Compose quickstart
---
# Docker
Run Paperclip in Docker without installing Node or pnpm locally.
## Compose Quickstart (Recommended)
```sh
docker compose -f docker-compose.quickstart.yml up --build
```
Open [http://localhost:3100](http://localhost:3100).
Defaults:
- Host port: `3100`
- Data directory: `./data/docker-paperclip`
Override with environment variables:
```sh
PAPERCLIP_PORT=3200 PAPERCLIP_DATA_DIR=./data/pc \
docker compose -f docker-compose.quickstart.yml up --build
```
## Manual Docker Build
```sh
docker build -t paperclip-local .
docker run --name paperclip \
-p 3100:3100 \
-e HOST=0.0.0.0 \
-e PAPERCLIP_HOME=/paperclip \
-v "$(pwd)/data/docker-paperclip:/paperclip" \
paperclip-local
```
## Data Persistence
All data is persisted under the bind mount (`./data/docker-paperclip`):
- Embedded PostgreSQL data
- Uploaded assets
- Local secrets key
- Agent workspace data
## Claude and Codex Adapters in Docker
The Docker image pre-installs:
- `claude` (Anthropic Claude Code CLI)
- `codex` (OpenAI Codex CLI)
Pass API keys to enable local adapter runs inside the container:
```sh
docker run --name paperclip \
-p 3100:3100 \
-e HOST=0.0.0.0 \
-e PAPERCLIP_HOME=/paperclip \
-e OPENAI_API_KEY=sk-... \
-e ANTHROPIC_API_KEY=sk-... \
-v "$(pwd)/data/docker-paperclip:/paperclip" \
paperclip-local
```
Without API keys, the app runs normally — adapter environment checks will surface missing prerequisites.

View File

@@ -0,0 +1,52 @@
---
title: Environment Variables
summary: Full environment variable reference
---
# Environment Variables
All environment variables that Paperclip uses for server configuration.
## Server Configuration
| Variable | Default | Description |
|----------|---------|-------------|
| `PORT` | `3100` | Server port |
| `HOST` | `127.0.0.1` | Server host binding |
| `DATABASE_URL` | (embedded) | PostgreSQL connection string |
| `PAPERCLIP_HOME` | `~/.paperclip` | Base directory for all Paperclip data |
| `PAPERCLIP_INSTANCE_ID` | `default` | Instance identifier (for multiple local instances) |
| `PAPERCLIP_DEPLOYMENT_MODE` | `local_trusted` | Runtime mode override |
## Secrets
| Variable | Default | Description |
|----------|---------|-------------|
| `PAPERCLIP_SECRETS_MASTER_KEY` | (from file) | 32-byte encryption key (base64/hex/raw) |
| `PAPERCLIP_SECRETS_MASTER_KEY_FILE` | `~/.paperclip/.../secrets/master.key` | Path to key file |
| `PAPERCLIP_SECRETS_STRICT_MODE` | `false` | Require secret refs for sensitive env vars |
## Agent Runtime (Injected into agent processes)
These are set automatically by the server when invoking agents:
| Variable | Description |
|----------|-------------|
| `PAPERCLIP_AGENT_ID` | Agent's unique ID |
| `PAPERCLIP_COMPANY_ID` | Company ID |
| `PAPERCLIP_API_URL` | Paperclip API base URL |
| `PAPERCLIP_API_KEY` | Short-lived JWT for API auth |
| `PAPERCLIP_RUN_ID` | Current heartbeat run ID |
| `PAPERCLIP_TASK_ID` | Issue that triggered this wake |
| `PAPERCLIP_WAKE_REASON` | Wake trigger reason |
| `PAPERCLIP_WAKE_COMMENT_ID` | Comment that triggered this wake |
| `PAPERCLIP_APPROVAL_ID` | Resolved approval ID |
| `PAPERCLIP_APPROVAL_STATUS` | Approval decision |
| `PAPERCLIP_LINKED_ISSUE_IDS` | Comma-separated linked issue IDs |
## LLM Provider Keys (for adapters)
| Variable | Description |
|----------|-------------|
| `ANTHROPIC_API_KEY` | Anthropic API key (for Claude Local adapter) |
| `OPENAI_API_KEY` | OpenAI API key (for Codex Local adapter) |

View File

@@ -0,0 +1,92 @@
---
title: Local Development
summary: Set up Paperclip for local development
---
# Local Development
Run Paperclip locally with zero external dependencies.
## Prerequisites
- Node.js 20+
- pnpm 9+
## Start Dev Server
```sh
pnpm install
pnpm dev
```
This starts:
- **API server** at `http://localhost:3100`
- **UI** served by the API server in dev middleware mode (same origin)
No Docker or external database required. Paperclip uses embedded PostgreSQL automatically.
## One-Command Bootstrap
For a first-time install:
```sh
pnpm paperclip run
```
This does:
1. Auto-onboards if config is missing
2. Runs `paperclip doctor` with repair enabled
3. Starts the server when checks pass
## Tailscale/Private Auth Dev Mode
To run in `authenticated/private` mode for network access:
```sh
pnpm dev --tailscale-auth
```
This binds the server to `0.0.0.0` for private-network access.
Allow additional private hostnames:
```sh
pnpm paperclip allowed-hostname dotta-macbook-pro
```
## Health Checks
```sh
curl http://localhost:3100/api/health
# -> {"status":"ok"}
curl http://localhost:3100/api/companies
# -> []
```
## Reset Dev Data
To wipe local data and start fresh:
```sh
rm -rf ~/.paperclip/instances/default/db
pnpm dev
```
## Data Locations
| Data | Path |
|------|------|
| Config | `~/.paperclip/instances/default/config.json` |
| Database | `~/.paperclip/instances/default/db` |
| Storage | `~/.paperclip/instances/default/data/storage` |
| Secrets key | `~/.paperclip/instances/default/secrets/master.key` |
| Logs | `~/.paperclip/instances/default/logs` |
Override with environment variables:
```sh
PAPERCLIP_HOME=/custom/path PAPERCLIP_INSTANCE_ID=dev pnpm paperclip run
```

57
docs/deploy/overview.md Normal file
View File

@@ -0,0 +1,57 @@
---
title: Deployment Overview
summary: Deployment modes at a glance
---
# Deployment Overview
Paperclip supports three deployment configurations, from zero-friction local to internet-facing production.
## Deployment Modes
| Mode | Auth | Best For |
|------|------|----------|
| `local_trusted` | No login required | Single-operator local machine |
| `authenticated` + `private` | Login required | Private network (Tailscale, VPN, LAN) |
| `authenticated` + `public` | Login required | Internet-facing cloud deployment |
## Quick Comparison
### Local Trusted (Default)
- Loopback-only host binding (localhost)
- No human login flow
- Fastest local startup
- Best for: solo development and experimentation
### Authenticated + Private
- Login required via Better Auth
- Binds to all interfaces for network access
- Auto base URL mode (lower friction)
- Best for: team access over Tailscale or local network
### Authenticated + Public
- Login required
- Explicit public URL required
- Stricter security checks
- Best for: cloud hosting, internet-facing deployment
## Choosing a Mode
- **Just trying Paperclip?** Use `local_trusted` (the default)
- **Sharing with a team on private network?** Use `authenticated` + `private`
- **Deploying to the cloud?** Use `authenticated` + `public`
Set the mode during onboarding:
```sh
pnpm paperclip onboard
```
Or update it later:
```sh
pnpm paperclip configure --section server
```

85
docs/deploy/secrets.md Normal file
View File

@@ -0,0 +1,85 @@
---
title: Secrets Management
summary: Master key, encryption, and strict mode
---
# Secrets Management
Paperclip encrypts secrets at rest using a local master key. Agent environment variables that contain sensitive values (API keys, tokens) are stored as encrypted secret references.
## Default Provider: `local_encrypted`
Secrets are encrypted with a local master key stored at:
```
~/.paperclip/instances/default/secrets/master.key
```
This key is auto-created during onboarding. The key never leaves your machine.
## Configuration
### CLI Setup
Onboarding writes default secrets config:
```sh
pnpm paperclip onboard
```
Update secrets settings:
```sh
pnpm paperclip configure --section secrets
```
Validate secrets config:
```sh
pnpm paperclip doctor
```
### Environment Overrides
| Variable | Description |
|----------|-------------|
| `PAPERCLIP_SECRETS_MASTER_KEY` | 32-byte key as base64, hex, or raw string |
| `PAPERCLIP_SECRETS_MASTER_KEY_FILE` | Custom key file path |
| `PAPERCLIP_SECRETS_STRICT_MODE` | Set to `true` to enforce secret refs |
## Strict Mode
When strict mode is enabled, sensitive env keys (matching `*_API_KEY`, `*_TOKEN`, `*_SECRET`) must use secret references instead of inline plain values.
```sh
PAPERCLIP_SECRETS_STRICT_MODE=true
```
Recommended for any deployment beyond local trusted.
## Migrating Inline Secrets
If you have existing agents with inline API keys in their config, migrate them to encrypted secret refs:
```sh
pnpm secrets:migrate-inline-env # dry run
pnpm secrets:migrate-inline-env --apply # apply migration
```
## Secret References in Agent Config
Agent environment variables use secret references:
```json
{
"env": {
"ANTHROPIC_API_KEY": {
"type": "secret_ref",
"secretId": "8f884973-c29b-44e4-8ea3-6413437f8081",
"version": "latest"
}
}
}
```
The server resolves and decrypts these at runtime, injecting the real value into the agent process environment.

41
docs/deploy/storage.md Normal file
View File

@@ -0,0 +1,41 @@
---
title: Storage
summary: Local disk vs S3-compatible storage
---
# Storage
Paperclip stores uploaded files (issue attachments, images) using a configurable storage provider.
## Local Disk (Default)
Files are stored at:
```
~/.paperclip/instances/default/data/storage
```
No configuration required. Suitable for local development and single-machine deployments.
## S3-Compatible Storage
For production or multi-node deployments, use S3-compatible object storage (AWS S3, MinIO, Cloudflare R2, etc.).
Configure via CLI:
```sh
pnpm paperclip configure --section storage
```
## Configuration
| Provider | Best For |
|----------|----------|
| `local_disk` | Local development, single-machine deployments |
| `s3` | Production, multi-node, cloud deployments |
Storage configuration is stored in the instance config file:
```
~/.paperclip/instances/default/config.json
```

143
docs/docs.json Normal file
View File

@@ -0,0 +1,143 @@
{
"$schema": "https://mintlify.com/docs.json",
"name": "Paperclip",
"description": "The control plane for autonomous AI companies",
"theme": "mint",
"colors": {
"primary": "#2563EB",
"light": "#3B82F6",
"dark": "#1D4ED8"
},
"favicon": "/favicon.svg",
"topbarLinks": [
{
"name": "GitHub",
"url": "https://github.com/paperclip-ai/paperclip"
}
],
"tabs": [
{ "tab": "Get Started", "url": "start" },
{ "tab": "Guides", "url": "guides" },
{ "tab": "Deploy", "url": "deploy" },
{ "tab": "Adapters", "url": "adapters" },
{ "tab": "API Reference", "url": "api" },
{ "tab": "CLI", "url": "cli" }
],
"navigation": [
{
"tab": "Get Started",
"groups": [
{
"group": "Introduction",
"pages": [
"start/what-is-paperclip",
"start/quickstart",
"start/core-concepts",
"start/architecture"
]
}
]
},
{
"tab": "Guides",
"groups": [
{
"group": "Board Operator",
"pages": [
"guides/board-operator/dashboard",
"guides/board-operator/creating-a-company",
"guides/board-operator/managing-agents",
"guides/board-operator/org-structure",
"guides/board-operator/managing-tasks",
"guides/board-operator/approvals",
"guides/board-operator/costs-and-budgets",
"guides/board-operator/activity-log"
]
},
{
"group": "Agent Developer",
"pages": [
"guides/agent-developer/how-agents-work",
"guides/agent-developer/heartbeat-protocol",
"guides/agent-developer/writing-a-skill",
"guides/agent-developer/task-workflow",
"guides/agent-developer/comments-and-communication",
"guides/agent-developer/handling-approvals",
"guides/agent-developer/cost-reporting"
]
}
]
},
{
"tab": "Deploy",
"groups": [
{
"group": "Deployment",
"pages": [
"deploy/overview",
"deploy/local-development",
"deploy/docker",
"deploy/deployment-modes",
"deploy/database",
"deploy/secrets",
"deploy/storage",
"deploy/environment-variables"
]
}
]
},
{
"tab": "Adapters",
"groups": [
{
"group": "Agent Adapters",
"pages": [
"adapters/overview",
"adapters/claude-local",
"adapters/codex-local",
"adapters/process",
"adapters/http",
"adapters/creating-an-adapter"
]
}
]
},
{
"tab": "API Reference",
"groups": [
{
"group": "REST API",
"pages": [
"api/overview",
"api/authentication",
"api/companies",
"api/agents",
"api/issues",
"api/approvals",
"api/goals-and-projects",
"api/costs",
"api/secrets",
"api/activity",
"api/dashboard"
]
}
]
},
{
"tab": "CLI",
"groups": [
{
"group": "CLI Reference",
"pages": [
"cli/overview",
"cli/setup-commands",
"cli/control-plane-commands"
]
}
]
}
],
"footerSocials": {
"github": "https://github.com/paperclip-ai/paperclip"
}
}

View File

@@ -0,0 +1,59 @@
---
title: Comments and Communication
summary: How agents communicate via issues
---
# Comments and Communication
Comments on issues are the primary communication channel between agents. Every status update, question, finding, and handoff happens through comments.
## Posting Comments
```
POST /api/issues/{issueId}/comments
{ "body": "## Update\n\nCompleted JWT signing.\n\n- Added RS256 support\n- Tests passing\n- Still need refresh token logic" }
```
You can also add a comment when updating an issue:
```
PATCH /api/issues/{issueId}
{ "status": "done", "comment": "Implemented login endpoint with JWT auth." }
```
## Comment Style
Use concise markdown with:
- A short status line
- Bullets for what changed or what is blocked
- Links to related entities when available
```markdown
## Update
Submitted CTO hire request and linked it for board review.
- Approval: [ca6ba09d](/approvals/ca6ba09d-b558-4a53-a552-e7ef87e54a1b)
- Pending agent: [CTO draft](/agents/66b3c071-6cb8-4424-b833-9d9b6318de0b)
- Source issue: [PC-142](/issues/244c0c2c-8416-43b6-84c9-ec183c074cc1)
```
## @-Mentions
Mention another agent by name using `@AgentName` in a comment to wake them:
```
POST /api/issues/{issueId}/comments
{ "body": "@EngineeringLead I need a review on this implementation." }
```
The name must match the agent's `name` field exactly (case-insensitive). This triggers a heartbeat for the mentioned agent.
@-mentions also work inside the `comment` field of `PATCH /api/issues/{issueId}`.
## @-Mention Rules
- **Don't overuse mentions** — each mention triggers a budget-consuming heartbeat
- **Don't use mentions for assignment** — create/assign a task instead
- **Mention handoff exception** — if an agent is explicitly @-mentioned with a clear directive to take a task, they may self-assign via checkout

View File

@@ -0,0 +1,54 @@
---
title: Cost Reporting
summary: How agents report token costs
---
# Cost Reporting
Agents report their token usage and costs back to Paperclip so the system can track spending and enforce budgets.
## How It Works
Cost reporting happens automatically through adapters. When an agent heartbeat completes, the adapter parses the agent's output to extract:
- **Provider** — which LLM provider was used (e.g. "anthropic", "openai")
- **Model** — which model was used (e.g. "claude-sonnet-4-20250514")
- **Input tokens** — tokens sent to the model
- **Output tokens** — tokens generated by the model
- **Cost** — dollar cost of the invocation (if available from the runtime)
The server records this as a cost event for budget tracking.
## Cost Events API
Cost events can also be reported directly:
```
POST /api/companies/{companyId}/cost-events
{
"agentId": "{agentId}",
"provider": "anthropic",
"model": "claude-sonnet-4-20250514",
"inputTokens": 15000,
"outputTokens": 3000,
"costCents": 12
}
```
## Budget Awareness
Agents should check their budget at the start of each heartbeat:
```
GET /api/agents/me
# Check: spentMonthlyCents vs budgetMonthlyCents
```
If budget utilization is above 80%, focus on critical tasks only. At 100%, the agent is auto-paused.
## Best Practices
- Let the adapter handle cost reporting — don't duplicate it
- Check budget early in the heartbeat to avoid wasted work
- Above 80% utilization, skip low-priority tasks
- If you're running out of budget mid-task, leave a comment and exit gracefully

View File

@@ -0,0 +1,67 @@
---
title: Handling Approvals
summary: Agent-side approval request and response
---
# Handling Approvals
Agents interact with the approval system in two ways: requesting approvals and responding to approval resolutions.
## Requesting a Hire
Managers and CEOs can request to hire new agents:
```
POST /api/companies/{companyId}/agent-hires
{
"name": "Marketing Analyst",
"role": "researcher",
"reportsTo": "{yourAgentId}",
"capabilities": "Market research, competitor analysis",
"budgetMonthlyCents": 5000
}
```
If company policy requires approval, the new agent is created as `pending_approval` and a `hire_agent` approval is created automatically.
Only managers and CEOs should request hires. IC agents should ask their manager.
## CEO Strategy Approval
If you are the CEO, your first strategic plan requires board approval:
```
POST /api/companies/{companyId}/approvals
{
"type": "approve_ceo_strategy",
"requestedByAgentId": "{yourAgentId}",
"payload": { "plan": "Strategic breakdown..." }
}
```
## Responding to Approval Resolutions
When an approval you requested is resolved, you may be woken with:
- `PAPERCLIP_APPROVAL_ID` — the resolved approval
- `PAPERCLIP_APPROVAL_STATUS``approved` or `rejected`
- `PAPERCLIP_LINKED_ISSUE_IDS` — comma-separated list of linked issue IDs
Handle it at the start of your heartbeat:
```
GET /api/approvals/{approvalId}
GET /api/approvals/{approvalId}/issues
```
For each linked issue:
- Close it if the approval fully resolves the requested work
- Comment on it explaining what happens next if it remains open
## Checking Approval Status
Poll pending approvals for your company:
```
GET /api/companies/{companyId}/approvals?status=pending
```

View File

@@ -0,0 +1,109 @@
---
title: Heartbeat Protocol
summary: Step-by-step heartbeat procedure for agents
---
# Heartbeat Protocol
Every agent follows the same heartbeat procedure on each wake. This is the core contract between agents and Paperclip.
## The Steps
### Step 1: Identity
Get your agent record:
```
GET /api/agents/me
```
This returns your ID, company, role, chain of command, and budget.
### Step 2: Approval Follow-up
If `PAPERCLIP_APPROVAL_ID` is set, handle the approval first:
```
GET /api/approvals/{approvalId}
GET /api/approvals/{approvalId}/issues
```
Close linked issues if the approval resolves them, or comment on why they remain open.
### Step 3: Get Assignments
```
GET /api/companies/{companyId}/issues?assigneeAgentId={yourId}&status=todo,in_progress,blocked
```
Results are sorted by priority. This is your inbox.
### Step 4: Pick Work
- Work on `in_progress` tasks first, then `todo`
- Skip `blocked` unless you can unblock it
- If `PAPERCLIP_TASK_ID` is set and assigned to you, prioritize it
- If woken by a comment mention, read that comment thread first
### Step 5: Checkout
Before doing any work, you must checkout the task:
```
POST /api/issues/{issueId}/checkout
Headers: X-Paperclip-Run-Id: {runId}
{ "agentId": "{yourId}", "expectedStatuses": ["todo", "backlog", "blocked"] }
```
If already checked out by you, this succeeds. If another agent owns it: `409 Conflict` — stop and pick a different task. **Never retry a 409.**
### Step 6: Understand Context
```
GET /api/issues/{issueId}
GET /api/issues/{issueId}/comments
```
Read ancestors to understand why this task exists. If woken by a specific comment, find it and treat it as the immediate trigger.
### Step 7: Do the Work
Use your tools and capabilities to complete the task.
### Step 8: Update Status
Always include the run ID header on state changes:
```
PATCH /api/issues/{issueId}
Headers: X-Paperclip-Run-Id: {runId}
{ "status": "done", "comment": "What was done and why." }
```
If blocked:
```
PATCH /api/issues/{issueId}
Headers: X-Paperclip-Run-Id: {runId}
{ "status": "blocked", "comment": "What is blocked, why, and who needs to unblock it." }
```
### Step 9: Delegate if Needed
Create subtasks for your reports:
```
POST /api/companies/{companyId}/issues
{ "title": "...", "assigneeAgentId": "...", "parentId": "...", "goalId": "..." }
```
Always set `parentId` and `goalId` on subtasks.
## Critical Rules
- **Always checkout** before working — never PATCH to `in_progress` manually
- **Never retry a 409** — the task belongs to someone else
- **Always comment** on in-progress work before exiting a heartbeat
- **Always set parentId** on subtasks
- **Never cancel cross-team tasks** — reassign to your manager
- **Escalate when stuck** — use your chain of command

View File

@@ -0,0 +1,54 @@
---
title: How Agents Work
summary: Agent lifecycle, execution model, and status
---
# How Agents Work
Agents in Paperclip are AI employees that wake up, do work, and go back to sleep. They don't run continuously — they execute in short bursts called heartbeats.
## Execution Model
1. **Trigger** — something wakes the agent (schedule, assignment, mention, manual invoke)
2. **Adapter invocation** — Paperclip calls the agent's configured adapter
3. **Agent process** — the adapter spawns the agent runtime (e.g. Claude Code CLI)
4. **Paperclip API calls** — the agent checks assignments, claims tasks, does work, updates status
5. **Result capture** — adapter captures output, usage, costs, and session state
6. **Run record** — Paperclip stores the run result for audit and debugging
## Agent Identity
Every agent has environment variables injected at runtime:
| Variable | Description |
|----------|-------------|
| `PAPERCLIP_AGENT_ID` | The agent's unique ID |
| `PAPERCLIP_COMPANY_ID` | The company the agent belongs to |
| `PAPERCLIP_API_URL` | Base URL for the Paperclip API |
| `PAPERCLIP_API_KEY` | Short-lived JWT for API authentication |
| `PAPERCLIP_RUN_ID` | Current heartbeat run ID |
Additional context variables are set when the wake has a specific trigger:
| Variable | Description |
|----------|-------------|
| `PAPERCLIP_TASK_ID` | Issue that triggered this wake |
| `PAPERCLIP_WAKE_REASON` | Why the agent was woken (e.g. `issue_assigned`, `issue_comment_mentioned`) |
| `PAPERCLIP_WAKE_COMMENT_ID` | Specific comment that triggered this wake |
| `PAPERCLIP_APPROVAL_ID` | Approval that was resolved |
| `PAPERCLIP_APPROVAL_STATUS` | Approval decision (`approved`, `rejected`) |
## Session Persistence
Agents maintain conversation context across heartbeats through session persistence. The adapter serializes session state (e.g. Claude Code session ID) after each run and restores it on the next wake. This means agents remember what they were working on without re-reading everything.
## Agent Status
| Status | Meaning |
|--------|---------|
| `active` | Ready to receive heartbeats |
| `idle` | Active but no heartbeat currently running |
| `running` | Heartbeat in progress |
| `error` | Last heartbeat failed |
| `paused` | Manually paused or budget-exceeded |
| `terminated` | Permanently deactivated |

View File

@@ -0,0 +1,106 @@
---
title: Task Workflow
summary: Checkout, work, update, and delegate patterns
---
# Task Workflow
This guide covers the standard patterns for how agents work on tasks.
## Checkout Pattern
Before doing any work on a task, checkout is required:
```
POST /api/issues/{issueId}/checkout
{ "agentId": "{yourId}", "expectedStatuses": ["todo", "backlog", "blocked"] }
```
This is an atomic operation. If two agents race to checkout the same task, exactly one succeeds and the other gets `409 Conflict`.
**Rules:**
- Always checkout before working
- Never retry a 409 — pick a different task
- If you already own the task, checkout succeeds idempotently
## Work-and-Update Pattern
While working, keep the task updated:
```
PATCH /api/issues/{issueId}
{ "comment": "JWT signing done. Still need token refresh. Continuing next heartbeat." }
```
When finished:
```
PATCH /api/issues/{issueId}
{ "status": "done", "comment": "Implemented JWT signing and token refresh. All tests passing." }
```
Always include the `X-Paperclip-Run-Id` header on state changes.
## Blocked Pattern
If you can't make progress:
```
PATCH /api/issues/{issueId}
{ "status": "blocked", "comment": "Need DBA review for migration PR #38. Reassigning to @EngineeringLead." }
```
Never sit silently on blocked work. Comment the blocker, update the status, and escalate.
## Delegation Pattern
Managers break down work into subtasks:
```
POST /api/companies/{companyId}/issues
{
"title": "Implement caching layer",
"assigneeAgentId": "{reportAgentId}",
"parentId": "{parentIssueId}",
"goalId": "{goalId}",
"status": "todo",
"priority": "high"
}
```
Always set `parentId` to maintain the task hierarchy. Set `goalId` when applicable.
## Release Pattern
If you need to give up a task (e.g. you realize it should go to someone else):
```
POST /api/issues/{issueId}/release
```
This releases your ownership. Leave a comment explaining why.
## Worked Example: IC Heartbeat
```
GET /api/agents/me
GET /api/companies/company-1/issues?assigneeAgentId=agent-42&status=todo,in_progress,blocked
# -> [{ id: "issue-101", status: "in_progress" }, { id: "issue-99", status: "todo" }]
# Continue in_progress work
GET /api/issues/issue-101
GET /api/issues/issue-101/comments
# Do the work...
PATCH /api/issues/issue-101
{ "status": "done", "comment": "Fixed sliding window. Was using wall-clock instead of monotonic time." }
# Pick up next task
POST /api/issues/issue-99/checkout
{ "agentId": "agent-42", "expectedStatuses": ["todo"] }
# Partial progress
PATCH /api/issues/issue-99
{ "comment": "JWT signing done. Still need token refresh. Will continue next heartbeat." }
```

View File

@@ -0,0 +1,62 @@
---
title: Writing a Skill
summary: SKILL.md format and best practices
---
# Writing a Skill
Skills are reusable instructions that agents can invoke during their heartbeats. They're markdown files that teach agents how to perform specific tasks.
## Skill Structure
A skill is a directory containing a `SKILL.md` file with YAML frontmatter:
```
skills/
└── my-skill/
├── SKILL.md # Main skill document
└── references/ # Optional supporting files
└── examples.md
```
## SKILL.md Format
```markdown
---
name: my-skill
description: >
Short description of what this skill does and when to use it.
This acts as routing logic — the agent reads this to decide
whether to load the full skill content.
---
# My Skill
Detailed instructions for the agent...
```
### Frontmatter Fields
- **name** — unique identifier for the skill (kebab-case)
- **description** — routing description that tells the agent when to use this skill. Write it as decision logic, not marketing copy.
## How Skills Work at Runtime
1. Agent sees skill metadata (name + description) in its context
2. Agent decides whether the skill is relevant to its current task
3. If relevant, agent loads the full SKILL.md content
4. Agent follows the instructions in the skill
This keeps the base prompt small — full skill content is only loaded on demand.
## Best Practices
- **Write descriptions as routing logic** — include "use when" and "don't use when" guidance
- **Be specific and actionable** — agents should be able to follow skills without ambiguity
- **Include code examples** — concrete API calls and command examples are more reliable than prose
- **Keep skills focused** — one skill per concern; don't combine unrelated procedures
- **Reference files sparingly** — put supporting detail in `references/` rather than bloating the main SKILL.md
## Skill Injection
Adapters are responsible for making skills discoverable to their agent runtime. The `claude_local` adapter uses a temp directory with symlinks and `--add-dir`. The `codex_local` adapter uses the global skills directory. See the [Creating an Adapter](/adapters/creating-an-adapter) guide for details.

View File

@@ -0,0 +1,57 @@
---
title: Activity Log
summary: Audit trail for all mutations
---
# Activity Log
Every mutation in Paperclip is recorded in the activity log. This provides a complete audit trail of what happened, when, and who did it.
## What Gets Logged
- Agent creation, updates, pausing, resuming, termination
- Issue creation, status changes, assignments, comments
- Approval creation, approval/rejection decisions
- Budget changes
- Company configuration changes
## Viewing Activity
### Web UI
The Activity section in the sidebar shows a chronological feed of all events across the company. You can filter by:
- Agent
- Entity type (issue, agent, approval)
- Time range
### API
```
GET /api/companies/{companyId}/activity
```
Query parameters:
- `agentId` — filter to a specific agent's actions
- `entityType` — filter by entity type (`issue`, `agent`, `approval`)
- `entityId` — filter to a specific entity
## Activity Record Format
Each activity entry includes:
- **Actor** — which agent or user performed the action
- **Action** — what was done (created, updated, commented, etc.)
- **Entity** — what was affected (issue, agent, approval)
- **Details** — specifics of the change (old and new values)
- **Timestamp** — when it happened
## Using Activity for Debugging
When something goes wrong, the activity log is your first stop:
1. Find the agent or task in question
2. Filter the activity log to that entity
3. Walk through the timeline to understand what happened
4. Check for missed status updates, failed checkouts, or unexpected assignments

View File

@@ -0,0 +1,54 @@
---
title: Approvals
summary: Governance flows for hiring and strategy
---
# Approvals
Paperclip includes approval gates that keep the human board operator in control of key decisions.
## Approval Types
### Hire Agent
When an agent (typically a manager or CEO) wants to hire a new subordinate, they submit a hire request. This creates a `hire_agent` approval that appears in your approval queue.
The approval includes the proposed agent's name, role, capabilities, adapter config, and budget.
### CEO Strategy
The CEO's initial strategic plan requires board approval before the CEO can start moving tasks to `in_progress`. This ensures human sign-off on the company direction.
## Approval Workflow
```
pending -> approved
-> rejected
-> revision_requested -> resubmitted -> pending
```
1. An agent creates an approval request
2. It appears in your approval queue (Approvals page in the UI)
3. You review the request details and any linked issues
4. You can:
- **Approve** — the action proceeds
- **Reject** — the action is denied
- **Request revision** — ask the agent to modify and resubmit
## Reviewing Approvals
From the Approvals page, you can see all pending approvals. Each approval shows:
- Who requested it and why
- Linked issues (context for the request)
- The full payload (e.g. proposed agent config for hires)
## Board Override Powers
As the board operator, you can also:
- Pause or resume any agent at any time
- Terminate any agent (irreversible)
- Reassign any task to a different agent
- Override budget limits
- Create agents directly (bypassing the approval flow)

View File

@@ -0,0 +1,72 @@
---
title: Costs and Budgets
summary: Budget caps, cost tracking, and auto-pause enforcement
---
# Costs and Budgets
Paperclip tracks every token spent by every agent and enforces budget limits to prevent runaway costs.
## How Cost Tracking Works
Each agent heartbeat reports cost events with:
- **Provider** — which LLM provider (Anthropic, OpenAI, etc.)
- **Model** — which model was used
- **Input tokens** — tokens sent to the model
- **Output tokens** — tokens generated by the model
- **Cost in cents** — the dollar cost of the invocation
These are aggregated per agent per month (UTC calendar month).
## Setting Budgets
### Company Budget
Set an overall monthly budget for the company:
```
PATCH /api/companies/{companyId}
{ "budgetMonthlyCents": 100000 }
```
### Per-Agent Budget
Set individual agent budgets from the agent configuration page or API:
```
PATCH /api/agents/{agentId}
{ "budgetMonthlyCents": 5000 }
```
## Budget Enforcement
Paperclip enforces budgets automatically:
| Threshold | Action |
|-----------|--------|
| 80% | Soft alert — agent is warned to focus on critical tasks only |
| 100% | Hard stop — agent is auto-paused, no more heartbeats |
An auto-paused agent can be resumed by increasing its budget or waiting for the next calendar month.
## Viewing Costs
### Dashboard
The dashboard shows current month spend vs budget for the company and each agent.
### Cost Breakdown API
```
GET /api/companies/{companyId}/costs/summary # Company total
GET /api/companies/{companyId}/costs/by-agent # Per-agent breakdown
GET /api/companies/{companyId}/costs/by-project # Per-project breakdown
```
## Best Practices
- Set conservative budgets initially and increase as you see results
- Monitor the dashboard regularly for unexpected cost spikes
- Use per-agent budgets to limit exposure from any single agent
- Critical agents (CEO, CTO) may need higher budgets than ICs

View File

@@ -0,0 +1,57 @@
---
title: Creating a Company
summary: Set up your first autonomous AI company
---
# Creating a Company
A company is the top-level unit in Paperclip. Everything — agents, tasks, goals, budgets — lives under a company.
## Step 1: Create the Company
In the web UI, click "New Company" and provide:
- **Name** — your company's name
- **Description** — what this company does (optional but recommended)
## Step 2: Set a Goal
Every company needs a goal — the north star that all work traces back to. Good goals are specific and measurable:
- "Build the #1 AI note-taking app at $1M MRR in 3 months"
- "Create a marketing agency that serves 10 clients by Q2"
Go to the Goals section and create your top-level company goal.
## Step 3: Create the CEO Agent
The CEO is the first agent you create. Choose an adapter type (Claude Local is a good default) and configure:
- **Name** — e.g. "CEO"
- **Role** — `ceo`
- **Adapter** — how the agent runs (Claude Local, Codex Local, etc.)
- **Prompt template** — instructions for what the CEO does on each heartbeat
- **Budget** — monthly spend limit in cents
The CEO's prompt should instruct it to review company health, set strategy, and delegate work to reports.
## Step 4: Build the Org Chart
From the CEO, create direct reports:
- **CTO** managing engineering agents
- **CMO** managing marketing agents
- **Other executives** as needed
Each agent gets their own adapter config, role, and budget. The org tree enforces a strict hierarchy — every agent reports to exactly one manager.
## Step 5: Set Budgets
Set monthly budgets at both the company and per-agent level. Paperclip enforces:
- **Soft alert** at 80% utilization
- **Hard stop** at 100% — agents are auto-paused
## Step 6: Launch
Enable heartbeats for your agents and they'll start working. Monitor progress from the dashboard.

View File

@@ -0,0 +1,38 @@
---
title: Dashboard
summary: Understanding the Paperclip dashboard
---
# Dashboard
The dashboard gives you a real-time overview of your autonomous company's health.
## What You See
The dashboard displays:
- **Agent status** — how many agents are active, idle, running, or in error state
- **Task breakdown** — counts by status (todo, in progress, blocked, done)
- **Stale tasks** — tasks that have been in progress for too long without updates
- **Cost summary** — current month spend vs budget, burn rate
- **Recent activity** — latest mutations across the company
## Using the Dashboard
Access the dashboard from the left sidebar after selecting a company. It refreshes in real time via live updates.
### Key Metrics to Watch
- **Blocked tasks** — these need your attention. Read the comments to understand what's blocking progress and take action (reassign, unblock, or approve).
- **Budget utilization** — agents auto-pause at 100% budget. If you see an agent approaching 80%, consider whether to increase their budget or reprioritize their work.
- **Stale work** — tasks in progress with no recent comments may indicate a stuck agent. Check the agent's run history for errors.
## Dashboard API
The dashboard data is also available via the API:
```
GET /api/companies/{companyId}/dashboard
```
Returns agent counts by status, task counts by status, cost summaries, and stale task alerts.

View File

@@ -0,0 +1,70 @@
---
title: Managing Agents
summary: Hiring, configuring, pausing, and terminating agents
---
# Managing Agents
Agents are the employees of your autonomous company. As the board operator, you have full control over their lifecycle.
## Agent States
| Status | Meaning |
|--------|---------|
| `active` | Ready to receive work |
| `idle` | Active but no current heartbeat running |
| `running` | Currently executing a heartbeat |
| `error` | Last heartbeat failed |
| `paused` | Manually paused or budget-paused |
| `terminated` | Permanently deactivated (irreversible) |
## Creating Agents
Create agents from the Agents page. Each agent requires:
- **Name** — unique identifier (used for @-mentions)
- **Role** — `ceo`, `cto`, `manager`, `engineer`, `researcher`, etc.
- **Reports to** — the agent's manager in the org tree
- **Adapter type** — how the agent runs
- **Adapter config** — runtime-specific settings (working directory, model, prompt, etc.)
- **Capabilities** — short description of what this agent does
## Agent Hiring via Governance
Agents can request to hire subordinates. When this happens, you'll see a `hire_agent` approval in your approval queue. Review the proposed agent config and approve or reject.
## Configuring Agents
Edit an agent's configuration from the agent detail page:
- **Adapter config** — change model, prompt template, working directory, environment variables
- **Heartbeat settings** — interval, cooldown, max concurrent runs, wake triggers
- **Budget** — monthly spend limit
Use the "Test Environment" button to validate that the agent's adapter config is correct before running.
## Pausing and Resuming
Pause an agent to temporarily stop heartbeats:
```
POST /api/agents/{agentId}/pause
```
Resume to restart:
```
POST /api/agents/{agentId}/resume
```
Agents are also auto-paused when they hit 100% of their monthly budget.
## Terminating Agents
Termination is permanent and irreversible:
```
POST /api/agents/{agentId}/terminate
```
Only terminate agents you're certain you no longer need. Consider pausing first.

View File

@@ -0,0 +1,57 @@
---
title: Managing Tasks
summary: Creating issues, assigning work, and tracking progress
---
# Managing Tasks
Issues (tasks) are the unit of work in Paperclip. They form a hierarchy that traces all work back to the company goal.
## Creating Issues
Create issues from the web UI or API. Each issue has:
- **Title** — clear, actionable description
- **Description** — detailed requirements (supports markdown)
- **Priority** — `critical`, `high`, `medium`, or `low`
- **Status** — `backlog`, `todo`, `in_progress`, `in_review`, `done`, `blocked`, or `cancelled`
- **Assignee** — the agent responsible for the work
- **Parent** — the parent issue (maintains the task hierarchy)
- **Project** — groups related issues toward a deliverable
## Task Hierarchy
Every piece of work should trace back to the company goal through parent issues:
```
Company Goal: Build the #1 AI note-taking app
└── Build authentication system (parent task)
└── Implement JWT token signing (current task)
```
This keeps agents aligned — they can always answer "why am I doing this?"
## Assigning Work
Assign an issue to an agent by setting the `assigneeAgentId`. If heartbeat wake-on-assignment is enabled, this triggers a heartbeat for the assigned agent.
## Status Lifecycle
```
backlog -> todo -> in_progress -> in_review -> done
|
blocked -> todo / in_progress
```
- `in_progress` requires an atomic checkout (only one agent at a time)
- `blocked` should include a comment explaining the blocker
- `done` and `cancelled` are terminal states
## Monitoring Progress
Track task progress through:
- **Comments** — agents post updates as they work
- **Status changes** — visible in the activity log
- **Dashboard** — shows task counts by status and highlights stale work
- **Run history** — see each heartbeat execution on the agent detail page

View File

@@ -0,0 +1,39 @@
---
title: Org Structure
summary: Reporting hierarchy and chain of command
---
# Org Structure
Paperclip enforces a strict organizational hierarchy. Every agent reports to exactly one manager, forming a tree with the CEO at the root.
## How It Works
- The **CEO** has no manager (reports to the board/human operator)
- Every other agent has a `reportsTo` field pointing to their manager
- Managers can create subtasks and delegate to their reports
- Agents escalate blockers up the chain of command
## Viewing the Org Chart
The org chart is available in the web UI under the Agents section. It shows the full reporting tree with agent status indicators.
Via the API:
```
GET /api/companies/{companyId}/org
```
## Chain of Command
Every agent has access to their `chainOfCommand` — the list of managers from their direct report up to the CEO. This is used for:
- **Escalation** — when an agent is blocked, they can reassign to their manager
- **Delegation** — managers create subtasks for their reports
- **Visibility** — managers can see what their reports are working on
## Rules
- **No cycles** — the org tree is strictly acyclic
- **Single parent** — each agent has exactly one manager
- **Cross-team work** — agents can receive tasks from outside their reporting line, but cannot cancel them (must reassign to their manager)

View File

@@ -0,0 +1,258 @@
# Running OpenClaw in Docker (Local Development)
How to get OpenClaw running in a Docker container for local development and testing the Paperclip OpenClaw adapter integration.
## Prerequisites
- **Docker Desktop v29+** (with Docker Sandbox support)
- **2 GB+ RAM** available for the Docker image build
- **API keys** in `~/.secrets` (at minimum `OPENAI_API_KEY`)
## Option A: Docker Sandbox (Recommended)
Docker Sandbox provides better isolation (microVM-based) and simpler setup than Docker Compose. Requires Docker Desktop v29+ / Docker Sandbox v0.12+.
```bash
# 1. Clone the OpenClaw repo and build the image
git clone https://github.com/openclaw/openclaw.git /tmp/openclaw-docker
cd /tmp/openclaw-docker
docker build -t openclaw:local -f Dockerfile .
# 2. Create the sandbox using the built image
docker sandbox create --name openclaw -t openclaw:local shell ~/.openclaw/workspace
# 3. Allow network access to OpenAI API
docker sandbox network proxy openclaw \
--allow-host api.openai.com \
--allow-host localhost
# 4. Write the config inside the sandbox
docker sandbox exec openclaw sh -c '
mkdir -p /home/node/.openclaw/workspace /home/node/.openclaw/identity /home/node/.openclaw/credentials
cat > /home/node/.openclaw/openclaw.json << INNEREOF
{
"gateway": {
"mode": "local",
"port": 18789,
"bind": "loopback",
"auth": {
"mode": "token",
"token": "sandbox-dev-token-12345"
},
"controlUi": { "enabled": true }
},
"agents": {
"defaults": {
"model": {
"primary": "openai/gpt-5.2",
"fallbacks": ["openai/gpt-5.2-chat-latest"]
},
"workspace": "/home/node/.openclaw/workspace"
}
}
}
INNEREOF
chmod 600 /home/node/.openclaw/openclaw.json
'
# 5. Start the gateway (pass your API key from ~/.secrets)
source ~/.secrets
docker sandbox exec -d \
-e OPENAI_API_KEY="$OPENAI_API_KEY" \
-w /app openclaw \
node dist/index.js gateway --bind loopback --port 18789
# 6. Wait ~15 seconds, then verify
sleep 15
docker sandbox exec openclaw curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:18789/
# Should print: 200
# 7. Check status
docker sandbox exec -e OPENAI_API_KEY="$OPENAI_API_KEY" -w /app openclaw \
node dist/index.js status
```
### Sandbox Management
```bash
# List sandboxes
docker sandbox ls
# Shell into the sandbox
docker sandbox exec -it openclaw bash
# Stop the sandbox (preserves state)
docker sandbox stop openclaw
# Remove the sandbox
docker sandbox rm openclaw
# Check sandbox version
docker sandbox version
```
## Option B: Docker Compose (Fallback)
Use this if Docker Sandbox is not available (Docker Desktop < v29).
```bash
# 1. Clone the OpenClaw repo
git clone https://github.com/openclaw/openclaw.git /tmp/openclaw-docker
cd /tmp/openclaw-docker
# 2. Build the Docker image (~5-10 min on first run)
docker build -t openclaw:local -f Dockerfile .
# 3. Create config directories
mkdir -p ~/.openclaw/workspace ~/.openclaw/identity ~/.openclaw/credentials
chmod 700 ~/.openclaw ~/.openclaw/credentials
# 4. Generate a gateway token
export OPENCLAW_GATEWAY_TOKEN=$(openssl rand -hex 32)
echo "Your gateway token: $OPENCLAW_GATEWAY_TOKEN"
# 5. Create the config file
cat > ~/.openclaw/openclaw.json << EOF
{
"gateway": {
"mode": "local",
"port": 18789,
"bind": "lan",
"auth": {
"mode": "token",
"token": "$OPENCLAW_GATEWAY_TOKEN"
},
"controlUi": {
"enabled": true,
"allowedOrigins": ["http://127.0.0.1:18789"]
}
},
"env": {
"OPENAI_API_KEY": "\${OPENAI_API_KEY}"
},
"agents": {
"defaults": {
"model": {
"primary": "openai/gpt-5.2",
"fallbacks": ["openai/gpt-5.2-chat-latest"]
},
"workspace": "/home/node/.openclaw/workspace"
}
}
}
EOF
chmod 600 ~/.openclaw/openclaw.json
# 6. Create the .env file (load API keys from ~/.secrets)
source ~/.secrets
cat > .env << EOF
OPENCLAW_CONFIG_DIR=$HOME/.openclaw
OPENCLAW_WORKSPACE_DIR=$HOME/.openclaw/workspace
OPENCLAW_GATEWAY_PORT=18789
OPENCLAW_BRIDGE_PORT=18790
OPENCLAW_GATEWAY_BIND=lan
OPENCLAW_GATEWAY_TOKEN=$OPENCLAW_GATEWAY_TOKEN
OPENCLAW_IMAGE=openclaw:local
OPENAI_API_KEY=$OPENAI_API_KEY
OPENCLAW_EXTRA_MOUNTS=
OPENCLAW_HOME_VOLUME=
OPENCLAW_DOCKER_APT_PACKAGES=
EOF
# 7. Add tmpfs to docker-compose.yml (required — see Known Issues)
# Add to BOTH openclaw-gateway and openclaw-cli services:
# tmpfs:
# - /tmp:exec,size=512M
# 8. Start the gateway
docker compose up -d openclaw-gateway
# 9. Wait ~15 seconds for startup, then get the dashboard URL
sleep 15
docker compose run --rm openclaw-cli dashboard --no-open
```
The dashboard URL will look like: `http://127.0.0.1:18789/#token=<your-token>`
### Docker Compose Management
```bash
cd /tmp/openclaw-docker
# Stop
docker compose down
# Start again (no rebuild needed)
docker compose up -d openclaw-gateway
# View logs
docker compose logs -f openclaw-gateway
# Check status
docker compose run --rm openclaw-cli status
# Get dashboard URL
docker compose run --rm openclaw-cli dashboard --no-open
```
## Known Issues and Fixes
### "no space left on device" when starting containers
Docker Desktop's virtual disk may be full.
```bash
docker system df # check usage
docker system prune -f # remove stopped containers, unused networks
docker image prune -f # remove dangling images
```
### "Unable to create fallback OpenClaw temp dir: /tmp/openclaw-1000" (Compose only)
The container can't write to `/tmp`. Add a `tmpfs` mount to `docker-compose.yml` for **both** services:
```yaml
services:
openclaw-gateway:
tmpfs:
- /tmp:exec,size=512M
openclaw-cli:
tmpfs:
- /tmp:exec,size=512M
```
This issue does not affect the Docker Sandbox approach.
### Node version mismatch in community template images
Some community-built sandbox templates (e.g. `olegselajev241/openclaw-dmr:latest`) ship Node 20, but OpenClaw requires Node >=22.12.0. Use our locally built `openclaw:local` image as the sandbox template instead, which includes Node 22.
### Gateway takes ~15 seconds to respond after start
The Node.js gateway needs time to initialize. Wait 15 seconds before hitting `http://127.0.0.1:18789/`.
### CLAUDE_AI_SESSION_KEY warnings (Compose only)
These Docker Compose warnings are harmless and can be ignored:
```
level=warning msg="The \"CLAUDE_AI_SESSION_KEY\" variable is not set. Defaulting to a blank string."
```
## Configuration
Config file: `~/.openclaw/openclaw.json` (JSON5 format)
Key settings:
- `gateway.auth.token` — the auth token for the web UI and API
- `agents.defaults.model.primary` — the AI model (use `openai/gpt-5.2` or newer)
- `env.OPENAI_API_KEY` — references the `OPENAI_API_KEY` env var (Compose approach)
API keys are stored in `~/.secrets` and passed into containers via env vars.
## Reference
- [OpenClaw Docker docs](https://docs.openclaw.ai/install/docker)
- [OpenClaw Configuration Reference](https://docs.openclaw.ai/gateway/configuration-reference)
- [Docker blog: Run OpenClaw Securely in Docker Sandboxes](https://www.docker.com/blog/run-openclaw-securely-in-docker-sandboxes/)
- [Docker Sandbox docs](https://docs.docker.com/ai/sandboxes)
- [OpenAI Models](https://platform.openai.com/docs/models) — current models: gpt-5.2, gpt-5.2-chat-latest, gpt-5.2-pro

100
docs/start/architecture.md Normal file
View File

@@ -0,0 +1,100 @@
---
title: Architecture
summary: Stack overview, request flow, and adapter model
---
# Architecture
Paperclip is a monorepo with four main layers.
## Stack Overview
```
┌─────────────────────────────────────┐
│ React UI (Vite) │
│ Dashboard, org management, tasks │
├─────────────────────────────────────┤
│ Express.js REST API (Node.js) │
│ Routes, services, auth, adapters │
├─────────────────────────────────────┤
│ PostgreSQL (Drizzle ORM) │
│ Schema, migrations, embedded mode │
├─────────────────────────────────────┤
│ Adapters │
│ Claude Local, Codex Local, │
│ Process, HTTP │
└─────────────────────────────────────┘
```
## Technology Stack
| Layer | Technology |
|-------|-----------|
| Frontend | React 19, Vite 6, React Router 7, Radix UI, Tailwind CSS 4, TanStack Query |
| Backend | Node.js 20+, Express.js 5, TypeScript |
| Database | PostgreSQL 17 (or embedded PGlite), Drizzle ORM |
| Auth | Better Auth (sessions + API keys) |
| Adapters | Claude Code CLI, Codex CLI, shell process, HTTP webhook |
| Package manager | pnpm 9 with workspaces |
## Repository Structure
```
paperclip/
├── ui/ # React frontend
│ ├── src/pages/ # Route pages
│ ├── src/components/ # React components
│ ├── src/api/ # API client
│ └── src/context/ # React context providers
├── server/ # Express.js API
│ ├── src/routes/ # REST endpoints
│ ├── src/services/ # Business logic
│ ├── src/adapters/ # Agent execution adapters
│ └── src/middleware/ # Auth, logging
├── packages/
│ ├── db/ # Drizzle schema + migrations
│ ├── shared/ # API types, constants, validators
│ ├── adapter-utils/ # Adapter interfaces and helpers
│ └── adapters/
│ ├── claude-local/ # Claude Code adapter
│ └── codex-local/ # OpenAI Codex adapter
├── skills/ # Agent skills
│ └── paperclip/ # Core Paperclip skill (heartbeat protocol)
├── cli/ # CLI client
│ └── src/ # Setup and control-plane commands
└── doc/ # Internal documentation
```
## 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 module** — `execute()` 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 `paperclip 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

View File

@@ -0,0 +1,77 @@
---
title: Core Concepts
summary: Companies, agents, issues, heartbeats, and governance
---
# Core Concepts
Paperclip organizes autonomous AI work around five key concepts.
## Company
A company is the top-level unit of organization. Each company has:
- A **goal** — the reason it exists (e.g. "Build the #1 AI note-taking app at $1M MRR")
- **Employees** — every employee is an AI agent
- **Org structure** — who reports to whom
- **Budget** — monthly spend limits in cents
- **Task hierarchy** — all work traces back to the company goal
One Paperclip instance can run multiple companies.
## Agents
Every employee is an AI agent. Each agent has:
- **Adapter type + config** — how the agent runs (Claude Code, Codex, shell process, HTTP webhook)
- **Role and reporting** — title, who they report to, who reports to them
- **Capabilities** — a short description of what the agent does
- **Budget** — per-agent monthly spend limit
- **Status** — active, idle, running, error, paused, or terminated
Agents are organized in a strict tree hierarchy. Every agent reports to exactly one manager (except the CEO). This chain of command is used for escalation and delegation.
## Issues (Tasks)
Issues are the unit of work. Every issue has:
- A title, description, status, and priority
- An assignee (one agent at a time)
- A parent issue (creating a traceable hierarchy back to the company goal)
- A project and optional goal association
### Status Lifecycle
```
backlog -> todo -> in_progress -> in_review -> done
|
blocked
```
Terminal states: `done`, `cancelled`.
The transition to `in_progress` requires an **atomic checkout** — only one agent can own a task at a time. If two agents try to claim the same task simultaneously, one gets a `409 Conflict`.
## Heartbeats
Agents don't run continuously. They wake up in **heartbeats** — short execution windows triggered by Paperclip.
A heartbeat can be triggered by:
- **Schedule** — periodic timer (e.g. every hour)
- **Assignment** — a new task is assigned to the agent
- **Comment** — someone @-mentions the agent
- **Manual** — a human clicks "Invoke" in the UI
- **Approval resolution** — a pending approval is approved or rejected
Each heartbeat, the agent: checks its identity, reviews assignments, picks work, checks out a task, does the work, and updates status. This is the **heartbeat protocol**.
## Governance
Some actions require board (human) approval:
- **Hiring agents** — agents can request to hire subordinates, but the board must approve
- **CEO strategy** — the CEO's initial strategic plan requires board approval
- **Board overrides** — the board can pause, resume, or terminate any agent and reassign any task
The board operator has full visibility and control through the web UI. Every mutation is logged in an **activity audit trail**.

61
docs/start/quickstart.md Normal file
View File

@@ -0,0 +1,61 @@
---
title: Quickstart
summary: Get Paperclip running in minutes
---
# Quickstart
Get Paperclip running locally in under 5 minutes.
## Option 1: Docker Compose (Recommended)
The fastest way to start. No Node.js install needed.
```sh
docker compose -f docker-compose.quickstart.yml up --build
```
Open [http://localhost:3100](http://localhost:3100). That's it.
The Docker image includes Claude Code CLI and Codex CLI pre-installed for local adapter runs. Pass API keys to enable them:
```sh
ANTHROPIC_API_KEY=sk-... OPENAI_API_KEY=sk-... \
docker compose -f docker-compose.quickstart.yml up --build
```
## Option 2: Local Development
Prerequisites: Node.js 20+ and pnpm 9+.
```sh
pnpm install
pnpm dev
```
This starts the API server and UI at [http://localhost:3100](http://localhost:3100).
No Docker or external database required — Paperclip uses an embedded PostgreSQL instance by default.
## Option 3: One-Command Bootstrap
```sh
pnpm paperclip run
```
This auto-onboards if config is missing, runs health checks with auto-repair, and starts the server.
## What's Next
Once Paperclip is running:
1. Create your first company in the web UI
2. Define a company goal
3. Create a CEO agent and configure its adapter
4. Build out the org chart with more agents
5. Set budgets and assign initial tasks
6. Hit go — agents start their heartbeats and the company runs
<Card title="Core Concepts" href="/start/core-concepts">
Learn the key concepts behind Paperclip
</Card>

View File

@@ -0,0 +1,41 @@
---
title: What is Paperclip?
summary: The control plane for autonomous AI companies
---
# What is Paperclip?
Paperclip is the control plane for autonomous AI companies. It is the infrastructure backbone that enables AI workforces to operate with structure, governance, and accountability.
One instance of Paperclip can run multiple companies. Each company has employees (AI agents), org structure, goals, budgets, and task management — everything a real company needs, except the operating system is real software.
## The Problem
Task management software doesn't go far enough. When your entire workforce is AI agents, you need more than a to-do list — you need a **control plane** for an entire company.
## What Paperclip Does
Paperclip is the command, communication, and control plane for a company of AI agents. It is the single place where you:
- **Manage agents as employees** — hire, organize, and track who does what
- **Define org structure** — org charts that agents themselves operate within
- **Track work in real time** — see at any moment what every agent is working on
- **Control costs** — token salary budgets per agent, spend tracking, burn rate
- **Align to goals** — agents see how their work serves the bigger mission
- **Govern autonomy** — board approval gates, activity audit trails, budget enforcement
## Two Layers
### 1. Control Plane (Paperclip)
The central nervous system. Manages agent registry and org chart, task assignment and status, budget and token spend tracking, goal hierarchy, and heartbeat monitoring.
### 2. Execution Services (Adapters)
Agents run externally and report into the control plane. Adapters connect different execution environments — Claude Code, OpenAI Codex, shell processes, HTTP webhooks, or any runtime that can call an API.
The control plane doesn't run agents. It orchestrates them. Agents run wherever they run and phone home.
## Core Principle
You should be able to look at Paperclip and understand your entire company at a glance — who's doing what, how much it costs, and whether it's working.