How to use Paperclip Blueprints and wire the company it gives you

Paperclip Blueprints generates a complete agent company from a markdown brief in about five minutes. The bundle imports clean, the org chart is intact, the validation passes. What it doesn't do, and what nobody hands you a checklist for, is the wiring that turns an imported company into a running one. That part is by hand, it lives in the Paperclip UI, and it's the difference between a company that looks done and one that actually works.

I built Blueprints because I was standing up Paperclip companies and hand-writing the same dozens of files every time, drifting a little on each pass. Now I describe the company once, in plain language, and the tool builds it. This is the full path, from brief to bundle to a company you've wired and woken, with the exact screens for the steps that trip people up.

Part 1: From a brief to a bundle

The input isn't config. It's a brief. You describe the company the way you'd describe it to a person: what it is, what it's emphatically not, the outcomes it chases, and the one north star everything serves. Roles, reporting lines, and operating rules are derived from that. You don't hand-write them.

Write the brief, then run one command:

uv run blueprints generate --input my-company-brief.md --output companies/acme/

A few minutes and a dollar or two of API credits later you have a directory in Paperclip's import format: a COMPANY.md identity file, a README with a generated mermaid org chart, operations rules, and a folder per agent holding its role, mandate, and heartbeat. Every file is schema-checked before it's written, so structural mistakes surface before any agent runs on them.

Import the directory through Paperclip and the company appears: agents, projects, tasks, org chart, all there. It looks done.

It isn't done. It's imported. Here's the rest.

Part 2: Wire the company (the part after import)

A bundle is portable by design, which means it can't carry the things specific to your machine and your accounts: secrets, credentials, file paths, the model runtime. That's the wiring, and it's all in the UI. Do it in this order.

1. Attach your skills to your agents

The bundle assigns skills to each agent, but the import loads them into the company without wiring the attachments, so you'll open Skills in the left nav and find a full shelf of skills that belong to nobody.

Open each skill and check USED BY. If it says "No agents attached," attach it to the agents the bundle intended (the intended list is in each agent's AGENTS.md frontmatter). To add a skill that isn't in the company yet, use Paste path, GitHub URL, or skills → Add at the top of the Skills panel.

An agent with no skills still runs. It just runs without the knowledge you gave it, and nothing errors to tell you, which is exactly why this is step one.

2. Bind your secrets

Model-provider keys and integration tokens go in as secrets, referenced by the agents, never pasted into a bundle file. In an agent's Configuration → Environment variables, set the key name the process expects, switch the type from Plain to Secret, and Seal it so the value resolves at run start instead of living in the config.

Use a least-privilege credential wherever the work allows it. A secret in a plain field is a secret you'll leak the first time you export or share the company.

3. Set each agent's adapter and model, and don't get billed by accident

Open an agent → Configuration → Adapter. Pick the adapter that drives it (e.g. Claude Code (local)), then set the Primary Model for the role and, if you want a cheaper model for routine summaries, the Cheap Model. Thinking effort can stay on Auto. It scales deliberation to the task.

This screen is also where the most expensive mistake hides. If you run on a subscription through a local adapter, an API key in the environment will silently override the subscription and bill you per token instead. Check the Environment variables block has no stray ANTHROPIC_API_KEY, and assign models by role: the reasoning seats earn a stronger model, the high-frequency low-stakes seats don't need one.

4. Stand up a local model for the cheap seats

The agents that wake often and do bounded work (a listener, a poller) belong on a cheap local model, not a frontier one. That's a runtime you install on the host and point the adapter at; it isn't in the bundle. Wiring it keeps your busiest agents off your paid budget entirely, which is the single biggest lever on what the company costs to run.

5. Point your projects at your code

If agents work in a repo, open the project → Configuration → Codebase and set the local folder to the full absolute path on the host (the shorthand ~ is rejected). Set it only on the projects that should touch that code, and leave every other project's codebase unset.

This is your blast radius: an agent can't change code its project can't reach.

6. Set budgets and run-policy caps before anything wakes

Do this before you let a single agent run. The out-of-box defaults are wide open: in an agent's Configuration, Max turns per run ships at 1000, and under Run Policy → Advanced, Max concurrent runs ships at 20. A stuck or looping agent at those numbers burns a lot before anything stops it.

Bring Max turns per run down to what a real task finishes inside, around 30. Cap Max concurrent runs to 1–2 (1 for a decision-maker like the CEO, so two runs can't make conflicting calls at once). If Continue after max-turn stop is on, know it softens that cap: one continuation attempt means a run can reach ~60 turns, not 30. Then set a per-agent budget on the Budget tab.

Turns cap the loop, budget caps the spend. Together they make a bad run fail cheap.

7. Heartbeats and routines

Agents wake on a timer and on events like a task assignment or a mention, so you don't need a fast heartbeat for responsiveness. In Run Policy, Heartbeat on interval is the timed wake; Wake on demand handles events. Reserve the timed heartbeat for proactive recurring work, match its cadence to how often there's genuinely something to do (daily and weekly, not minutes), and drive recurring jobs from Routines rather than a fast pulse.

A heartbeat firing every few minutes mostly pays to discover there's nothing to do.

8. Wire integrations and check the org

Connect whatever lives outside Paperclip, like the newsletter and analytics, and confirm the reporting chain matches the org chart you intended. With the company finally in front of you, reread the generated mandates once and fix anything that reads wrong now that it's real.

Part 3: Wake one agent, watch, then ramp

Don't turn the company on. Turn one agent on (the one at the top) using the Run Heartbeat button on its page for a manual wake, not a schedule.

Then read the run on the Runs tab: did it authenticate, what did it cost, what did it actually decide. The first agent you wake is the one most able to set the whole org moving in the wrong direction, so you want eyes on it before it's on a timer. When that single run looks right, flip on a conservative interval and bring the others up one at a time. A company you raise one agent at a time is one you can still reason about when something surprises you.

Where this goes

Generation is the fast part and it's solid. A good chunk of this wiring is work the tool should eventually own: safe run-policy defaults, model assignment, skill attachments shipped already wired. I'm building toward that. The rest (secrets, credentials, host paths) can't ride a portable bundle and will always be yours to set; that's the right place to draw the line.

Blueprints is open source, MIT-licensed, and runs today. If you're setting up Paperclip companies and you're tired of hand-writing the scaffolding, it's worth ten minutes: github.com/Grolea-HQ/paperclip-blueprints.

I write about AI ops and building in the Paperclip ecosystem every other week in my newsletter. Come follow along.