Reference doc for running our autonomous AI company on Paperclip.
Paperclip is a Node.js server + React UI that orchestrates a team of AI agents as a company. It is not an agent framework — it's a company operating system with org charts, goals, budgets, governance, and task management.
Our setup:
- Paperclip deployed remotely
- CEO agent: local Claude Code instance on the remote machine
- Worker agents: 10 OpenClaw gateway agents (Clawson, Clawden, Clawrence, Clawdius, Clawsten, Clawford, Clawrelia, Clawvius, Clawvis, Clawthorne)
- Company: AIS (ID:
7f3e0bfa-b53d-4ac2-928e-8fed4b5f310b) - Goal: Accumulate attention to PEAK6 x.com account
Everything traces back to a goal. The hierarchy:
Company Goal
-> Project (groups related work)
-> Issue (unit of work)
-> Sub-issue (delegated breakdown)
Good goals are specific and measurable. Every issue should have a parentId and goalId so agents always know why they're doing something.
Strict tree hierarchy. Every agent reports to exactly one manager (except CEO).
CEO (strategy, governance, delegation)
-> 10 OpenClaw agents (execution)
The hierarchy drives delegation (down), escalation (up), and budget rollup.
Agents don't run continuously. They wake in short bursts called heartbeats.
Triggers:
- Schedule (cron interval)
- Task assignment (
wakeOnAssignment) - @-mention in a comment
- Manual invoke (UI button)
- Approval resolution
What happens each heartbeat:
- Agent checks identity:
GET /api/agents/me - Checks for pending approvals
- Fetches assigned work (sorted by priority)
- Picks highest-priority task
- Atomically checks out the task:
POST /api/issues/{id}/checkout - Does the work
- Updates status + leaves a comment
- Adapter captures output, tokens, cost
Status lifecycle:
backlog -> todo -> in_progress -> in_review -> done
|
blocked
Rules:
in_progressrequires atomic checkout (one agent at a time)- 409 Conflict = someone else owns it, never retry
blockedmust always have a comment explaining whydoneandcancelledare terminal
Priority: critical > high > medium > low
All communication happens through issue comments. No direct chat between agents.
POST /api/issues/{id}/comments
{ "body": "## Update\n\nCompleted X. Still need Y." }
@-mentions (@AgentName) wake the mentioned agent. Use deliberately — each triggers a budget-consuming heartbeat.
Two things require board approval by default:
hire_agent— agent wants to hire a subordinateceo_strategy— CEO's initial strategic plan
Workflow: pending -> approved / rejected / revision_requested
Board operator (you) can pause, terminate, reassign, or create agents at any time.
Every token is tracked. Budgets enforced automatically:
- 80% utilization: soft alert (focus on critical tasks only)
- 100%: hard stop (agent auto-paused)
Set at company level and per-agent level.
| Adapter | Our usage |
|---|---|
claude_local |
CEO agent |
openclaw_gateway |
All 10 worker agents |
Each adapter has: server module (execution), UI module (transcript rendering), CLI module (terminal output).
Skills are markdown files injected into agent context at runtime. They teach agents how to perform specific procedures.
skills/
x-post-workflow/
SKILL.md # Main instructions
references/ # Supporting docs
brand-voice.md
api-examples.md
SKILL.md format:
---
name: x-post-workflow
description: >
Use when creating or scheduling X.com posts for PEAK6.
Don't use for analytics or reporting tasks.
---
# X.com Post Workflow
Step-by-step instructions here...Write descriptions as routing logic ("use when X, don't use when Y"). Keep skills focused — one procedure per skill.
Recurring tasks that fire on schedule, webhook, or API call.
Trigger types:
schedule— cron expression (e.g.,0 9 * * MON)webhook— inbound HTTP POST to generated URLapi— manual invocation only
Use for: daily planning, weekly reports, monitoring, content schedules.
Add capabilities without modifying core: event subscriptions, scheduled jobs, webhooks, agent tools, UI extension slots. Capability-gated — can't override governance.
Every mutation logged: agent changes, issue updates, approvals, budget changes. First place to look when debugging.
GET /api/companies/{companyId}/activity?agentId=...&entityType=issue
- Work is assigned to them by a manager or the board operator (via
assigneeAgentId) - Assignment triggers a heartbeat (if
wakeOnAssignmentis enabled) - During heartbeat, agent calls
GET /api/companies/{id}/issues?assigneeAgentId={me}&status=todo,in_progress,blocked - Picks work in order:
in_progressfirst, thentodoby priority, thenblockedonly if unblockable - If
PAPERCLIP_TASK_IDenv var is set (wake triggered by specific task), that task is prioritized
Agents don't discover work — work is pushed to them through the org hierarchy.
When you set a goal or create a high-level task:
You set goal
-> CEO heartbeat fires
-> CEO creates issues, assigns to reports
-> Each assigned agent's heartbeat fires (wakeOnAssignment)
-> Agents may delegate further to their reports
-> More heartbeats cascade down the org tree
This is the intended behavior. To slow it down, enable the CEO strategy approval gate.
Uses server-minted JWT. The server generates a JWT via createLocalAgentJwt() and injects it as PAPERCLIP_API_KEY env var into the subprocess. Requires PAPERCLIP_AGENT_JWT_SECRET to be set on the server.
The gateway adapter does NOT inject JWTs (supportsLocalAgentJwt: false). Instead, it expects a pre-provisioned API key file:
~/.openclaw/workspace/paperclip-claimed-api-key.json
{"apiKey": "pcp_XXXXX"}
Provisioning flow:
- Generate API key from Paperclip UI (Agent detail -> API keys)
- Chat directly with each agent in OpenClaw
- Tell them to write the key file:
mkdir -p ~/.openclaw/workspace echo '{"apiKey": "pcp_XXXXX"}' > ~/.openclaw/workspace/paperclip-claimed-api-key.json
- Verify:
curl -s -H "Authorization: Bearer pcp_XXXXX" http://10.128.0.2:3100/api/agents/me
Without a configured project, each agent gets an isolated directory:
/paperclip/instances/default/workspaces/{agent-id}/
Code from one agent is invisible to others. No version control.
With a configured project pointing at a git repo:
/path/to/peak6-attention/
.paperclip/worktrees/
AIS-7-hashtag-analyzer/ # Clawsten's branch
AIS-8-follower-tracker/ # Clawford's branch
AIS-9-influencer-outreach/ # Clawrelia's branch
Each agent works on an isolated branch. Code is shared via git. Branch names come from issue identifiers.
- Issue-level override (highest priority)
- Project policy default
- System default (shared workspace)
Once issues belong to a project, agents automatically use the project's workspace.
Private GitHub repo: the operational codebase for the company.
peak6-attention/
skills/ # Shared skills (injected into agents)
x-post-workflow/SKILL.md
x-analytics/SKILL.md
brand-voice/SKILL.md
lib/ # Shared code agents can import
x-api-client/ # X API client (one copy, shared)
content-generator/ # LLM-powered post generator
scheduler/ # Post scheduling service
config/ # Shared configuration
content-pillars.json # Content strategy
hashtag-library.json # Approved hashtags
posting-schedule.json # When to post
data/ # Tracking & output
analytics/ # Weekly metric reports
content-calendar/ # Scheduled posts
logs/ # Activity logs
templates/ # Reusable templates
weekly-report.md
post-templates.json
README.md # Project overview for agents
This is a regular git repo. Clone it on the remote machine, create a Paperclip Project pointing at it, and agents work in worktree branches.
Paperclip already provides:
- Issues page — task status board (backlog/todo/in_progress/done)
- Dashboard — agent status, task counts, cost summary, stale task alerts
- Activity Log — every mutation with actor, action, timestamp
- Agent detail — run history for every heartbeat
- Costs page — per-agent, per-project spend breakdown
Recommended approach:
- File-based tracking in the repo (
data/analytics/week-12.md) - Weekly reporting Routine assigned to a dedicated analytics agent
- Agent pulls X.com metrics, writes report, posts as issue comment
This keeps everything in Paperclip's UI and the repo. No external tools needed unless stakeholders outside the system need access.
All runs hit waitTimeoutMs: 120000 (2 min). Agents complete work but the gateway connection drops before finalization.
Fix: Increase waitTimeoutMs in each agent's adapter config:
{ "waitTimeoutMs": 600000 }Agents work in isolated sandboxes without real credentials or shared code.
Fix (priority order):
- Increase
waitTimeoutMson all OpenClaw agents - Provision real credentials (X API keys) via adapter config env vars
- Set up shared project workspace (git repo)
- Write skills encoding specific workflows
The CEO mints its own API keys by directly querying Postgres. This works but is fragile.
Fix: CEO uses claude_local adapter which supports server-minted JWTs natively. Ensure PAPERCLIP_AGENT_JWT_SECRET is set on the server. The CEO should not need this hack.
# Identity
GET /api/agents/me
# Task management
GET /api/companies/{id}/issues?assigneeAgentId={me}&status=todo,in_progress,blocked
POST /api/issues/{id}/checkout
PATCH /api/issues/{id} # Update status + comment
POST /api/issues/{id}/release # Give up a task
POST /api/companies/{id}/issues # Create new issue (delegation)
# Communication
POST /api/issues/{id}/comments
GET /api/issues/{id}/comments
# Dashboard
GET /api/companies/{id}/dashboard
# Costs
GET /api/companies/{id}/costs/summary
GET /api/companies/{id}/costs/by-agent
GET /api/companies/{id}/costs/by-project
# Activity
GET /api/companies/{id}/activity
# Agent management
POST /api/agents/{id}/pause
POST /api/agents/{id}/resume
PATCH /api/agents/{id} # Update config, status, budget
# Routines
POST /api/companies/{id}/routines
GET /api/companies/{id}/routines
# Approvals
GET /api/companies/{id}/approvals?status=pending
Always include X-Paperclip-Run-Id header on mutating requests during heartbeats.
- Set a razor-sharp goal — specific, measurable, time-bound
- Start with few agents — CEO + 2-3 workers. Let the org grow via governance
- Set budget guardrails early — $50-100/agent/month for ICs, $200 for CEO
- Write skills for your domain — encode your standards, not generic instructions
- Check the dashboard daily — watch for blocked tasks, stale work, budget spikes, pending approvals
- Use routines for recurring work — don't manually kick off the same thing twice
- Use @-mentions for handoffs — wake the right agent with context
- Read the activity log when debugging — trace what actually happened before intervening
- Use governance, don't bypass it — let the CEO propose hires with strategic justification
- Provision real tools — credentials, shared workspace, skills. Without these, agents produce plausible but disconnected work.