Fireside chat · 4:25 PM · Wednesday, May 13, 2026
So with that, David, Lata, thank you for joining us.
Hello, everybody. Thank you for joining us. So with me today I've got Lata Varghese. She is SVP, Americas Enterprise Market Unit at Rackspace. And one of the reasons we wanted to talk was Rackspace has been working closely with Palantir. And Palantir are kind of the poster boy for FDEs, Forward Deployed Engineers. And everyone's talking about Forward Deployed Engineers, right? And Lata is working in spaces where making AI work is really difficult because we're talking about complex environments. We're talking about lots of governance issues, regulated industries. So I thought you might have a few tips for us all. But let's kick off with the whole question of what even is an FDE? How are you defining it at Rackspace?
Before I define what an FDE is, let's talk about what that FDE does. So they are, basically it's a combination of engineering process and domain that needs to come together to scale any AI use case in production. And I manage the regulated industries, which is healthcare and banking financial services. Every one of our clients has been doing the same things everybody's been talking about all day. They've been starting pilots and not able to scale. Because ultimately it comes down to the infrastructure. What is it going to take to run all this at scale? What's the cost of it? How do I govern it? How do I audit it? And so forth, right?
So when they start to think about, and that's where Rackspace's positioning is, you know, very unique because we run the entire stack from the infrastructure to the inferencing to the data orchestration to the application layer, how are we going to enable these clients to actually take these things that they've built, maybe with a hyperscaler, maybe with other sort of solutions, point solutions that all come in and creating a bunch of AI sprawl in the system. How do I actually take and scale it? And then it all comes down to infrastructure, boring old infrastructure because you got to know that I have controls around this. What have I built at the scale?
So that's where the FDE is really, I get less concerned about FDE as a term and it's really what do they do? You need to bring these elements of engineering process and domain together to actually build close to the workflow, the data, and the controls for you to be able to actually scale the solution, right? Which means you have to observe the workflow first. You have to understand the constraints with which that workflow works today. Then you have to build with the users while you surface these production issues early. That is really what you're trying to do when you're building with this different type of pod team.
And honestly, you know, there are models in which, you know, Palantir has done, you know, the origin story of how they built the supply chain solution, right, for the COVID vaccine. But even you're working with the problem and with the users of that application or that system, you are going to unearth all of that early. You're not going to park it for later so that you can come back and solve it. So this is a way of building close to the problem. So you can actually take it to scale. And then you have to operate it day two, right? It's not like you scale it and it's running. Somebody has to explain it. You know, a CISO, a CCO, everybody's going to want to get involved in what is this thing doing. And it is absolutely true. I missed some of the in-between sessions because I'm actually talking to a client. Where it is real. How do I take these things and scale? It all comes down to how am I going to run this and secure this, right?
So the FDE, how we define it is you've got these tools, much better tools, which potentially gives you a guarded view of the data. How are you going to fundamentally think differently about how you're going to build software with this, right? You're not going to bolt on yet another solution to an already complex environment. They're drowning, right? It's not like the CIOs we work with in healthcare. We already run infrastructure that speaks natively, HIPAA and HL7 and FHIR, right? They are going to be deploying some of these AI solutions at scale when they have to come and also do the same things. You don't get a get out of jail free card just because you're doing AI solution. It has to come and run in that governed infrastructure. So when you do that, you have to be able to build it in a way that is explainable and auditable, and this is a different way to build software.
It's not the same old way. That's a lot of work, right?
That is.
For one unicorn-type human being. What's really going on there with the FDE model? Does it have to be one person? And what are the skills that need to be combined into one person or into a team? How does it work?
I think you put the people close to the workflow, and then you need to have somebody who obviously is a good engineer, knows how these tools work really well, right? It's not everybody's cup of tea. There are high 10X engineers that know how to use these tools better, and there are people who are learning, right? But it's a curve for everybody. So there's good AI engineers, but there's fundamentally the process, right? If you do not break down the process, like, for example, you know, people talk about these clinical use cases that, you know, a lot of our CIOs I talk to tell me we don't have a lack of use cases. We're drowning in good ones. It's about which one do I scale? What do I deprecate? And you are counting on the clinician to actually come and train all that. And that is all never talked about in an AI success story. What is the cost of all that, right? To actually build out that solution. So I think it's a question of how do you make sure that you are taking effort and time from people who are already strained for time, right? Clinicians are, so if they have to become the integration layer for your AI solution, you've failed. So how do you account for that when you bring in that domain knowledge?
Actually train the models. So I'd like to dig into that a little bit because it's easier said than done right and we can say we can get close to a process or we can get close, we can understand the business. How is it actually done? I understand there's some kind of hardcore workshopping required because another of the kind of big sales of FDEs is that it makes everything faster to outcomes. So what's the kind of pace of work that's required? And what are those extra elements?
You have to acknowledge that you have the engineering has to be tight, right? So we lead the people. And domain, to be honest, there is some domain also comes from the business user. It's not going to come from consulting all my career. It's not going to all come from the consultant. Typically, in traditional software development, you write the requirements, and then you have the contract, and then you have delivery, right? We are crunching that, the tooling is changing, the technology is changing, there's a lot of pressure to adopt. So you have to acknowledge that some part of this is going to come by the users wanting to lean in and adopt, and make sure that you don't take that for granted.
So if you start a bunch of these, and that's where the human element of it, is that user or set of users going to see enduring value for this, and that's where the IP questions come, right? They don't want to be training like frontier AI models, you know, reading my API pipeline and learning all my secrets. So that's when they come to, okay, I want to do it on my infrastructure, right? So the question you're asking is, is it one person? It could be, but it doesn't need to be. But you definitely need the, you need the application now, you know, you need the engineering, you need the domain and the process.
And for sure, there are clients we see who are getting ready to scale, and they are 100% thinking about infrastructure and how they have governance control and auditability, because if you are, like for a banking customer, they've been sold, a fraud solution is here. There's another solution, you know, piping in for fraud, that's one use case, right? That creates another set of rules, another data dependency, another set of audit burden, right? So if you look at it in this kludgy way, they're like, how the hell do I scale this thing, right? So I need to be, when I'm sitting in front of a governance committee, I need to be able to explain that my same consistent principle is how all of these, the auditability, the governance has to be explainable.
So I'm not saying that everybody is already there and doing it at scale, but the ones that are looking to scale are definitely looking at the infrastructure piece of it and how this thing runs after it is deployed is super important, right? It's like the inference economics start to matter. How is this, what is it going to cost me? So all the way to say, look, if you don't think about this while you're building with that, so really it's a different way to build software. FDE, you know, it can be one person, it can be multiple. You bring in a part of the right skill sets to go fix the problem and you surface the problems early, so you go fix it, right?
So I think you might be giving some hope to people in the room because one of the challenges is, where the hell am I going to find these FDEs from? Because they seem like they're magic. But you're saying you can combine skills into a unit, and as long as you have the right processes in place to get close to what the business needs to do to actually make AI work in that business, that's gonna be good enough.
That's right, and then you don't need to go do everything with large language models that are using billions of parameters, right? You can actually train smaller language models with the right set of data. You can create an ontology. Again, I don't like to get caught on all these, it's not buzzwords, right? Ultimately, it's about getting a view of your data, making sure that you know how things connect together, and if you build a workflow and you've thought about three other problems, this is where the engagement from the, you have to find a real problem that has multiple workflows that get, burden gets eased with time, so if you think about it right in the beginning, you are gonna go solve a real problem.
Then you get a continuous feedback engagement loop with the users wanting to scale it. And we are 100% seeing it, but they are worried about still, you know, how am I gonna explain it? Because there's a lot of people sitting in the room, you know, a CISO needs to know that what is a threat vector, you know, if I do take this model to scale, what happens, right? A CCO is looking at it from data and governance and all of that. Everybody has to come together. So this whole model is really you build, you surface it early. You know there is power. There's enough demand. People are buying these things. You have to get ROI means you have to do this difficult work, which is so separate the tech and the tech hype and look at the real applications. 100% we are seeing people, we have to scale it, and what do I need to do to do that?
So it raises some questions for me, this kind of requirement to control the governance. In your experience, what are you hearing from clients now about sovereignty? And I'm interested in, you mentioned ontology. I think you mentioned it once, we got away with it. But let's maybe talk about context. And that's more lingua franca. Everyone's talking about context engineering. And in some ways I see what we are able to do with the capturing of context or ontology through the kind of processes you're talking about as a kind of first time we've been able to capture culture because of the way things work around here. We're actually capturing that in a digital way, which we can then repurpose for the next primitive that comes along because there will be others, right? We ain't stopping here. So who gets to own that? Who gets to own that context layer when you're capturing that? Does that stay with the enterprise? And is that part of the requirements that you're hearing now as companies want to control more of what the LLMs might want to do?
So if you're asking about IP, they're definitely like, I don't know, the CIO that I was talking to earlier today, so you're on to something because I don't want my part, listening to all the API pipes and taking all my ideas and going and building competition. So you're talking about IP, they're certainly worried about, who gets to own that. They don't want to train that. When you say the ontology, I mean, ultimately, you build a set of small language models that are trained with the data for that enterprise, and they will, obviously you're not gonna go, and if you're building inside the workflow, you won't build for one and then not think about the future. So the moment you have engagement from real users, you are going to surface the right problem that everybody is gonna lean in and want to take the next step and the next step.
So from that standpoint, it is the set of users that come together and decide, "I'm gonna solve this problem." You know, there's a bit of the client IP, of course, in that process, right? But this is where our model of our FDEs are not like, we're not saying that they are like, of course they are superhuman, but we're not saying that, you know, you have to train them right with the right set of tools and then they go and enable these outcomes, sitting with the users and do the work, post deployment, day two. They don't disappear, right? I've handed it over to you. It's your problem. They're still there running and operating those environments.
So you have accountability. Your folk are being trained in the Palantir model.
Yes. As well as Uniphore. We had a couple of partners. And that's where we look at, we have the governed infrastructure layer, right? Then we've got the inferencing layer. We've got the infrastructure part of it. We've got ecosystem partners who can bring in the right set of tooling for the right set of problems that the clients want to solve. And then you forward deploy engineers, call it whatever, right? But you basically, what I'm saying is you bring this combination of process and engineering, right? And the domain will actually come from the client because if they don't lean in and give you, you can't claim to understand a client's full business. I'm certainly not arrogant enough, no, despite all the time I've spent in the industry.
So the Palantir model comes with a kind of halo of reassurance. Everyone knows that they can, Palantir can make AI work in your company. That's kind of guarantee one. But it also comes with a really high price. So there's that scary bit as well. How are you guys managing the challenge of price in particular?
Which is where, you know, Palantir is not for everybody. And if you find the big enough problem where you are going to solve a big enough, you're going to significantly take out cost, right? You will find that because that's the beauty of going and getting access to your data in a way that you didn't have before. Then you're able to go and create the right solution that unlocks that value. So if you're talking about Palantir software price, it is absolutely valuable when you do this work to identify where you want to deploy it, right? If you do that work and you know how much cost that you can take out, it is actually for everybody. But will everybody do it? Right. It's, you know, begs the question, right? But it's about finding the right problem and putting the right set of eyes in terms of engineering and domain and process.
I bring it back to that. These are the three elements, right? If you don't have all three ingredients and you don't have a view of what all you're going to scale, like, are you going to create a governed intelligence layer on top of which every agentic solution for the bank is going to think about that in that way or are you going to put a fraud solution here, a KYC solution there? And this is what they get pitched at all the time. You integrate all this. I'm like, now I have AI sprawl. I don't know. And people are forced to buy these solutions. So they're taking a step back and saying, how do I think about what? I'm not going to scale labor linearly to grow. My business has to grow. How am I going to have agents replace some of the work I do? But where am I going to deploy it? What are the tools that will help me build the right set of agentics? And Palantir is truly powerful for that, right? It may not be for every use case and every client, but it's powerful.
You mentioned agentic, and I'm interested to know how you're using that yourselves in order to scale the capabilities of your FDE teams.
Yes, so we are eating our own dog food, so we are implementing internally Palantir for part of our back office systems. And we certainly, you know, that gives us the right to go and tell a client, you know, here's what we found, right? Here's where it's really good, and it's wicked good. The tool is wicked good. Now, is it, again, going to solve everything? We are very realistic, right? You have to build towards it, but it's definitely a different and better way to build software. And there will be more solutions as well, which is why we look at it as an ecosystem of partnerships. And we are not, like, getting tied into you have to only buy this. Ultimately, you have to focus on the problem. If you find the right problem to solve and you do the hard work to solve it, you're going to make progress.
And just finally, is there any kind of lessons you think you can already draw from some of your interactions with clients and their appetite for this approach, the outcomes that they're starting to see, what lessons would you apply for others working in very complex environments now?
I would say don't minimize and, you know, like wave hand. I've written this down because I've spent less time in healthcare than in banking. So when you hand wave and say, oh, access scheduling, great use case, right, for hospitals, they all need them. And to build a solution that really works, you need to know access rules, provider templates, referral patterns, patient preference, clinical urgency, call center workflow, escalation point. In which world can you sit down and write requirements for all this in a perfect way in day one? You just can't, right? So when you decide the use case, make sure you think through that workflow and do it collaboratively with the user, the person who's going to be using the operator, and make sure that you don't minimize all the other things that need to happen, the infrastructure, the thing, the fact that these, you know, things, models are not.
And another great example, Ambient AI, you know, our clients are collecting a lot of this information, right? When you see a doctor today, they are recording. So this is very high-fidelity data. It's not just recording, you know, what you say. It's tone and footsteps and, you know, so many things, great data to have, in addition to everything that the nurse and the doctor are entering on the side. But all this data is collected. So all this data, at some point, who can distinguish what did the nurse write versus what's in the system through the ambient? They have to start thinking about it, and then this is healthcare records. So if you have to start storing all these high-fidelity things for years and years, what does it mean? What is the cost? So thinking through multiple layers of the stack, super important.
It's not important to just build something, oh, I built it and there's a strategy, you should do this. We are very humble. We don't, we know it's hard. So you sit and do the hard work with the client and the ones that want to scale and are ready have great governed infrastructure when we don't have to do it, we are not a, you know, neo-cloud claiming to be. We actually run, we operate mission critical workloads for hospitals and uptime and all that is non-negotiable in today's world with patient care workflows. Why is it going to be negotiable in an AI world? So we look at it as this is another way to build software. How do you build infrastructure solutions and prepare our clients for the future? Doing all the hard work and not just hand-waving all the tough things. And that's why FDE, it's a great model. You're putting the people near that. They're staying accountable, and everybody is building FDEs, but my FDEs stay there day two, deploy, and they're there for the solution.
So it's digging through the complexity of making, understanding how you can deliver an outcome, and ultimately being able to control all of the elements that lead to that outcome, which is going to help when you get around to contracting for pricing against that outcome.
Correct. And there's a lot of ground to be covered to figure out the pricing of these things, how do you define enduring value. But if you engage in the right way and do the nitty-gritty work of solving the problems, because 100% of our clients we're looking to, they've paid the investment. They are not going to scale labor. They are going to want to scale these tools, and it is our mission and hope to help them through that journey.
We're going to have to draw a line at that point. You're going to be around for cocktails afterwards, if anyone has questions. Fantastic. So apologies if we haven't got time for questions right now. But thank you very much indeed.
If you don't have an account, Register here |
With the exception of our Horizons reports, most of our research is available for free on our website. Sign up for a free account and start realizing the power of insights now.
Our premium subscription gives enterprise clients access to our complete library of proprietary research, direct access to our industry analysts, and other benefits.
Contact us at [email protected] for more information on premium access.
If you are looking for help getting in touch with someone from HFS, please click the chat button to the bottom right of your screen to start a conversation with a member of our team.
