The Rise of the FDE Role Amid the AI Deployment Wave: Model Companies, Private Equity, and Consulting Face Transformation

This article comes from the WeChat public account: 硅谷101 (Silicon Valley 101). Interview/text and images: Yiwen. Header image: AI-generated

The hottest job in Silicon Valley right now is none other than the FDE. FDE stands for "Forward Deployment Engineer," which can be directly translated as "前线部署工程师" (Forward Deployed Engineer). They need to understand both models and technology, as well as the customer's data, processes, and business pain points. Their core task is to turn AI from a demo into AI-native workflows for each profession. According to a 2026 survey of 1,500 FDEs by Perspective AI, the median total annual compensation for senior FDEs at frontier labs reached $485,000, while at the senior staff level it was as high as $725,000, with total compensation at top labs falling in the range of $350,000 to $550,000.

Behind this boom is a major strategic pivot by top AI companies. In May of this year, OpenAI partnered with 19 private equity firms to invest over $4 billion in total to establish a Deployment Company, and acquired Tomoro, an AI implementation services company, taking 150 FDEs along with it. Anthropic also announced a partnership with multiple financial institutions, including Blackstone, to establish a joint venture worth $1.5 billion. These top model companies have all begun betting on the same kind of service: not just providing AI tools, but going deep inside enterprises to truly deploy AI capabilities in specific business scenarios.

In this episode, we invited two frontline practitioners to discuss FDEs and Deployment Companies. We talked about what the FDE job actually looks like, its origins in Palantir's early military deployment model, and how private equity and the consulting industry are changing amid this wave of AI implementation.

Jove, head of the FDE team at Cresta. Cresta provides AI agents for enterprise call centers, and Jove began expanding the FDE team at the start of last year. Oliver, a former McKinsey consultant and currently VP of Enterprise Business at Invisible Technologies.

Below are highlights from this conversation:

1. Why are model companies getting into deployment?

Yiwen: Jove, what do you think about the recent moves by OpenAI, Anthropic, and other model companies to start doing AI deployment?

Jove: I think this is partly why FDEs have suddenly gotten everyone so excited. As a job type, FDEs have existed for over a decade, starting with Palantir. Our company started this kind of FDE deployment in January of last year. At the time, we didn't have a clear mandate to hire FDEs, but we vaguely felt we needed to pull some engineers out to get closer to customers, and through this very close engagement, understand what they wanted and put our product to good use.

But over the past month or two, especially in the last week or two, there has been a flood of discussion about FDEs. I knew this moment would come, but I didn't expect it to come so fast and so fiercely. I think this confirms a few things: first, model companies will realize that the model itself is not a product—getting a product to land requires a tremendous amount of work, which traditional model companies tend to overlook or even look down on. But without this kind of very close collaboration, even customers with money who want to buy the model feel that after buying it, they don't know how to use it. We found that the FDE is a very good format for this.

Also, the boundary between model companies and application companies has become very blurry. OpenAI and Anthropic's approach is more like: I still hire the best people to train my models—including Anthropic, as everyone probably knows their models are exceptionally good, but also exceptionally expensive; they can be sold at a high price, and in terms of revenue per employee, it may be very high. But as for landing the model in every industry under the sun—that requires a huge number of people, and I may not want to do that myself. That's why some of this is done through acquisitions, and some through capital, letting other companies do the FDE work. So the friend-and-foe relationship between model companies and application companies has become even more entangled.

2. What FDEs actually do

Yiwen: If you had to define an FDE in one sentence, what would you say?

Jove: An FDE is an engineer who works closely with customers to get AI applications actually running, and who also takes on the responsibility of making the product better. So an FDE must, first, land the AI, and second, take the lessons learned and use them in a direct way to change the product and make it better. It's almost like being a "Forward Deployed CTO"—you are a very well-rounded person: you need to close the deal, land the AI application, and lock in the customer. But as a CTO, you're not just thinking all day about how to make the product better—you even have to disrupt yourself. So that's what an FDE does: land the AI and use those lessons learned to make the product stronger and stronger.

Yiwen: Among the customers you've worked with, how do FDEs change their existing workflows? For example, the Fortune 100 companies you serve are in many different fields, with different needs for AI-powered call centers (Cresta's core business), and the work inevitably involves a lot of terminology, knowledge, and even data from their professional domains. How do these customers communicate their needs to you? And how do you understand those needs and carry out the deployment?

