From Chaos to Command: How My AI Agent Team Migrated to Paperclip

Running eight AI agents on a single Oracle Cloud ARM64 server sounds like a recipe for chaos. For a while, it was. But today, they're all orchestrated through Paperclip — an open-source agent management platform — running as a Docker Swarm service on the same 4-vCPU, 24GB RAM box that powers everything else at Afrotomation.

This is the story of how we got here.

The Before: Agents Everywhere, Control Nowhere

When I first set up my AI agent team on Ada (my Oracle Cloud VPS named after Ada Lovelace), each agent was essentially a standalone process managed through OpenClaw's gateway. The setup worked, but it was held together with PM2 scripts, cron jobs, and a healthy dose of optimism.

Here's what the team looked like:

Eight agents. Five different AI models. One server. And for months, the coordination between them was entirely manual — I'd message Ada, who'd spawn a sub-agent, which would run Claude Code in a PTY session, and I'd hope the output made it back to me before the process timed out.

Why Paperclip?

I'd been watching the agent orchestration space for a while. Most solutions were either too enterprise (read: expensive and opaque) or too experimental (read: broke every Tuesday). Paperclip hit the sweet spot:

• Open source — I can read the code, fix bugs, contribute back
• Self-hostable — critical for someone running everything on a single VPS
• Docker-native — fits perfectly into my existing Swarm setup
• Multi-agent aware — built for exactly this use case
• Claude Code integration — agents can authenticate and push code directly

The tipping point was when I realized Paperclip could manage agent sessions, track work history, handle approvals, and provide a proper UI for monitoring — all things I'd been cobbling together with markdown files and cron jobs.

The Migration

Infrastructure

The migration wasn't a clean cutover — it was additive. I kept the native OpenClaw gateway running on port 18789 (still live at ada.afrotomation.com) and deployed Paperclip as a Docker Swarm stack alongside it.

The Swarm stack ended up looking like this:

paperclip_server  → port 3100 → paperclip.afrotomation.com
paperclip_db      → PostgreSQL 17 (internal)
openclaw_gateway  → port 18790 → swarm.afrotomation.com
portainer         → port 9443 → portainer.afrotomation.com

Everything runs behind Cloudflare Tunnels — no ports exposed to the internet, no firewall rules to manage. The tunnel connector itself runs as a Docker container, which means the entire stack is reproducible from a single docker stack deploy command.

The "Never Get Locked Out" Pattern

One thing I learned the hard way: if your only access to the server is through a service running on that server, you're one bad deploy away from a very bad day.

So I set up redundant access paths:

• ada.afrotomation.com → native OpenClaw gateway (PM2-managed)
• swarm.afrotomation.com → Dockerized OpenClaw gateway (Swarm-managed)
• SSH → direct access (Oracle Cloud, fail2ban protected)
• Portainer → Docker management UI at portainer.afrotomation.com

If the Docker stack implodes, the native gateway keeps running. If PM2 crashes, the Docker gateway takes over. If both die, SSH is still there. Belt, suspenders, and a backup belt.

Claude Code Inside Docker

The most satisfying part of the migration was getting Claude Code authenticated inside the Paperclip container. The agents can now:

1. Receive a task through Paperclip's inbox
2. Spawn a Claude Code session
3. Write code, run tests, commit changes
4. Push directly to GitHub

All from inside a Docker container, with credentials mounted read-only from the host. The ~/.claude directory is bind-mounted into the container, so OAuth tokens persist across container restarts without being baked into the image.

volumes:
  - /home/ubuntu/.claude:/home/node/.claude:ro
  - /home/ubuntu/.openclaw/workspace:/home/node/workspace

What Changed

Before Paperclip

• Agent coordination via markdown files (projects/wip.md)
• Sub-agent spawning through OpenClaw's sessions_spawn
• Manual tracking of what each agent was doing
• No approval workflow — agents just did things
• History scattered across log files

After Paperclip

• Centralized inbox for all agent tasks
• Approval workflows with pending count badges
• Persistent session history per agent
• Proper work assignment and tracking
• A real UI instead of docker logs | tail -50

The approval sidebar we just shipped today is a small thing, but it represents the shift: agents now ask permission through a proper interface instead of just announcing what they did in a chat message.

The Numbers

Here's what's running on this single Oracle Cloud ARM64 instance right now:

• 67 uptime monitors (Uptime Kuma)
• 61 websites tracked in analytics (Umami)
• 8 AI agents orchestrated through Paperclip
• 2 trading bots running a 60-day strategy bakeoff
• 6 Cloudflare tunnel endpoints (ada, dashboard, status, swarm, paperclip, postiz)
• Disk usage: 49%
• Monthly cost: $0 (Oracle Cloud free tier ARM)

Zero dollars. The entire AI agent infrastructure runs on a free-tier cloud instance. The only cost is the API usage for the AI models themselves.

Lessons Learned

1. Docker Swarm is underrated. Everyone reaches for Kubernetes, but for a single-node setup, Swarm is simpler, lighter, and does everything I need. Service updates, rolling deploys, health checks — it just works.

2. Always have two paths in. The redundant gateway pattern saved me during this migration when a config change killed the Docker instance. The native gateway kept running while I fixed it.

3. Self-hosting is a superpower. Running Paperclip, OpenClaw, analytics, social posting, and monitoring on my own server means I control the data, the uptime, and the cost. No vendor lock-in, no surprise bills.

4. AI agents need structure, not freedom. The biggest improvement wasn't giving agents more capabilities — it was giving them a proper workflow. Inboxes, approvals, and session history made them dramatically more useful.

5. Start with the config, not the code. Half the migration bugs were path mismatches (/home/ubuntu vs /home/node inside Docker). Getting the configuration right is 80% of the work.

What's Next

The Paperclip migration was Phase 1. Here's what's coming:

• Ticket-to-fix pipeline — GitHub issues automatically assigned to agents, PRs opened without human intervention
• CodeniServer SSO — single sign-on across all Afrotomation apps, with Paperclip as the orchestration layer
• CodeniWork — an AI-powered job hunting platform, built entirely by the agent team
• Multi-node Swarm — adding a second Oracle Cloud instance for redundancy

The dream has always been autonomous development: push a bug ticket, go to work, come home to a merged PR. We're not there yet, but with Paperclip managing the agents and OpenClaw handling the communication layer, we're closer than ever.