TBR has consistently highlighted hyperscalers’ professional services units, despite their relatively small revenue streams, as potentially credible threats to IT services companies.  Hyperscalers do not intend to displace global system integrators (GSIs) in consulting or managed services, but their growing services capabilities create more margin pressure for (and anxiety among) the GSIs each quarter. This report examines where hyperscalers’ professional services units overlap with GSIs’ and how their roles continue to evolve. We begin by comparing the companies’ services operating models.

How hyperscalers work alone

Among the hyperscalers, Amazon Web Services (AWS), Google and Microsoft have their own services units, with AWS having the highest cloud professional services revenue and being the most vocal about its offerings. AWS ProServe (Professional Services) and Amazon Managed Services take tailored approaches and have customer-forward strategies. AWS provides ProServe offerings on AWS Marketplace, making it easier for account teams and customers to procure consulting alongside cloud products.
 
At the end of 2025, AWS launched the Professional Services Delivery Agent, which changed the workflow for AWS and its clients, making agents the first step, not a consultant-led pilot. Now agents can perform architecture validation, migration planning, code generation and documentation while consultants focus on customer-specific decisions. In comparison, Google Cloud Consulting introduced packaged engagements around new technologies, such as AI Readiness and Agent Launchpad, to help customers reach production quickly before partners scale the deployments.
 
Microsoft’s professional services practice, which once focused on paid implementation, is moving toward adoption and customer success through services like FastTrack, Unified, and Cloud Solution architects. The introduction of Microsoft Frontier Company could change the dynamic by giving the company a more direct role in helping clients design, deploy and scale agentic AI solutions. The model creates a more comprehensive delivery motion that may resemble AWS’ and Google Cloud’s by taking a more formalized approach to technology, engineering support and consulting around emerging AI workloads.
 

 
Figure 1 contains TBR’s proprietary data and includes estimates of professional services revenue developed over years of experience covering these companies and the broader IT services market. Microsoft receives the smallest share of revenue from cloud professional services, and this may be part of why the company rebranded its former Microsoft Consulting Services to be included as part of Microsoft Industry Solutions and the broader Microsoft Professional Services unit, which is more closely aligned with the client-facing brands AWS ProServe and Google Cloud Consulting. Microsoft intends to gain higher margins in consulting-related work as part of its broader strategy to become AI-first.
 
TBR believes Microsoft may be trying to emulate margin leader AWS’ approach in its professional service business. Compared to five years ago, Microsoft’s and Google Cloud’s professional services revenue has been declining as a percentage of total cloud sales. Yet, many vendors are increasingly giving away managed services as a value-add.
 
As AI matures and repeatable solutions become more attainable, AWS may borrow Microsoft’s and Google Cloud’s more platform-based approach. In addition, repeatable outcomes will make services partners even more important, and they can focus on ecosystem orchestration. Services orchestration of go-to-market motions incorporating emerging solutions indicates that interconnected revenue is rising. Google Cloud saw a 9x combined increase in seats sold with partners and in the number of partners using the application internally in 1Q26. On the GSI side, TBR believes hyperscaler partnerships will become more important and account for a larger share of revenue, as described in TBR’s 1Q26 Accenture report, for example.

Where is the threat to services partners?

Hyperscalers’ services revenue is increasing much more year-to-year than GSIs’. Each of the three hyperscalers’ professional services revenue grew by more than 10% from 2024 to 2025. TBR believes this is due in part to adding services to existing and emerging product lines. Hyperscalers want to ensure customer satisfaction, since it is their AI platform and software on the line, while GSIs remain technology agnostic as their measure of client satisfaction comes from their own services and not the technology products or platforms delivered by the hyperscalers. In addition, hyperscalers also want to obtain more consumption usage around AI.
 
TBR believes GSIs may be losing ground around adoption and solution-specific implementation engagements. TBR’s Cloud Professional Services Market Forecast 2025-2030, which focuses on a GSI perspective, predicts that hyperscalers “can influence not only how services are delivered but also how outcomes are achieved, strengthening their role in driving client success and increasing their share of the value chain.”
 