Jove: In the customer experience space, we have relatively deep accumulated experience, having started in 2017. So before this wave of AI, a huge amount of human-to-human conversations were already stored in the Cresta system—of course, we put a lot of effort into compliance and the like. So, for example, big companies like Marriott had human agents even before the agent era, so there's a large volume of text and voice corpora stored at Cresta in a compliant manner.

So you can imagine that once we decide to pick a few AI agent use cases to work on, we will definitely analyze which use cases have high volume but aren't too complex to implement. That means use cases that don't require much human judgment—in other words, where the SOP is fairly clear and the volume is large. Maybe 80% of the business volume comes from 20% of the use cases. Once we have some rough judgments, we can draw on past history to abstract out what typical questions customers are asking, and how an agent—whether human or AI—should effectively resolve those issues with them. This avoids a lot of guesswork, because I believe AI and data need to be well integrated.

When we take on a relatively large deal, the customer has often already been using other Cresta products for a long time. We can extract patterns from their human conversation data, and we can even use their data to train a small model, and use that model to run more simulations. So the FDE has to act as a relatively experienced AI implementation officer, judging which use cases we can start with and whether the resources corresponding to those use cases are in place. If they're not in place, we don't tend to just fix a batch for them—instead, we co-create with the customer, including building a version of the agent afterward, which then requires extensive testing and optimization, which also takes a lot of effort.

Yiwen: Do you need to be on-site to see how customers do this work?

Jove: The term "forward deployment" is quite eye-catching. But neither I nor my colleagues have ever spent more than a week at a single customer site. That's because we FDEs don't need to do initial outreach or anything sales-oriented; rather, by the time we come in, the customer already has strong intent, and they bring us in as experts to figure out the best way to land the deployment.

So we might have a kickoff meeting where everyone flies to their office, and we might hold closed-door sessions for two or three days to set high-level goals, define KPIs, validate the corresponding APIs, and if things go well, we can even do a small PoC (proof of concept) on-site to get them interested. But after that, we each go back home. We have meetings weekly or even daily, and development happens either in the office or at home.

We might get together again during what's called UAT (User Acceptance Testing) on a project, or when we're discussing how to approach the next wave of use cases. And being face to face, people have eye contact, and can even build some personal rapport. Building that rapport and trust early on is very useful for later work. A lot of things people don't feel comfortable putting in writing can be worked out through casual conversations and communication, building more tacit understanding and learning more background context—things that are often hard to achieve unless you're on site.

But all of these purposes combined are about making AI implementation more solid—not forcing customers to learn, but rather understanding what you need and then building it for you. After it's done, you can maintain it yourself if you want, but AI implementation is inherently difficult and time-consuming, and the FDE model makes it a bit easier.

Yiwen: The FDE concept was originally invented and popularized by Palantir. In the earliest days, Palantir actually had two teams, one called Echo and one called Delta, and together these two became what is now an FDE. But the Deltas were probably closer to what we now understand as an FDE—the engineer role—while the Echo folks were more familiar with the professional domain. Can you tell us what you think the core problem Palantir was solving back then?

Jove: Right, Palantir, as the original creator of this model, certainly deserves respect. Of course, their business is quite unusual, because not every vendor can do military work. When they started 10 or 15 years ago, I think it was because many clients were unwilling to spell out exactly what they wanted—you had to be face to face with them, go into the same military camp tent, see the data, before they were willing to get into details. And along the way it might involve things like data modeling or building APIs on the fly. So they hired two teams: one somewhat like forward deployed software engineers, and the other more business-owner-oriented—people who were familiar with combat operations or rescue missions, that kind of thing. One technical, one non-technical.

In the usual sense, the FDE is still a very technical role. For Cresta, we also feel this approach works well. The ideal scenario, of course, is one person who can do everything—like the so-called one-person company, being both CEO and CTO—but such people are hard to hire, and everyone's energy is limited.

So we've made some attempts. For example, early on we had so-called "conversation designers," who were more familiar with the details of human interaction and empathy and didn't need technical skills. Over roughly the past year, our approach has been to pair an FDE with an FDPM (Forward Deployed Product Manager), where the FDPM doesn't need to be as technical.

