Home / Company brain / Claude as an AI chief of staff
Concept

Claude as an AI chief of staff: setting it up in a biotech

The setup question that matters is not which prompt. It is which surface, because two of them run the same engine and only one can enforce a rule. The packaged version answers this for you and ships as an app.

If you have decided you want a chief of staff that lives in your files rather than in a chat window, the first fork is a product decision inside Claude itself, and Anthropic's own documentation is unusually clear about it. Cowork, in the Claude desktop app, uses the same agentic architecture that powers Claude Code, without opening a terminal. Same engine. What differs is containment, what it can load, and what it can enforce.

 CoworkCode
Where it runsA contained space on your computer, limited to the folders you shareDirectly in your project, with access to your file system and terminal
ExtensionsConnectors, Skills, Claude in Chrome, PluginsThe same, plus Hooks
Local setupLoads what is enabled for your claude.ai account; does not read the Claude Code CLI's local directoryReads the local setup on the machine
Sub-agentsYesYes

Two rows in that table decide the whole build. Cowork does not read the Claude Code command line tool's local configuration directory, so anything installed there has to be re-added through the account's own customization surface before Cowork can see it. And hooks exist only on Code. If your idea of a safe install includes rules that fire whether or not the model feels like following them, that machinery has no equivalent on the other surface. That fork matters if you are assembling this yourself. If you are not, the packaged version settles it for you: it ships as an app, built on the surface that can enforce. The fuller comparison, and what it costs either way, is Claude for biotech: the AI that runs locally.

What the setup actually consists of

Less than people expect, and none of it is a chatbot personality. There are four pieces.

There is no migration. Nothing is imported. The system reads the last few months of mail and builds the records from what it finds, which is why it is useful in the first week rather than after a quarter of being fed. It is also why the install is one seat: one owner, one mail identity, one set of files.

Putting the four pieces in place takes about half an hour of actual work. It is an app you install yourself, and the instructions are written to be followed by the person who will use it. If you would rather not, it can be done with you instead. It is in limited early access, so getting a copy starts with a conversation.

What to point it at first in a biotech

Pick the thing that keeps falling through, not the thing that would demo best. In practice that is usually one of three.

The external timeline that determines your filing date. A tox study at one contract research organization, an analytical method transfer at another, a manufacturing slot at a third, each communicating a slip by email to one person on a Friday. Pointing the system at that one chain means a date that moves in a vendor's message moves in your record, and the downstream items move with it rather than three weeks later when somebody notices.

The partnering conversation. A diligence request list with a deadline, a data room with a gap the other side found first, a term sheet on its second redline, and a counterparty who has gone quiet for eleven days. That work is treated as a tooling decision in build or buy deal tracking software, but as a first install it is simply the folder where the most promises live.

The agreement with obligations in it. Notice periods, milestone triggers, cost-share splits, reporting duties. These are the items that are cheapest to catch and most expensive to miss, and they are sitting in a signed PDF nobody has opened since the signature page.

What has to be true for this to work. You can grant the machine access to your own mail without a committee. Nothing in scope touches patient data. You are the person who decides, rather than a procurement process. And the pain you are solving is threads and promises, not analysis. If two of those are false, the honest answer is that the install will stall, and it is better to find that out in a conversation than after one.

What this setup assumes that a generic one does not

The four pieces above are the same wherever this pattern is run: files, a standing instruction, connectors, a scheduled pass. What changes in a drug development company is the assumption underneath them. Most of your state arrives from organizations outside your building, on their schedule, in prose, and the cost of missing one is measured in months of program time rather than in a missed meeting. That is why the routing rules matter more than the wording, and why the first thing you point it at is an external chain rather than your own task list.

If you have not settled the underlying question of what you are building, start at what an AI company brain is and the role framing at an AI chief of staff for a biotech founder. If the open question is whether to build any of it in-house, that is Claude Code for biotech vs off-the-shelf AI tools.

WEIGHING COWORK AGAINST CODE WITH NOTHING BUILT YET?

Four pieces, already in place

There is a built install behind this, and the demo walks through it: plain-file folders per program and partner, the standing instruction, the mail and calendar connectors, and the overnight pass that moves a vendor's slipped date through the record. Take the walkthrough and the surface question settles itself.

See the demo