Lately, the hottest job in Silicon Valley is undoubtedly FDE. FDE stands for "Forward Deployment Engineer." They need to understand both models and technology, as well as the client's data, processes, and business pain points. Their core mission is to transform AI from a demo into AI-native workflows tailored to each profession. According to a 2026 survey by Perspective AI of 1500 FDEs, the median total annual compensation for senior FDEs in leading labs reached $485,000, while for experienced staff it was as high as $725,000. Top labs' total compensation ranges between $350,000 and $550,000.
Behind this frenzy is a major strategic shift by top AI companies. In May of this year, OpenAI, in collaboration with 19 PE firms, invested over $4 billion in total to establish a Deployment Company and acquired an AI implementation service company, Tomoro, taking its 150 FDEs along. Anthropic also announced partnerships with multiple financial institutions, including Blackstone, to form a $1.5 billion joint venture. These top model companies are now betting on the same service: not just providing AI tools, but deeply embedding themselves within enterprises to truly deploy AI capabilities in specific business scenarios.
On this episode of "Silicon Valley 101," we invited two frontline practitioners to discuss FDEs and deployment companies. We talked about the specific nature of the FDE role, its origins in Palantir's early military deployment model, and how private equity and the consulting industry are changing amidst this wave of AI adoption.
Jove, Head of the FDE Team at Cresta. Cresta provides AI Agents for enterprise call centers. Jove has been expanding his FDE team since the beginning of last year.
Oliver, former McKinsey consultant, current VP of Enterprise Business at Invisible Technologies.
Here are selected highlights from our conversation:
01. Why Are Model Companies Starting Deployment?
Yiwen: Jove, how do you view the recent moves by OpenAI, Anthropic, and other model companies to start AI deployment?
Jove: I think this is precisely why FDEs have suddenly captured everyone's attention. As a job type, FDEs have existed for over a decade, starting with Palantir. Our company started deploying FDEs last January. At the time, there wasn't a clear mandate to hire FDEs, but there was a vague sense that we needed engineers to get closer to customers. Through this very close service, we could understand what they wanted and implement our product effectively.
But in the past month or two, especially the last couple of weeks, there's been a huge surge in discussion about FDEs. I knew this trend was coming, but I didn't expect it to be so fast and fierce. However, I think this confirms a few things: First, model companies are realizing that the model itself is not a product. Turning it into a product requires a lot of work—something traditional model companies often overlook or even disdain. But without this very close collaboration, even customers with the budget to buy the model feel lost about how to use it. We've found FDEs to be a very effective format.
Furthermore, the boundary between model companies and application companies is becoming blurred. The approach of OpenAI and Anthropic is more like: We'll still hire the best people to train our models—like Anthropic, whose models are known to be excellent but also very expensive, allowing for high pricing and potentially high efficiency per person. But as for deploying to every industry out there, that requires a lot of manpower. That's something they might not want to handle themselves, which is why some choose acquisitions and others use capital to have other companies handle FDE work. So, the relationship between model companies and applications becomes even more entangled, both friend and foe.
02. The Specific Work of an FDE
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 clients to get AI applications truly running, and they bear the responsibility of improving the product based on that experience. So, an FDE's job is twofold: first, to deploy AI; second, to take the lessons learned and directly improve the product. They're almost like a "Forward Deployed CTO"—a very well-rounded person. You need to close deals, deploy AI applications, lock in customers; but as a CTO, you're not just thinking about improving the product; you might even need to self-disrupt. So, that's what an FDE does: deploy AI and use those lessons to make the product stronger.
Yiwen: In your experience with clients, how do FDEs change their existing workflows? For instance, you serve Fortune 100 companies across different fields, each with different needs for an AI-powered call center (Cresta's core business). The work likely involves a lot of their domain-specific terminology, knowledge, and even data. How do these clients communicate their needs to you, and how do you understand and deploy based on them?
Jove: In the customer experience domain, we have relatively more accumulated experience, having started in 2017. So even before the AI wave, a vast amount of human-to-human conversations were already in Cresta's system, of course with significant effort on compliance, etc. So, for large companies like Marriott, even before the Agent era, there were human agents, so we have a lot of that text and voice data stored compliantly within Cresta.
So you can imagine, once we decide to pick a few AI Agent use cases to implement, we would certainly analyze which use cases have high volume but aren't overly complex to implement—meaning those with less human judgment, relatively clear SOPs, and high volume. Perhaps 80% of the business volume comes from 20% of the use cases. With some initial judgments, we can leverage past history to abstract out what typical questions customers ask and how an agent—whether human or AI—should effectively resolve them. This avoids a lot of guesswork because AI and data need to be well integrated.
When we take on a relatively large project, the client has often been using other Cresta products for a long time. We can analyze their human conversation data to identify patterns; we can even train a small model on their data to run more simulations. So the FDE acts as a relatively experienced AI implementation officer, judging which use cases to tackle first and whether the corresponding resources are in place. If not, we don't just change things for them; we prefer to co-create with the client. Even after building a version of the Agent, it requires extensive testing and optimization, which also takes a lot of effort.
Yiwen: Do you need to go on-site to see how clients perform these tasks?
Jove: The term "forward deployment" is quite attention-grabbing. Personally, and for my colleagues, we've never spent more than a week at a client's site. Our FDEs don't handle initial outreach or pre-sales activities; it's more that there's already strong intent, and we're brought in as experts to see how best to implement.
We might have a kickoff meeting where we fly to their office, have a closed-door meeting for two or three days to set high-level goals, define KPIs, validate the relevant APIs, and if things go smoothly, maybe even run a small PoC (Proof of Concept) on-site to generate interest. But after that, we go back to our respective bases. We have meetings weekly or even daily, and development happens either in the office or at home. We might gather again during the project's UAT (User Acceptance Testing) phase or when discussing the next wave of use cases. Face-to-face meetings allow for eye contact and can build personal rapport. Building that rapport early fosters trust, which is very useful for subsequent work. Often, things that aren't easily put in writing can be communicated through chats and conversations, building more默契 (tacit understanding) and providing more background context—things hard to achieve without being on-site.
But all these purposes are aimed at making AI implementation more solid, not forcing the client to learn, but rather understanding what they need and building it for them. After it's done, they can maintain it themselves if they want. But AI implementation is inherently difficult and time-consuming; FDEs just make it slightly easier.
Image source: Pixabay
Yiwen: The concept of FDE was invented and popularized by Palantir initially. Early on, Palantir actually had two teams, one called Echo and one called Delta. Together, they formed an FDE. But perhaps Deltas are closer to what we understand as FDEs today—the engineering role. The Echo group was more familiar with the professional domain. Could you tell us what core problem Palantir was solving back then?
Jove: Yes, Palantir, as the original creator of this model, certainly deserves respect. Their business was quite unique, as not every vendor can work with the military. When they started 10 or 15 years ago, I think because many specific requirements weren't clearly stated—you had to be face-to-face, in the same military tent, seeing the data before they'd share details—and it involved data modeling or creating APIs on the fly. So they hired these two teams: one was like on-site forward-deployed software engineers, and the other was more like business leads—familiar with operations or rescue missions, for example. One was technical, the other non-technical.
Typically, an FDE is still a very technical role. At Cresta, we also find this approach suitable. The ideal, of course, is one person who can do everything, like a so-called one-person company where you're both CEO and CTO. But such people are hard to find, and everyone's energy is limited. So we've experimented. For example, early on we had "conversation designers" who were more familiar with human interaction, empathy, and details, without needing deep technical skills. Our approach for the past year or so has been pairing FDEs with FDPMs (Forward Deployed Product Managers). The FDPM doesn't need to be as technical.
An FDE is like a Forward Deployed CTO; you can imagine the FDPM as the Forward Deployed CEO. They use their interpersonal skills, communication, and negotiation abilities to deeply engage with the client, spend a lot of time building trust, and understand what they truly want. This includes things like what an Agent should or shouldn't say, how to create test sets—tasks not directly related to coding. They don't need to know about security configurations or networking, but this is a substantial piece of work. The FDPM can specialize in managing this. Like a CEO is responsible for the entire company, the FDPM is responsible for the entire AI Agent's behavior and capability standards. The FDE ensures the technical implementation is sound, corresponding tests are robust, and also bears the responsibility of bringing lessons learned back to the company to improve the product.
Pairing an FDPM with an FDE works well because we often have meetings with two or three clients a day. Not every meeting requires the FDE's presence—they might be discussing what to say first, what to say later. If conclusions are reached and the implementation isn't difficult, then the分工 (division of labor) is different. The FDE can focus more on AI industry best practices and how to turn frequently needed development tasks into SDKs, toolkits, or CLIs, contributing more from a technical angle. The FDPM can manage specific requirements, including risks, escalation, or even upselling—like moving from three use cases to six. There's a lot of that. Think of it as the difference between a CEO and a CTO. I think it's effective because it avoids setting the hiring bar impossibly high and prevents one person from having to juggle too many different tasks daily. Separating the roles works better.
Yiwen: So to summarize, an FDE is essentially a highly technical role, while an FDPM requires more industry knowledge. I imagine many FDPMs come from consulting backgrounds or have more enterprise operations experience. I think this is a good opportunity to ask: What kind of person is best suited to be an FDE? What does an excellent FDE look like?
Jove: I'll try to be concise: I aim to build the world's best FDE team. It's a goal. While we've achieved some success, I believe Palantir's huge success or its stock rise—how much of that is due to FDEs? It's hard to say because there are many factors, but they pioneered this model. Now FDEs are hot because AI implementation is so challenging, and this complexity shouldn't be dumped on the client. FDEs can digest these complex layers and deliver a good solution.
For many product, SaaS, or platform companies, FDEs take frontline lessons and directly improve the product. Think about it: 10 years ago, even if a Palantir FDE knew the product had flaws, what could they do? Maybe write a letter or submit a ticket begging for changes, which might take six months. But now, with powerful AI coding, our FDEs—we hire with a high bar, seeking good engineers—but also, because of AI Coding Agents, Claude Code, or other models, when you know what's wrong, what needs improvement, or what could be done differently, even across five or ten different repos, languages, or stacks, you can easily have the AI implement it, and then just have someone review it. So iteration is much faster.
Beyond coding, skills themselves can now be effectively distilled using models. Previously, knowledge stayed in people's heads, requiring lots of time for knowledge transfer. Now you can write it as a skill—a long markdown with scripts and reference docs. After doing two or three similar things, it becomes a valuable skill that can be quickly applied to the next project. Or if we have 30 FDEs and hire 20 more, the new ones can just install and access these skills without having to learn them. This creates a snowball effect. So now is a good time for FDEs; hiring more FDEs can accelerate deployment.
I'm here in New York for TechWeek partly to host events and find the right people—they first need to be competent engineers because, like a CTO, you don't want someone who can't code well. They must be technically strong. Since my team focuses specifically on AI Agent FDEs, I don't require as much expertise in data engineering or information security, but they absolutely must know AI Agents.
I often see resumes saying "I'm an AI engineer." Well, nowadays, if you're a software engineer and *not* an AI engineer, you're already out of the game. No one expects you to write every line of code yourself. You must know how to use harness frameworks, Cursor, Claude Code. But not many people know how to develop and test AI Agents. That skill is crucial for us. We don't want to spend two or three months training someone; they should be able to join a project within two to three weeks. So you need to be a good developer who has built and tested AI Agents.
Another aspect is having solid, credible experience interfacing with clients. After all, we are forward deployed. Even if most meetings are online or occasional short trips, you still need to communicate with the client's CTO, IT director, senior personnel, and sometimes non-technical staff. You should know how to simplify complex issues or pick up specific points from their explanations for verification; sometimes you have to say no. This involves not just English communication skills but overall maturity—like a CTO who isn't just a coder.
This skill often comes from having done consulting, being a founding engineer, having extensive experience, or even being a freelancer—all are good backgrounds. Besides programming and client interaction, the remaining qualities are being reliable and resilient, because FDEs are genuinely busy. You multitask, handle pressure, and face an imperfect world—APIs might be flimsy, SOPs non-existent, documentation all over the place. The pressure is immense, and people might have unrealistic expectations. So you need a strong ability to handle massive complexity and uncertainty. You need autonomy to know how to push things forward and when to step in.
That's why I like hiring founders, co-founding engineers, or people who've been through storms—those who know nothing is guaranteed, and you must work extremely hard just to reach a slightly better state. This reliability and resilience are qualities we look for. I don't hire any junior FDEs because, as mentioned, a project might only have one or two people co-creating with the client's CTO. A junior person would struggle to build that trust and might lack direction; you can't just ask AI what to do without your own judgment. So technical capability must be there, client-facing skills must be there, and you must be able to handle many things end-to-end.
Yiwen: You mentioned FDEs face an imperfect world and relatively new Agent tools. Is this role a long-term position or a transitional one? In the AI era, as tools continuously self-iterate and mature, do you think this role will change or disappear?
Jove: The only constant is change. But compared to many other engineering roles, the path to automating FDE work with AI is still long. Short-term, say 1-2 years, there will be more tools to make FDEs more efficient. For example, many calls or conversations can be recorded with tools like Gong, transcribed, translated, and even queried. Tools like Glean can search recent chat logs and code. These tools help those juggling multiple tasks be more efficient. Sometimes my calendar has two or three meetings overlapping; I'll miss some, but these tools help me be "present" in more places or not miss key points.
These tools might allow an FDE—say currently handling 2-3 projects on average—to handle 5-6 later. So tool improvements boost efficiency and capacity. But looking further, there will be differentiation. High-end FDEs will tackle the hardest problems. You can use all sorts of tools, but the tools themselves won't solve everything; you still need very experienced people.
On one hand, many who previously didn't need FDEs might think, "Can I hire a cheaper FDE?" Similar to the trend with software engineers, demand might actually rise. Small clinics, individual proprietors who thought they couldn't hire a software engineer might now think they can to productify a workflow. Correspondingly, there might emerge a batch of FDEs targeting SMBs, long-tail markets, or remote locations like Vietnam—FDEs who never go on-site but combine client needs with their AI skills to deliver. If they can productize their own solutions, that's another model.
So as long as client complexity exists, and there's a gap in what AI can fully automate, that gap will need FDEs to fill. If one day there's a fully AI FDE—even now SDRs (Sales Development Representatives) aren't fully automated—if 99% of FDE work could be AI-automated, from understanding clients, writing prompts, testing, to client communication, even AI-to-AI agent communication between companies, then we wouldn't just be worried about FDEs; the whole industry and world would be different, with minimal human involvement. But I think that's a long way off.
I'm very confident about FDEs. This role will become more diverse, involve more people, and its importance will be increasingly recognized.
03. Private Equity as a Key Entry Point for AI Deployment
Our conversation with Jove raised two questions: First, what deployment companies do—embedding in enterprises, transforming processes, helping them use AI effectively—sounds similar to traditional consulting. Will consulting be replaced by this wave? Second, as Jove mentioned, why are model companies partnering with PE? Institutions like Blackstone hold vast portfolios of companies, many traditional businesses operating for decades. What's the appeal for PE in these collaborations?
Jove touched on part of this. Next, I spoke with Oliver, who has a consulting background and long-term experience serving PE clients, to discuss these industry changes.
Yiwen: Hello Oliver, please briefly introduce yourself and your current company.
Oliver: Thanks, Yiwen. I'm Oliver, VP of Enterprise Business at Invisible Technologies. My job is to help enterprise clients implement AI using our solutions. Before this, I was at McKinsey in private equity consulting, part of the Rewired team, which helps companies rethink their business models to become more tech-driven and AI-driven.
Yiwen: You said you help companies implement solutions. What kind of solutions specifically?
Oliver: Sure, let me briefly explain what we do. Our company is Invisible Technologies. Our name comes from the idea that when technology is done well enough, it becomes invisible—you don't feel it. Our approach differs from many software companies. In daily life, we all use AI tools; they're great, but that's precisely the problem: there's a huge gap between individual AI usage and enterprise adoption. This gap is largely due to how the market serves enterprises.
Think about the current market: either big model vendors sell directly, or there are wraparound products—like Harvey for law or Granola for meeting notes. They're good tools, but they don't change how you work; they just enhance existing methods. The result is many companies deploy AI but don't see transformative change.
So we took a different path: instead of implementing tools one by one, we切入 (enter) workflow by workflow, building customized software for each company. We deconstruct a workflow. Say there are ten steps; we determine that five must be deterministic due to mathematical calculations, compliance, etc.—they can't be wrong. Three or four steps can use AI, allowing for some flexibility. Two steps might need human review to ensure everything's correct. This is the right way to truly use AI to change business.
But to do this, you must customize for each company because every company, every department's processes are different. So if you want to turn "pre-AI" companies into AI-native ones, you must build customized software adapted to their workflows. That's what we do—we built a modular platform so we can do it quickly.
Yiwen: What you're doing sounds quite similar to what OpenAI recently announced with its "Deployment Company"—also helping enterprises implement. How do you view their move? Why do you think they're doing this?
Oliver: I think they're very correct. Over the past six months, you can clearly see CFOs and enterprise executives talking more about cost compression. Meanwhile, reports from MIT and Stanford show that very few enterprises have truly operationalized and scaled AI. This gap is unsustainable; it can't continue. So big model vendors must drive real adoption on the enterprise side, prove ROI. Just selling a chatbot won't do that. To open that door, they must take the same path we're on.
So I think it's a very well-timed move. Of course, they have massive capital and strong technical capabilities; they'll certainly succeed. But their original approach was very horizontal—though they have some vertical apps, essentially they build general models. Now suddenly shifting to building customized workflows for enterprises is a completely different market motion, a completely different sales motion, very different from what they're used to. I believe they can figure it out, but it will take time.
Yiwen: I'd like to start by discussing the private equity side. Since you serve many financial institution clients, I see two lines here: one is these institutions using AI internally; the other is their portfolio companies—many traditional SaaS companies PE firms invest in that may also need transformation. What do you think they need most right now? What are they afraid of? And is this why they're partnering with OpenAI and Anthropic?
Oliver: I think PE and private capital firms have three core demands.
First is signaling value. I've been dealing with PE firms for a while: three years ago, they'd ask, "Can you come explain how AI works?" Two years ago, it became "Can you help me think about rolling out AI across my portfolio?" This year, it's completely changed. They come to me saying, "I need to raise funds from LPs, from pensions, from my investors. I must 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. Now for GPs, demonstrating AI capability relates to fundraising survival. Partnering with the biggest names in the industry is excellent validation, so the signaling value is very high.
Second is value creation for the portfolio. This is a very real need. Using AI correctly can create significant value. The details are complex, but this aspect is genuine.
Third is the investment return itself. The structure of these collaborations is quite attractive. Essentially, it allows GPs to enter a high-return sector, gaining exposure to high-growth assets. From that angle, the logic also holds.
Yiwen: Your first point is interesting. What's driving LPs to push for AI?
Oliver: It's the same reason most companies are pushing AI. From a consumer perspective, the more you read about what AI can do, the more you realize its potential. The pace of change is truly frightening; everything seems to be moving at breakneck speed. So everyone realizes AI can do so much; if you're not seriously doing AI, you're falling behind.
From an LP's perspective, if I give money to a GP, of course I want to ensure they're also using AI to transform portfolio companies. It's a very real need. Another point, since you mentioned SaaS: Over the past five to ten years, PE's two biggest asset classes have been healthcare and software. Almost every PE has software exposure. This year, there's been a lot of noise about "SaaS is dead." LPs and GPs are highly nervous. GPs are trying hard to prove "we're fine," so the signaling value is amplified further.
But looking at Anthropic's collaborations with Coatue and others, the partners aren't pure software investors. Because you're right: the biggest value creation from AI often isn't in software companies.
Yiwen: Right, it's those traditional enterprises, including industrial, manufacturing, etc.
Oliver: Business services, industrial, healthcare—especially healthcare, that's huge. Basically, all industries where software couldn't help much before can now do very interesting things with software. Another great example is the GP firms themselves. What does a PE firm do? Source deals, value them, invest, manage assets. It's very labor-intensive, using very expensive people—whether internal teams or external advisors. This workflow is precisely ripe for AI transformation. I have a large client, a very big asset management firm. We're transforming their workflows, and the impact is astonishing.
Yiwen: Could you give some concrete examples? Talking to many finance professionals, they seem to use AI mainly for research, summarization—things related to LLMs. I'm curious how you truly automate workflows.
Oliver: Sure, there's a lot to share. Breaking down an investment fund's business, there are several modules: fundraising, investment management, compliance/finance, and fund operations. Let me pick a few workflow examples.
First, fundraising. I have a large client, a major asset management firm. They wanted to partner with a smaller asset manager who would include their products in their lineup for a commission—sounds good. But the smaller firm said they needed a sales manager from the large firm in every client meeting. The large firm couldn't accept that; profits would vanish. So they came to us asking if we could build an AI sales assistant to participate in these conversations.
The workflow is: They have about a thousand products, so first you build data infrastructure to integrate them. Then an input layer for the partner to input client data, with permission isolation. Then a calculation module to determine the optimal product mix for that client—this part is deterministic (math). Then generate sales scripts for pre-meeting prep. A tool for during the meeting. Finally, post-meeting, automatically update proposals based on meeting notes. It's a feedback loop of about seven steps. This system allows the large asset manager to serve a much broader client base. That's one case.
Another I'm interested in is the investment decision process itself. During due diligence, you typically run ten workstreams, hiring legal, various advisors—commercial DD, environmental DD. Coordinating with so many people is stressful for the investment team. We're building a platform for them to interact with all advisors, push questions, automatically scan the data room. You get a real-time dashboard tracking all advisors' progress, and you can pull questions the fund asked on similar past deals, leveraging institutional historical knowledge. This uses the firm's past lessons while streamlining communication with external advisors. Finally, document output is automated, which is also a big burden. I've seen too many investors working weekends on this; I'm happy to help eliminate that.
Another is fund operations, like NAV calculation or account reconciliation—confirming account balances are correct after each month's or even day's close. My first job was bookkeeping; it's very time-consuming, but this process can be fully automated. Okay, I've given many examples to show useful scenarios.
Yiwen: Based on what you said, I wonder if PE acquisition itself has changed in the AI era. Traditionally, PE acquiring a company might involve post-acquisition M&A among portfolio companies, roll-up integrations. Now it feels like we're entering an "AI roll-up" era—on the surface, you're buying companies, but essentially you're buying their workflows, then transforming them into AI-native companies. Do you think this changes how PE itself operates?
Oliver: I've seen different approaches, but they mainly fall into two categories. The first type of investor says we can't invest in areas with too high AI disruption risk—that's many people's intuitive reaction. The second type actively embraces it, saying now is actually a very interesting time to create value through AI. The Amex GBT deal is a good example; there are many similar deals. Investors acquire businesses that weren't very tech-heavy in the past and very aggressively empower them with technology and AI. So this is clearly becoming an emerging strategy, with some forward-leaning GPs already doing it. And I believe the scale of value they can create is real.
But truly creating that value isn't simple. A problem I see now is the gap between what people imagine they can do and the reality of what gets implemented. I want to emphasize a core point: a common mistake is viewing AI only as a cost-reduction tool. Actually, AI's real value often lies in revenue creation, opening new revenue opportunities.
So I often ask clients: If I gave you 10,000 college-educated employees for free, what would you do? What couldn't you do before that you could do now? Because in a way, that's the capability AI brings now. Like my two asset management examples, for them, it means entering a completely new customer or business segment—one they couldn't reach before. So it's not about reducing costs but increasing revenue. I think that's the direction many companies should take. But currently, the focus is still heavily on cost reduction via AI, which I don't think is the most powerful entry point. They should think: What can I do now that I couldn't do before? That's revenue creation.
It can take many forms. Another example: We have a dairy company client with many farms and cows. We asked them: If you had 10,000 people, what would you do? They said that's interesting; we'd write reports for all accounts because they want to reduce time spent on reports and spend more time maintaining cow health. So we built a whole data integration and custom AI system to generate health reports for all cows. This frees up more time to focus on maintaining cow health, which wasn't feasible before.
04. How AI Changes Consulting and Enterprises Themselves?
Yiwen: What you do sounds similar to what consulting firms do, which leads to my other topic. Traditional consulting firms helped clients with areas they weren't familiar with. Now tech companies like yours and AI firms seem to be replacing that role, using AI to transform processes. Do you think the consulting industry will become obsolete? Or will consulting itself evolve into AI transformation consulting?
Oliver: I think consulting will see growth over the next three to five years because all enterprises talking about AI need to rethink their business models. A simple example is law firms, which traditionally bill by the hour—increasingly difficult now. If switching to outcome-based billing, the entire incentive structure changes. That's the kind of transformation you need people to discuss. You want to know how others are doing it, if there's experience to draw from, need guidance. So I believe there will be clear demand growth for consulting in the next three to five years.
But the real value release comes from those who ultimately leave behind a transformed business. So I think the model of AI labs and companies like us—who come in, do the work, and leave a reconfigured business—is what truly creates value, not just talking about transformation. But that said, market uncertainty is high now; everyone is watching and waiting. So the demand for consulting is real—people don't know how to proceed or where to start. That's a big part of my job: sitting down with clients to figure out what's worth doing first, which must be case-by-case.
Yiwen: Have you encountered companies thinking they could handle a workflow with AI but it just doesn't work? For instance, are people sometimes too optimistic about AI or misunderstand how it operates?
Oliver: The most common issue is wanting to AI-fy everything, but that path doesn't work. You must get a few things right. The most critical is a good data platform; its value compounds. AI can be brilliant, but without sufficient information and knowledge, it can't do anything. We have a data module called Neuron that integrates data, maps it clearly, ensures it's usable. This is the first hurdle for most companies, and it's costly because they've never done it before.
The second common mistake: In a ten-step workflow, not every step should use AI. You can use AI to optimize the overall process, clarify logic, determine which steps are deterministic, but not all steps should go to AI. For financial processes like account reconciliation, you don't want AI doing it; you want deterministic results. So AI can help梳理 (sort out) workflow logic, but many execution steps should be hard-coded, deterministic calculations. I think the two biggest pitfalls are data and using AI for things that should be deterministic.
This article is from the WeChat public account "Silicon Valley 101," author: Yiwen