If the FDE is like a Forward Deployed CTO, you can imagine the FDPM as a Forward Deployed CEO—someone who uses their interpersonal, communication, and negotiation skills to work closely with customers, spending a lot of time building trust and figuring out what they really want. Including things like: when building an agent, what should it say and what shouldn't it say, how should the test set be created—a lot of things that aren't directly related to coding. They don't need to know how security should be done or how the network should be configured, but this is itself a substantial chunk of work, and the FDPM can specifically take ownership of it.

Just as a CEO is responsible for the entire company, the FDPM is responsible for the overall behavior and capability level of the AI agent; the FDE ensures from a technical standpoint that the implementation is sound and that our corresponding tests are robust. The FDE also carries the responsibility of bringing these lessons learned back to the company to make the product better.

With an FDPM and FDE combined—because we easily have many meetings with two or three clients in a single day—not every meeting needs the FDE's attendance, since they might still be discussing what to say first and what to say later. Once there's a conclusion, implementation usually isn't that hard, so the division of labor is different.

The FDE can focus more on industry best practices for AI, turning frequently repeated development work into SDKs, toolkits, and CLIs—contributing more from a technical angle—while the FDPM can manage specific requirements, including handling risks and escalation when needed, and even upselling—you've already done three use cases, can you turn that into six? There's a lot of this. Just think of it as the difference between a CEO and a CTO—I think that's an effective framing. It avoids setting the bar too high for any single hire, and avoids having one person spend their days doing very different things. Splitting it into two roles works better.

Yiwen: So to summarize: the FDE is itself a fairly technical role, while the FDPM is more about industry knowledge. My understanding is that many of these people come from consulting backgrounds, or more from enterprise operations backgrounds. I'd like to take this opportunity to ask: what kind of person do you think is best suited to be an FDE? What does an excellent FDE look like?

Jove: I'll push myself to say this: I want to build the world's best FDE team. Yes, that's the goal. Although we've achieved some results, I honestly think that with Palantir's enormous success, or its rising stock price, it's hard to say what proportion is attributable to the FDE model, because so many factors are involved—but they pioneered this model. The reason FDE has become so hot now is that AI implementation faces so many difficulties, and you don't want to throw that complexity directly at the customer. The FDE can absorb those layers of complexity themselves and deliver a great solution to the customer.

And for many product companies, or SaaS and platform companies, FDEs take lessons learned on the front lines and directly change the product. Think about it: 10 years ago, what could a Palantir FDE do even if they knew the product had many flaws? They could probably only go back and write a letter or file a ticket begging someone to fix it, and maybe it would get fixed six months later.

But because AI coding is now so powerful, our FDEs—of course we set a high bar in hiring and look for strong engineers—on the other hand, with these AI coding agents, Claude Code, and these models, if you know what's wrong, where there's room for improvement, where things could be done differently—even if you have 5 or 10 different repos, different languages, different stacks—you can easily have the AI get it into that shape for you, then find the right person to review it. So iteration is very fast.

Beyond coding, skills themselves are now also a great model—a way to distill knowledge. Previously it all stayed in people's heads, and a lot of time had to be spent on knowledge transfer. Now you can write it as a skill—a long markdown file, some scripts, some reference documentation. After doing two or three similar things, you can turn it into a great skill, and that capability can be quickly reused in the next project. Or, say we now have 30 FDEs and 20 more join—those 20 FDEs can just install the skill and access it; they don't even need to learn it. So it easily becomes a snowball effect. FDE is definitely in a good state right now—hiring more FDEs to drive implementation.

Including my trip to New York TechWeek this time—I'm hoping to run some events and hire the right people. First, they need to be a fully qualified engineer, because this role is essentially like a CTO—you certainly wouldn't want someone who can't write code well as a CTO, so they must be technically strong. Since the team I'm hiring for is limited to AI agent FDEs, I don't have particularly strong requirements around data engineering or information security, but you absolutely must know AI agents.

A lot of times I see a resume that says "I'm an AI engineer," and I think—well, obviously? These days, if you're a software engineer who isn't an AI engineer, you're already falling behind. Nobody expects you to write every line of code yourself. You have to know how to use these harness frameworks, use Cursor, use Claude Code.

