The ambition of Alibaba Cloud does not lie in Agent Builder
In the past year, the moves of several cloud vendors have been remarkably aligned. In August this year, Alibaba Cloud upgraded its Agent-related service capabilities into an All-In-One enterprise-level full-stack Agent service platform — Agent Studio, and officially launched it on Alibaba Cloud Bailian; at Microsoft Build in June, Microsoft Foundry clearly shifted its focus further to the production link, with capabilities including Hosted Agents, Toolboxes, and Memory successively added to the platform; in April, Google Cloud launched the Gemini Enterprise Agent Platform, integrating Build, Scale, Govern, and Optimize into a single unified platform; last October, AWS's Bedrock AgentCore split capabilities such as Runtime, Memory, and Gateway into a set of composable services, aiming to eliminate the need for developers to rebuild the operating base for each Agent from scratch.
Some large companies with sufficient engineering capabilities are also doing similar things. In July this year, DoorDash, the largest food delivery service platform in the United States, abstracted general capabilities such as Memory, model access, and Tracing into shared infrastructure, and specially built an Agent Gateway layer to centrally manage the identity, permissions, credentials, rate limiting and audit of Agents when calling internal tools.
While public attention generally stays on what new tasks Agents can accomplish and what popular new applications have emerged, few people notice that more and more companies are starting to devote a large amount of engineering energy to things that do not sound very "AI-related".
The reason is very simple. Everyone is hitting the same problem: as the number of Agents increases, tasks get longer, and call chains become more complex, the old way of organizing infrastructure is no longer sufficient.
More interestingly, even model development companies cannot bypass this "pit". In April this year, Anthropic rarely reviewed a "rework" of its Agent infrastructure: initially for simplicity, it stuffed Session, Agent Harness and Sandbox into the same Container. But after actual operation, it found that fault isolation, state preservation and network expansion all became problems, and finally had to split the three parts apart again.
This rework more or less illustrates one thing: no matter how good the model is, once the Agent is actually running, none of the necessary engineering lessons can be skipped. But the question is, does every company need to rebuild this set of infrastructure by itself?
The real bottleneck lies beyond the model
When we shift our perspective to the scenario where an Agent performs a specific task, we will find that the really troublesome things often happen outside the model.
In July this year, McKinsey released an Enterprise AI FinOps survey. When enterprises move from scattered AI use cases to larger-scale deployment, the overall AI expenditure nearly quadruples; 93% of the surveyed organizations said that their AI expenditure has exceeded the budget. Boston Consulting even specifically discussed the cost issue of Agentic AI in June this year. It divided the costs into two categories: one is one-time construction costs, including cloud access, network connection, etc.; the other is continuous operation costs. In addition to model calls, this part of the cost is also affected by the Agent orchestration method, tool call frequency, monitoring intensity and system integration method.
Obviously, the deeper the use of Agents, the more difficult it is for enterprises to simply explain their bills by "how many Tokens have been called". Computing, storage, data access, tool services, runtime, and operation and maintenance governance all generate costs, and a considerable part of these investments are likely to be pure inputs that can hardly directly create business differentiation.
This is also a major headache for many enterprises at present: when building Agents, how many things do enterprises still need to develop on their own? At present, the industry has roughly explored three paths around this problem.
The first path is full self-development, where enterprises build their own Agent platforms. A typical example is DoorDash mentioned earlier. In its public technical article in July this year, it specifically disassembled the platform behind Ask DoorDash: business Agents such as Restaurant, Grocery, and Reservations are still the responsibility of each team, but capabilities that every Agent will repeatedly encounter, including Session State, Memory, Artifacts, model access, Tracing, Evaluation and Rollout Controls, are uniformly placed at the platform layer.
The focus of this set of engineering work is to remove the repeated parts between Agents as much as possible. DoorDash's judgment is that only when multiple businesses need the same capability, and building a separate version for each will bring reliability or operation and maintenance problems, is it worth turning it into public infrastructure. The final effect is quite obvious: the Reservations Agent reuses the production links of Restaurant and Grocery, and was successfully launched in just one week, with a 10-fold speed improvement; each new Agent uses the unified Tracing capability, which also saves nearly a month of observability construction work.
However, DoorDash has not disclosed how much money, manpower and time it has invested in this platform, but the platform itself is a product that requires continuous construction. This path works for DoorDash largely because it has a sufficient number of Agents and a strong enough engineering team. But for more companies, maintaining a dedicated team to build Agent Infra just to develop Agents is not a cost-effective choice. Therefore, more companies tend to choose the second path: first build Agents with a development framework.
In recent years, a number of frameworks such as LangChain, LangGraph, Microsoft AutoGen, and CrewAI have emerged one after another, turning many logics that originally required developers to write manually into more easily reusable components, lowering the threshold for enterprises to build Agents. The US ride-hailing platform Lyft mentioned in its previously published customer service Agent construction case that it used LangGraph to orchestrate multiple professional Agents, compressing the Agent development cycle that originally took about half a year to just a few weeks.
But what development frameworks can currently solve are mainly the first batch of problems encountered in the process of Agent development. The problems that arise after the Agent is running are still a huge hurdle to cross.
This is also why in the past year, many cloud vendors, enterprise software platforms, data platforms, and even model companies have begun to move towards the third path: enterprise-level Agent platforms. In addition to AWS, Google and Microsoft mentioned earlier, Salesforce launched Agentforce 360, putting data, business processes and Agents into a unified platform; Snowflake has also further expanded Cortex Agents, emphasizing capabilities such as Build, Managed Runtime, MCP access, and code execution.
In China, this path has also become clear, with Alibaba Cloud as a typical representative. At the Alibaba Cloud Feitian Launch Event on August 14, the newly released Agent Studio aims to converge the originally scattered capabilities into a service layer centered on Agents, enabling enterprises to complete Agent development in one stop and build Agents through drag-and-drop operations.
But what is more worth discussing is, for enterprises, how much of the repeated engineering work and trivial matters that originally needed to be done in each Agent project can be avoided? Agent Studio just provides a perspective for observation.
Agent Studio is now available on Alibaba Cloud Bailian, experience link: agent.console.aliyun.com
What "dirty work" does Agent Studio take over for enterprises?
After the Agent actually starts working, enterprises obviously have more things to worry about.
If we break down the entire link of an Agent from "being built" to "actually working", we will find that operation is only the most basic capability. But that does not mean this work is simple.
Agents are different from traditional applications and ChatBots. Executing a single task may take more than ten hours or even several days, during which they need to continuously read and write files and call tools, so they are usually stateful services. The refactoring that Anthropic did in April this year, which separated Session, Agent Harness and Sandbox, is to ensure that the state will not disappear together with a single execution container.
At the cloud platform level, this type of problem has now become a directly callable service. The Managed Agent in Agent Studio is essentially a hosted Agent Runtime. Developers only need to define what the Agent does, and the rest of the trivial matters such as operation, isolation, state and credentials can be handed over to Managed Agent.
The complete set of engineering work saved for enterprises will eventually be reflected in business results: with the same manpower, more tasks can be processed, the delivery speed is faster, and the results are more stable.
Taking enterprise insurance policy clause review as an example, in the past, a complex insurance policy usually required underwriters to complete parsing, clause alignment, risk rating and compliance checks on their own. After being encapsulated as a Managed Agent, this process can be executed continuously in the cloud, and people only need to handle the final key items that require confirmation. According to data disclosed by Alibaba Cloud, the time for a single review has been shortened from three or four hours to about 15 minutes, with an efficiency improvement of more than 10 times. The number of insurance policies that underwriters can process every day has also increased several times, and the cost for one insurance policy is only 0.12 yuan.
"Managed Agent is actually born specifically for complex tasks that take a long time and have many steps, enabling business Agents to move beyond simple chatting and actually get work done." The product lead of Managed Agent mentioned that Managed Agent has five layers of capabilities: the bottom layer is the runtime base, which hosts session state, sandbox, tool execution, event records and Agent Harness together, supporting long tasks to resume after interruption; the upper layer is context management, enabling files, code repositories and cross-session memories to be continuously reused; the next layer is tool extension, which accesses external systems through MCP and Skills, and encapsulates mature processes into reusable capabilities; the security layer is responsible for sandbox isolation and key hosting; the top layer is observability and integration, which records the Agent execution and tool call process, and connects to business systems through APIs, Deployment and other methods.
Looking at these five layers of capabilities together, we can see that the most troublesome batch of underlying work in the long-running tasks of Agents can now be handed over to Managed Agent for hosting. But this is only the first step. After the Agent is running, the problem of how to connect tools still needs to be solved.
MCP has standardized part of the way different tools are connected to Agents, but it has not completely eliminated the access cost. For each MCP service connected, developers often have to register accounts separately, apply for API Keys, process authentication, and manage bills separately. When there are many services, the development work that was originally saved can easily become a new operation and maintenance burden.
This is why the One Key Service system upgraded this time in Agent Studio has quickly sparked discussions in the community. It tries to achieve true "One Key All Server", using a unified API Key to compress N original authentication links into one.
According to Alibaba Cloud, the first batch of One Key MCP has accessed 14 cloud market partners, covering e-commerce, geographic information, finance, law, industrial research, logistics and other fields; nearly 50 MCP ecological service providers will join the One Key Service system next; subsequent Agent Studio-related services that support the A2A protocol will also be gradually incorporated into this system.
If One Key MCP solves the problem of "being able to connect", the redesigned Skill system solves the problem of "how to use it better". Agent Studio divides Skills into three layers this time: carefully selected from the square, directly supplied by service providers, and user-defined. General capabilities can be installed directly, industry service providers can encapsulate MCP together with Prompts, call examples and best practices, and enterprises can also precipitate their own tools, data and processes into private Skills.
When the Agent can run and has access to tools, it still needs to know "what information is missing now" and "what has been known in the past" when facing complex businesses. A single search is obviously not enough, which is where traditional RAG often struggles in complex tasks. The upgraded Agentic Search capability of Agent Studio this time solves this problem by enabling Agents to continuously search, cross-verify information like experts, and dynamically adjust the retrieval direction according to the task.
Specifically, it will first understand the intent, break down sub-problems, and then retrieve from the corresponding knowledge bases respectively; if sufficient information is not found halfway, it will rewrite the Query, change the retrieval strategy or retry the retrieval tool, and continue to search along the existing results. In addition to semantic search, it also provides different retrieval methods such as chapter browsing, chapter in-depth reading, and page browsing.
Alibaba Cloud has actually been paving the way for this for some time. In July this year, Alibaba Cloud launched the enterprise-level Agentic RAG service Knowledge Studio, providing capabilities such as multi-modal search and response, Agentic Search, multi-library hybrid retrieval Q&A, supporting joint retrieval of 15 knowledge bases. To improve the long-term memory capability of Agents, Alibaba Cloud also launched a memory base in April this year, with four built-in modules of "Extract - Store - Retrieve - Inject". After each user's conversation with the Agent ends, the system can extract key information according to the rules, save it, and recall it in subsequent conversations. With this release of Agent Studio, the memory capability is further organized into Memory Studio, which is divided into three categories: observation memory, user memory and skill memory. Observation memory answers what happened, user memory answers "who you are", and skill memory answers "how this thing was done in the past".
Looking at Agentic Search and Memory Studio together, the logic is quite clear: one is responsible for answering what is missing now, and the other is responsible for answering what was known in the past. In this way, when facing complex tasks, the Agent can not only actively search according to the current problem to supplement information, but also continue to use past experience and status without starting from scratch every time.
At this point, several key capabilities of Agents, including how to run, how to call tools, how to find information, and how to remember the past, are basically connected by Agent Studio. But Alibaba Cloud wants to go one step further: it hopes to use one entry to turn the full-stack capabilities of Alibaba Cloud Agents into a template that everyone can get started with personally. Agent Studio Playground is the last piece of the puzzle that Alibaba Cloud offers this time.
According to the introduction, Agent Studio Playground puts capabilities such as Flow Agent, Managed Agent, RAG, Memory, MCP and Skill into a unified experience center, and presets scenario templates. Developers can directly run an existing scenario first, then check which capabilities are used behind it, and can also use Vibe Builder to generate workflows and Agents with natural language.
On the surface, this may only be a change at the experience layer, but in essence, it is a new way of organizing cloud services. In the past, developers needed to select, access and combine various cloud services on their own. With Agent Studio, these capabilities are pre-combined around specific tasks, turning into