Autonomous agent framework options v4: Paperclip evaluation
Date: 2026-06-07
Question: should we implement Paperclip now instead of building our own orchestration layer for long-running PM/Dev work?
Recommendation: run a bounded Paperclip pilot now, but do not migrate the whole workflow yet. Paperclip directly targets our missing layer: durable agent teams, tickets, heartbeats, budgets, governance, and audit trails. The right next step is a self-hosted local pilot with one PM agent and one Dev agent, using OpenClaw as Telegram front door and Codex as the coding executor. If Paperclip can run one PM → Dev → PR cycle with auditable state, it should replace most of the custom orchestration work proposed in v3.
Executive assessment
| Dimension | Assessment | Implication |
|---|---|---|
| Cost | Core project appears MIT-licensed and self-hostable. Hosted Paperclip.inc is paid and usage/budget metered. | Start self-hosted locally. Do not assume hosted SaaS is free. |
| Security | Adds a new control plane that can coordinate agents, secrets, GitHub work, budgets, approvals, and audit logs. | Potentially improves governance, but materially expands the attack surface. |
| Compatibility | Paperclip explicitly advertises support for OpenClaw, Codex, Claude, Cursor, Gemini, shell/HTTP agents, scheduled heartbeats, tickets, and adapters. | Good fit conceptually. Needs hands-on adapter validation in our environment. |
| Readiness | Looks more ready than building from scratch, but still early. Roadmap still lists several important items as not done. | Pilot before committing. Validate failure handling, GitHub behavior, and local security. |
Cost and business model
Is Paperclip really open source?
The public Paperclip site says it is open source, self-hosted, MIT-licensed, and does not require a Paperclip account for local use. The GitHub repository also presents Paperclip as MIT licensed and self-hosted.
Important nuance: the open-source project can be free to run, but that does not make hosted Paperclip free. The hosted Paperclip.inc pricing page shows paid tiers and metered/budgeted work.
| Cost item | What research found | Risk for us |
|---|---|---|
| Self-hosted software | MIT license; local quickstart via npx paperclipai onboard --yes; embedded Postgres option. | Low direct subscription cost; operational maintenance moves to us. |
| Hosted SaaS | Paperclip.inc pricing advertises paid company plans, teammates, included budgets, managed EU inference, and enterprise options. | Not free; likely useful later only if we want managed hosting and support. |
| Model/runtime usage | Paperclip is bring-your-own-agent/model; hosted page says model keys can be brought or managed inference used. | We still pay OpenAI/Codex/other model usage. Paperclip does not eliminate model cost. |
| Codex Pro subscription | OpenAI says Codex is included across ChatGPT plans with plan-dependent limits; Codex CLI can sign in with ChatGPT. | Good compatibility with our existing spend, but limits/credits still need measured validation. |
Who created it and how do they make money?
Official pages name Paperclip Labs, Inc. on paperclip.ing and Paperclip.inc OÜ on the hosted pricing page. The official sources I found do not clearly identify the founder in the product pages. A third-party review attributes Paperclip AI to Ayush Pathak, but I would treat that as unverified until confirmed from an official profile, GitHub maintainer identity, company registry, or direct Paperclip docs.
The monetization path is clear enough: self-hosted open source plus hosted SaaS and enterprise offerings. Hosted pricing mentions subscriptions, teammate charges, managed inference, longer audit logs, SSO/SCIM, dedicated database, SOC 2 report, DPA, support, and SLA.
Security evaluation
Main security concern: Paperclip would become a control plane above agents that already have file, shell, GitHub, and messaging access. That can improve oversight, but if misconfigured it becomes a high-value system for prompt injection, secret exposure, runaway execution, or unwanted GitHub writes.
| Risk | Why it matters | Mitigation for pilot |
|---|---|---|
| Secret concentration | Paperclip supports provider keys, agent API keys, JWTs, secrets/storage, and adapters. | Use local-only instance; no broad secrets; separate low-scope GitHub token; no production/private credentials. |
| Agent privilege escalation | Agents can be assigned work, woken by tickets, and integrated with shell/HTTP/OpenClaw/Codex. | Start with read-only PM and one write-scoped Dev repo. Require approval before PR push/merge. |
| Prompt injection via tickets/GitHub | Issues, comments, and external docs can become agent instructions. | Keep our existing untrusted-content rules. Add Paperclip company skill warning agents not to obey issue text as system policy. |
| Runaway spend | Multi-agent heartbeats can multiply model usage. | Hard monthly budgets, soft warning thresholds, and auto-pause. Start with one PM heartbeat and manual Dev trigger. |
| Telemetry | Paperclip GitHub README says anonymous telemetry is enabled by default but can be disabled. | Disable telemetry for pilot with documented config/env var before any private project context enters the system. |
| Network exposure | Docs mention local, LAN/tailnet, and cloud deployment modes. | Start loopback only. If remote access is needed, use Tailscale with auth, not public internet. |
| Supply-chain trust | Quickstart uses npx and Node packages. | Clone repo, inspect package scripts/dependencies, pin version/commit, run in a dedicated local directory. |
Compatibility with our stack
| Current stack | Paperclip fit | Pilot approach |
|---|---|---|
| OpenClaw / obot | Paperclip explicitly names OpenClaw as a supported bring-your-own agent and references OpenClaw onboarding/adapters. | Keep obot as Telegram-facing orchestrator. Paperclip should manage agent tickets/runs, not replace the chat interface. |
| Telegram chats | Paperclip marketing/docs emphasize tickets, Slack/Discord-style notifications, HTTP agents; Telegram is not the obvious first-class interface. | Do not route Telegram directly into Paperclip at first. Let obot create/read Paperclip tasks and summarize results. |
| GitHub issues/PRs | Paperclip has its own ticket model; docs mention GitHub integration/adapters, and the site says bring-your-own ticket system is on the roadmap. | Keep GitHub as public source of truth. Paperclip tasks should link to GitHub Project/Requirement/Task issues, not replace them. |
| Codex Pro / Codex CLI | Paperclip advertises Codex as a supported agent/runtime. OpenAI positions Codex as a coding agent with CLI, app, cloud/GitHub, skills, worktrees, and automations. | Use Codex Local first because it already works here. Later test Codex cloud/GitHub task delegation if access is stable. |
| Current local skills/AGENTS.md | Paperclip references SKILL.md and company/agent skills. | Map our PM, Dev, Telegram, GitHub, and report-design skills into Paperclip company/agent skills. |
Paperclip implementation plan
Phase 0 — Verify and contain
Same day
- Clone Paperclip from GitHub into a dedicated local workspace.
- Pin exact commit/version and record license, dependencies, package scripts, telemetry setting, and exposed ports.
- Run local loopback only; disable telemetry; no cloud account; no production secrets.
- Create a short security note before adding any private context.
Phase 1 — Minimal company model
Pilot
- Create one company: Open Source OrangeBot.
- Create Board role: Jeremy, approval authority.
- Create PM agent role: portfolio audit, issue hygiene, queue selection, Human ToDo gate.
- Create Dev agent role: Codex Local executor, PR-native implementation, checks, evidence.
- Create one project mapped to obot-claw.github.io issue #24 or successor issue for autonomous workflow.
Phase 2 — Adapter test
Acceptance gate
- Connect a PM heartbeat that only reads GitHub/local state and produces an audit ticket.
- Verify Paperclip logs task ownership, heartbeat state, comments, and run artifacts.
- Connect Dev only after PM audit works.
- Run Dev against a safe documentation-only issue first.
Phase 3 — PM → Dev chain
Decision point
- PM selects one GitHub-linked task and assigns Dev.
- Dev opens or updates one PR.
- Paperclip shows durable state: who owned the work, what ran, cost/budget, approvals, and result.
- obot sends Telegram only after Paperclip/GitHub artifact exists.
Competitor readiness
| Option | Best fit | Readiness for our PM/Dev problem | Assessment |
|---|---|---|---|
| Paperclip | Agent-team control plane: org chart, tickets, budgets, heartbeats, audit, approvals. | High conceptual fit; early product risk; needs local pilot. | Best candidate for orchestration layer if self-hosted security checks pass. |
| OpenAI Codex | Software engineering execution: worktrees, PRs, CLI, cloud/GitHub tasks, skills, automations. | High for Dev execution; medium for PM portfolio governance. | Use as executor inside Paperclip or directly for GitHub-native coding work. |
| GitHub Copilot coding agent / Agent HQ | GitHub-native issue-to-PR delegation. | High for repo-native dev tasks; lower for cross-repo PM/governance. | Worth evaluating, but not a full replacement for PM orchestration. |
| OpenHands | Open-source autonomous coding agent with sandbox, CLI/web/cloud options. | Medium-high as Dev executor; low as PM/company control plane. | Strong fallback/competitor for Codex execution, not Paperclip governance. |
| Claude Code | High-quality local coding agent. | High for local Dev; low for orchestration unless wrapped. | Good executor; still needs Paperclip/OpenClaw/runner above it. |
| Devin | Managed autonomous software engineer. | Medium-high for Dev; low control over our local/OpenClaw/Telegram stack. | Potential paid benchmark, not the first pilot. |
| LangGraph / AutoGen / CrewAI | Build custom multi-agent applications. | Low for immediate adoption because we would still build orchestration ourselves. | Do not use for this problem unless Paperclip fails and we need a custom framework. |
| Temporal / Prefect / n8n | Durable workflow scheduling. | Medium for reliability, low for agent governance out of the box. | Useful as infrastructure, not a complete agent-management solution. |
Recommendation
Adopt a Paperclip-first pilot. The v3 custom runner plan is still the fallback, but Paperclip appears to solve more of the real problem: durable tickets, heartbeats, org structure, budgets, approvals, and audit. The pilot should be deliberately constrained: local-only, telemetry off, one PM, one Dev, one safe repo, one documentation PR. If that works, expand. If not, return to the supervised Codex runner plan with better evidence.
Go / no-go checklist
| Gate | Go condition | No-go condition |
|---|---|---|
| Install safety | Can pin source, disable telemetry, run loopback only. | Requires hosted account or broad secrets before evaluation. |
| Adapter fit | Can wake OpenClaw/Codex or local shell process and record run state. | Cannot start/observe our agent runtimes reliably. |
| GitHub fit | Can link Paperclip task to GitHub issue/PR without replacing GitHub source of truth. | Forces migration away from GitHub issues or creates duplicate unclear task state. |
| Security | Approvals, budget caps, audit logs, and scoped credentials work locally. | Agents need broad machine/GitHub access to function. |
| Value | PM → Dev cycle completes with less custom code than v3 runner. | We still have to build most supervision/adapter logic ourselves. |
Sources
- Paperclip GitHub README: https://github.com/paperclipai/paperclip
- Paperclip product site: https://paperclip.ing/
- Paperclip docs index: https://docs.paperclip.ing/
- Paperclip hosted pricing: https://paperclip.inc/pricing
- OpenAI Codex product page: https://openai.com/codex/
- OpenAI Codex plan/help page: https://help.openai.com/en/articles/11369540-getting-started-with-codex
- OpenHands GitHub: https://github.com/OpenHands/OpenHands
- GitHub Copilot coding agent troubleshooting: https://docs.github.com/en/copilot/using-github-copilot/coding-agent/troubleshooting-copilot-coding-agent