However, not many people know how to develop and test AI agents, and this is a skill we care deeply about. We don't want to spend two or three months training someone; ideally, a person should be able to join a project within two to three weeks. So you need to be a good developer, and you need to have developed and tested AI agents.

The other thing is that they need solid, convincing experience working directly with clients. After all, we're doing forward deployment—even if in the past you've only had online meetings, or occasionally spent a few days on-site, you still need to communicate with the client's CTO, their IT director, and their senior people; sometimes you also communicate with non-technical staff.

You should know how to simplify a complex problem, or be able to pick up on specific points from what they're saying and verify them; sometimes you have to say no. This isn't just about communication in English—it's about being seasoned as a whole person, essentially like a CTO—a CTO can't just be someone who writes code.

So for these skills, I generally expect candidates to have either done consulting, or been a founding engineer themselves, or have extensive freelance experience—I think all of those are great. Beyond coding and client-facing work, what remains is that people need to be reliable and resilient, because being an FDE is genuinely exhausting—you're juggling many things at once, under a lot of pressure, facing a deeply imperfect world—where APIs are paper-thin, SOPs are as good as nonexistent, and documentation is all over the place.

The pressure is intense, and people may have unrealistic expectations, so you need a strong ability to face enormous complexity and enormous uncertainty. That means having independent judgment—knowing how to push things forward, and how to step outside the box to get things done.

So I really like hiring founders, co-founding engineers, or people who have weathered many storms—people who understand that nothing is guaranteed to succeed, and that you simply have to work extremely hard to reach a state that's just slightly better.

This kind of reliability and resilience is something we hope to see demonstrated through exactly this kind of experience. I don't hire any junior FDEs, because as I mentioned earlier, a project might have only one or two people co-creating with the client's CTO. A very junior person would struggle to earn that kind of trust, and often wouldn't know where to start—you can't just open an AI tool and ask it to tell you what to do; without your own judgment, your ability is very weak. So technical skills absolutely have to be there, your client-facing abilities have to be there, and you need to be able to handle many things, end to end.

Yiwen: You just said that FDEs face an imperfect world, working with agent tools that are still relatively new. So will this role be a long-term position, or a transitional one? In the AI era, as tools keep iterating and maturing on their own, do you think this role will change? Or will it disappear?

Jove: The only constant is change, but compared to many other software engineering jobs, I think there's still a long way to go before FDEs get replaced by AI. In the short term—say, one to two years—there will certainly be more and more tools that make FDE work more efficient. For example, a lot of our calls and communications are now recorded by tools like Gong, which can transcribe them, and you can even ask questions against the recording; yes, and we have tools like Glean that can search the latest chat logs and surface code snippets.

The emergence of these tools makes those of us juggling multiple things more efficient. Sometimes I might have two or three meetings booked in the same time slot on my calendar—you're bound to miss some—and these tools let you be present in multiple places at once, or at least avoid missing many specific details.

But these tools can enable FDEs—for example, suppose we currently average two to three projects per person; after a while it might become five to six. So improvements in tools will make us more efficient, or able to do more. But further out, things will diverge: there will be demand for many highly senior FDEs to tackle the really hard problems. You can use all kinds of tools, but the tools themselves can't solve them—you still need very experienced people to do that.

On the other hand, there will be a large group of people who previously didn't need FDEs thinking, "Can I hire a cheap FDE?" Just like what's happening with software engineers—hiring demand is actually rising, because small clinics and sole proprietors who previously thought they couldn't afford a software engineer now think they can hire one to productize one of their workflows.

Correspondingly, a batch of FDEs will emerge targeting small and medium-sized businesses, targeting this long tail, even remote ones—say, in Vietnam or other less developed places—FDEs who may never go on-site, but who combine the client's needs with their AI skills to build what's needed. If they can distill that into a product of their own, that's another viable model.

So as long as this kind of client complexity still exists, there will always be a gap in what AI can fully automate, and that gap needs to be filled by FDEs. Only when the day truly comes—say, a fully AI FDE—even now, SDRs (Sales Development Reps) haven't been well automated by AI—suppose one day 99% of FDE work can be automated by AI, whether it's understanding clients, writing prompts, running tests, communicating with clients, or even the AI conducting agent-to-agent communication and alignment with another client's AI—at that point, what we'd worry about wouldn't be FDEs themselves; the entire industry and world would already be different, and human involvement would be minimal. But I think there's still a long road to get there.

