MEDIVA Project
AI-powered smart medicine for more agile clinical management
Between “there’s a problem here” and “someone uses the solution every day” there’s a gap that in most companies is measured in months. The Forward Deployed Engineer exists to shorten it: someone who sits in the middle of the problem, builds there, and is responsible for the solution being used, not for having delivered it. Palantir came up with the name, and it carries a word that misleads: of the three things it promises — going ahead, deploying, and doing engineering — the last one is the least important.
When I joined Origen, my position was called AI expert. Too fancy for what an expert should actually know about artificial intelligence. One day Palantir put a name to all this and called it Forward Deployed Engineer. The label stuck, and along with it came a misunderstanding.
It’s worth saying it straight: I’m not an engineer. I’ve come from years in product, design, and user experience, and for a long time I felt limited because I didn’t control the development side; there were things in my head that I couldn’t see through to the end. What’s changed isn’t that I’ve become an engineer. It’s that building things has stopped being the barrier. Artificial intelligence gave me the technical piece I was missing, and with it the ability to close the whole loop: from the idea to something someone uses every day.
That’s where the shift explaining the role comes in. When building was expensive, the scarce resource was someone who knew how to build. Now that building is cheap, the scarce resource is someone who knows what is worth building, who will use it, and why they don’t use it today. That’s not an engineering skill.
An FDE is the fruit of all your previous positions. It’s not a new specialty: it’s a foundation. If I can do what I do today, it’s because of the years I spent in previous roles, and because of a human side that the job demands every day and that no tool can replace: truly listening, reading a room, winning over someone who’s been solving things differently for twenty years, and maintaining the relationship when something goes wrong.
That’s why an FDE isn’t hired for a language or a framework, and you don’t get it from a course. It accumulates.
| Consultant | Diagnoses and recommends; builds another one. The FDE delivers a working proof of concept, and development adds the final layers. |
| Product Engineer | Build for an added user and a roadmap. The FDE, for a specific user and a specific problem. |
| Pre-sales or solutions architect | It shows what technology already does. FDE solves what it still doesn’t. |
| Developer assigned to an area | Carry out what’s specified to you. The FDE decides what is worth building. |
The fundamental difference is just one: an FDE doesn’t get written requirements. They sit where the problem is, see how things are done today, and decide right there what to build.
When I was asked about the qualities the position requires, I didn’t mention any language or framework. I said listening, flexibility—in ideation, in building, and with the client—and creative ability: being able to visualize problems, solutions, and use cases. Some people sit down with you and get it instantly, and others, there’s just no way. None of that is learned in a technical course.
The reason is that the role goes through the whole cycle, and each stage demands something different.
| Detect | Look at the work as it is today, alongside the person who has the problem. It demands listening and business curiosity. |
| Frame | Decide what gets built and what gets discarded, with the impact and cost on the table. It takes product judgment and the ability to say no. |
| Build | Prototype up and running in days, using real data and systems. Requires ease with the tools and speed. |
| Validate | He puts it in front of the user, picks up what fails, and either fixes it or abandons it. It demands communication and detachment from your own work. |
| To industrialize | He takes it to production and leaves the team able to operate it without him. He demands operational rigor and teaching skills. |
Of those five requirements, four are human. The technical part only shows up in one phase, and that’s precisely the one that has received the most support over the past two years. Listening, deciding what to discard, handling a no, and teaching still rely entirely on the person. And none of them can be passed on to the next stage: whoever frames the work has to have been in the detection phase, and whoever industrializes it has to have gone through validation. That’s why it’s such a hard profile to find.
If four out of five requirements are human, it’s worth saying which ones. It’s the part that doesn’t show up in any job description, the one that can’t be certified, and the one that’s most noticeable when it’s missing.
Listening, to begin with, is not waiting for your turn. People rarely tell you their problem: they tell you the workaround they’ve been using for years to avoid it. You have to sit next to them, watch them work, and understand what really hurts them, not what they say hurts them. Everything else comes from that, and if that fails, it won’t matter how well-built what comes next is.
Then there’s trust, and you have to earn it every time. You arrive at a position where someone has been solving their own stuff their way for twenty years, and you bring a tool that at first glance looks like it’s here to take their place. If that person doesn’t believe you, they won’t show you how they really work: they show you the official procedure, which is almost never the same. Without that, there’s no project, no matter how good the technology is.
And there’s detachment. You’re going to propose things that the client will reject, and you have to be able to throw them away yourself, without defending them just because they’re yours. Building today is cheap; getting attached is expensive.
None of this is the soft part of the job. It’s what decides whether a project ends up being used or just remains a nice demo, and it’s exactly what no tool is going to do for you. Technical competence today can be achieved. It’s built up over time, with years and with experience.
At Origen, the FDE doesn’t improvise, but he doesn’t always apply the same recipe either. The first thing he decides, once he’s taken a close look at the problem, is how to solve it. And that answer isn’t always an agent.
When the case fits, we work on Genesis, our agent production platform, which follows a twelve-step process spread over three phases: understand, build, and activate and learn. Here the division is clear: Genesis automates what can be automated —capturing the brief, requirements questionnaire, expert advice, security audit, agent package generation, and QA— while the client provides the reality and validates it.
But Genesis is just one solution, not the answer to everything our clients ask us. Some problems are solved with an integration, a change in the process, a tool the company already pays for but nobody uses, or by stopping something that’s no longer needed. Part of the job, and one of the least appreciated parts, is recognizing when the problem doesn’t require an agent and stating it.
What doesn’t change is the FDE’s role. With or without Genesis, it’s the thread that runs through the case from start to finish, doing what no platform can do: observing the real process on the job, weighing recommendations against what they’ve seen there, negotiating permissions with IT, testing with real data, and being accountable for the production outcome.
The idea
Without FDE, a platform produces demos. With FDE, it produces agents that get used.
There’s also a pace that this work allows that the previous one didn’t. Nowadays, it’s so cheap to fail, undo, and redo that you propose something, mess up, the client tells you no, and you redo it without drama. It’s nothing like the grind of drawing 7,000 screens in Figma. I’ve even built things in front of the client, watching their tool take shape during the same meeting. And when you build something with someone, that person feels like it’s theirs.
In its first version, the agent just reads. It checks emails, ERP systems, files, and data, and drafts summaries, overviews, and action proposals. It doesn’t change anything in the client’s systems: if it makes a mistake, it doesn’t break anything.
Writing is earned. It only opens when tests with real data meet the agreed criteria, the client confirms that the agent’s proposals were correct, and someone is appointed to approve the irreversible. And only one action is opened at a time, with minimum privilege, logging every step, and documented rollback.
There are more rules like that:
But it’s the reading one that best explains the trade. Trust isn’t declared: it’s shown.
An agent that’s not used doesn’t exist. That’s why an FDE isn’t measured by the number of deliverables or open pilots, but by real use: how many people have incorporated it into their daily routine and are still using it weeks later.
That changes where the work ends. It doesn’t end at delivery: it ends when the team runs the solution without depending on anyone. On-the-job training with the client’s cases, not with slides. Support during the first few weeks. And if it’s not used, find out why.
At Origen, we put it another way: if we haven’t made the client feel it, we’re not there. They need to notice that this is going to make them grow.
For everything you set up, you seriously doubt it will hold. That it will expire, that it will need to be redone in six months, or that it won’t even be useful. You end up internalizing it; the problem is when the client doesn’t. Windows Vista used to last three years. Now a solution lasts three months.
And it’s worth saying the other thing without sugarcoating: millions of licenses and subscriptions are sold, the numbers are heard all the time, but inside companies people still don’t use this. In Spain, even less. We’re very far from what can already be done today. Not what’s coming: what already exists.
That gap is exactly the work. Someone has to sit where the problem is, build there, and stay until it’s used. That someone doesn’t have to be an engineer: they just need to know how to listen, decide, and stick around.
One last thing, for honesty’s sake: the anxiety in this line of work isn’t caused by users, clients, or your boss. It’s caused by technology itself, because it doesn’t let you breathe. Professionally it’s good — the more demanding it is, the more up-to-date you stay and the more unique you become — but it’s good to know that before you start.
To dive deeper into how a Forward Deployed Engineer really works, you can check out the full conversation between Rodrigo San Andrés, Forward Deployed Engineer at Origen, and Matteo Di Paolantonio from Orbitant.
They talk about the change in the product cycle, how you go from the customer’s problem to a working proof of concept, the importance of soft skills, technology adoption, and what happens when a solution really has to go into production.
You can watch the full interview below:
Between “there’s a problem here” and “someone uses the solution every day” there’s a gap that in most companies is measured in months. The Forward Deployed Engineer exists to shorten it: someone who sits in the middle of the problem, builds there, and is responsible for the solution being used, not for having delivered it. Palantir came up with the name, and it carries a word that misleads: of the three things it promises — going ahead, deploying, and doing engineering — the last one is the least important.
When I joined Origen, my position was called AI expert. Too fancy for what an expert should actually know about artificial intelligence. One day Palantir put a name to all this and called it Forward Deployed Engineer. The label stuck, and along with it came a misunderstanding.
It’s worth saying it straight: I’m not an engineer. I’ve come from years in product, design, and user experience, and for a long time I felt limited because I didn’t control the development side; there were things in my head that I couldn’t see through to the end. What’s changed isn’t that I’ve become an engineer. It’s that building things has stopped being the barrier. Artificial intelligence gave me the technical piece I was missing, and with it the ability to close the whole loop: from the idea to something someone uses every day.
That’s where the shift explaining the role comes in. When building was expensive, the scarce resource was someone who knew how to build. Now that building is cheap, the scarce resource is someone who knows what is worth building, who will use it, and why they don’t use it today. That’s not an engineering skill.
An FDE is the fruit of all your previous positions. It’s not a new specialty: it’s a foundation. If I can do what I do today, it’s because of the years I spent in previous roles, and because of a human side that the job demands every day and that no tool can replace: truly listening, reading a room, winning over someone who’s been solving things differently for twenty years, and maintaining the relationship when something goes wrong.
That’s why an FDE isn’t hired for a language or a framework, and you don’t get it from a course. It accumulates.
| Consultant | Diagnoses and recommends; builds another one. The FDE delivers a working proof of concept, and development adds the final layers. |
| Product Engineer | Build for an added user and a roadmap. The FDE, for a specific user and a specific problem. |
| Pre-sales or solutions architect | It shows what technology already does. FDE solves what it still doesn’t. |
| Developer assigned to an area | Carry out what’s specified to you. The FDE decides what is worth building. |
The fundamental difference is just one: an FDE doesn’t get written requirements. They sit where the problem is, see how things are done today, and decide right there what to build.
When I was asked about the qualities the position requires, I didn’t mention any language or framework. I said listening, flexibility—in ideation, in building, and with the client—and creative ability: being able to visualize problems, solutions, and use cases. Some people sit down with you and get it instantly, and others, there’s just no way. None of that is learned in a technical course.
The reason is that the role goes through the whole cycle, and each stage demands something different.
| Detect | Look at the work as it is today, alongside the person who has the problem. It demands listening and business curiosity. |
| Frame | Decide what gets built and what gets discarded, with the impact and cost on the table. It takes product judgment and the ability to say no. |
| Build | Prototype up and running in days, using real data and systems. Requires ease with the tools and speed. |
| Validate | He puts it in front of the user, picks up what fails, and either fixes it or abandons it. It demands communication and detachment from your own work. |
| To industrialize | He takes it to production and leaves the team able to operate it without him. He demands operational rigor and teaching skills. |
Of those five requirements, four are human. The technical part only shows up in one phase, and that’s precisely the one that has received the most support over the past two years. Listening, deciding what to discard, handling a no, and teaching still rely entirely on the person. And none of them can be passed on to the next stage: whoever frames the work has to have been in the detection phase, and whoever industrializes it has to have gone through validation. That’s why it’s such a hard profile to find.
If four out of five requirements are human, it’s worth saying which ones. It’s the part that doesn’t show up in any job description, the one that can’t be certified, and the one that’s most noticeable when it’s missing.
Listening, to begin with, is not waiting for your turn. People rarely tell you their problem: they tell you the workaround they’ve been using for years to avoid it. You have to sit next to them, watch them work, and understand what really hurts them, not what they say hurts them. Everything else comes from that, and if that fails, it won’t matter how well-built what comes next is.
Then there’s trust, and you have to earn it every time. You arrive at a position where someone has been solving their own stuff their way for twenty years, and you bring a tool that at first glance looks like it’s here to take their place. If that person doesn’t believe you, they won’t show you how they really work: they show you the official procedure, which is almost never the same. Without that, there’s no project, no matter how good the technology is.
And there’s detachment. You’re going to propose things that the client will reject, and you have to be able to throw them away yourself, without defending them just because they’re yours. Building today is cheap; getting attached is expensive.
None of this is the soft part of the job. It’s what decides whether a project ends up being used or just remains a nice demo, and it’s exactly what no tool is going to do for you. Technical competence today can be achieved. It’s built up over time, with years and with experience.
At Origen, the FDE doesn’t improvise, but he doesn’t always apply the same recipe either. The first thing he decides, once he’s taken a close look at the problem, is how to solve it. And that answer isn’t always an agent.
When the case fits, we work on Genesis, our agent production platform, which follows a twelve-step process spread over three phases: understand, build, and activate and learn. Here the division is clear: Genesis automates what can be automated —capturing the brief, requirements questionnaire, expert advice, security audit, agent package generation, and QA— while the client provides the reality and validates it.
But Genesis is just one solution, not the answer to everything our clients ask us. Some problems are solved with an integration, a change in the process, a tool the company already pays for but nobody uses, or by stopping something that’s no longer needed. Part of the job, and one of the least appreciated parts, is recognizing when the problem doesn’t require an agent and stating it.
What doesn’t change is the FDE’s role. With or without Genesis, it’s the thread that runs through the case from start to finish, doing what no platform can do: observing the real process on the job, weighing recommendations against what they’ve seen there, negotiating permissions with IT, testing with real data, and being accountable for the production outcome.
The idea
Without FDE, a platform produces demos. With FDE, it produces agents that get used.
There’s also a pace that this work allows that the previous one didn’t. Nowadays, it’s so cheap to fail, undo, and redo that you propose something, mess up, the client tells you no, and you redo it without drama. It’s nothing like the grind of drawing 7,000 screens in Figma. I’ve even built things in front of the client, watching their tool take shape during the same meeting. And when you build something with someone, that person feels like it’s theirs.
In its first version, the agent just reads. It checks emails, ERP systems, files, and data, and drafts summaries, overviews, and action proposals. It doesn’t change anything in the client’s systems: if it makes a mistake, it doesn’t break anything.
Writing is earned. It only opens when tests with real data meet the agreed criteria, the client confirms that the agent’s proposals were correct, and someone is appointed to approve the irreversible. And only one action is opened at a time, with minimum privilege, logging every step, and documented rollback.
There are more rules like that:
But it’s the reading one that best explains the trade. Trust isn’t declared: it’s shown.
An agent that’s not used doesn’t exist. That’s why an FDE isn’t measured by the number of deliverables or open pilots, but by real use: how many people have incorporated it into their daily routine and are still using it weeks later.
That changes where the work ends. It doesn’t end at delivery: it ends when the team runs the solution without depending on anyone. On-the-job training with the client’s cases, not with slides. Support during the first few weeks. And if it’s not used, find out why.
At Origen, we put it another way: if we haven’t made the client feel it, we’re not there. They need to notice that this is going to make them grow.
For everything you set up, you seriously doubt it will hold. That it will expire, that it will need to be redone in six months, or that it won’t even be useful. You end up internalizing it; the problem is when the client doesn’t. Windows Vista used to last three years. Now a solution lasts three months.
And it’s worth saying the other thing without sugarcoating: millions of licenses and subscriptions are sold, the numbers are heard all the time, but inside companies people still don’t use this. In Spain, even less. We’re very far from what can already be done today. Not what’s coming: what already exists.
That gap is exactly the work. Someone has to sit where the problem is, build there, and stay until it’s used. That someone doesn’t have to be an engineer: they just need to know how to listen, decide, and stick around.
One last thing, for honesty’s sake: the anxiety in this line of work isn’t caused by users, clients, or your boss. It’s caused by technology itself, because it doesn’t let you breathe. Professionally it’s good — the more demanding it is, the more up-to-date you stay and the more unique you become — but it’s good to know that before you start.
To dive deeper into how a Forward Deployed Engineer really works, you can check out the full conversation between Rodrigo San Andrés, Forward Deployed Engineer at Origen, and Matteo Di Paolantonio from Orbitant.
They talk about the change in the product cycle, how you go from the customer’s problem to a working proof of concept, the importance of soft skills, technology adoption, and what happens when a solution really has to go into production.
You can watch the full interview below:
