I do not hire a chief of staff. I built one. Copy the patterns, not the products.
This page is different from the rest of the library. The playbooks tell you what I would do in your company. This one shows you what I actually run in mine, mechanism by mechanism, so you can judge whether the advice survives contact with reality. It is also the fastest-aging page on this site, which is why it carries a date.
The through-line: hiring a chief of staff is a large bet on a person who does not scale. Building one is a recurring software cost that does, and every mechanism below is a piece of it.
At 7am on weekdays, an agent sweeps my inbox over the Microsoft Graph API. Receipts and routine notifications get filed by a plain script with no AI in it at all, because deterministic work belongs in deterministic code. The threads that need me get triaged, and the ones that need replies get full drafts written in my voice, sitting in my drafts folder.
The rule that makes this safe enough to run unattended: the system drafts and never sends. Not as a preference, as an architecture. There is no path in the automation that transmits an email without me clicking send. I read the brief over coffee, edit two drafts, send five, and start the day at inbox zero. The first edition of this page described the same pattern on my old mail stack; the pattern survived the migration to Microsoft 365 untouched, which is the point of patterns.
Every call is recorded and transcribed, no exceptions. The tool matters less than what happens next, which is where most companies get this wrong. Transcripts do not flow straight into a knowledge base. They land in a review queue: the system proposes what the meeting was, who spoke, which engagement it belongs to, and what should be extracted, and a human approves or corrects the card before anything is filed permanently. Resolve first, extract second, analyze third. When the system is not sure who "Mike" is, it asks instead of guessing, and once answered, it never asks again.
Only after that gate does a meeting become memory, and it lands in three places at once, which is the architecture the next section describes. A recap email is drafted within minutes of a call ending. The client thinks I am very organized. I am not. The system is.
The first edition described my memory layer as a single product. My thinking has moved, and this is the biggest revision on this page. What I actually run today is a structure, not a product: written files and journals, a shared memory layer, and a retrieval layer. Three angles on one brain, each doing the job it is best at.
Every project in the company has a memory directory in its repository: a brief that says where things stand right now, and a dated journal of what happened and what was decided. A nightly job consolidates the journals into the briefs. Any AI session, any tool, any machine starts by reading the brief and ends by writing the journal. The system does not remember everything. It writes everything down, and version control is the audit trail.
Alongside the files, a shared memory service holds atomic facts, decisions, and preferences that cut across projects, readable by every AI tool I use. Switching tools does not mean starting over, and that portability is leverage over every vendor I buy from.
The document corpus itself (transcripts, contracts, analyses) sits behind retrieval, so questions get answered with citations back to the source instead of from a model's impression of the source.
One rule governs all three: one fact, one home. The lesson I would give any CEO: your memory should be boring, inspectable, and yours. Files beat databases you cannot read, and a fact you cannot trace to its source is not institutional memory; it is a rumor with confidence.
I run the company from an agentic coding environment most of the day. The first edition described a two-window pattern: one AI as architect, one as builder, me as the protocol between them. The pattern held; the shape matured. Today it is one orchestrating session that plans and judges, delegating legwork to subordinate agents in parallel, with the expensive reasoning reserved for the decisions that deserve it. Same idea, better plumbing: the human sets direction and quality bars, the machines fan out.
For starting something new, the on-ramp question matters less than it used to. Perplexity still has a place as the simplest starting point: quick connectors, fast to make something function, right for beginners and for quick thesis tests. It is becoming less necessary as chat-native agent tools fill that role, but rung one is still whatever gets a working prototype in front of you fastest, and the prototype's only job is to argue for itself.
Let me also say plainly what all this building is not, because the word misleads. We do not train models. We do not run our own platforms. We do not write our own harnesses. Everything I run is proven platforms, integrated and modified to function the way we need: plumbing, not manufacturing. You are customizing a car, not building one. The distinction matters because the failure mode on each side is different: people who think they are building overinvest in infrastructure; people who think they are renting underinvest in integration, and integration is where all the value is.
And the rule that governs autonomy: agents earn the right to run alone the way a junior teammate does, by getting it right while I was watching. New workflows run attended, with me reviewing each move. Only after repeated clean runs does a workflow graduate to unattended, and if I cannot describe in advance what done looks like, it stays attended. The trap is running unattended on work you have never run attended.
No agent ever sees the whole vault. Secrets live in vertical stores, one domain each: mail, cloud, billing, code. Each agent has its own machine identity scoped to exactly the vaults it needs, so identity is the unit of audit and the blast radius of any single failure is one domain, not the company. Rotation is a scheduled job; the audit is calendar-locked. Boring, architectural, and the reason the rest of this page is safe to run.
I stopped counting precisely somewhere past a hundred scheduled jobs, pipelines, and agents; the exact figure changes monthly and matters less than the shape, which has not changed all year. Most net-new client work now ships without anyone opening a traditional development environment. The practical effect is the output of a small team from one operator, and the whole stack (model subscriptions, memory, storage, transcription, and the plumbing) runs low four figures a month all-in: a fraction of one junior hire.
Five honest revisions, because a field note that never changes its mind is marketing.
Start with the morning brief on one inbox, drafts only, approval always. It is the highest-leverage single agent I run, it touches nothing irreversibly, and it teaches you the supervision habits everything else depends on.
The fastest path is the one I take with clients: build the map (that is Phase Zero) if you need it, then the first agent on a workflow that already works. If you already have the map, we start at the agent: that is a Pilot Build.
See how BuildClub works Start with Phase Zero