I'm very confident about FDEs: this profession will become richer and richer, more and more people will join it, and everyone will increasingly recognize its importance.

III. Private Equity and a Key Entry Point for AI Deployment

In my interview with Jove, two layers of questions emerged for us: First, what deployment companies do—including going deep into enterprises, transforming their processes, and helping them use AI well—is actually quite similar to the logic of traditional consulting. Will the consulting industry be replaced by this wave? Second, as Jove mentioned, why would model companies seek partnerships with PE firms? We know that institutions like Blackstone hold large portfolios of portfolio companies, many of them traditional businesses that have been operating for decades. For PE, what exactly is the appeal of this partnership?

Jove touched on part of this from his perspective. Next, I spoke with Oliver, who has a consulting background and long experience serving PE clients, about these two questions from the angle of industry change.

Yiwen: Hello Oliver, could you briefly introduce yourself and your current company to our listeners?

Oliver: Thank you, Yiwen. I'm Oliver, VP of the enterprise business at Invisible Technologies. My job is to help enterprise clients deploy AI using our solutions. Before this, I did private equity consulting at McKinsey, on a team called Rewired, which specialized in helping companies rethink their business models to become more technology-driven and AI-driven.

Yiwen: You said you help companies deploy solutions—what do those solutions look like specifically?

Yiwen: It sounds like what you're doing is quite similar to the "Deployment Company" OpenAI announced a while back—they're also helping enterprises deploy AI. How do you view their move? Why do you think they're doing it?

Oliver: I think they're doing exactly the right thing. Over the past six months, you can clearly sense CFOs and corporate executives talking more and more about cutting costs. Meanwhile, research reports from MIT and Stanford also show that very few companies have actually gotten AI working and scaled it up. This gap is unsustainable—it can't go on like this. So large model vendors must drive real adoption on the enterprise side and prove ROI; just selling a chatbot won't achieve that. If they want to open this door, they have to take the same path we do.

So I think this move is well-timed. Of course, they have massive capital and strong technical capabilities, so they can certainly pull it off. It's just that their original playbook was very horizontal—although they had some vertical applications, at their core they build general-purpose large models, and now they're suddenly pivoting to building customized workflows for enterprises. That's a completely different market move, a completely different sales approach, very different from the playbook they're used to. I believe they'll figure it out, but it will take some time.

Yiwen: I'd like to start this question from the private equity side. You mentioned you serve a lot of financial institution clients, and I feel there are two threads here: one is these institutions using AI internally, and the other is the companies they invest in—portfolio companies, many of which are traditional SaaS companies that PE firms have invested in and may also need to transform. What do you think they need most right now? What are they afraid of? And is this why they're going to partner and invest with OpenAI and Anthropic?

Oliver: I think PE and private capital firms have three core needs.

The first is signaling value. I've been working with PE firms for a while: three years ago, people were still asking "can you come explain how AI works"; two years ago it became "can you help me think about how to roll out AI across the entire portfolio"; this year it has completely changed—they come to me saying "I need to fundraise from LPs, from pension funds, from my capital providers, and I have to prove I'm at the forefront of AI. I need case studies showing I've created value through AI, otherwise LPs won't give me money." It's a completely different logic. For GPs today, being able to demonstrate AI capability is now a matter of fundraising survival. Partnering with the loudest names in the industry is a great form of endorsement, so the signaling value is very high.

The second is portfolio value creation. This is also a very real need. When AI is used correctly, it really can create significant value. The details are complex, but this part is genuinely real.

The third is the investment returns themselves. The structure of these partnerships is quite attractive—essentially, they let GPs enter a high-return track and gain exposure to high-growth assets. From that angle, the logic makes complete sense too.

Yiwen: I find your first point really interesting. What do you think is driving LPs to push for AI?

Oliver: It's the same reason most companies are pushing AI. From an ordinary consumer's perspective, the more content you read about it, the more you sense what AI can do. The pace of change is genuinely frightening—everything feels like it's moving at a crazy speed. So everyone realizes AI can do so much, and if you're not seriously working on AI, you're falling behind.