Typically, GSIs are more instrumental in broader transformation and change management engagements that require greater scale and complexity. TBR does not expect these areas of influence to change anytime soon. As discussed in TBR’s 1Q26 Cloud Go-to-market Benchmark, “As [cloud] portfolios shift toward consumption-based and modular pricing, [services] partners play a critical role in driving adoption, expansion and usage discipline, which directly influences lifetime value even when the initial transaction is small.”
 
In turn, hyperscalers are increasingly relying on GSIs’ large benches. As we also noted in the benchmark, “many AI and platform revenues are usage-based or deferred, while partner services revenue is front-loaded. [Cloud] vendors use incentives to bridge this timing mismatch and keep partners economically engaged even when vendor revenue recognition lags. Essentially, incentives are replacing guaranteed margins, enabling [cloud] vendors to steer partners’ behavior without permanently increasing the ecosystem’s costs, which would happen if they continually added headcount.”
 
Hyperscalers’ growing influence is affecting which services GSIs offer. Each new frontier model and agent release promises new, exciting potential outcomes across business workflows, security measures and applications. Yet it is up to GSIs to ensure all technology layers are prepared for AI, beyond what hyperscalers’ professional services teams offer. Hyperscalers are more interested in developing advanced solutions and earning more consumption-based revenue.

How are cloud professional services evolving on their own?

Do hyperscalers and GSIs differ in their delivery approaches? Hyperscalers may have more depth in platform-enabled delivery, given their closer proximity to innovation and heavier IP assets. Hyperscalers are not headcount-heavy and thus are motivated to keep headcount in check. AWS’ Professional Services organization is adding AI agents internally, including a Professional Services Delivery Agent, to speed consulting work and reduce delivery costs. More broadly, GSIs are an entry point for multiparty orchestration when clients need packaged repeatable offerings across cloud, services, AI-native and hardware ecosystems. We expect cloud-partner-backed revenue to increase as a share of overall revenue over the second half of the decade. However, multiparty orchestration creates competition for margins. A strong partnership means all parties need to be upfront about pricing expectations and about which engagements are best for each point of contact, the latter of which TBR believes hyperscalers and services vendors are already addressing.
 
Hyperscalers want to be the first choice of technology providers for basic migration. As such, the three companies are focusing on providing consulting with designated solutions and more defined frameworks. Alongside strong alliance partners, repeatable solutions help hyperscalers keep consistent professional services despite some recent increases in cloud professional services revenue. For example, AWS’ cloud professional services revenue rose an estimated 26.7% from 2024 to 2025, but the company’s professional services headcount grew an estimated 6% year-to-year from 4Q24 to 4Q25. The conservative headcount growth is indicative of hyperscalers staying true to their nature and not becoming a services business. Meanwhile, Google Cloud, which has significantly lower headcount numbers in its professional services unit, may increase hiring or, at the very least, redirect resources to make services headcount more accommodating for effective AI deployment.
 
Forward-deployed engineers (FDEs) are changing the conversation around services headcount. As the IT market scrambles to accommodate growing client demand for ROI, hyperscalers are introducing FDEs. These professionals are being deployed alongside GSIs’ teams and are gaining headlines, but a deeper look suggests these roles previously existed in some capacity. The FDE model is less a clean break from prior services roles and more of a product- and adoption-oriented version of technical architecture support. FDEs share similarities with systems architects in that both sit close to the client and translate platform capabilities into workable solutions, but FDEs are more tightly linked to implementation and iteration as AI use cases move into production. One example of this is Avanade, the joint venture between Microsoft and Accenture.
 
