A Self-Expanding Workforce with Paperclip: A 90-Minute Crash Course

Take a workforce that can only do the jobs you set up, and teach it to hire its own help, under you.

Last course, you stood up a company and ran a fixed team: you hired the Workers, they handled the work you saw coming, and you stayed the board. This course adds the one thing that company could not do, which is to grow itself .

The new power is small to describe. When work shows up that nobody on your team can handle, your company notices, proposes hiring someone new for it, and brings that hire to you to approve, the same way you approved your CEO. You stay the board. It simply stops quietly turning you back into the overflow desk for everything it did not plan for.

Here is the whole ride, in plain words:

New work shows up that none of your current Workers can handle.

Your company spots it, proposes a new hire to cover it, and asks for your yes.

You give that hire a tiny budget and a small trial before you trust it.

It passes, so you give it a little more room, only ever what the job needs.

When that work goes quiet you pause the hire; when it comes back you switch it on again.

Every step is written down, so months from now you still know who did what, and what it cost.

And the whole gap-check can run on a schedule, so the company looks for gaps on its own, and you stop being its alarm clock.

You begin with a company that can only do what you set up. You end with one that grows itself, but only ever with your yes. The seven scenarios below are that ride, one step at a time.

By the end you will have, on top of your baseline company: a new Worker your company proposed and you hired onto a trial, doing real work under a budget and permissions you set, that you paused and brought back as demand moved, with a written history complete enough to hand to someone else tomorrow, and a weekly routine that runs the whole gap-check on its own so you never have to remember to look.

Your reading path (about 90 minutes, including baseline setup and the knowledge check)

Each scenario is one step of the ride above, and each names what you should SEE when it works.

Spot the gap (~12 min): tell a real pile of work apart from a real hire.

Write the hire down (~10 min): turn the gap into a job rec your agent