From the LP's perspective, if I'm giving my money to a GP, of course I want to make sure they're also using AI to transform their portfolio companies—that's a very real need. And one more point, since you mentioned SaaS: over the past five to ten years, the two biggest asset classes for PE have been healthcare and software—almost every PE firm has exposure to software companies. This year, the "SaaS is dead" narrative has been making a lot of noise, and both LPs and GPs are highly anxious. GPs are all scrambling to prove "we're fine," so the signaling value is amplified even further.

That said, if you look at partnerships like Anthropic's with Coatue, the counterparties aren't pure software investors—because you're right, the biggest value creation from AI often comes precisely from non-software companies.

Yiwen: Right, those traditional businesses—industrials, manufacturing, and so on.

Oliver: Business services, industrials, healthcare—especially healthcare, which is enormous. Basically every industry where software couldn't previously help much can now do really interesting things with software. Another great example is the GP itself. What do PE firms do? Source deals, value companies, invest capital, manage assets. This is highly labor-intensive work that requires very expensive people—whether internal teams or external advisors. This workflow is precisely the kind that's most suited to AI transformation. I have a major client, a very large asset manager, and we've been able to help them transform these workflows with astonishing results.

Yiwen: Can you give us a few concrete examples? When I talk to a lot of finance practitioners these days, they're still using AI for research and summarization—the same use cases tied to large language models. I'm quite curious how you manage to truly automate workflows.

Oliver: Sure, there's a lot to talk about. If you break down an investment fund's business, it roughly consists of several modules: fundraising, investment management, compliance and finance, and fund operations. Let me pick a few workflows as examples.

Let's start with fundraising. I have a major client, a very large asset manager, who wanted to partner with a smaller asset manager—the smaller firm would incorporate their products into its own product line and take a commission, which sounded good. But the smaller firm said every client meeting would need one of the large firm's sales managers present—something the large asset manager obviously couldn't accept, because the profit would disappear; it was simply not viable. So they came to us asking if we could build an AI sales assistant to participate in these conversations.

The workflow goes like this: first, they have roughly a thousand products, so you need to build the data infrastructure to integrate those thousand products; then build an input layer so the other party can enter client data, with permissions properly segregated; then a computation module that calculates the optimal product mix for a given client—this part is deterministic, since it's essentially math; then generate sales talking points for pre-meeting preparation; then a tool for use during the meeting; and finally, after the meeting, automatically update the product proposal based on the meeting notes. It's a complete feedback loop, about seven steps. This system allows the large asset manager to serve a much broader range of clients—a classic case.

Another one I find really interesting is the investment decision process itself. When doing due diligence, you typically have to run ten parallel workstreams, hiring lawyers and all kinds of advisors—commercial due diligence, environmental due diligence, and so on. Coordinating with all these people puts a lot of pressure on the investment team. We're building them a platform where they can interact with all their advisors, push questions to them, and automatically scan the entire data room. You can see a real-time interface tracking all the advisors' progress, and you can also pull up questions this fund has asked in similar deals in the past, drawing on lessons learned from previous investments.

This way, they can leverage the firm's institutional knowledge while dramatically streamlining communication with external advisors. The final document outputs are automated too, which was previously a major burden. I've seen too many investors working weekends on this stuff, and I'm glad to help them save that time.

There's also fund operations—things like net asset value calculations or account reconciliations. Every month, or even every day after market close, you have to confirm account balances are correct. My first job was bookkeeping, which was extremely time-consuming, but this process can be fully automated. Okay, I've said a lot—I just wanted to show you some useful scenarios.

Yiwen: Based on what you just said, I'm actually wondering—do you think AI has changed the game of PE acquisitions? In the past, when we talked about a PE firm acquiring a company, we might think of things like post-investment M&A between portfolio companies, some roll-up consolidation. Now it feels like we've almost entered an era of so-called "AI roll-ups"—on the surface you're buying these companies, but what you're actually buying is their workflows, and then we transform them into an AI-native company. Do you think this will change how PE itself operates?

Oliver: I've seen many different approaches, but they mainly fall into two categories. The first type of investor says: any area where AI disruption risk is too high, we won't invest in—that's actually many people's gut reaction. The second type is investors who more actively embrace this, saying that right now is actually a very interesting moment to create value through AI. The Amex GBT deal is a great example, and there are many similar deals.