The two companies are deploying FDEs together, with a focus on Microsoft’s Frontier Suite. As described in TBR’s 1Q26 Microsoft Cloud report, “The announcement is important because the FDE model, while made prominent by Palantir, has historically been less common among software vendors that prefer more scalable and margin-accretive delivery models. FDEs are expensive because they place technical resources close to the customer, but that proximity becomes more valuable as AI moves from experimentation into mission-critical workflows that require customization, governance and fault tolerance.” Hyperscalers are rebranding existing solutions to highlight their capabilities.
 
In the newest example, Microsoft has launched the Microsoft Frontier Company and announced a $2.5 billion investment. The company will “embed” 6,000 professionals to design and implement AI solutions, suggesting a more services-forward approach to clients, perhaps similar to AWS’. Although FDEs and related professionals are important and are likely to expand in some capacity, especially in the short term, as technical expertise is necessary for enterprises navigating AI transformation, we believe the build-out will be confined to when AI solutions begin to reach maturity. For now, hyperscalers’ professional services units will stay in their lane, focusing on how their solutions are best built and deployed, leaving the other noise, such as change management and ecosystem orchestration, to the GSIs.
 

Hyperscalers and ISVs add new title to their technology consulting bench: forward-deployed engineer

Although agentic AI platforms have proliferated across the enterprise software and platforms industry, monetization has been primarily concentrated within the narrower agentic coding space. Even there, where early adoption has transitioned to annual run rate (ARR) in the tens of billions of dollars, growing usage has been constrained by cost concerns and capped token budgets. In some cases, AI capability has grown faster than many enterprise customers can digest efficiently. In other cases, agentic engagements are stalling because the value is not proven. As a result, many customers are experiencing greater uncertainty around AI adoption and showing an inclination toward capping usage versus expanding token consumption, even in the most mature part of the market.
 
Against this backdrop, hyperscalers, ISVs and model leaders have begun rapidly positioning forward-deployed engineers (FDEs) as embedded technical builders who work directly inside customer environments to identify high-value AI use cases, build or configure agentic systems, contextualize those systems on enterprise data, and help move deployments from pilot to production. FDEs are being framed as hands-on engineers who code, debug, test, iterate and ship alongside customer teams. To many, this definition may prompt the question: Are FDEs meaningfully different from the cloud architects, solution engineers and consultants whom vendors have deployed into enterprise transformation projects for years? In many respects, the answer is no, but the name change suggests a new urgency among technology vendors to accelerate and influence enterprise AI architectural strategy.
 
In TBR’s opinion, the decision to pursue a more embedded services posture with FDEs suggests two things: Agentic AI technology has reached a point where vendors are willing to raise the stakes and work directly with customers to enable hands-on adoption support, and AI value remains very hard to deliver. By putting boots on the ground, vendors are betting that the right FDE paired with the customer’s technical talent can identify the opportunities for agentic automation that overcome these adoption hurdles, expand usage, and convert AI experimentation into repeatable commercial value.

Forward-deployed engineers are the solution architects for the AI era

The distinction between FDEs and solution architects that vendors might point to can be traced back to Palantir, which popularized the role through its high-touch, FDE-led operating model. Each Palantir engagement starts with the company’s portfolio of modular microservices, and the solution that comes out of the engagement is a unique configuration of these microservices combined with custom-built microservices to form a bespoke platform. The emphasis is on  the customized nature of the platform at the end of the engagement. By using Palantir’s nomenclature, the industry is leaning into the idea of a bespoke agentic system, one built alongside the client and contextualized on the client’s data.

The market’s FDE go-to-market strategy will look different than Palantir’s FDE operating model

In TBR’s opinion, the push toward FDEs does not represent an industrywide shift toward Palantir’s operating model, and TBR expects the company to remain an “n of 1.” It is possible a more customized platform strategy will emerge within select, strategic customer relationships, but most vendors will target a broader market than a bespoke approach requires, keeping the emphasis on selling repeatable solutions. In fact, for some vendors, internal FDEs will act more like development resources than go-to-market resources. These vendors are deploying FDEs with select clients with the goal of codeveloping agentic capabilities that can be packaged and sold elsewhere without the burden of field engineers. Microsoft’s industry model strategy is a strong example of this in action, with the company relying on customer-partners to provide the domain data necessary for training smaller, niche AI models.
 
