An AI coworker in Claude for a biotech team
The word implies something shared, sitting between people. What actually installs is one per person, and that difference is worth understanding before you plan a rollout around it.
"Coworker" is a better word than "assistant" for what this is, because it names the working relationship rather than the hierarchy: something that holds the context, does the unglamorous half, and hands back the decisions. It is a misleading word in one specific way, and it is the way that matters when a team of four is deciding what to do.
The structural fact: one seat, one mail identity
This installs for one person. One set of files, one owner, one mail identity, one calendar. That is not a licensing decision, it is what the thing is: the record writes itself because it reads the mail and meetings of a particular person, and that person's inbox is the natural edge of what it can see. A team of four is served today by four installs, not by one shared brain that everybody logs into.
Everything follows from that. Nobody's system assigns a task to anybody else. A commitment your colleague made shows up in your record as something you are waiting on, phrased as your own follow-up, because that is the only honest way a system with one mail identity can represent it. There is no shared queue and no notification going out to a colleague, because nothing outbound leaves without the seat holder saying yes.
What a team of four actually gets
| Seat | What their record holds | What they see of the others |
|---|---|---|
| Founder | Board commitments, investor threads, the whole-company picture | Only what reached their own mail or a meeting they were in |
| Business development | Deals, diligence lists, partner history, conference schedules | The same |
| Program management | Timeline, vendor deliverables, risks, stage gates | The same |
| Alliance | Obligations register, governance decisions, cost share | The same |
Read that right-hand column carefully, because it is the seam. Four seats give you four current records and no automatic reconciliation between them. The specific way that bites in drug development is worth spelling out. The program lead hears on a study call that the GLP tox readout is slipping three weeks, which moves the package assembly and therefore the IND target. The alliance director separately holds a partner milestone that pays on the filing. The founder holds the commitment made to the board about filing this quarter. All three facts are now inconsistent, and unless the study call's outcome reaches all three inboxes, only one record knows. The overlap in a small company is large, because most of this traffic sits on threads with several people copied, but it is overlap rather than a guarantee, and the one time it fails is the time everybody was on a plane.
What this rules out. No shared dashboard everyone reads. No task assignment across people. No single company-wide brain that a new hire logs into on day one. If that is what you are shopping for, this is not it, and the version of it that exists is a different kind of product with a different kind of implementation.
Where the per-seat shape is right, and where it hurts
It is right more often than it sounds, for two reasons. The first is that in a small biotech the operating load is not evenly distributed. One person is drowning and three are fine. Giving four people a system is usually a way of not giving the drowning one enough attention. The second is that the mail identity really is the natural boundary of context. A business development lead's diligence threads are covered by confidentiality agreements. An alliance director sits on governance material that the whole company does not need. A per-seat install means nobody has to draw those lines by hand, because the boundary is already there.
Where it hurts is handover and continuity. The single-point-of-failure problem does not go away: if the program lead leaves, their record leaves with the seat unless somebody deliberately moves it. It is plain files, so moving it is genuinely possible in a way that exporting from a hosted tool is not, and that portability is one of the arguments in Claude for biotech: the AI that runs locally. But it is a decision somebody has to make rather than something the design does for you.
How to sequence it
Start with one seat, and pick the person by where the operation is actually jammed rather than by seniority. Usually that is whoever holds the most external threads: the person the contract organizations, the partner and the board all email. Run it for a quarter. If it holds, add the second seat next to it, and let the overlap between two records show you where a shared layer would actually earn its keep rather than guessing.
The capability list each seat gets is the same regardless of who holds it, and it is broken down in the Claude chief of staff skill. What the top seat's week looks like specifically is an AI agent for biotech CEOs, and the setup mechanics, including which surface of Claude you build on, are in Claude as an AI chief of staff, set up in a biotech.
If the question underneath this is whether to have your own developer assemble it instead, the comparison is Claude Code for biotech vs off-the-shelf AI tools. And the concept all of it serves is what an AI company brain is.
What a single seat holds
The demo is one install, running: one person's external threads filed, their commitments held in both directions, nothing assigned to a colleague and nothing leaving without them. Come and see it, then work out whose seat should be the first one.
See the demo