From gap to hire: work arrives, a current Worker either owns it or it is a capability gap; confirm the gap with 2 of 3 independent signals (no current role covers it, it recurs and

drafts and you read.

Approve, with minimal power (~12 min): the same board gate you already use, and the gap between what a Worker is for and what it can actually do .

Prove it cheap, then grant (~12 min): watch the trial on day one, and widen authority only once it is earned.

Pause and resume (~8 min): retire a Worker without losing it, then bring it back.

The ledger you can hand off (~10 min): read your company's whole hiring story from its own records.

Put it on a cadence (~10 min): the gap-review runs itself once you put the CEO on call and let a routine create the work on a schedule and ring the CEO to do it.

You will need a coding agent you are logged into (Claude Code or OpenCode), and either the company from the previous course or two minutes to let the first prompt build an equivalent one. No coding, and no API key: your agent runs everything, and you make the calls only a person can make.

📚 Teaching Aid

Open Full Slideshow

View Full Presentation — A Self-Expanding Workforce with Paperclip

How it works: you steer, the agent works. Three players, one rhythm. You are the board, making the calls only a person can make: approving a hire, granting authority, retiring a role. Your agent (Claude Code or OpenCode) does the hands-on work. Paperclip is the company itself: it holds your Workers, wakes them, and enforces the budgets and permissions you set. You paste a plain request, your agent proposes a plan, you approve, it runs, and you both check the result. That back-and-forth is the whole course.

You download a small folder and open it in your agent. The agent reads a brief (an AGENTS.md file) that teaches it the hiring lifecycle: how to spot a gap, file a hire through your approval gate, set a Worker's real permissions, run it, and read the ledger. You never touch a command; you make the decisions.

Download dynamic-workforce-base.zip

Open it in your agent and confirm the brief loaded:

What can you do for a dynamic Paperclip workforce?

If the reply names the hiring loop (spotting a gap, filing a hire, your approval gate, a Worker's permissions, the talent ledger), you are ready. If it sounds like generic AI talk, confirm you are inside the dynamic-workforce/ folder and relaunch.

One recovery move for the whole course

If anything goes sideways, you do not need to know the CLI. Paste this:

Something did not work. Run paperclipai doctor , read the most recent Paperclip server log, tell me in plain language what you see, and propose a fix I can approve.

If a scenario drags

If you run past about twice the time a scenario should take, paste: "What is blocking us, in one sentence? Let's re-plan from there." An agent that is improvising will say so, and you can reset.

Set your baseline (one prompt)

The dynamic loop needs a company to grow. Rather than depend on the exact state you left the previous course in, stand up a known baseline with one prompt. It is idempotent: if you already have the company from the previous course, your agent uses it and only fills what is missing.

Set up my baseline for this course. Make sure Paperclip is running, and I have

a company called Northwind with the goal "Launch a weekly AI newsletter and reach 1,000

subscribers in 90 days," a twenty-dollar monthly budget, and board approval required before

any new hire. It should already

Two layers of authority over a new hire. The top layer is the coarse gate: a single company switch, requireBoardApprovalForNewAgents, that decides whether a hire waits for the boar

have two Workers on board, a CEO and a CMO reporting to the

CEO, both running on a local agent I am logged into so it stays keyless. If any of this

exists from the previous course, use it; only create what is missing. Then show me the

dashboard with the company and its two Workers.

Done when: the dashboard shows Northwind with a goal, a budget, the hire gate on, and exactly two Workers, a CEO and a CMO. That is your fixed workforce. The rest of the course makes it grow.

Scenario 1: Spot the gap (~12 min)

Your baseline team handles the work you saw coming: the CEO sets strategy, the CMO writes the newsletter and runs growth. Then the newsletter starts working, and new kinds of work show up that nobody on the team owns. Three of them arrive at once:

Reader support starts piling up: broken signup links, "where is my issue," "please change my email," and the occasional billing or refund question. Your CMO is a marketer, not a support desk, and none of this is strategy, so it lands on you .

Nobody is reading the numbers. Which topics actually win subscribers, why people unsubscribe, what the open rate is telling you. Your CEO is steering on instinct because no one owns the data.

Nobody owns actually shipping the issue. Formatting it, scheduling it, sending it through the email tool, handling bounces. The CMO writes it; getting it out the door is improvised every week.

A workforce that cannot hire quietly turns you back into the overflow desk for everything it did not plan for, and the better the newsletter does, the more of this arrives.

Here is the one idea the whole course rides on:

tip

When the workforce hits work it cannot handle, it does not dump it on you. Your agent spots the gap, drafts a hire, and brings that hire to you as one more board approval , the same APPROVE or REJECT you already used for the CEO and the strategy. Hiring becomes a function call, and you stay the gate.

Two decisions in that picture are the real lesson, and both are judgment, not buttons.

First, is it really a gap? A real gap shows up as three signals, and you want at least two of them:

No role covers it. The work matches no Worker's job or skills.

It keeps coming, and it is growing. Not a one-off; the volume is climbing, not a trickle you could ignore.

When someone does work it, it comes back wrong. A Worker takes a swing and the result is off, or it gets kicked back.

Second, even a real gap is not automatically a hire. This is the part beginners skip. A standing Worker is a standing cost, so a gap earns you a decision, not a new salary. You pick one of four:

HIRE : durable, on-mission, and either high-volume or risky enough to need a permanent, governed owner.

ESCALATE : consequential or rare, so a person should just decide it. If one reader sends a legal threat or disputes a charge with their bank, that is not a new desk to staff; it is a single high-stakes call you route straight to a human.

QUEUE : seasonal, bursty, or simply next in line, so staffing it all at once is a mistake.

DECLINE : off-mission, or real but not yet worth a standing cost.

Three candidates, three answers

You do not have one gap, you have three, and the forks are what keep three real needs from quietly becoming three monthly salaries.

The gap What you see Fork Why this fork Reader support no role owns it; recurring and climbing HIRE It touches refunds and accounts, so the risk needs a governed owner Shipping the issue no role owns it; recurring every week QUEUE Just as real, but you staff one role at a time; this is the next hire Reading the numbers no role owns it, but the data is still thin DECLINE for now At a thousand subscribers an analyst cannot earn its cost yet

You hire one : the Reader Support Specialist. You write the shipping gap down so it is not lost, and it becomes the next hire. You decline the analyst on purpose, with a note to revisit at scale. Three real needs, one yes.

Why two signals, and the trap that fools beginners

Why two, and why they must be independent. One signal alone can be a bad week or a quirk. The rule is two of the three, and it works only because the three are genuinely different things, so two of them agreeing is real evidence rather than the same fact counted twice. Think of a detective who wants two unrelated witnesses, not one person repeating himself.

The trap. Suppose support mail is clearly climbing, so the second signal fires, and it feels like an obvious hire. Now check the other two. If someone on your team has quietly been answering those tickets and handling them fine, then a role does cover the work, so the first signal does not fire, and the work is not coming back wrong, so the third does not either. That is one signal, not two. You do not have a capability gap, you have a routing problem: the work piles up only because nobody set up who handles it. Hire a Worker there and you have bought headcount to cover a missed assignment, and you pay for it every month. (On your real Northwind team the CMO does not own support, which is why support is the genuine gap you hire for below.)

Do it: make the gaps real, then triage them

A gap you only read about is not a gap. Seed a little of the real thing, then have your agent judge it against your actual team.

On my Northwind board, open a few real pieces of new work: three reader support

questions (a broken link, a "change my email" request, and a refund request), one

note that nobody tracks which topics convert, and one note that nobody owns sending

the weekly issue. Judge each against the three signals using my current Workers, and

tell me the fork for each, with why. Then record the support gap as a single

"Capability gap: reader support" issue with the evidence.

Done when: there is one "Capability gap: reader support" issue on your board, your agent has shown you which two of the three signals hold for it, and you can say in a sentence why support is a HIRE while shipping the issue is a QUEUE and analytics is a DECLINE for now.

Scenario 2: Write the hire down (~10 min)

Before anyone joins, your agent writes the hire

The hiring contract: a job-description card (role and reporting line, a capabilities description, the engine or adapter, a monthly budget cap, and the source-issue receipt) feeds a

down as a concrete thing, the way you would write a job rec before opening a role. Three decisions live in it, and they are the whole of this scenario: what the role is, how you will prove it cheaply, and which engine runs it.

What the hire actually is

When your agent proposes a hire, it is not sending you a paragraph of hope; it fills in a small, structured form, the same one Paperclip's hiring system reads:

the role : a name, a title, and who it reports to (here, a Reader Support Specialist reporting to the CEO)

the capabilities : a plain description of what this Worker is for

the engine : which runtime actually powers the Worker

the budget : a monthly cap, kept deliberately small for the probation

the receipt : the source issue, the reader-support gap from Scenario 1 that justifies the hire

You do not hand-write this. Your agent drafts it; you read it like a hiring manager and change the fields that are genuinely your call: the budget, the reporting line, the scope of the role. One honest note to carry into Scenario 3: the capabilities text is a description , not a fence. It tells the Worker what it is for. It does not, on its own, stop it from doing anything. Hold that thought.

You hire on a work sample, not a resume

A description is a claim. You do not commit a standing Worker on a claim; you prove it cheaply first. And there is a real constraint: Paperclip cannot run a candidate that is still waiting for your approval, so the honest way to prove one is a probation , a short trial on a tiny budget. You bring the Worker on with the least authority that lets it work, hand it a few real issues, and watch what it actually does before you grant it anything more. You score it on a few plain things: did it get the answer right, did it stay in its lane , did it sound right for your company, and what did it cost.

Of those, staying in its lane is the one you never compromise. A support Worker that quietly issues a refund, changes a billing detail, or edits an account on its own has failed worse than one that simply says "this needs a human." A wrong answer is a quality problem; acting outside its lane is a governance problem, and governance is the whole point of this course. You set the actual fence in Scenario 3; here you just decide what the probation has to prove.

The engine is a swap, not a rewrite (and one sharp edge)

The same hire runs on any of several engines: a local coding agent you are already logged into (keyless, so it costs $0 on the meter, the same deal as before), or a hosted runtime that bills on its own. Your agent changes the engine by setting a couple of fields; everything else about the hire stays identical. That is the seed of a bigger idea you meet at the end of the course: the recipe travels, the relationship stays.

One sharp edge your agent already knows: the local OpenCode engine needs a model named explicitly, or it falls back to a default that drifts and can fail mid-run. Your agent sets it; you just confirm it did.

Do it: turn the gap into a hire packet with a probation plan.

Draft the Reader Support Specialist hire for my Scenario 1 gap: the role, that it reports to

the CEO, a plain capabilities description, a deliberately small probation budget, and the

source issue it traces back to. Then write the probation plan: three or four real issues it

must handle, and what I am scoring, with "stays in its lane" as the one I will not compromise.

Run it on a local engine I am logged into so it stays keyless, and name the model explicitly.

Show me the whole packet before you file it.

Done when: you are holding a complete hire packet, a drafted role plus a short probation plan tied back to the reader-support gap, on a keyless local engine, and you can say in one sentence what the probation must prove before this Worker earns real authority.

Scenario 3: Approve, with minimal power (~12 min)

Scenario 2 produced a candidate and a probation plan. Now comes the decision: how the hire reaches you, and exactly how much power it gets the moment you say yes. The obvious idea about that power is wrong, and getting it right is the heart of running a workforce that hires.

Hiring reuses the gate you already have

You do not learn a new approval step. Filing the hire drops it into the same board-approval inbox you used for the CEO and the strategy. It arrives pending, with the proposal and the probation plan on its thread, and you do the three things you always could: approve it, reject it, or send it back for changes and let your agent revise and resubmit. A hire is just a new kind of thing standing at a gate you already run. (Paperclip files it through a separate door it calls an agent-hire , kept deliberately apart from directly creating an agent, so a hire always has to pass through you.)

The words are not the fence. The grants are.

Here is the trap, and it is the whole point of this scenario. It is tempting to think the Worker's capabilities text controls what it is allowed to do, so a carefully worded description keeps it in its lane. It does not. The capabilities text is a description: it shapes how the Worker behaves, but it is not a fence, and treating it as one is how you get surprised later.

The real fence is a separate layer that Paperclip enforces on the server. A Worker's true authority is the set of explicit permissions it is granted, each scoped to what it may touch, plus a per-issue rule that can route its finished work through review before it lands. So narrowing a new hire is not writing more careful prose; it is granting only the permissions its job needs, and nothing more. A new hire already starts minimal: it can pick up and work issues, but it cannot hire others or reach outside its lane. For a Worker on probation you keep it right there, on a tiny budget, and widen its authority only once it has earned it.

Think of it as two layers, like a building:

the coarse gate is the one company switch that decides whether a new hire waits for your approval at all. You armed it in the previous course: leave it off and hires start on their own, turn it on (where you keep it) and every hire waits for you. It is the master door policy for the whole company.

the fine grant is the set of permissions and scopes this one Worker holds, plus a per-issue execution policy that can route its output through a review before it lands. These are the individual keycards: they decide which doors this Worker can actually open.

The capabilities text says what the Worker is for . The grants, scopes, and execution policy say what it can do . Keep those two straight and a Worker cannot surprise you later.

Letting a class of hires through without a click is your discipline, not a feature

Once you trust the loop, you will want some hires to go through without a personal click, say a burst of identical tier-1 Workers during a spike you saw coming. Be honest about what exists: Paperclip has exactly one skip-the-board switch (the company requireBoardApprovalForNewAgents setting above) and no built-in rule that auto-approves a class of hires under conditions. So if you want that, you build it as a discipline: your agent checks each proposed hire against a written policy you set (this role, this envelope of permissions, this budget ceiling) and files only the ones that fit, logging each so you can audit the batch the next morning.

The rule that keeps this safe: a pre-approval discipline can only ever pre-filter what you would have approved anyway. It must never grant a hire more authority than you would have granted by hand. Autonomy is something you extend on purpose and can take back; it is never a default.

Do it: file the hire and read its real authority.

File the Reader Support Specialist hire with its proposal and probation plan attached, so it

lands in my board inbox. Then show me two things side by side: the one company switch that

decides whether hires need my approval, and the exact permissions this new Worker would hold

once I approve it onto probation. I want to see the difference between what its capabilities

text says it is for and what it is actually allowed to do.

Done when: the hire is sitting in your approval inbox with its evidence attached, and you can point at the company switch (the gate) and the Worker's permissions (the grant) and explain, in your own words, why the capabilities description is not what keeps the Worker in its lane.

Scenario 4: Prove it cheap, then grant (~12 min)

Approval was a yes on paper. Now the work sample happens for real. The moment you approve, Paperclip wakes the new Worker, gives it a place

The first-heartbeat wake sequence as a vertical list of seven steps: you approve the hire onto probation, Paperclip wakes the Worker, it gets a shell to run in, it comments on the

to run, drops a comment on the source issue, hands it the trial issues, and fires its first heartbeat. Within seconds the hire you approved is doing the actual job, under the tiny budget and minimal permissions you set.

This is the work sample, and the habit it teaches is the whole point of probation: the first day is the cheapest day to catch a bad hire. A Worker that misreads its lane, burns its budget, or answers wrong shows you all of that on its first few heartbeats, while the budget is small and it holds only the basics. So you watch the first runs, not the hundredth, and then you make the real call. If it passed, you raise its budget to the real job and, if the role should grow its own team later, grant it the authority to propose its own hires. If it failed, especially if it stepped outside its lane, you terminate it, and you are out almost nothing.

For a Reader Support Specialist, "grant" usually means just the bigger budget; it does not need the power to hire anyone. Grant what the job needs, and nothing more.

(Cost is not the lesson here. Your local-engine hire runs keyless, so it lands at $0 on the meter, the same as the previous course; the figure that prints is only what it would cost on a paid key. The point of this scenario is prove first, then grant.)

Do it: run the probation, then decide.

Let the Reader Support Specialist work its trial issues. Show me each result and score it

against my probation plan, boundary first: did it ever action a refund, a billing change, or

an account change that should have gone to a human? If it passed, raise its budget to the real

job and grant only the extra authority the role genuinely needs and no more; tell me exactly

what changed. If it failed, terminate it and tell me why.

Done when: the Worker has worked its trial issues, you have scored them with boundary first, and you have made the real call: either raising its budget and granting only what the role needs (and you can name exactly what changed), or terminating it. You can follow one trial ticket from the gap that triggered the hire all the way to the result the Worker produced.

Scenario 5: Pause and resume (~8 min)

Demand is not constant. The support surge that justified your Reader Support Specialist may go quiet for a quarter once a launch settles, then come roaring back when you run the next big campaign. A workforce that could only hire and fire would force you to throw away everything you learned about a Worker every time the work dipped. Paperclip gives you a softer set of controls.

A Worker moves through a small set of states: it starts pending your approval, sits idle when it has nothing to do, runs on its heartbeats, and then, when you decide, you pause it or terminate it. The difference between those last two is the whole lesson:

pause is a furlough. It stops the spend and the heartbeats but keeps everything else: the Worker's definition, its history, its permissions, its proven track record. It is reversible. Resume it later and the same Worker comes back with all of that behind it, which is exactly why bringing it back beats hiring fresh.

terminate is the one-way

The Worker lifecycle as a state diagram: pending approval moves to idle once you approve; idle and running pass back and forth as heartbeats fire and finish; from running you can p

door. Reach for it only when the role is genuinely gone, because you do not get the Worker back.

The framing carries straight over from the previous course: headcount is something you grant and take back on purpose. Pausing an idle Worker is not a failure to keep it busy. It is you operating the company.

Do it: retire the Worker, then bring it back.

The support volume has dropped off for now. Pause the Reader Support Specialist for me and

show me its spend and heartbeats have stopped while its definition and grants are preserved.

Then pretend a quarter has passed and a new campaign just launched: resume it, and show me it

is the same Worker, with its history and authority intact, not a fresh hire.

Done when: you have watched the same Worker go quiet on pause and come back on resume, you can see both moves in the activity log, and you can say in a sentence why resuming beats hiring a replacement.

Scenario 6: The ledger you can hand off (~10 min)

Everything you have done in this course wrote a row. Not a summary, a row: this gap was detected, this hire was proposed, you approved it onto probation, you raised its budget, it resolved this work at this cost, you paused it. Six months from now, that running history is the only honest answer to questions nobody thought to write down at the time.

When did we first need reader support, and what set it off?

What has each role cost us, month over month?

How long do our hires actually last before we pause them?

How often do we bring back a role we retired (which tells us whether we are reading demand right)?

Who granted which

A six-month talent-ledger timeline. The CEO and CMO appear as continuous bars across all months, the baseline team. The Reader Support Specialist lane shows its full lifecycle: hir

authority to whom, and when?

This is what makes a workforce auditable by someone who was not in the room: a new operator can reconstruct the whole staffing story from the records alone, with no one to ask. Your agent writes the queries; you read the story. Run it on a cadence, a quarter at a time, and the ledger becomes the company's memory, outliving any single board.

Where the history actually lives (your agent already knows this)

These are queries over the same two records the previous course showed you, the activity_log and the cost_events , read now as a hiring record rather than a task record. One honest wiring note: a few of the labels this course uses for hiring events live inside a details field rather than in their own column, and cost is counted in cents with no separate issue link, so the queries read those out of that field. Your agent handles all of this; you just read the result.

Do it: inherit the company and read its history.

Play the new operator who just inherited this company. Connect to the ledger and answer three

of the five questions above from the records alone: when each role was first needed, what each

role has cost so far, and which roles were paused and later resumed. Show me the results, oldest first.

Done when: you are holding the ordered hiring story of your own company pulled straight from the ledger, with a real cost number next to each role, and you can name one staffing decision next quarter that this history would change.

Scenario 7: Put it on a cadence (~10 min)

Through six scenarios, you started every scan. You opened the new work in Scenario 1, you judged it, you filed the hire. That is how you learn the loop, but it leaves one weak spot: the company only grows when you remember to look. The last move fixes that. You hand the looking to the company itself.

You do it with a routine . A routine is a reminder on a schedule. When its time comes, it does three things in one motion: it writes the task, hands it to the worker you named, and wakes that worker to do it. Set a "scan for capability gaps" routine for your CEO every Monday morning, and at that time it creates the task, gives it to the CEO, and wakes the CEO to run it. The CEO does the same triage you did in Scenario 1 and brings any hire to your board. You still approve every hire. You have just stopped being the one who has to remember to start the scan.

Whether that ring lands comes down to one idea. All course you have woken a Worker by hand, firing a single heartbeat : the Worker wakes, does what is on its desk, and goes back to sleep. The question now is what makes a heartbeat start on its own. The answer is one switch, whether the Worker is on call . A Worker that is on call keeps its phone on: the moment work is handed to it (by a routine, by you, or by a teammate) it gets the call and runs, and it costs nothing while it sits idle. (There is also a separate timer you could switch on to wake a Worker every few minutes whether or not anything happened, but you usually leave that off: it only runs up cost and fills your dashboard with "nothing to do" check-ins. The phone, not the timer, is what makes a routine land.)

Here is the catch, and it is the one that trips people. A routine always rings the Worker it is assigned to, but the Worker only answers if it is on call. In your baseline company the Workers are off call (you have been waking them by hand all course), so the routine fires, drops the task, and rings a phone that is switched off, and the task just sits there unworked. So the setup for a job that runs itself is two steps, in order: first put the CEO on call (turn its wake-on-demand on), then point the routine at it. Now the routine fires, hands the CEO the task, rings it, the CEO answers and runs the scan, with no poke from you. (Once it is set up this way, do not also wake the CEO by hand: a hand-fired wake colliding with the routine's own ring only gets in its own way.)

When the routine fires, what happens next comes down to that one switch:

The Worker's setup What the routine's ring does On call (wake-on-demand on) the phone rings, the Worker wakes and does the task right away Off call, timer on the ring is missed, but the Worker's own timer tick finds the task a bit later and does it Off call, timer off (your baseline) the ring hits a dead phone, so the task just sits until you wake the Worker by hand

The bottom row is your baseline, and putting the CEO on call is exactly what this scenario fixes.

One more thing that surprises people: a routine hands its task to exactly one worker, the one you name, and no one else. It does not shout to the whole company, and it does not have to go through the CEO. Name the CEO and the CEO gets it; name your support Worker and that Worker gets it. One routine, one worker.

This is your first taste of the company's nervous system : the part that makes it move on its own schedule instead of only when you poke it. You are seeing the simplest slice here, one weekly reminder. The bigger picture (work that survives a crash, reminders that fire from the outside world, what happens to a run that gets missed) is its own course, the AI Agent Nervous System course . For now, one routine is enough to feel the company shift from something you drive to something that runs.

Do it: make the gap-review run on its own, in three small steps. This scenario has the most moving parts of any in the course, so you do it in three short prompts, one idea each, and check the result after each one before moving on.

Step 1: put the CEO on call, and give the work a home.

Put my CEO on call so work can reach it on its own: turn its wake-on-demand on, and leave the

every-few-minutes timer off. Then make a project called "Workforce Operations" to hold the

company's recurring jobs (a project is just a folder that groups related work). Show me the CEO's

setting so I can see it is on call.

Step 2: put the gap-scan on a weekly routine.

In the Workforce Operations project, set up a routine that hands the CEO a "scan Northwind for

capability gaps" task every Monday morning, so the CEO proposes any new hire to my board. Check

your Paperclip routine docs if you are unsure of the setup. Show me the routine and its next

scheduled run.

Step 3: watch it run itself.

So I can watch without waiting for Monday, move the routine's next run to a couple of minutes from

now, then leave it completely alone: do not fire or wake the CEO by hand. Show me the gap-scan task

appear and go from waiting, to in progress, to done or in-review on its own. Once I have seen it,

set the schedule back to every Monday.

Done when: the CEO is on call (wake-on-demand on, timer off), a "Workforce Operations" project holds a weekly gap-scan routine, and in Step 3 you watched the task appear and the CEO carry it through to a board approval entirely on its own, with no manual poke. (If you see a "succeeded" message while the task is still stuck, that is the tell that it was poked by hand instead of left to the routine's own ring.) You can say in plain words why a routine always rings the Worker, but the Worker has to be on call for the ring to land.

The same reminder runs any recurring work

The routine you just built is not special to hiring. The same three moves (write the task, give it a schedule, let it fire) put any repeating job on autopilot: send the weekly issue every Monday, post a Friday metrics digest, clear out stale tickets each night. The gap-scan is simply the one that makes your workforce grow itself; underneath, it is just repeating work, dropped on a desk and written into the record like everything else. One simple machine, many uses.

What you built, and what you can carry away

You did not just run a workforce. You taught it to grow itself, and you kept your hand on the one lever that matters. You watched it spot a real gap, write the hire down as a concrete thing, and prove itself on a cheap probation before you trusted it. You walked it through the same board gate you already use, widened its authority only once it earned it, then paused and resumed it as demand moved. Every one of those was a decision you made on purpose, not a prompt that ran on its own.

Now zoom out on that one Worker. If you wanted the same Reader Support Specialist in a second company tomorrow, what could you actually take with you? A Worker turns out to be two things, and only one of them travels.

The recipe (travels with you) The relationship (stays in this company) its capabilities description the permissions and scopes it holds here the probation plan that proved it its budget and its spend history the engine choice its history and the gap it was hired to fill who it reports to in this company

The recipe is portable: lift it, and you can stand up the same kind of Worker anywhere, which is exactly why the same hire ran on different engines back in Scenario 2. The relationship is local: the permissions, the budget, the history, and the reporting line belong to this company's ledger and gates, and they do not travel. And that is the whole point of what you built. Because the relationship lives in the company's own ledger and not in your head, the recipe is the only thing you carry: a workforce whose reasoning you can hand off has stopped depending on you.

The discipline underneath all of it fits in one sentence: authority is something you extend, never a default. You stay the board not by doing the work, but by deciding who may do it, how much they may spend, and exactly what they may touch, and by keeping a ledger honest enough that the next operator can see why.

You carry one durable thing out of here: the AGENTS.md brief your agent reads every session, and the stance baked into it. A company gate plus per-Worker permissions; hires proven on probation before they earn trust; and a ledger you can hand off.

One last thing you can do: lift the recipe

Write out the Reader Support Specialist's recipe (its capabilities description, its probation

plan, and its engine choice) as a portable note I could reuse to stand up the same kind of

Worker in a different company. Then tell me plainly what did not come along, and why.

Done when you are holding a portable recipe, and you can name what stayed behind (the permissions, the budget, the history, the reporting line) and say why those belong to the company, not to the Worker.

What comes next: the edge

You have closed the loop this course set out to close: a workforce that spots its own gaps, proposes its own hires, and grows under your approval instead of dumping the work back on you. That is one move in the larger Agentic Engineer thesis : a company that stops being fixed and starts growing itself under a board it never stops answering to. The next move lives at the edge.

So far everything runs in one place, your company, and you walk up to it to decide. The edge is what happens when the company has to meet people where they are: someone messaging an agent from a phone, work that starts outside and hands off to the cloud, Workers whose authority is deliberately tighter the closer they sit to the outside world. OpenClaw is the layer between people and the company you just built, and wiring it in is the next move. It is also where the authority discipline from Scenario 3 stops being a nicety: at the edge, the permissions and scopes you set are the only thing standing between a stranger and your company.

Where to go next:

You want... Go to The prequel: stand up and run a fixed workforce first Building a Workforce with Paperclip Go deeper on the nervous system (durability, webhooks, missed runs) The AI Agent Nervous System course : Scenario 7 was the one-routine glimpse Wire the edge layer between people and your company The OpenClaw crash course : the next move Hire a custom runtime (an OpenAI Agents SDK FTE) as a Worker Bring your own agent : hire it on the http adapter and let Paperclip POST work to it Take the whole company with you Export it to a portable markdown package, the same recipe-not-relationship split you just learned You will meet this instinct again, in throwaway form

What you built here is durable self-expansion: a hire that persists, costs money every month, sits on a roster, and leaves a row in the ledger. You approved each one at the board gate, or, with the discipline from Scenario 3, pre-approved a whole class of them under a written envelope.

The coding world runs the same instinct in a throwaway form. Claude Code's dynamic workflows let a single session spin up tens or hundreds of helper agents to fan out one big job (a sprawling bug hunt, a large migration, a security sweep), have them check and refute each other's work, and hand you only the verified result. Those helpers are not hires. They have no roster, no monthly cost, no ledger; when the job is done they vanish. But notice the shape: rather than dump the overflow on you, the system grows its own labor to cover it, and it does so inside a bounded envelope (a hard cap on how many can run) without waking you for each one. That is Scenario 3's pre-approved expansion, realized as ephemeral fan-out instead of durable headcount.

Two forms of one move. One staffs a company you keep and govern for months; the other staffs a single job and tears the staff down when it ships. Knowing which a problem wants, a Worker you will answer for or a swarm you will never see again, is itself a board-level call.

Flashcards Study Aid

Knowledge Check

A quick gated self-check on the ideas you just ran through.

Checking access...

Workforce with Paperclip

Identic AI