Hyperscalers are inserting FDEs into a much broader AI go-to-market apparatus that already includes professional services, solution architecture, partner delivery, field engineering, marketplace programs, industry teams and customer success. Microsoft’s Frontier Company is a clear  example of this approach. Microsoft is not positioning FDEs as a stand-alone Palantir-style business model but rather as part of a broader enterprise AI deployment push that embeds industry and engineering experts more directly with customers. Amazon Web Services (AWS) is taking a similar ecosystem-oriented approach, pairing internal FDE investment with a partner-led motion designed to scale delivery through trained consulting partners. Google Cloud’s FDE job postings place the role inside Google Cloud Consulting or AI go-to-market and describe FDEs as embedded builders focused on moving generative AI (GenAI) products into production-grade customer environments. These examples suggest hyperscalers are not trying to replicate Palantir’s operating model outright. Instead, they are adopting aspects of Palantir’s FDE approach and scaling them through existing technical field organizations and partner ecosystems.
 
The strategies of hyperscalers and most ISVs are markedly more partner-driven as the leaders look to add a scale multiplier via formal FDE resources with existing strategic partners. Salesforce was early with its launch of a new FDE Partner Program. Microsoft’s Frontier announcement followed the launch of Accenture’s formal Microsoft FDE practice, as well as Microsoft’s FDE-oriented partnership expansion with EY. For their part, services firms are already emphasizing the size of their FDE benches, the number of certified resources they can mobilize, and the breadth of capacity they can bring to market as the market shifts toward the evolving opportunity.
 

Services partners bring scale, industry expertise and an agnostic opinion to FDE engagements

When technology vendors’ announce billion-dollar investments in consulting capacity, the natural reaction is to assess the new potential for competitive friction, but TBR suspects the current trend, which places more influence in the hands of partners, will prevail. Digital transformation projects have long combined technical resources among alliance partners, and many existing joint go-to-market positions will be preserved as the solution architect title shifts to FDE.
 
The services vendors still hold an important position, armed with greater domain expertise and a technology-agnostic approach. Before the FDE buzz gained steam, TBR was hearing more from services leaders about how they were transitioning from a purely agnostic adviser toward a posture that is still technology-agnostic but somewhat opinionated, meaning enterprises were expecting providers to come to the table knowing the right solution configuration to meet their transformation goals. If services providers can build robust benches with resources trained in agentic AI, an opinionated position could become their point of entry, offering an opinion without a conflict of interest in selecting the right AI model and harnessing architecture for the use case.

FDE engagements should be equal parts coinnovation and change management

In TBR’s opinion, services partners are also better positioned to support the nontechnical aspects of AI transformation. Agentic AI requires customers to rethink workflows, roles, permissions, approval processes, risk controls and success metrics. A technically sound agent that does not fit how employees actually work, how decisions are governed or how accountability is assigned will struggle to scale. This makes FDEs part engineer, part translator and part change agent. The coinnovation component is still central, but the value of that work depends on whether the customer can absorb the change. Many enterprises are still learning where AI should augment work, where it should automate work and where human oversight remains necessary.
 
This is another area where the FDE label may overstate what is new. Consultants and architects have long helped customers manage technology-enabled change. The difference in the AI era is the speed and ambiguity of the work. FDEs are often helping customers discover the use case while building it, making changement management less of a downstream activity and more of a core part of the engagement. Vendors that treat FDEs only as technical builders may miss the larger adoption challenge.
 

Forward-deployed engineering is likely to be a loss leader for technology vendors, while monetization pressure for services partners will promote repeatable frameworks

