By: Nicolas Fuentes, Forward deployed engineer for Agentic AI in clinical development, Medable
What exactly is a forward deployed engineer?
If you have spent any time around AI and enterprise software this year, you have probably heard the term FDE, or forward deployed engineer. It sounds like a buzzword, but the role is why we’re able to solve real problems for our clinical trial clients in record time.
Defining the term
The term forward deployed engineer was coined about ten years ago by Palantir, whose idea was simple and straightforward. The company would put software engineers out in the field with customers, let them see the actual problems firsthand, and then bring those learnings back to the product team.
With the rise of AI, that model is becoming more relevant than ever. Companies understand that AI has value, but most of them do not have anyone on staff who understands both the technology and their specific domain. That gap is exactly where an FDE lives.
In clinical development, a general purpose AI model or LLM will not work well out of the box. The frontier labs building these models are not accounting for the nuisances of a Phase 3 rare-disease clinical trial, for example.. At the same time, a pre-trained model that does understand clinical trials is also not useful if there aren’t teams leveraging the model on a GXP platform and into workflows that can actually scale inside an organization.An FDE is the person who closes both gaps at once.
Why this moves faster than traditional software cycles
In a traditional model, a change request travels from the client to a business rep, from the rep to a product manager, and from the product manager to engineering. A familiar process that can easily take a year or more to reach production.
With the FDE model, that timeline compresses dramatically. Customer discovery consists of real-world findings that can be compressed into 2 weeks.. Building the agent then takes one or two weeks. Leaving the client to test it in three or four weeks or less. Now, what used to take over a year can now be delivered in a couple of months, because the client is talking directly to the person who can either fix the issue themselves or go directly to the engineers who can.
A real example, from one of our production deployments
One of our pharma clients is a great example of what this looks like in production.
One of the biggest hurdles in getting real world value from AI agents is for any-size pharma to move past the pilot phase and enter into production. A Top-10 pharma decided to expedite their ROI and build agents for production-level applications.
We solved a problem that is quite common among sponsors, milestone cleanliness and anomaly detection across clinical trial management systems (CTMS).
During discovery, we found that sitestaff enter these dates manually, and errors slip through. Sometimes, trial information or data is incorrectly entered into the system. For example, a date of 2016 is entered instead of 2026, or a first patient in date ends up logged after the last patient in date. These are common issues that no among the many responsibilites of site staff running trials, can often trickle into audit or inspection problems.
Unfortunately, large enterprise systems often do not catch these errors automatically or have turned off these alerts at the request of the sponsor & the fluid nature of clinical trials. This is where agentic AI and FDEs like myself thrive. Together with the client, we built a solution that proactively scans for these anomalies, catching data entry errors and date logic before they become bigger problems.
How we built it, in three phases
To get an understanding of the issues and what we needed to do to solve them, we used a three phrase process.
The first phase was discovery. We spent a couple of weeks with the client team defining the actual problem, what systems we would be allowed to connect to our GXP platform, and mapping out the model context protocols, or MCPs, needed to integrate with those systems. The biggest objective of discovery is to understand customer pain-points. This means badging into their offices, shadowing them through their current processes and clearly articulating what “good” looks like.
The second phase was co-building and user level validation. This phase consists of weekly meetings with the client, sitting alongside super users and subject matter experts to get a more in-depth context of who we are building the solution for and how it’s intended to be used. In these sessions, we’d run through tests and feedback sessions to deploy adjustments and tweaks for an optimal production deployment.
The third and final phase was deployment. This is where Medable separates itself from the frontier lab providers. Most avid AI users are running agents in a sandbox towards an individual use-case. However, there are governance boxes that are required to be checked-off such as enterprise level approvals, training sessions, IT permissions and isolated data layers that are all part of Medable’s Agent Activation Program (AAP).
The agent has now been live for about a month, actively surfacing anomalies for the team, and we are already working on version two.
The real ROI question that agentic AI answers
The question we always ask a client is simple, how are you doing this today. The answer is almost always the same, manually. Someone on the team is spending hours of their day combing through data by hand, because the expectation is that the data should already be correct, and it often is not.
Large healthcare systems move slowly, and they are not going to overhaul their platforms for a narrow issue like this. What they need is a workflow that catches the problem for them. That is the shift an FDE and an agent bring, turning a multi hour manual process into something that surfaces results in a couple of minutes.
When paired with a system like ours, that lets clients use their existing software stacks, we’re able to solve issues faster than ever imagined. This is real ROI.
The bottom line
AI does not solve clinical development problems on its own, and neither does domain knowledge on its own. It takes someone who can sit between the two, translate a real operational pain point into a working agent, and stay embedded with the team long enough to keep improving it. That is the role an FDE plays, and it is why we see this function only becoming more central as more sponsors move from pilots to production.
