EN / 中文

The Battle for Enterprise AI Platforms: From Microsoft Foundry to Tencent WorkBuddy

by aifenxiifenxi·September 15, 2026

Enterprise AI platforms are forming multiple intersecting evolutionary paths: some originate from model services, while others focus on Agent development, enterprise knowledge, Skills, or computing resource management. As enterprise AI transitions from experimentation to production, these platforms are strengthening their core capabilities while expanding into adjacent areas such as development, operations, and governance.

Microsoft Foundry and Tencent WorkBuddy, originating from cloud and model services, and work entry points and Skills respectively, illustrate different directions for the cross-layer expansion of enterprise AI platforms. This raises a fundamental question for enterprise selection: products with similar names may manage completely different objects, cover different lifecycles, and assume entirely different production responsibilities.

Without a unified frame of reference, MaaS, Agent development platforms, knowledge management platforms, Skill platforms, and computing resource management platforms would be conflated and compared indiscriminately (see Table 1).

Table 1: Five Product Forms of Enterprise AI Platforms

These product forms have counterparts in familiar products: Bailian and Volcano Ark provide model services; Volcano HiAgent and Dify support Agent development; Tencent Lexiang focuses on enterprise knowledge management; WorkBuddy handles Skills and task execution; and QingCloud AI Computing Platform manages computing resources. Their capabilities also overlap; for instance, Bailian supports both model fine-tuning and application building, while Dify includes a knowledge base. Microsoft Foundry serves as a representative case for observing this evolution and transformation. Starting from a model service entry point, it has gradually expanded into Agent development, operations, and governance. As the bottleneck of enterprise AI shifts from acquiring models to reliably deploying applications into production, the objects managed by the platform and the responsibilities it assumes expand accordingly.

This further raises an industry question: as platforms with different starting points continuously expand their capabilities, what boundaries and division of labor will ultimately emerge? Based on public product information and vendor research, iFenxi believes that enterprise AI platforms are more likely to achieve cross-layer integration while retaining professional stratification. Leading vendors will connect multi-layer capabilities through suites and unified governance, while specialized vendors will participate in various ecosystems via interfaces. What will gradually stabilize are the responsibility boundaries and connection methods.

01 Comparing Enterprise AI Platforms: Three Key Dimensions

To compare the positioning and capability boundaries of different platforms, one can approach it from three dimensions: what objects are managed, which lifecycle stages are covered, and what production responsibilities are assumed (see Table 2). This analytical framework summarizes the practical differences among platforms in terms of asset management, functional coverage, and service delivery, answering "what to manage, which stages to cover, and to what extent to take responsibility."

Table 2: Three Dimensions for Comparing Enterprise AI Platforms

Different management objects result in different value metrics for the platforms. Computing platforms focus on utilization rates, queuing times, and task throughput; MaaS focuses on model performance, latency, and token costs; Agent platforms focus on task completion and tool invocation; knowledge platforms focus on whether content is trustworthy, timely, and compliant with access permissions; and Skills focus on whether task methods can be reused and continuously updated.

The lifecycle reflects the extent to which a platform covers the application production process. Some platforms focus on orchestration and debugging, while others further support deployment, operations, and governance. Once applications enter production, they must continuously execute tasks under quality, security, and cost constraints. Whether a platform can support these requirements determines how much additional work an enterprise must undertake to transition from prototypes to real-world applications. Production responsibilities further clarify how much work the vendor handles within the covered stages. For instance, when supporting Agent operations, self-deployed software and fully managed services leave different operational and maintenance tasks for the enterprise. Similarly, merely providing vector retrieval components differs significantly from simultaneously managing data connections, index updates, and permission synchronization in terms of the workload assumed.

The expansion of platform responsibilities does not mean the elimination of enterprise responsibilities: business rules, data quality, exception handling, and final task outcomes remain the enterprise's responsibility. For example, when using AI to process customer refunds, the platform can help the AI connect to the order system, control operational permissions, and record the processing workflow; however, the enterprise must define the refund thresholds for automatic processing, the conditions requiring manual approval, and the error-handling procedures. The platform ensures operations are executed according to the rules, while the enterprise defines the rules and authorization scope. Based on these three dimensions, iFenxi defines enterprise AI platforms as a set of reusable capabilities that organize models, data, knowledge, Skill tools, and runtime environments to support AI application development, operations, and governance.