The economics of forward-deployed engineering will vary by provider type, making monetization as important as operating model design. For technology vendors, FDE or FDE-like support is unlikely to appear as a stand-alone line item in every engagement. Instead, the cost can be embedded in broader software, cloud consumption, enterprise agreement, marketplace, premium support or strategic account economics. This gives vendors room to subsidize embedded technical resources when the downstream value is large enough, including higher product adoption, faster consumption growth, larger renewals, stronger account control, reusable product feedback and customer proof points that can be applied elsewhere.
 
That equation is more complicated for services partners. SIs and consulting firms cannot usually recover FDE investment through core platform pricing, model usage or cloud consumption in the same way a hyperscaler, AI model provider or enterprise software vendor can. Their FDE-like resources, therefore, need to be monetized more directly through advisory, implementation, managed services, engineering, governance or transformation fees. Vendor-funded incentives, training subsidies, marketplace programs and cosell motions can help partners build capacity, but partners still need a clear commercial model for converting embedded AI engineering into billable, repeatable services.
 
This difference will shape how the market scales. Technology vendors can selectively subsidize FDEs in strategic accounts to drive product learning and consumption. Services firms need broader repeatability and utilization discipline. As a result, the partner-led forward-deployed engineering market is likely to look less like free embedded engineering and more like AI transformation services with stronger technical depth, faster prototyping cycles and closer alignment to vendor agentic AI platforms.

FDE involvement raises the stakes in every engagement

The promise of forward-deployed engineering is that vendors can get closer to the customer’s highest-value AI opportunities. The risk is that getting closer also raises expectations. Once a vendor embeds technical talent into a customer’s environment, the engagement becomes harder to frame as a generic software deployment. The vendor is no longer just selling a platform and enabling a partner. Instead, it is participating more directly in the customer’s attempt to prove AI value. That dynamic increases the pressure on both sides. Customers will expect clearer business outcomes, faster iteration and more accountability for results. Vendors will need to be more selective about which accounts and use cases receive FDE support, as not every opportunity will justify the scarce technical resources. Partners will need to understand where their role begins and ends, especially when vendors want to retain control over product learning and strategic customer relationships. Poorly scoped FDE engagements could create delivery risk, margin pressure and customer disappointment if the promised AI outcomes do not materialize.
 
Forward-deployed engineering also changes the economics of AI adoption. The model makes sense when embedded engineering produces reusable assets, consumption growth, expansion opportunities or strategic customer proof points. It becomes harder to justify when each engagement remains bespoke. This is why repeatability is the key test. If FDE teams help vendors identify patterns that can be turned into packaged agents, industry templates, implementation playbooks or product enhancements, the model can support software-led growth. If not, forward-deployed engineering risks becoming an expensive services layer attached to products whose stand-alone value remains difficult to prove.

Conclusion

Forward-deployed engineering is becoming the preferred language for the final mile of AI adoption, but the label should not obscure the underlying uncertainty. Vendors have embedded technical resources into customer transformations for years, and much of today’s forward-deployed engineering activity builds on that history.
 
What has changed is the urgency. Agentic AI has widened the gap between product capabilities and production value, forcing vendors to place more technical talent closer to customer workflows.
 
TBR does not expect the broader market to move fully toward Palantir’s FDE-led operating model. Palantir will likely remain an “n of 1,” with most vendors adopting narrower, more selective versions of the FDE role that fits existing partner ecosystems and software business models. The market will settle into a spectrum: Palantir at one end, early forward-deployed engineering explorers at the other, and most major AI and enterprise software vendors in the middle, using internal FDEs for strategic coinnovation while relying on partners for scale.
 
The durability of forward-deployed engineering will depend on whether vendors can turn high-touch engagements into repeatable value. If FDEs help customers identify validated use cases, manage organizational change and generate reusable product assets, the model could become an important layer in enterprise AI adoption. If forward-deployed engineering remains a rebranded services motion, its impact will be more limited. The next phase of competition will therefore be less about which vendors announce FDE teams and more about which vendors prove that those teams can convert AI experimentation into scalable, value-accretive outcomes.