How to build an AI chief of staff: a working setup for a biotech

Nothing here is trained, and none of it is a chatbot personality. The build is a record, a set of standing rules, read access to your mail, and a pass that runs whether or not you remember to run it.

The pieces are ordinary: a folder of plain files, an agent with standing rules over them, connectors to the mail and calendar you already use, and a scheduled pass. Those four are explained on Claude as an AI chief of staff, set up in a biotech, along with the platform fork that decides which surface can enforce a rule. This page is the order you build them in, and the decisions hiding inside each step, because the order is where most attempts go wrong.

Start with the record, not the model

Choose the shape of the record first, not a tool, because everything after it is routing into that shape. One folder per thing that has a deadline and a counterparty: a program, a deal, a partner, a signed agreement. Not one folder per department, which is how filing cabinets are organised, not how work arrives.

Each folder carries a single index file holding the current status, the decisions with their dates, the open questions and the next actions. That file is the one true status, and every other view reads from it, the only reliable way to stop two numbers about the same program drifting apart. Keep it in plain text on your own machine, under version control, so a day of automatic edits can be undone in one move.

There is no migration step. You point the indexing pass at what you already have and let it propose where each item belongs. In the one unaided external install on record, that pass ran over a genuinely disorganised documents folder and categorised it with a couple of corrections, so tidying up first is not a prerequisite.

Write the standing rules before you write any prompt

The piece people mistake for a prompt is a standing instruction file that holds on every session: where records live, what may be done without asking, what must never be done, and how to route what arrives. The difference between that and a clever request is the subject of the Claude chief of staff prompt. Three rules earn their place first.

• Drafts, never sends. Every outbound step is written in full and staged for you: it takes the reversible action and stops at the decision.
• Routing, including what to do when routing is ambiguous. Most of the value is in which folder an arriving item lands in, and the rule that matters covers the item that could belong to two: ask rather than guess.
• Nothing stated as settled without a source. Then a second pass, with no memory of the first, re-reads the answer against the file it cited and downgrades anything that overclaims. Running that check as a separate process with its own context is the subject of the Claude chief of staff agent.

Connect the mail and calendar, and expect a permission wall

Read access is what makes the record write itself. Without it you are pasting, and a system you have to feed is one you will stop feeding by the third week. Connect the sent folder as well as the inbox: a note you fire off on a Tuesday makes a promise, names a date, and creates someone who owes you a reply, and all three belong in the record without you typing them.

Budget for a permission problem. In the one unaided external install on record, the machine had more than one user account and the desktop mail application's permissions could not be granted at all. The working route was to drop that mail app and connect Gmail and Google Calendar instead, which worked. Treat the mail connector as an option chosen at install, and test it on the real machine first.

The scheduled pass, where it stops being a chat window

A pass is a standing job rather than a conversation. It reads what arrived since the last one, files each item to its folder, closes what that item resolved, opens what it created, moves the dates that moved, and writes the next step as a full draft rather than a stub. Then it re-checks its own output before you see any of it.

Be honest about cadence. The realistic ceiling is hourly, and scheduled runs need a scheduler plus a machine that is awake. Without both, every pass is a command you run yourself, which works, but it is you pressing the key rather than the record maintaining itself overnight. Building it yourself takes months and then keeps taking them; the app installs in about 30 minutes, yourself or done with you, and it is in limited early access, so getting a copy starts with a conversation.

Prove it on one chain before you widen it

A build is finished when it survives a real message, not when the folders exist. In a drug development company the chain worth testing first is an external one, because the state that decides your filing date is produced by organisations that are not yours. A revised date from a vendor arrives on a Friday afternoon, buried in a thread about invoices. Watch three things: whether your routing rule puts that message in the program folder, whether the pass moves the date and flags the downstream items that assumed the old one, and whether the draft reply is one you would actually send. When one of the three misses, the fix is a line in the standing instruction rather than a different tool, and that is the loop you repeat until the record keeps itself.

What you are building is deliberately narrow, and it is cheaper to know that now: it is not a lab notebook, not a validated system for regulated documents, it does not do discovery science, and nothing in scope goes near patient data. It is one seat, one owner and one mail identity, so it never assigns work to a colleague and never notifies anyone on your behalf; someone else's commitment is held as your own follow-up to check. If what you need is a shared plan for a team, start with the category comparison in chief of staff AI tools. If you want the role framing before the build, that is an AI chief of staff for a biotech founder, and the definition underneath all of it is what an AI company brain is.