Specific products may focus on only a subset of these stages, and their boundaries must be evaluated in conjunction with the management objects, lifecycle coverage, and production responsibilities. Therefore, enterprises should not first ask which platform offers the most features; instead, they should first identify the assets most in need of management, the current stage of their applications, and the specific tasks they expect the vendor to continuously handle.

02 Production Demands Drive Platform Convergence, Vendor Foundations Determine Differentiation

As enterprise AI transitions from model validation to business applications, it drives platforms to augment task execution, operations, and governance capabilities. Meanwhile, varying industries, application scenarios, and existing enterprise systems create divergent demands. Consequently, vendors expand along their respective technological and customer foundations, resulting in a parallel process of capability evolution, product differentiation, and cross-layer integration, rather than a sequential upgrade path from MaaS to Agent, knowledge, and Skills (see Figure 1).

Figure 1: Enterprise Demands and Vendor Foundations Jointly Shape Platform Evolution

1. Enterprise Needs Are Shifting from Model Capabilities to Production Capabilities

Acquiring a model does not equate to an application being ready for production. Enterprises must also address how the model connects to internal data and systems, how tasks are executed, and how to maintain continuous operation under quality, cost, and security constraints. Agents amplify this gap. They require task decomposition, tool invocation, state retention, and failure handling; once integrated into core business processes, additional security measures such as identity authentication, access control, and auditing are required. Consequently, enterprises no longer solely compare model performance and token unit prices; they focus on time-to-market, task success rates, business outcomes, and the cost per successful task. While Q&A applications typically handle a single input and output, an Agent may span multiple steps and systems, running for minutes or even longer. The platform must track the task's progress, identify invoked tools, determine the cause of failures, and decide whether to retry, roll back, or escalate to human intervention. The closer a model gets to task execution, the more operational responsibilities the platform must assume. As enterprise AI transitions from model validation to business applications, the platform must support stable task execution while enabling the reuse of data connections, knowledge, and workflows across multiple projects, gradually crystallizing into sustainably maintainable assets for the enterprise.

2. Vendors Expand Along Their Strengths Without Complete Overlap

While enterprise demands for production capabilities are gradually converging, the paths vendors take to augment these capabilities vary significantly. Existing customer bases, technological foundations, and delivery models dictate where vendors expand and which capabilities are best built in-house versus sourced through partners (see Table 3).

Table 3: Five Types of Vendors Expanding Along Their Strengths

These foundations create path dependencies, making the advantages of various vendors difficult to substitute for one another. MaaS vendors excel in model services, knowledge platforms accumulate enterprise content and permission systems, and office software is closer to user workflows. Augmenting platform capabilities is a gradual evolutionary process. Judging whether the market is converging requires looking beyond whether feature lists are similar; it depends on which layer of responsibility vendors ultimately assume and whether these layers can be stably connected.

03 Microsoft Foundry: From Model Entry Point to AI Application Production Platform

Microsoft Foundry provides a specific case for observing the aforementioned mechanisms: enterprise demands for application deployment drive its continuous capability expansion, while Microsoft's existing cloud and enterprise software foundations shape its integration approach. Tracing the evolution of the Foundry product reveals how the platform gradually expands its management objects and production responsibilities from a model entry point, with changes primarily reflected in the following four nodes (see Figure 2).

Figure 2: Microsoft Foundry Expanding from a Model Entry Point to an AI Application Production Platform

Azure AI Studio initially focused on providing model supply and training services. With the addition of Agent Service in 2024, the platform began organizing models, data, and tools around applications. From 2025 to 2026, Foundry IQ, Control Plane, and Hosted Agents have incorporated enterprise context, cross-project governance, custom Agent hosting, and operational quality management into the platform.

Among these, the key change in 2024 was the platform's shift from "selecting and optimizing models" to "organizing AI applications": Agents not only invoke models but also connect to data, tools, and external systems. The changes post-2025 further address two production issues—how Agents acquire enterprise context, and how enterprises can uniformly manage the risks, performance, and costs of different projects.

This enables Foundry to expand simultaneously across three dimensions: management objects extend from models to knowledge, tools, Agents, and runtime resources; the lifecycle extends from model optimization and deployment to application development, operations, evaluation, and governance; and production responsibilities extend from providing components to hosting partial Agent operations and unified control.

Consequently, Foundry has evolved from a model entry point into a construction and operations entry point for enterprise AI applications, and its strategic value has shifted accordingly. Microsoft is no longer competing solely for model invocation volume, but also for the data connections, tools, workflows, and governance relationships formed around AI applications, leveraging these to connect Azure computing, databases, Fabric, identity and security systems, and business entry points such as Microsoft 365.

