Autonomous AI and Agent Orchestration - Buzz + Paperclip

Timestamps

• 00:00 - Intro
• 01:30 - VPS Setup
• 03:29 - App Overviews
• 08:01 - Cost Management
• 09:33 - What are heartbeats in Paperclip?
• 10:18 - Assigning a task in Paperclip
• 10:43 - Setting up our Paperclip structure
• 12:11 - Building out a Workflow
• 12:38 - What was created in GitHub?
• 13:41 - SSH Port Forwarding
• 14:23 - Typeform
• 19:00 - Creating agents with Buzz
• 23:44 - An overview of everything Buzz can do
• 24:26 - Running local models through Buzz
• 26:25 - Building with Buzz
• 29:40 - Buzz vs Paperclip

Buzz and Paperclip both help manage AI agents, but they go about it in pretty different ways.

Buzz is a shared workspace. You talk to agents in channels and DMs, kinda like Slack. Paperclip is organized around a company, an org chart, tasks, budgets, and scheduled runs called heartbeats.

The initial difference is who starts and assigns the work. In Buzz, you normally mention an agent and tell it what to do. Other people on your team can join the workspace and use the agents you allow them to access. In Paperclip, work usually moves down from the company goal through the CEO and other managers, then agents wake up on heartbeats to check what is assigned to them.

VPS setup

Both projects can run locally. I put them on a VPS so they can stay available and respond to events even when my computer is off.

Hostinger has one-click installs for both:

• Deploy Buzz on Hostinger
• Deploy Paperclip on Hostinger

Use code calebcurry for an extra 10% off. I used the KVM 2 plan and installed both apps on the same VPS.

Buzz also needs its desktop app. Choose Join a community, copy the public npub1... key, then use the relay URL from Hostinger's Docker Manager to connect.

💡 Tip[!tip]
Your npub1... value is public. An nsec1... value is your private identity key and should not be pasted into a form, chat, or server configuration.

If you want Claude Code to walk through the Hostinger setup, connect the Hostinger MCP server:

claude mcp add --transport http --scope user hostinger https://mcp.hostinger.com
claude mcp login hostinger
claude -c

Here is a shorter version of the setup prompt I used:

You are my Hostinger deployment copilot. Help me deploy either Buzz or
Paperclip on a Hostinger VPS. Use the Hostinger MCP tools for anything you
can do automatically and give me exact browser steps for everything else.

Work one step at a time. Start by asking which app I want to deploy, then:
1. List my VPS instances and subscriptions.
2. Recommend the right VPS and ask before purchasing anything.
3. Walk me through the one-click install in Docker Manager.
4. Configure the firewall for SSH, HTTP, HTTPS, and required app ports.
5. Verify the containers are running and healthy.
6. Give me the app URL and explain how to connect.

Never purchase, delete, or run a destructive command without showing me
exactly what will happen and getting my explicit approval. Never ask me to
paste a password, API key, nsec key, or other secret into chat.

Paperclip

The Paperclip quickstart starts with a company and its goal. The first agent is the CEO, which can propose more hires and pass work down through the org chart.

I started with an existing software product and gave Paperclip this basic context:

This is a live product for hosting digital products. I need help with bug
fixes, features, UX, and making it usable for new customers. I am a solo
developer, the project scope has grown, and it is challenging to keep up.
Small feature requests would help get this first push finished.

The CEO proposed an org structure, then I approved the hires I wanted. You can ask a leader to propose a hire, configure a runtime yourself, or copy an onboarding prompt to an outside agent. My example ended up with a triage lead, product engineer, and UX specialist underneath the CEO.

Open an agent to see its assigned issues and individual runs. The inbox collects failed runs and approvals, so this is where I found a missing GitHub secret and an agent that stopped after running out of credits.

Each agent has its own configuration, instructions, runtime, and budget. Runs are triggered through heartbeats. I would leave scheduled heartbeats off while learning the tool and trigger them manually, especially if the agents are using paid APIs.

Paperclip burned through my starting credits pretty quickly while I was setting up the company. Set company and agent budgets before letting heartbeats run on a timer.

Using a Claude subscription

In the recording I tested using my own Claude subscription with Paperclip instead of paying for every request through an API key. I generated the setup token with:

claude setup-token

The result from claude setup-token is a credential, so treat it like a password. In current Paperclip, choose the claude_local adapter and use its Claude subscription login flow. Enter the result only when that protected flow asks for it. Don't put it in the agent instructions, source control, or the ANTHROPIC_API_KEY field, since that field is for usage-based API keys.

Codex works a little differently. On the same machine that runs Paperclip, sign the Codex CLI in to your ChatGPT subscription with:

codex login --device-auth

Complete the browser flow and leave OPENAI_API_KEY unset. Paperclip's codex_local adapter can copy the host Codex login in to its managed agent home. You can check the login with codex login status. The official Codex authentication docs cover the normal browser flow, device login, and headless machines.

If you want your local AI agent to walk you through either setup, copy this prompt:

Help me connect this Paperclip install to my own Claude or ChatGPT
subscription.

First inspect the current Paperclip version, where it is running, and which
adapters are installed. Ask me to choose Claude or Codex. Use the current
official Paperclip and provider docs. Do not switch me to API billing unless
I choose it.

For Claude, use the claude_local adapter and Paperclip's built-in Claude
subscription login. Tell me when to run claude setup-token, then pause while
I enter the returned credential directly into Paperclip's protected login
flow. Never ask me to paste the credential into chat, shell history, source
code, agent instructions, or a normal environment variable.

