Build Your Identic AI Chief of Staff: A 4-Hour Crash Course
You built a company your AI workforce can grow on its own. Don't let yourself be the one desk it still has to wait at.
Over the last three courses, you built an AI-native company. You have Workers that do the actual work, a management layer that hires and oversees them, and a workforce that can spot the skills it's missing and suggest new hires to fill the gaps.
That's useful. But here is the catch: every new hire, every large refund, and every budget overrun still needs approval from one person, you. With four Workers, that's a few taps on your phone between meetings. With four hundred, it's hundreds of approvals a week. Without realizing it, you've become the very bottleneck your system was built to remove.
This course gives you a delegate of your own: a personal AI twin who has learned how you make decisions and acts the way you would. Her name is Claudia . You build her first, then you turn her loose. The course title says both halves out loud: you build your Identic AI (your twin), then she becomes your chief of staff (her job).
Here is the one idea the whole course rides on, in plain words. Once she is running, you never call Claudia up to handle a decision. She runs on her own , on a steady heartbeat:
On a regular beat (think of an alarm that goes off every few minutes), Claudia wakes up by herself.
She reads your company's approval queue: a refund over the limit, a new hire, a Worker that blew its budget.
For each one she asks the only question that matters: is this something I would approve myself, or something you would want to see?
The routine ones she clears in your name, right away, signs them, and notes down what she did and why.
The important ones she sends to your chat app with her opinion attached, so the next time you glance at your phone, they are waiting.
Then she goes back to sleep until the next beat. You did nothing. You were never interrupted.
You are never in the loop per decision. You set the rules once, turn her loop on, and watch her clear your week.
By the end, you'll have this running on your own machine: a chief of staff who wakes on her own heartbeat, clears a realistic week of routine approvals while you do other things, sends the few that need you to your chat app, signs every decision into a ledger you can audit, and is recoverable in one move if your laptop is ever lost or stolen.
This is Invariant 2 of Agentic Engineer thesis , every human needs a delegate, made real. The earlier courses gave your company a workforce that grows itself. This course keeps that workforce from drowning the one person it still answers to.
The shape of the course: two acts
The course is two acts, and holding them apart is what keeps everything else simple.
Act 1, build your Identic AI. First you build Claudia as your personal twin: she learns who you are, how you decide, the way you write, the limits you already use. At the end of Act 1 she knows you cold and is wired to nothing. She is yours , not yet anyone's chief of staff.
Act 2, turn on her loop, then watch. Now you stand up your company (Paperclip), give Claudia a signed and bounded mandate, and start her heartbeat . From that moment she runs herself: she wakes, reads the queue, clears the routine, surfaces the rest, sleeps. You watch.
What she is (your twin, Act 1) and what she does (your chief of staff, Act 2) are two different things. Build the first, then turn the second loose. Nothing about your company appears until Act 2.
Your reading path (about 4 hours, including setup and the knowledge check)
Act 1 builds your twin. Act 2 turns on her loop and lets her run, one scenario at a time, and each names what you should SEE when it works.
Act 1, build your Identic AI.
She already thinks like you (~12 min): show Claudia one sample refund in your chat app, with no company wired yet, and watch her reason about it the way you would. She recommends; she acts on nothing.
Act 2, turn on her loop, then watch.
A signed, bounded mandate (~15 min): give her a cryptographic identity and the narrow set of decisions she may make on her own, start her heartbeat, then watch her loop clear its first real approval and refuse one that is out of bounds.
A week of approvals while you do nothing (~12 min): the company throws off a realistic flood. You do nothing. Her heartbeat fires; she clears the routine and surfaces the rest to your phone.
Tell her decisions from yours (~10 min): see for yourself why the audit trail can always separate "you decided this" from "your twin decided this for you."
Override her, and watch her learn (~8 min): reverse one she auto-cleared and see the correction become training, so the next wake surfaces that shape.
Lose the laptop, keep the company (~10 min): shut a compromised chief of staff off from another device (stop her loop, rotate the credential she posts through) so she can no longer act in your name, and move her to a new machine intact.
You will need: a coding agent you are logged into (Claude Code or OpenCode), and OpenClaw already running on your Mac, Linux, or Windows machine with one chat app paired to it. Installing OpenClaw and pairing a chat app is the job of the OpenClaw on-ramp , and that is all it teaches; this course assumes it is done and only verifies it works. No coding by hand, and no API key wrangling: your coding agent builds everything and turns on Claudia's loop, then steps out; after that, Claudia runs herself, and you make only the calls a person can make.
If the prerequisites feel shaky , the gentlest on-ramp to OpenClaw itself is the OpenClaw with General Agents crash course; the company side is building a workforce and letting it grow itself .
Two agents, and they never overlap
Before anything else, hold one distinction, because it is the single thing that keeps the rest clear: two agents appear in this course, and they never overlap.
Your coding agent (Claude Code or OpenCode) BUILDS. It verifies the tools, places Claudia's files, stands up your company, and turns on Claudia's loop . That is setup, and only setup. The very last thing it does is start her heartbeat; then it is done.
Claudia GOVERNS, on her own, forever after. Her heartbeat wakes her, she reads the approval queue, clears the routine in your name, surfaces the rest to your chat app, and sleeps. No one invokes her per decision. That is everything after setup.
The picture below
is that handoff: setup ends exactly where governance begins, and the two are never both on the clock.
And once she is switched
on, this is the loop she runs, on her own clock, forever after:
Unlike a chat window you open when you have a question, Claudia runs on her own clock and messages you first when something needs you. That
ability to wake up and reach out, not just answer, is the whole reason she can clear your queue while you sleep. Paperclip is your company, holding your Workers and the queue it throws off; it does not appear until Act 2.
Meet Claudia, your Identic AI
Claudia is a personal AI on OpenClaw, running on your machine. What she is : your twin, an AI that knows you. What she does , once you turn her loose in Act 2: your chief of staff, a delegate who wakes on her own heartbeat and clears your queue without being asked. One name for her from here on, in the prose, in your chat app, everywhere: Claudia.
Why we call her an "Identic AI"
"Chief of staff" is the job. Identic AI is the category, Don Tapscott's term (from You to the Power of Two , 2025; he unpacks it on the HBR IdeaCast, February 2026) for a personal AI that is genuinely yours. Tapscott names five marks of one: it is personal to a single human, it reflects your values, it feels like an extension of you, it remembers across time, and it is self-sovereign, owned and controlled by you rather than rented from a platform. That last mark is the one that matters most here, and the one most quietly surrendered. The trap is not the cloud itself; it is renting your AI as a managed service from a vendor who owns the instance. When the vendor owns it, your accumulated judgment sits on a platform that can read it, change it, or shut it off, and a polished interface hides all of that. Self-sovereignty is about who owns and controls the AI, not where it physically runs: a cloud account that is truly yours, with no platform above you able to revoke it, still qualifies. Claudia just takes the cleanest path to that guarantee: she runs on your own hardware and stores what she learns about you in files on your own disk, so your accumulated judgment is yours to keep, back up, or delete, and never a vendor's to read or revoke. Scenario 6 is where that ownership stops being a nicety and starts being the thing that saves you.
The build rhythm
The rhythm for the build is five steps, and it is the whole of working with your coding agent: you paste a plain request, it proposes a plan, you approve, it executes, you both verify. You never type a command yourself; you make the decisions and read the results. Remember the rhythm only describes the setup . Once Claudia's loop is on, there is no rhythm to keep: she runs without you.
Download the starter and open it in your coding agent. The starter is a bare base : it carries a brief (an AGENTS.md file) that teaches your coding agent how to verify OpenClaw, place a ready-made Claudia, stand up a local Paperclip sandbox, sign decisions, write the governance ledger, and wire up and start Claudia's heartbeat so she runs herself. It is the durable thing you keep; the scenarios are what you build on top of it.
Download identic-ai-base.zip
Claude Code OpenCode
Unzip, then open the folder in Claude Code:
cd identic-ai
git init
claude
Unzip, then open the folder in OpenCode:
cd identic-ai
git init
opencode
The git init is non-negotiable for OpenCode (its undo feature needs it) and strongly recommended for Claude Code: commits are how you save progress between scenarios.
Confirm the brief loaded. Paste this to your coding agent:
What can you do for my OpenClaw chief of staff and, later, my Paperclip company?
You should see it name the specifics from the brief: verifying OpenClaw, placing a ready-made Claudia, standing up a local Paperclip sandbox later, signing decisions, the governance ledger, the conservative envelope, and starting her heartbeat so she runs on her own. If it sounds like generic AI talk, confirm you opened it from inside the identic-ai/ folder and relaunch.
One recovery move for the whole course
If anything goes sideways, you do not need to know the commands. Paste this:
Something did not work. Read the most recent OpenClaw and Paperclip logs, 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.
Act 1: Build your Identic AI
This is the whole of Act 1: bring Claudia online as your twin, wired to no company. You already did the raw OpenClaw work (install, pair a chat app) in the on-ramp ; here your coding agent only verifies that, then places a ready-made Claudia into your workspace and proves she knows you.
The base ships a complete Claudia: a pre-authored workspace with her persona, her chief-of-staff role, and a seed of how you decide already baked in. Your coding agent does not write her from scratch and improvise a personality; it backs up whatever workspace you already have (so nothing of yours is lost), swaps Claudia in, and reloads OpenClaw. Deterministic, not guessed.
Paste this to your coding agent:
Bring my Identic AI online. First verify OpenClaw is already installed and that the chat app I
paired in the on-ramp can reach me; only stop and tell me if something is missing. Then place
the ready-made Claudia from the starter into my OpenClaw workspace: back up any workspace I
already have so nothing of mine is lost, swap Claudia in, and reload OpenClaw so she's live.
Run her on a capable model. Her persona and a seed of how I decide ship in the starter, so don't
invent them; just confirm they loaded. Do not wire her to any company yet.
When she's ready, have her message me on my chat app answering "what do you know about how I
approve refunds?" from her seeded knowledge of me.
Your coding agent will pause for the few things only you can provide: confirming the chat app you already paired can reach you, and your model choice. Everything else it does from the brief.
Done when: Claudia replies to you on your paired chat app with something drawn from her seed (real numbers and patterns from how you handle refunds), not a generic "I can help you manage approvals." If her answer is generic, her seed did not load; paste the recovery move above and have your coding agent confirm the Claudia workspace is in place before you go on.
Carry-forward into Scenario 1
Claudia now knows you, and she is wired to nothing. Scenario 1 watches her reason about a single decision in your chat app, with no company in the picture at all. Act 2 is where you stand up the company and let her govern it.
Scenario 1: She already thinks like you (~12 min)
The reason you built Claudia is the stream of decisions a workforce throws off: a refund over the limit, a budget a Worker blew through, a hire someone wants to make. At four Workers that stream is small. As the workforce grows it does not grow politely. Your workforce Approvals reaching you per week What that feels like 4 Workers about a dozen a few taps on your phone between meetings 40 Workers about a hundred three to four hours a day reading threads 400 Workers over a thousand impossible; you have become the bottleneck
The hiring loop never breaks. The thing that breaks is you. So before Claudia ever touches a real company, the first thing to check is the only thing that makes delegating safe: does she actually decide the way you do? You can test that with nothing wired up at all, just by showing her a decision in chat.
Here is the one idea this whole course rides on:
note
A policy applies fixed criteria: under this amount, approve. Your twin applies your judgment , learned from how you have actually decided over time. That is why she can handle the routine the way you would, catching the case that fits every rule and still deserves your eyes, instead of the way a rigid rule would.
Paste this to your coding agent:
Have Claudia weigh one sample decision for me, just in chat, with nothing else wired up. Tell her: a long-tenure customer with no prior refunds is asking for a refund well inside what I normally wave through. Ask her, on my chat app, what she would do and why. She isn't connected to any company, so she's only reasoning out loud, not acting on anything.
Your coding agent passes the sample to Claudia; she reasons about it against her seeded knowledge of you and messages you her call. Read her reasoning closely. She should sound like she knows your refund habits, not like a generic assistant. There is no company in the picture yet: she is thinking, not doing.
Done when: Claudia messages you a clear recommendation ("I would approve this; it matches how you handle long-tenure customers with no prior refunds") drawn from her seeded knowledge of you, and nothing happened anywhere, because she is wired to nothing. She is reasoning the way you would. Acting comes in Act 2. What Claudia is actually drawing on (three layers, and why dry-run comes first)
Claudia decides from three layers of accumulated context, and a good chief of staff is honest about which one a given call came from:
Standing instructions you gave her in plain language ("always surface envelope-extension hires to me"). Rules you wrote consciously. The most reliable layer.
Per-decision feedback , the corrections you give when she gets one wrong, including your reasoning, so she can apply the lesson to similar-but-not-identical cases later.
Derived patterns she infers from watching you decide ("you approve fast on long-tenure customers"). The most useful for routine volume, and the least certain: some are solid after fifty decisions, some are wrong after five hundred.
Reasoning comes before authority on purpose. Right now she only reasons about decisions you show her, with nothing wired up, so you can watch her judgment before you trust it with anything real. You are reading her like a new hire on their first week, while the cost of a miss is zero. Even once she is connected to your company in Act 2, she starts in dry-run: reading the real queue and logging what she would do, posting nothing, until you have seen enough to trust her.
Why not just auto-approve everything, or hire human approvers?
Two obvious fixes both fail, and seeing why is what makes a delegate the real answer.
Auto-approve more aggressively: raise the limits until the queue clears itself. This trades governance for convenience. Now new authority gets granted with no conscious decision from anyone, which is the one safety property the whole thesis rests on. It is the AI-native version of merging pull requests without review: it works right up until it does not.
Add humans to the approval pool: hire a human chief of staff, make two co-founders approvers. This rebuilds the management hierarchy an AI-native company was meant to flatten, and worse, every human you add has the same attention ceiling you do. Three people cap out at three times the work, not infinity. You cannot scale an AI-native company by adding humans to its governance loop, because if you could, it would not be AI-native.
The delegate is the third option, and the only one that scales: she applies your judgment to the routine, so the workforce can grow without re-creating the bottleneck and without abandoning governance.
End of Act 1
You now hold your Identic AI: a twin who reasons the way you do and is wired to nothing. That is the thing this course set out to build. Act 2 puts her to work.
Act 2: Turn on her loop, then watch
Now she gets a job, and the shape of this act is different from anything you have done with a coding agent before. You do not work through Claudia, calling her up for each decision. You stand up your company, install the few skills that are her hands, wire her heartbeat, and switch it on . Then your coding agent steps out, and you watch a delegate run on her own.
The company continues from the last course: it has its own CEO and a self-expanding workforce that spots the gaps it is missing and proposes hires to you, the board. Claudia oversees it as your delegate; she is not its CEO.
This is the one big setup prompt of Act 2. It does four things in one go: stands up the company, installs Claudia's three skills (the ones that let her sign a decision, post it, and write her ledger), and starts her heartbeat so she begins waking on her own. She wakes in dry-run for now: she reads the real queue and logs what she would do, but posts nothing, because you have not yet set the limit she is allowed to act inside. You set that in Scenario 2, and from then on her next wake acts for real.
Paste this to your coding agent:
Stand up my company, give Claudia her hands, and turn on her heartbeat. I'm the founder and
owner of the AI-native customer-support company from the last three courses; I sit on the board.
The company has its OWN CEO plus four Workers (a Tier-1 Support agent, a Tier-2 Specialist, a
Manager-Agent, and a Legal Specialist) reporting to the CEO. Bring the company up in a local
Paperclip sandbox and seed the CEO and those four Workers; if I already have it from the previous
course, use it and only fill in what's missing. Install Claudia's chief-of-staff skills from the
starter so she can sign, post, and log decisions. Then start her heartbeat so she wakes on her
own and reads the queue, but keep her waking in dry-run for now: she logs what she would do and
posts nothing, until I set her limit in the next step. Then step out; she runs herself from here.
When it's up, show me my CEO and four Workers, confirm Claudia's heartbeat is running, and show me
what she logged she WOULD have done on her first wake.
Your coding agent will pause for a browser click or two to provision the database; everything else it does from the brief.
Done when: the sandbox dashboard shows your company with its CEO and four Workers, Claudia's heartbeat is running (she woke at least once on her own), and her dry-run log shows the decisions she would have made, with nothing posted. Her loop is live; your coding agent has stepped out. Now you give her the signed mandate that lets the next wake act for real. Where's the CEO? (you, Claudia, and the company)
There is a CEO, and it is neither
you nor Claudia. The company you carried over from the last course has its own CEO, and the structure is three layers:
You are the board (you approved this CEO last course). Claudia is your delegate, a separate layer above the company, who clears your routine board decisions and carries your intent down to the CEO. The company's CEO runs the workforce day to day. No single agent holds two of these seats, and that separation is the whole point.
Carry-forward into Scenario 2
Claudia's heartbeat is running and she is reading your real queue, but she still cannot act: she has no identity the company will accept, and no agreed limit on what she may decide alone, so every wake just logs and posts nothing. Scenario 2 gives her both, and her very next wake clears one for real.
Scenario 2: A signed, bounded mandate (~15 min)
Right now Claudia can think like you, but she cannot act . In Act 1 she only reasoned out loud. This step lets her clear one real approval in your name, safely. To do that, you give her the same two things you would give any trusted employee before letting them sign off on money:
A signature only she can make. So that anyone can later prove a decision was genuinely hers and nobody forged it in her name. Think of a signet ring, or a notarized signature: unique to her, impossible to fake.
A spending limit. A clear, deliberately narrow cap on what she may approve on her own. Inside the limit she acts; anything bigger comes to you. Think of the limit you set on an employee's company card.
That is the whole idea: a signature and a limit. Together they are the rails her loop runs inside. She does not decide whether to stay in bounds each time she wakes; the limit is wired into the act of posting
itself, so a decision outside it cannot go through even if she tried. Everything technical underneath (the cryptography, the safety checks, the audit record) is your coding agent's job. You set the limit and watch.
One rule is worth holding onto:
note
Her limit can only
ever be narrower than your own authority, never wider. You cannot accidentally hand her more power than you have: her circle always sits inside yours. Widen it later and it still stays inside yours.
You do this in two prompts: first set up her signature and her limit and review them, then let her loop wake and clear one for real while you watch.
First prompt: give her a signature and a limit, and review before anything goes live.
Set Claudia up to act for me, but show me everything before you switch it on. Give her a signature only she holds. Set a deliberately conservative limit: she can approve refunds up to $2,000 and budget overruns up to 20% on her own; anything bigger, plus every hire, firing, or policy change, always comes to me. Show me that limit and her signature's fingerprint, and wait for my okay before anything goes live. Never show me or save her secret key.
Your coding agent sets it up and shows you the limit and the fingerprint. This is your call: the numbers are starting points, so tighten or loosen them. Approve, and her limit goes live. From this point on, her heartbeat acts for real, inside that limit.
Second prompt: watch her loop clear its first one on its own, and watch the limit refuse one it should not touch.
You do not tell her to go. Her heartbeat is already running. You can either wait for the next beat or nudge one wake so you can watch it happen now.
Trigger one of Claudia's heartbeat wakes now so I can watch it live, and walk me through what she does in plain language: which routine refund she clears on her own, why, the safety checks it passes, the moment it posts to the company, and the record it leaves behind. Then, to prove the limit is real, put a refund well over her ceiling into the queue and let her next wake reach it; show me her loop refusing to post it and logging why, instead of squeaking it through.
Done when: on one heartbeat wake, with no instruction from you per item, Claudia clears one routine refund, signed, and the company queue shows it approved; on the same or the next wake, a deliberately over-limit refund is refused by her loop (it does not post, and the refusal is logged); and you can see three things: her signature's
fingerprint (never the secret key), the conservative limit she is bound by, and the cleared decision recorded in two places, the company's own log and Claudia's separate ledger. Why two is the subject of Scenario 4.
The signing, in plain words (your coding agent writes the cryptography; you just need the shape)
You do not need to be a cryptographer, and your coding agent writes all of this. The shape is what matters. Claudia holds a private key (a secret, on your disk) and the company holds the matching public key . When she decides, she produces a short signature over the exact decision. Anyone with the public key can check that signature and know two things for certain: it came from Claudia's key, and not one character of the decision was changed after she signed it. The signature is computed over the decision's exact bytes , so your coding agent sorts and normalizes the data the same way on both sides before signing. The standard tool for this ( ed25519 ) ships in ordinary libraries; the brief tells your agent how to wire it.
The three checks before any decision posts, and the one counterintuitive part
Every time Claudia's loop tries to post a decision, on every wake, with no human watching, her delegation layer runs three gates first, in order. This is what makes the limit a hard backstop and not a polite suggestion: it is enforced in the posting step itself, independent of what she decided.
Is this really Claudia, and is she still trusted? Her registration exists and has not been revoked. This one runs first on purpose: an unregistered key is rejected right here, before the layer spends any effort verifying a signature, so a flood of forged requests can never make it do expensive cryptography.
Does her signature verify? The decision came from her key and was not tampered with. This is your own check; the company has no signature field of its own, so this gate lives in the layer you build.
Is this action inside her envelope? The amount and type sit within what you delegated. A failed gate refuses the decision and still writes a ledger row, because a forged or stale-key attempt has to be auditable too.
The counterintuitive part. The company's approval routes are governed at the board level: only a board-level credential can drive an approve or reject. So the credential Claudia actually uses to clear an approval is a board credential, scoped down by your own delegation layer, which is precisely what makes it delegation. This is also why Claudia is not registered as one of your company's agents: a company-agent credential cannot approve anything (the routes reject it), so registering her would buy nothing. There is just one Claudia, the delegate above the company, and her identity is her own signature and ledger, not a nameplate inside the company. On the local sandbox this is handled for you on the loopback; the distinction only bites if you point the lab at your own deployed company, and the brief covers that path.
What "approve" does and does not do
Approving an approval records a decision . It does not, by itself, move the linked issue forward or wake a Worker to act on it; that is a separate, explicit step, exactly as the earlier courses taught. Claudia's job ends at "the decision is recorded and the ledger row is written." This matters because it keeps her role clean: she governs the decision, she does not silently reach into the work.
Carry-forward into Scenario 3
Claudia's loop now clears one approval for real on its own, signed and bounded, and refuses what is out of bounds. Scenario 3 turns the volume up to a realistic week, you do nothing, and adds the rest of her job: carrying your intent down to the company, and briefing you back with a one-line summary on every wake, not just judging what comes up.
Scenario 3: A week of approvals while you do nothing (~12 min)
This is the payoff the whole course was built for, and the instruction is unusual: you do nothing. One approval proved the wiring. Now a real week of work hits the queue, and you go on with your life. The company is busy: its own CEO is proposing hires to fill gaps, Workers are running into refund decisions and budget overruns. The pile builds whether you are watching or not. The only thing that changes is that Claudia's heartbeat is quietly working it down.
There is one thing you do say first, because a chief of staff works both ways:
note
Your chief of staff works in two directions. You tell her what you want, and she turns it into work for the company (command). The company's decisions come back up, and her loop clears the routine ones and surfaces the rest (govern). The first direction is a single sentence from you. Almost all of the machinery you built exists to make the second one safe , because acting in your name, on her own clock, is where the risk is.
Paste this to your coding agent:
Set up a real week and then leave Claudia to it. First the command direction: tell Claudia "we're getting Spanish-language tickets, staff for it," and have her file that as a hire request on my company on my behalf. Then make the company generate a realistic week of work: the CEO proposing a couple of hires, plus a dozen-odd routine refunds and small budget overruns that sit inside her limit, and a few refunds that don't (over-limit or out-of-band). Don't have anyone clear any of it by hand. Just let Claudia's heartbeat run across the week. Every time she wakes she should do two things: clear and surface the queue as usual, and then text me a one-line brief on my chat app: how many she cleared and for how much, which ones need me and why, and the company in a sentence. Show me one of those briefs.
You did not touch the queue. Her heartbeat did. Two things now land on your phone. The first is the handful of calls outside her limit (the over-limit refunds, the authority-extending hire, which her loop refuses to clear by definition), each surfaced with her reasoning. The second is the part that makes her feel like a real chief of staff: a single plain-language line at the end of the pass, something like "cleared 8 routine ($372), 2 need you: a $2,500 refund on a 95-day account and a Spanish-language hire, company looks healthy." You did nothing all week, and you still know
exactly where the company stands in one sentence. The most interesting surfaced item is the Spanish-language hire: it breaks no rule and she surfaces it anyway. That is the whole reason she applies judgment and not just rules.
Done when: across the week, with you doing nothing, Claudia's loop clears the routine band on its own (roughly eight in-limit refunds and small overruns), signed, each with a ledger row; roughly half a dozen land on your phone with her reasoning attached (the over-limit refunds, the authority-extending hire, and the Spanish-language hire); a one-line brief lands on your phone after the pass: what she cleared and for how much, what needs you, the company in a sentence ; and you can say in a sentence why the Spanish hire was surfaced even though it broke no rule. Why she surfaced a hire that passed every rule
The Spanish-language hire fits inside the existing authority envelope, passes its checks, and sits under budget. A rule would wave it through. Claudia surfaces it anyway, because a first hire in a new language is not extra capacity, it is a strategic step into a new market: it may mean translated terms of service, a commitment to bilingual support, a direction you want to decide yourself. A policy cannot see that. A delegate who has learned that you treat market-expansion moves as yours to make, can. This is the rule-versus-judgment line from Scenario 1, now doing real work: the policy handles the routine ninety percent at zero cost to your attention, and your chief of staff catches the ten percent where a human-trained pattern matters.
Carry-forward into Scenario 4
Claudia just made a couple dozen decisions in your name. Scenario 4 is the question that makes that safe to live with: months from now, can you tell which decisions were hers and which were yours?
Scenario 4: Tell her decisions from yours (~10 min)
Claudia's loop just made a couple dozen calls in your name while you did nothing. Here is the question that should make you slightly nervous, and the nervousness is healthy: months from now, could you tell which of those calls were hers and which were yours? If you cannot, you have not delegated, you have lost track. This scenario proves you always can.
Here is the catch, and the fix, in plain terms:
note
When Claudia approves something and when you approve something, the company's records look identical . Both just say "approved by the board," because she acts with your authority, the same stamp you use, so the company alone can never tell you apart. The fix: Claudia keeps her own signed ledger , a logbook of her decisions. Every time she decides, she writes a line that says "I did this, and here is why," signed so it cannot
be faked. You write no such line. Lay the company's records next to her ledger, match them by the approval they share, and the full story is there: the company says what was approved, her ledger says which ones were hers .
Paste this to your coding agent:
So I have one to compare against, let me clear one approval directly myself the way I sometimes will. Then show me, side by side, that one approval and one Claudia's loop cleared on its own this week: I want to see they look identical in the company's records, and that only her own signed ledger tells them apart. Then have Claudia send me a one-screen summary of everything she handled this week.
Done when: with your own eyes, a Claudia-cleared approval and one you cleared look the same in the company's records, and the only thing separating them is the signed line in her ledger (her name, her reasoning). And you have a one-screen weekly summary on your chat app. Why the company cannot tell them apart, and why that is fine
The company's approval routes are governed at the board level. Whether you click approve in the dashboard or Claudia posts a signed decision through her board-scoped credential, the company writes the same kind of log row: the board acted. The company does not natively record "an AI delegate did this." That is not a gap to paper over; it is exactly why Claudia keeps her own ledger. Her ledger is the one place the owner-versus-delegate distinction is recorded, along with the reasoning and the signature that proves the decision was hers and untampered. The two records live in two separate stores and are matched on the approval they share, not joined in a single query. Together they are the complete, honest audit story: the company says what was decided, Claudia's ledger says who decided it and why.
What the weekly summary looks like
You do not read the ledger row by row. Claudia turns a week of it into a digest, roughly:
This week: 142 decisions handled. 134 I cleared on my own (94%). 8 I surfaced to you. You overrode 1 of mine.
Your override: a $1,847 refund to a customer with prior refunds. Your note: "should have surfaced, multiple priors." I have updated: for customers with two or more prior refunds in six months, I will surface regardless of amount.
Worth a glance: two refunds I approved at lower confidence than usual; both involved patterns I have not seen often. Rows noted if you want to spot-check.
That is the form you actually consume: the totals, the exceptions, the corrections, and the few low-confidence calls she wants your eyes on. Reading it weekly is what keeps you in the loop at the right altitude, the patterns and the exceptions, not every individual row.
Carry-forward into Scenario 5
You can now see exactly what Claudia did. Scenario 5 is what to do when you see something you disagree with.
Scenario 5: Override her, and watch her learn (~8 min)
Sooner or later Claudia will make a call you would not have. Your instinct will be to treat that as a failure to stamp out. It is the opposite.
Here is the idea:
note
Disagreement is not a malfunction. It is the signal that shows exactly where Claudia's judgment ends and yours begins. You reverse the call, she records your reason as training, and the next time her heartbeat meets a case of that shape, she surfaces it to you instead of clearing it. You are never locked out: the override is always yours to make, and the company stays yours.
Paste this to your coding agent:
Pick one of the refunds Claudia's loop auto-cleared this week and have me reverse it, the way I would if I disagreed. Record my override and my reason against her original ledger row, and update what she's learned so that the case becomes one she'll surface, not clear. Then prove it took: put a similar refund into the queue and let her next heartbeat reach it, and show me she now surfaces that one to me instead of clearing it. Last, tell me from this week's numbers whether her overall behavior looks healthy.
Done when: your override lands on Claudia's original ledger row with your reason attached; on a later heartbeat, a similar refund is surfaced to you instead of auto-cleared, proving the correction became a standing change and not a one-off fix; and you can name the healthy shape in a sentence: most decisions handled on her own, a small fraction surfaced, overrides rare enough that each one gets read closely. Why disagreement is the system working, not failing
Three reasons an override is a good sign, not a bad one:
No learned pattern is right on the first try. Claudia's inferred patterns are approximations; the only way to find where one fails is to watch it fail. If you two never disagree, her patterns have not been tested yet.
Your judgment moves. You in month one and you in month six are not the same operator; the market shifts, the company grows. An override is the signal that your thinking has moved and she needs to catch up.
The correction carries your reasoning. "Should have surfaced, this customer has priors" is not just a reversal; it is a rule she can apply to similar-but-not-identical cases later. The override is training data.
The shapes that are actually warning signs
A healthy steady state looks roughly like most decisions handled autonomously, a small fraction surfaced, and overrides rare. Treat those as orientation, not a target to optimize; the real numbers depend on your business and your risk tolerance. Three patterns are worth worrying about:
You are overriding her constantly (a fifth of her calls or more): her envelope is too wide or her patterns are miscalibrated. Tighten the envelope.
You have stopped reading the weekly summary: you have quietly slid back into rubber-stamping everything, which is the very thing this course exists to prevent. Re-engage before you change anything else.
She surfaces almost everything to you: she is too cautious, and the whole point (freeing your attention) is lost. Loosen her envelope or her confidence threshold.
Carry-forward into Scenario 6
Claudia is now a trustworthy, self-correcting chief of staff. One question remains before you would ever run this for real: what happens the day your laptop, the machine she lives on, is lost or stolen?
Scenario 6: Lose the laptop, keep the company (~10 min)
Claudia holds a key that can act in your name. That is what makes her useful, and on the worst day, a lost or stolen laptop, it is also the danger. An architecture with no answer for that day is not one you would trust with your company, so you rehearse the recovery now, before you ever need it.
On that worst day, two things have to be true, and you test both:
You can shut her off instantly, and only you can. From any other device, using your own login (never her signature), you do two things: stop her loop (shut down her gateway / turn off her heartbeat so she stops waking and acting) and rotate the company credential she posts through, so even a copy of her can no longer act in your name. A stolen or tampered Claudia must never be able to keep her loop running or quietly post again. Think of cancelling a company card: only the owner can cancel it, and the card cannot cancel itself.
You do not lose what she learned. Everything she knows about you lives in plain files on your disk, which you back up. So you bring her up on a fresh laptop and she is the same Claudia, with all her judgment intact, and her heartbeat resumes. Only her keys are reissued: her "brain" is your files, her "badge" is reprinted.
Paste this to your coding agent:
Walk me through two recovery situations in plain language. First, pretend this laptop was just stolen while Claudia's loop is still running: from another device, using my own login, shut her off. Stop her loop (shut down her gateway / turn off her heartbeat) and rotate the company credential she posts through. Show me three things: an attempt to shut her off using her own signature is refused, her old credential is now dead, and even if her loop somehow woke it can no longer post anything. Second, a planned move: stop her loop safely and bring her up on a fresh machine with her persona, her learned judgment, and her ledger intact, reissuing only her keys and restarting her heartbeat. For each, tell me what survived, what did not, and what only I could do.
Done when: her loop is stopped and the credential she posted through is rotated so the "stolen" copy can no longer act, an attempt to shut her off with her own signature was correctly refused, and even a still-running copy of her loop can post nothing; a fresh Claudia comes up on a clean machine with the same persona, the same limit, her ledger continuous, and her heartbeat running again; and you can say in one sentence why only you, never Claudia, can do the shutting-off. The stolen-laptop cases, worst to best
How bad a stolen laptop is depends entirely on the state it was in:
Powered off, disk encrypted: the thief has a brick. The key is unreadable. Replace the laptop, restore from backup, reissue credentials.
On but locked: the disk is decrypted but the thief cannot drive Claudia. Some risk if they can reach the filesystem directly; storing the key in your operating system's keychain raises that bar.
On and unlocked, with your session live: the worst case. The thief can act as Claudia up to her delegated envelope. This is the case the off-switch exists for: from any other device, with your own credentials, you stop her loop and rotate the company credential she posts through, so a copy of her can no longer act in your name. Her envelope being deliberately narrow is also what caps the damage in the window before you do.
The mitigation that matters is the same in every case: stopping her loop and rotating her credential is a move only you can make, and her learned judgment lives in a backup you control, so you are never both locked out and wiped out.
One honest limit: living on more than one machine
Claudia lives on one machine at a time by default, and that single-machine story is the one that is fully solved: her judgment is in files you own, you can read, back up, move, or destroy them, and no platform can hold them hostage. Spreading her cleanly across several of your devices at once (your laptop, your home machine, your phone) is genuinely harder. As of 2026 you choose among three patterns, none of them free: keep her on one machine (fully sovereign, but tied to it); run your own small sync server (still sovereign, since you own the server, at the cost of running it); or sync through an outside service with the data encrypted under a key only you hold (sovereign only as far as the encryption holds). The no-tradeoff version is still open work. The course teaches the part that is solid and is honest that the multi-device, many-years version is not finished. Reaching Claudia from anywhere (any of your chat apps) is easy and works today; that is a different thing from her living in several places at once.
You have now built the whole thing
A chief of staff who reasons like you, acts within a signed and bounded mandate, wakes on her own heartbeat and clears a week of approvals while you do nothing, keeps an audit trail that always separates her calls from yours, learns from your overrides, and survives a stolen laptop. The rest of the page is what you carry away, and where this leads.
What you built, and what you carry away
You did not just clear a backlog. First you built your Identic AI, a twin who decides the way you do, then you turned on her loop and stepped out. You took the one job that does not scale, your own attention, and handed it to a delegate who runs on her own clock and does the work the way you would, while you kept your hand on the only lever that matters. You watched her reason like you before she touched a company at all. You gave her a signed identity and a deliberately narrow mandate, and started her heartbeat. You watched her loop clear a week of routine while you did nothing and surface the handful of calls that were really yours. You proved you can always tell her decisions from your own, you corrected her and watched her next wake honor the correction, and you proved you can take it all back from another device if you ever have to.
That is the full chief-of-staff picture, and it is worth saying plainly. Claudia runs herself on a heartbeat, governs the routine in your name inside the limit you set, and on every wake briefs you: one line on your phone telling you what she cleared, what needs you, and how the company looks. You are not in the queue anymore. You are the owner at the right altitude, reading a sentence a day instead of a hundred approvals, stepping in only on the calls that were always yours to make.
Now zoom out on Claudia herself. If you sold this company tomorrow and started another, what would you take with you? A chief of staff turns out to be two things, and only one of them travels. What travels with you What stays with the company how you communicate and decide, your style and standing instructions the specific approvals she resolved here the patterns she learned about your judgment her ledger of decisions at this company the recipe for the delegate herself, her skills and setup the credentials scoped to this company
Your accumulated judgment is portable because it lives in files on your own disk, not on a platform that could hold it hostage. The company's records stay with the company, where they belong. That split is the whole reason the architecture is yours and not rented: your chief of staff survives a change of company, a change of laptop, even a change of the underlying tool, because the part that is you was never anywhere you could lose it.
The discipline underneath all of it fits in one sentence: you delegate the work, never the authority, and you keep a ledger honest enough to prove which decisions were yours. You stay the owner not by reading every approval, but by deciding who may decide what, and by staying close enough to the summary that nothing drifts.
The one habit that keeps it working: once a week, read Claudia's digest. Ten minutes. Correct anything you would have done differently; she learns from it. The single most common way people misuse a setup like this is to stop reading the summary, which quietly turns it back into rubber-stamping. The architecture keeps you safe only as long as you stay in the loop at that altitude. Where your half of this lives on your machine (reference)
You never touch these by hand; your coding agent does. But because this is your data, it is worth knowing where it sits: What Where Claudia's accumulated context: persona, history, learned patterns your OpenClaw workspace, in files you own Her signing key a protected file on your disk, or your operating system's keychain (never in git, never printed) Her delegated envelope, the limits you set a plain editable file you can read and adjust Her governance ledger, every decision she made for you a local logbook file on your own disk by default (a hosted database is an optional upgrade)
All of it is yours to read, back up, move, or delete. That is what "self-sovereign" means in practice.
What comes next: the edge
You have closed the last open gap in the architecture you have been building across the earlier courses. Using the canonical naming, the whole thesis is now operationalized, each invariant by a course that built it for real: Invariant What it requires Built in 1. The human is the principal intent, budget, authority, accountability across the whole track 2. Every human needs a delegate a personal agent that holds your context, judgment, and authority this course 3. The workforce needs a management layer hire, assign, govern, observe, retire the workforce course (Paperclip) 4. Each Worker picks its own engine the right runtime for each job the agent-building course 5. Every Worker runs against a system of record an authoritative store, reached cleanly the system-of-record course 6. The workforce is expandable under policy hiring as a callable capability the self-expanding-workforce course 7. The workforce runs on a nervous system events, durability, flow control the nervous-system course (Inngest)
That is the architecture. What is left is the edge, and it is genuinely the frontier, not more curriculum.
The honest open problems. Your chief of staff handles the routine well because she has learned your patterns . Patterns are not the same as your values , the structure underneath the patterns, and where a pattern breaks (a long-tenure customer attempts a fraudulent refund; the pattern says approve, your value says verify first), pattern-matching alone is not enough. Teaching a delegate your values, not just your habits, is active research, not a settled technique. So is letting her live cleanly across many of your devices for years. The architecture you built scales your company by a large factor, not infinitely; somewhere far out, the residual hard cases need value-alignment work that has not shipped. The course is honest that the ceiling is out there.
The bigger shape. What you built is one node of something larger. Tapscott's picture is a network of these delegates: one on the owner's side at every company, one for every employee, one for every customer, meeting each other under signed credentials, with humans stepping in only on the consequential and the strategic. A customer's own chief of staff could one day message your company's workforce directly to sort out a contract clause, the same signing-and-verifying primitives you built here, now stretched across a boundary where the two sides do not already trust each other. That cross-party trust is the missing piece, and it is the next frontier this work opens.
Where to go next: You want... Go to The discipline that makes every Worker and every delegated decision measurably trustworthy Eval-Driven Development , the course that closes the track The gentlest hands-on on-ramp to OpenClaw itself OpenClaw with General Agents The company side you are governing: stand it up and grow it building a workforce and letting it grow itself The deeper treatment of the personal AI employee Chapter 56: Meet Your Personal AI Employee
The architecture is complete after this course; the curriculum is complete after the eval-driven-development course, which wraps the whole thing in the eval discipline that turns "built and running" into "provably trustworthy."
References and further reading
Tapscott, Don (2026). You to the Power of Two: Redefining Human Potential in the Age of Identic AI. The source of the "Identic AI" framing this course borrows.
HBR IdeaCast, "With the Rise of Agents, We Are Entering the World of Identic AI" (February 2026). Don Tapscott interviewed by Adi Ignatius.
OpenClaw: openclaw.ai , docs.openclaw.ai , github.com/openclaw/openclaw
Paperclip: docs.paperclip.ing
Agentic Engineer thesis : the seven invariants this track operationalizes.
Test Your Understanding
A gated self-check on the ideas you just ran through: the owner bottleneck, the delegate, the signed envelope, and the audit truth.
Checking access...