This is also the reason why Foundry has been elevated from an Azure product tool to Microsoft's enterprise AI platform entry point. Once enterprise applications enter production, they will continuously utilize databases, retrieval, monitoring, security, Agent operations, and business software. Foundry organizes these previously fragmented consumption and customer relationships onto a single application production chain. Its value lies not only in adding a platform fee but also in capturing the AI增量 (incremental growth) across Microsoft's multi-layer products.

However, Foundry has not eliminated platform stratification. The naming of Microsoft Foundry does not imply detachment from Azure; its computing, storage, search, and security capabilities remain built on Azure; it also needs to support third-party models, external frameworks, and existing enterprise systems. The落脚点 (focus) of Foundry is not to cram all AI features into a single portal, but to form a continuous chain of model, context, operations, and governance capabilities around production-grade applications.

04 AI Platforms Will Not Converge into One; Suite Integration on a Layered Architecture Is More Likely

Having discussed this, we need to disentangle two issues that are easily conflated. The cross-layer expansion of Foundry does not mean that enterprise AI will ultimately be reduced to a single full-stack platform; the market is likely to form three structures (as shown in Table 4).

Table 4: Three Potential Structures for Enterprise AI Platforms

Among these, suite integration on a layered architecture better aligns with production demands (see Figure3). AI applications require continuous support from development to operations; fragmented capabilities increase integration costs, while closed systems struggle to兼容 (accommodate) existing enterprise systems. Therefore, leading vendors tend to incorporate general capabilities into suites with unified governance, while specialized products participate via interfaces, retaining their independent value.

Figure 3: Convergence Direction of Enterprise AI Platforms: Suite Integration on a Layered Architecture

Leading overseas vendors are taking similar actions from different starting points. AWS is augmenting Agent operations, identity, and observability capabilities with AgentCore; Google continues to connect models, Agents, and cloud data services; and OpenAI and Anthropic are also extending beyond models into Agent development and hosted operations.

These products are not identical, but they all indicate that competition is shifting from providing single model capabilities to assuming more production responsibilities. The Chinese market also exhibits the characteristic of multiple parallel paths (see Table 5). Existing products such as cloud services, knowledge management, and office tools are being combined with model and Agent capabilities; emerging Agent platforms are expanding into operations and governance. Different vendors have formed the following routes around their respective customers and technological accumulations:

Table 5: AI Platform Product Routes in the Chinese Market

The above classification reflects the primary starting points and asset foundations of the products; a single product can cover multiple types of capabilities. These products expand along different paths. The early capability focus of Bailian included model training and fine-tuning such as SFT, later adding Agent development, and currently统摄 (orchestrating) model invocation, fine-tuning, and application building with comprehensive MaaS; Tencent Lexiang and Baidu have long been engaged in knowledge bases and knowledge management, with large models and Agents adding new interaction and execution methods on top of existing capabilities; computing platforms first address infrastructure management and operations, and large cloud vendors typically also embed similar capabilities.

Tencent WorkBuddy presents a path expanding from a work entry point to a platform. Enterprises want AI to combine internal materials, business rules, and existing systems to complete practical tasks such as business analysis and customer service.围绕 (Around) such demands, WorkBuddy reuses work methods through Skills, invokes business systems through connectors, and supports partners in combining industry experience and tools into dedicated workstations. This gives enterprises the opportunity to configure AI applications tailored to their own businesses on a general platform: the platform provides common task execution capabilities, while enterprises and partners supplement business knowledge and processes, reducing the independent construction work for each type of task.

Compared to Foundry extending from model services to application development and operations, WorkBuddy starts from user tasks and aggregates the capabilities needed to complete work. This suggests a possible market direction: enterprise AI platforms can also develop from application entry points, forming a combination of "general execution capabilities + reusable skills + industry applications." User experience is gradually integrated, while professional division of labor is retained; whether it can further enter core enterprise business depends on the reliability of task execution, permission governance, and the depth of business system connections.

From these paths, it can be seen that Agent development and task execution have become the convergence point for multiple capabilities: applications need to organize scattered capabilities and continuously meet operations and governance requirements. Knowledge management has formed a clear foundation of enterprise assets and procurement; the importance of Skills is rising, but they are more依附 (attached) to Agent platforms and work entry points, and whether they will form an independent category remains to be observed.