For Codex, use the codex_local adapter. Run codex login --device-auth on the
same host as Paperclip, then pause while I complete the official browser
flow. Leave OPENAI_API_KEY unset so Paperclip uses the host ChatGPT login.

After authentication, run the available login status check, use Paperclip's
Test Environment button, and run one manual heartbeat. Keep scheduled
heartbeats off. If this Paperclip version does not support subscription auth,
stop and explain what is missing instead of silently using an API key.

This is the part I was uncertain about in the video. Anthropic's current guidance says an end user can sign in to an unmodified Claude Code binary with their own subscription, including when a platform hosts it. It also says third-party developers cannot route requests through a user's plan credentials or collect and store Claude session tokens. Read Claude Code legal and compliance before deciding whether your exact Paperclip setup fits those rules.

Anthropic has also paused its planned subscription credit changes. For now, Claude Agent SDK, claude -p, and third-party app usage still draw from the normal subscription limits. Check the current subscription update, since this policy has already changed during the life of this recording.

Paperclip's official quickstart uses a provider API key. That is the clearer default if you do not want to depend on subscription behavior. Whichever route you use, set a small budget and keep heartbeats manual while testing.

When you are ready to test an agent, assign one small task and run a heartbeat manually. You can assign directly to the worker or give the request to the CEO and let it move down the org chart. The run log shows the model checking the task, doing the work, and reporting the result.

For GitHub access, create a fine-grained personal access token. Select only the repository the agent needs, use an expiration, and grant the smallest permissions that fit the task. My coding workflow needed repository contents and pull requests. Store the token in Paperclip's secrets area rather than an agent prompt.

Paperclip can also give a local coding agent access to its setup. From the Paperclip container, start the auth flow with:

paperclipai auth login --no-browser --api-base http://localhost:3100

Open the approval URL it prints while signed in to Paperclip. Keep the returned token out of chat and source control.

To inspect an app running on the VPS, use SSH port forwarding. Replace both ports and the server address with the values from your setup:

ssh -L LOCAL_PORT:localhost:REMOTE_PORT root@YOUR_VPS_IP

The example in the video had Paperclip import GitHub issues, propose an implementation, build a Typeform webhook integration, and open a pull request. Its test plan posted a realistic webhook payload, posted it again to confirm deduplication, then sent the wrong secret and expected a 401.

I connected the real Typeform webhook and submitted a form with a name, email, referral source, and monthly revenue. The first result reached Course Catalyst, but the nested Typeform fields were not parsed correctly because the agent had assumed a payload shape without checking it. I sent the failure back, and the next change stored the correct name, email, and custom attributes.

For future tasks I would require the agent to name the source it used for any external payload or data structure. That makes the assumption easier to catch during review.

I would keep a human check before merge. The useful part for me is getting a branch, test URL, and reviewed pull request instead of starting each issue from an empty editor.

Buzz

Buzz agents run through ACP, which lets the workspace connect to harnesses such as Codex or Claude. The execution can stay on your local machine even when the Buzz relay is hosted on the VPS. That also means the agent can use MCP connections already configured in its local harness.

I used Buzz for task updates, daily research, watchers for new content, and visibility into tools such as GitHub, Notion, and Paperclip. There is also a mobile app, which makes the shared workspace more useful away from the desk.

An agent is configured around the job first, then you choose the harness and model. My work-prioritization agent used Codex with a cheaper model and read Notion through the MCP connection already configured on my computer. I did not need to copy the Notion connection into Buzz because the agent execution was local and inherited the existing Codex setup.

Other examples in the recording included a daily research agent that looked for AI and backend engineering topics, a watcher for newly published YouTube videos, and channels that pulled updates from GitHub and Paperclip into one place. An agent with the GitHub CLI could then inspect issues from the same channel.

This was the main instruction for the engineering agent:

You will be fed a GitHub issue. Build the fix according to the issue as
closely as possible. Confirm it does not already have a pull request before
starting. Do not commit, merge, or deploy anything. Get the example running
locally, then respond with a summary, a URL to test, and clear instructions.

I later added a reviewer agent and had the engineer tag it on each pull request. The reviewer suggested corrections and approved the final change, but neither agent could merge.

Local models

Buzz can connect to an OpenAI-compatible local endpoint. I used Llama with a local GPT-OSS model, copied the model ID from the local server, and used a placeholder API key because the endpoint did not require a real one.

Use the custom OpenAI-compatible agent option, then set:

API type: chat
Base URL: your local OpenAI-compatible endpoint
Model: the exact model ID reported by your local server
Parallelism: 1

Parallelism at 1 is a reasonable starting point because a local model may already be using most of the available hardware.

Which one?

Buzz agents normally start when someone mentions them, unless you configure a watcher or recurring behavior. It fits collaborative work where humans and agents share channels, and it can act as a visibility layer across several tools.

Paperclip is more structured. Heartbeats wake agents up, the org chart passes work down, and budgets limit what each agent or company can spend. I would look at it first for a solo operation where recurring work needs to happen without a person sitting in the chat.

Buzz does not add its own dollar budgets. Spending follows whatever limits exist in the connected harness or model provider. Paperclip is API-first and puts per-agent and company budgets directly into the workflow.

They can overlap, but I would start with one small chore and add more after the workflow is working. My first Paperclip job was GitHub issue triage, while Buzz became the place where I could see updates and directly ask agents to build.