Why We Send Scientists, Not Engineers

When we launched workflows in EMET, we made a claim near the end that deserves its own post:
Our forward-deployed PhD scientists are not a support function we bolted on. They are the mechanism.
Here's what's behind that statement.
The library is the easy half
We shipped over 125 workflows across eleven areas of preclinical R&D. But a shipped workflow is a starting point, not a product. "The considerations around a single workflow component are manifold. Take hepatology risk synthesis: you need a small-molecule version and an antibody version. An oncology version and a neuro version. A version that reads the internal tox dataset that never leaves the building, scored against thresholds your company argued its way to over fifteen years and would never publish.
That last one is the only version that matters at a governance checkpoint. And nobody outside your company can write it.
So the real question isn't how many workflows we ship. It's who does the optimization— that determines what kind of person we hire.
Every AI company is hiring the wrong person for this
Palantir invented forward-deployed engineering in the mid-2000s. Fifteen years later, applied AI rediscovered it all at once. OpenAI, Anthropic, Databricks, Ramp, Sierra, everyone now embeds engineers with customers, because the model was never the hard part. The last mile is.
The wave has reached our space, and many are hiring forward-deployed engineers. Here's where we break with most of them: in drug discovery, the forward-deployed engineer solves the wrong problem.
An engineer is excellent at the problems that announce themselves. The auth is broken. The pipeline chokes on their schema. Latency is unacceptable at scale. Real problems, and someone sitting inside the customer's environment closes them faster than any ticket queue.
Now, the problem we actually have.
A scientist asks EMET for a literature gap analysis. The answer comes back fluent, structured, and with eleven citations. The API returned 200. Every system is green. Nothing failed anywhere in the procss.
But some of those cited PMIDs don't exist.
No engineer catches that from the logs. The only person who catches it is someone who reads the citation, notices that the described paper doesn't match the journal it's attributed to, and knows the field well enough to feel the wrongness before they can prove it. That was a real ticket. Our scientists found it, reproduced it, and confirmed the fix. It's a normal week.
You can't debug a hypothesis. An engineer can verify that a system returned an answer. Only a scientist can tell you the answer was wrong.
Customization is a scientific proposal, not an implementation ticket
When one of our scientists sits with a customer's team and optimizes a workflow, the conversation is about which evidence sources count here and why. What threshold makes a signal real? Which of your internal datasets should override the public one? What has to be in this target safety assessment for it to survive your committee?
Those are not requirements to be gathered. They are positions to be defended. Our scientist has to be able to push back on a principal scientist at a top-five pharma, as a peer, in real time—and to lose the argument when they're wrong.
That is the job. It's why the people doing it have doctorates and real bench time. They've personally lost six months to a bad antibody. They know which controls a reviewer will ask for. When they hand back a workflow, the customer's organization can validate and sanction it because a scientist they respect built it with them.
An engineer gathering requirements produces a configured workflow. A scientist collaborator produces one that the company will actually stand behind.
What a decade in pharma buys
"We hire PhDs" is the emptiest claim in biotech. Everyone says it.
We've been inside pharma R&D since 2015, working with most of the top twenty companies. That's a decade of watching how these organizations actually decide: where the data lives, who signs off, why the obvious integration is politically impossible, which workflows are sacred, and which are just habit.
Our scientists carry that into every deployment, and they carry it back out—the workflows we shipped came from them, not from a PM writing a spec off a customer interview. They're Our forward-deployed scientists are also the final evaluation before anything reaches you: every workflow tested multiple times, scored on whether it invokes reliably, whether outputs stay consistent, whether the science is actually valuable, and whether every claim traces to real evidence. Software QA can confirm that a citation has been rendered. Only a scientist can confirm it's real.
A company that entered this market last year can hire brilliant scientists. It cannot hire a decade of working alongside biopharma scientists.
Meet them
Sean Holloran — Lead Scientific Solutions Architect · Chicago

Andrea Manoppo — Senior Scientific Solutions Architect · Denver

Anna Cranston — Senior Scientific Solutions Architect · London

Sam Dziurdzik — Scientific Solutions Architect · Vancouver

Shouka Parvin Nejad — Scientific Solutions Architect · Toronto

Cino Ling — Scientific Solutions Architect · New York

Youn Hee Cho — Scientific Solutions Architect · New York

Luca Delfinis — Scientific Solutions Architect · Toronto

Dan Madularu — Lead Scientific Solutions Architect · Ottawa

Led by
Victoria Hipolito — Senior Director of Scientific Solutions

Alex Sheftel — Director of Scientific Solutions