Computing resource management continues to maintain strong infrastructure attributes. Microsoft Foundry illustrates the value of suite integration by large cloud vendors, and also the boundaries of full-stack platforms. It can connect models, context, operations, and governance within the same system, but still needs to接入 (access) third-party models, external data, and existing systems; products closer to business users and application entry points, such as Copilot Studio, may also coexist with Foundry in the long term.

"Full-stack" is therefore closer to a complete combination of capabilities, rather than all layers being merged into a single product. Combining domestic and international product changes, iFenxi judges that enterprise AI platforms will form a relatively stable division of labor in continuous evolution and differentiation: leading vendors reduce cross-layer collaboration costs with suites, specialized vendors form advantages around specific assets or business entry points, and interfaces support the combination and replacement of different capabilities. The focus of competition will shift from the number of features to how many production responsibilities the platform can assume and what reusable assets it can accumulate.

05 Buyers Should Choose a "Sufficient Platform," and Vendors Should Clarify Responsibility Boundaries

While platforms are still evolving, enterprises cannot merely compare feature lists; selection should sequentially answer the following five questions (see Figure 4):

Figure 4: Five-Step Judgment for Enterprise AI Platform Selection

These five questions have a sequential relationship: first confirm the primary bottlenecks and application stages, then inventory existing capabilities and divide responsibilities, and finally determine asset ownership. Skipping the first few steps to directly compare features容易 (easily) leads to purchasing a platform with broad coverage that fails to solve the current primary problems. For example, when the bottleneck is heterogeneous GPU utilization and multi-cluster scheduling, computing resource management should be addressed first; when the problem is scattered knowledge, complex permissions, and difficult updates, knowledge management is more important than adding model APIs; when an enterprise has completed multiple Agent pilots but struggles with deployment and governance, the focus should be on comparing Agent operations, evaluation, and control capabilities.

What enterprises usually need is not a full-set platform with the most features, but a "sufficient platform": one that covers current primary problems, assumes necessary production responsibilities, and reserves interfaces for adjacent capabilities and third-party products. During selection, enterprises need to pay attention to vendor lock-in and cost evaluation issues. An open system with multiple vendors does not mean there is completely no platform dependency.

Unified platform suites reduce construction and operations costs, inevitably accumulating configuration, connection, and governance relationships. What enterprises truly need to control is whether system dependencies are transparent, whether core data and knowledge can be exported, whether models and tools can be replaced, and whether migration costs match the efficiency gained. Vendor lock-in is not a simple "yes or no," but a commercial and technical trade-off that requires active management.

Cost evaluation also cannot stop at token unit prices. The actual costs of AI applications also include knowledge processing, tool invocation, Agent operations, evaluation monitoring, underlying computing, system integration, and manual handling. More meaningful metrics are the cost per successful task, and whether the platform can reduce repeated integration and long-term operations.

For vendors, the启示 (inspiration) from Foundry is not that broader coverage is always better, but to first determine the core management objects, then determine the upper limit of responsibilities and the direction of expansion. Computing platforms should optimize resource efficiency, MaaS should strengthen model supply and inference, Agent platforms should improve task completion rates and augment operations governance, knowledge platforms should ensure knowledge is trustworthy, timely, and compliant with permissions, and Skills should solve the encapsulation, distribution, and iteration of business methods.

When expanding, vendors need to choose directions adjacent to the core layer. Platforms close to business processes should focus on accumulating industry knowledge, workflows, Skills, and user entry points; platforms close to infrastructure should focus on optimizing performance, resource efficiency, and unified governance. Regardless of the starting layer, it is necessary to access upstream and downstream through model interfaces, data connectors, MCP, identity protocols, and observability systems.

06 Conclusion: What Converges Are Responsibility Boundaries and Connection Methods

Enterprise AI platforms will not converge into a single product. Models, Agents, knowledge, Skills, and computing will maintain different technological and procurement layers; leading cloud vendors will integrate more general capabilities, while independent vendors will continue to exist around specialized assets, business entry points, and open connections.

Foundry集中 (concentrates) this trend: when enterprise demands shift from acquiring models to application production, platforms begin to simultaneously manage models, context, operations, and governance; but cross-layer integration will not eliminate third-party models, specialized platforms, and existing enterprise systems. What enterprises need to determine are the assets most in need of management and the responsibilities they are willing to hand over to vendors; what vendors need to determine is at which layer to form irreplaceable capabilities, to what extent to assume responsibilities, and how to connect upstream and downstream. This is the convergence result that enterprise AI platforms are likely to form in continuous evolution and differentiation.