Investors are acquiring businesses that historically weren't very technology-intensive and aggressively empowering them with technology and AI. So this is clearly becoming an emerging playbook, and some forward-leaning GPs are already doing it. And I believe the scale of value they can create is real.

But actually creating that value is not a simple matter. One problem I see now is that there's a big gap between what many people imagine they can achieve and what can actually be delivered in reality. I want to emphasize a core point: a common mistake many people make is understanding AI only as a cost-reduction tool. But in reality, AI's true value often lies in creating revenue and opening up new revenue opportunities.

So I often ask clients a question: if I gave you ten thousand college-educated employees for free right now, what would you do? What have you always wanted to do but couldn't? Because in some sense, that's the capability AI brings today. Like the two asset manager examples I just gave—for them, it means being able to enter an entirely new customer or business segment—a market they simply couldn't reach before. So this isn't about reducing costs; it's about increasing revenue.

I think this is actually the direction many companies should truly be heading. But right now, everyone is still very focused on the cost reduction that AI brings, and I don't think that's the most compelling entry point. What they should really be thinking about is: what things could I not do before that I can do now? In other words, revenue creation.

It can take many forms. Let me give you another example: one of our clients is a dairy company with lots of farms and cows. When we talked with them, we asked: if you had ten thousand people, what would you do? They said, that's an interesting question—we would write reports for every single account, because they wanted to reduce the time spent on those reports and spend more time keeping their cows healthy. So we helped them build a full data integration and custom AI system to generate health reports for every cow. That way, they could reclaim more time to actually keep their cows healthy—something that simply wasn't feasible in the past.

4. How is AI changing consulting and businesses themselves?

Yiwen: It sounds like what you're doing is quite similar to what consulting firms do, which brings me to another topic I wanted to raise. Traditional consulting firms used to help clients handle areas they weren't familiar with themselves, but now tech companies and AI companies like yours seem to be taking over that role, using AI to transform processes. Do you think the consulting industry will become obsolete as a result? Or will consulting itself turn into AI transformation consulting?

Oliver: I think over the next three to five years, consulting will see a wave of growth, because every business talking about AI needs to rethink its business model. The simplest example is law firms: they used to bill by the hour, and that's getting harder and harder; if they switch to outcome-based billing, the entire incentive structure changes. For a transformation like that, you want someone to talk to—you want to know how others have done it, whether there's experience you can draw on. You need someone to walk you through that journey. So I believe there will be a clear increase in demand for consulting over the next three to five years.

But the ones who truly unlock value are those who ultimately leave behind a transformed business. So I think AI labs and companies like ours—this model of doing the work and then leaving, but leaving behind a transformed business—is the way to genuinely create value, rather than just talking about how to transform.

That said, there's a lot of uncertainty in the market right now, and everyone is in wait-and-see mode, so the demand for consulting is real—people don't know what to do or where to start. That's also a big part of my job: sitting down with clients to first figure out which things are worth doing first, and that has to be analyzed case by case.

Yiwen: Have you ever encountered a company that thought it could handle a certain workflow with AI on its own, but in reality it simply didn't work? For example, are people sometimes too optimistic about AI, or do they misunderstand how AI works?

Oliver: The most common problem is wanting to AI-ify everything, but the reality is that path doesn't work. You have to get a few things right. The most critical one is a good data platform, whose value compounds over time. No matter how smart the AI is, without sufficient information and knowledge, it can't do anything. We have a data module called Neuron that specifically helps you integrate data, map it out clearly, and make sure the data is usable. This is the first hurdle for most companies, and it's not cheap, because they've never done anything like it before.

The second common mistake is this: in a ten-step workflow, not every step should use AI. You can use AI to optimize the overall process, clarify the logic, and delineate which steps are deterministic, but not all steps should be handed to AI. Take financial processes like account reconciliation—you wouldn't want AI doing that; what you want is a deterministic result. So you can use AI to help you sort out the workflow logic, but many of the specific execution steps should be hardcoded, deterministic mathematical calculations. I think the two biggest pitfalls are, first, data, and second, letting AI do things that should be deterministic.