Your biopharma agent isn't your colleague
When we talk to customers about what an agent should be allowed to do in their workspace, the most common response is that the agent should be able to do whatever the user themselves can do. It's an intuitive answer. The agent is acting on your behalf, you have permissions to do X, therefore the agent should be able to do X.
In our experience, this is the wrong answer.
The thing the customer is implicitly doing in that moment is treating the agent like a cloned colleague, when the mental model that actually fits is closer to an external collaborator. The cost of getting this wrong in biopharma is higher than it is in most places, and the people most likely to get it wrong are the ones least equipped to recognize the mistake until they've already made it.
Why this is the wrong mental model
This issue isn’t really about whether models are capable enough to be given user permissions. They're often more capable than the user expects, which is part of the problem. The actual issue is that the capability profile of a modern language model doesn't match the capability profile of a competent human, so any intuition you've built about how to delegate work to competent humans gives you the wrong answer when you apply it to an agent.
Models are unevenly intelligent. They're extraordinarily good at certain things like writing code, translating between languages, summarizing structured data, and writing scripts that run checks against information... and surprisingly bad at other things a human would never get wrong, like counting the letters in a word or recognizing that an ambiguous experiment naming convention encodes meaning the model has no way to see. That unevenness is a structural property of how these systems work, which means the kinds of mistakes they make aren't the kinds of mistakes a competent colleague would make. They're closer to the kinds of mistakes a very capable person operating in a domain they don't quite understand would make. This is the worst kind of mistake from a trust standpoint because it's confident and plausible, and you only catch it if you already know the answer.
The other point here is that the technology pattern-matches to a colleague in a specifically misleading way. When you talk to a model, it sounds like a person and the impulse to anthropomorphize is strong. The AI industry has spent the last few years telling everyone that this is general intelligence, which calibrates user expectations toward treating models as competent generalists rather than capable specialists. As a result, the natural assumption is that the agent has common sense, because common sense is what conversational fluency seems to imply – and yet, common sense is the thing language models don't reliably have.
In biopharma, this calibration gap is wider than it is in most industries, in part because large swathes of biopharma users aren't tech-native. They're scientists, not engineers who've spent three years watching models hallucinate and building up the instinctive skepticism that comes from it. They came to AI in the last eighteen months, mostly through products that felt impressively capable, and the message they've absorbed from the industry is that the technology works. The assumption they bring to an agent in their workspace is that it's a smart new hire who needs onboarding, when in practice it's a powerful but uneven system that needs scoped access.
What the right mental model looks like
Biopharma already has a well-developed mental model for how to grant access to a powerful, capable, but not fully trusted party. It's the model used for CROs.
A CRO is competent at what they do. You trust them to run the assay, follow the protocol, report results honestly. You don't trust them, as a matter of policy and not as a matter of relationship, to have a complete view of the rest of your work, because the cost of being wrong about that trust is high enough that you don't want it to be the only thing standing between your IP and someone else's hard drive. So you give them scoped permissions. They see the experiment they're running, the deliverable they're producing, and not much else. The rest of the program stays inside.
That's also the right posture for an agent. Read access is mostly safe. Letting the model see what you can see, so it can summarize, analyze, surface relevant context, is rarely the thing that creates risk. The risk lives on the write side, which is why write access should be scoped narrowly to the specific actions the agent is doing in this specific context, not granted globally based on what the user happens to be allowed to do. A CRO doesn't get write access to your whole pipeline just because you have write access to your whole pipeline. They get write access to the deliverable they're producing. The same should be true for agents.
There's a subtler version of this point that comes up often in our customer conversations, which is that the permissions an agent inherits should be bounded by the creator's permissions and never exceed them. We've heard variations of the same story from people at very large companies, where someone on the team built an agent for an internal workflow and the agent quietly found workarounds to access files the creator wasn't supposed to have access to in the first place. The work to prevent this happens at the substrate level, by making the agent's behavior bound by the same rules that bound the human, automatically, with no special handling required.
How we design agentic features around this model
A lot of what we've built at Kaleidoscope over the last year sits underneath the argument above. The way we think about agentic features has been shaped by the trust-posture problem more than by the capability questions that get most of the airtime in agentic AI discourse. Four design choices have come out of that:
- We treat models as users in the system, with the same permission model as any other collaborator. There isn't a separate agent permission system bolted onto the side. When an agent acts in a Kaleidoscope workspace, it acts as an identity with scoped read and write permissions defined the same way a CRO's permissions are defined, against the same data model, enforced at the same layer. Part of this is an engineering decision, because maintaining two separate permission systems is a recipe for security failures at the seams. Part of it is a philosophical decision, because an agent really is another collaborator, and the right way to treat it is to use the abstractions you'd use for any other one.
- Skills are doing safety work as well as capability work. Skills, in the agentic sense, are documentation written for a non-human reader, describing how to do a specific thing inside the system. The interesting property of a skill is that it's a layer of constraint as much as a layer of capability. A well-written skill tells the agent how to perform an action and also implicitly tells the agent what it shouldn't do while performing it. When we write a skill for creating an experiment, the skill is opinionated about keeping the experiment simple, asking the user for clarification on specific fields rather than guessing from similar experiments, not auto-assigning external collaborators based on pattern-matching against historical data. We've started to think of the skill library as one of the more important surfaces for shaping agent behavior in our system.
- Our MCP service is one of the interfaces where permission boundaries get enforced. The MCP server lets customers bring their own models and their own agentic systems into a Kaleidoscope workspace through a permissioned, documented interface. We built it because biotech companies are increasingly running heterogeneous AI stacks, some of them using Claude/Gemini/etc., some using internal models, some using third-party tools with their own agentic capabilities. Two details worth drawing out here:
- First, the permissions are scoped to the protocol itself, defined around the specific tools the server exposes, rather than inherited wholesale from the web application. They're still a subset of the user's permissions, but they need a different shape, drawn around tool scopes rather than the broader data model.
- Second, we currently treat a user acting through MCP as still that user, with an audit trail noting the action came through MCP tools rather than the web app. The reasoning is that MCP actions are tightly controlled and the user tends to think of them as something they did with the support of the agent, not something an independent agent did on their behalf. That's the opposite end of the spectrum from a free-running agent, which fits the collaborator model described above. This is an area still shifting as we test with customers and learn what they expect.
- The default behavior in our agentic flows is to ask, not assume. Some of this is downstream of what the model providers have been doing, since harnesses have gotten much better at prompting models to clarify ambiguity rather than guess. Some of it is a deliberate choice about what we want the default behavior to be inside Kaleidoscope specifically. In biopharma, an agent that guesses wrong about a compound import or a CRO assignment is creating real operational cost, and the right default sits closer to "ask the human if there's any ambiguity" than to "make a reasonable inference and proceed."
What we keep coming back to
The design challenge for agentic features in biopharma is mostly a calibration challenge, on the user's side as much as the system's, and most of the work we've been doing has been about closing the gap between what users assume agents can safely do and what's actually safe to let them do without supervision.
If there's a single design principle that's emerged from this for us, it's that the right default for an agent in a biopharma workspace is to assume the user will be more excited about what the agent can do than careful about what it should do, and to make sure the path of least resistance is already the safe one. Read broadly, write narrowly, ask before assuming, never inherit more permission than your creator. The work of building good agentic features is mostly the work of making those defaults feel natural, so the user gets the safety without having to think about it.
Kaleidoscope is a software platform for intelligent Life Science work orchestration. With Kaleidoscope, teams can power their R&D operations confidently and efficiently, ensuring programs hit key milestones on time and on budget. By connecting teams, projects, decisions, and underlying data context in one spot, Kaleidoscope enables R&D orgs to translate IP to impact as quickly as possible.