Qoder Engineering Practices Series: If an agent's boundary is tool invocation, then the boundary of Cloud Use is cloud-native execution. The former lets AI help people operate software; the latter makes agents a new kind of cloud workload. By the end of this article, you will see that the difference between Cloud Use and ordinary Tool Use is not whether an agent can call APIs, but whether it can truly enter the cloud's production environment with a governed identity, credentials, environment, lifecycle, and audit trail.
At 2 a.m., a cross-border seller's new product suddenly sees a surge in orders. Before anyone wakes up, an agent is already at work. It creates a temporary sandbox, pulls inventory and payment data, checks anomalous orders, simulates different logistics options, calculates the impact of tariffs, drafts customer service responses, adjusts advertising recommendations, and routes high-risk orders to a human for confirmation. It has not opened a console or logged in to a server, but it is very much using the cloud.
At that moment, the questions become urgent: Whose identity does this agent use to access the inventory system? Has the payment data it sees been masked? Where are the credentials it uses to call cloud APIs? If it changes a resource's specifications, who authorized that? If the task fails after running for 40 minutes, can its state be recovered? Can every operation be audited? Getting an agent to call a cloud API once is not hard. The hard part is having it make calls every day, in the middle of the night, across systems, and within permission boundaries—and knowing, for every call, who authorized it, which credentials were used, what actions were taken, whether risk controls were triggered, and whether the result can be reproduced. These are the questions Cloud Use must answer.
For more than twenty years, cloud computing's primary interaction model has revolved around two kinds of actors: human operators and deterministic automation programs. People log in to consoles, create Elastic Compute Service (ECS) instances, configure databases, read logs, and handle alerts; CI/CD, Terraform, Kubernetes controllers, and scheduled scripts execute predefined rules. Later, CLIs, SDKs, IaC, and more automation platforms greatly reduced the effort required of people, but the underlying assumption remained clear: either a person was operating the system or a deterministic program was executing. This model was stable. Cloud platforms built their account systems, permission models, audit logs, console interactions, and ticketing workflows around it. A Resource Access Management (RAM) user, an AccessKey, or an operation record could usually be traced to a specific person, team, or system.
With the arrival of agents, a middle ground has emerged. An agent no longer just answers, "How do I use this cloud product?" or generates a script. It is starting to read logs, analyze bills, diagnose CI issues, inspect data tasks, call cloud APIs, submit a merge request (MR), and trigger pipelines. In other words, it is moving from an assistant that understands the cloud to a software actor that uses it.
Cloud computing was largely designed around human operators and deterministic automation programs. Agents introduce a new variable: a software actor that can reason, call tools, and act across systems.
The implications go far beyond "one more AI assistant." When the user is a person, consoles, CLIs, SDKs, and IaC all reduce the effort that person needs to operate the cloud. When a deterministic program is doing the work, the cloud platform manages service accounts, roles, policies, and logs. An agent sits between the two: it combines a person's ability to understand goals with a program's execution speed and volume of calls. It does not need a console, mouse, or desktop, but it does need identity, permissions, tools, data, a runtime environment, state management, cost records, failure recovery, and an audit trail. Putting these three kinds of users in one diagram makes the boundaries clearer.
In this diagram, humans and deterministic programs are both users the cloud already knows, with account systems and audit trails refined over twenty years. Agents are the new variable between them: they neither make a few mouse clicks at a time like people nor follow only predetermined paths like scripts. They reason and connect actions across systems. To accommodate them, cloud platforms must provide a path within the same governance layer. In practice, many agents that have only Tool Use capabilities, without cloud-native governance, look functional in demos but stall when they enter production. They can call tools, but the cloud platform has not yet accepted them as software actors it can manage.
We have all come to recognize that the problem is not how capable the model is, but that today's agents have never truly been accommodated by the cloud. They look impressive in demos, then reveal their limitations in production. A cloud agent demo is easy to build: give it an AccessKey ID and AccessKey secret (AK/SK), wrap a few cloud APIs as tools, write a prompt, and ask it to "check yesterday's billing anomalies." With a sufficiently capable model and well-wrapped tools, it can indeed produce a respectable result. Everything looks smooth on day one; by day two, questions arise. Whose AK/SK pair is this? Are its permissions too broad? Did the keys enter the model context? Where are the tool-call logs? Who is responsible if it accidentally deletes resources? Does the task keep running after the user shuts down their computer? How are credentials and context reused when another team member takes over? How does the security team audit it? These are not peripheral concerns. They determine whether an agent can move from demo to production.
An agent with only Tool Use capabilities typically consists of a conversation, a few tools, and a result. It often operates in a person's shadow: running on their computer, logging in with their account, calling APIs with their AK/SK, and relying on their online presence to keep the task alive. That works for short tasks and exploratory analysis. But without systems for identity, credentials, runtime, and auditing, it is hard for the agent to become a stable cloud workload. Cloud Use is not about whether an agent can call tools. Tool Use, Function Calling, and the Model Context Protocol (MCP) have already addressed part of that problem. Cloud Use addresses a different question: how the cloud can accommodate agents so they can run in ways that make them identifiable, authorizable, auditable, and platform-managed.
An agent with only Tool Use addresses "how a model calls tools." Cloud Use addresses "how the cloud accommodates agents as governed users."
That distinction is the dividing line. It moves the discussion from "which tools an agent can access" to "where it runs, under what identity, how it uses credentials, how long tasks can continue, whether it can recover from failure, and who can audit it."
| Aspect | Agent with Tool Use but No Cloud Platform Governance | Cloud Use |
|---|---|---|
| Execution location | Local process, browser session, or the context of a single chat | Cloud session, with tasks that can keep running, recover, and be scheduled |
| Identity model | Borrows a person's account or uses fixed keys | Uses a governed machine identity and task-level authorization |
| Credential use | AK/SK and tokens can easily end up in prompts, scripts, or logs | Uses credentials by reference through a Vault, keeping them out of the model context |
| Tool boundaries | Wraps individual APIs, with governance scattered across implementations | Exposes capabilities through MCP or similar tool protocols, with permissions, auditing, and confirmation mechanisms integrated at the platform layer |
| Production risks | Credential leaks, excessive permissions, interrupted tasks, and unclear accountability | Low-risk actions execute automatically; high-risk actions require confirmation; the entire process is traceable |
An agent relying only on Tool Use is like a temporary assistant sitting beside you, helping you operate things. Cloud Use is more like issuing the agent an employee badge and admitting it to the cloud workplace—while recording every access check, every evidence-gathering step, and every action.
That is enough theory for now. Breaking it down by scenario will show which production gaps Cloud Use actually fills. Saying only that "agents can query logs, run reports, and call APIs" does little to distinguish it from ordinary agents, because they can do those things too. The real difference lies in how the work changes: whether tasks are independent of a person's online presence, whether agents can enter the cloud environment themselves to gather evidence, and whether their actions have defined identity, credential, and audit boundaries.
Many cloud tasks are not complicated, yet they still depend on people. Returning to the cross-border seller at the start of this article, the team has plenty to check the day after the order surge: Has inventory been depleted? Is the payment failure rate abnormal? Have logistics costs suddenly risen? Are customer service tickets concentrated in one region? Today, this usually means someone opens the BI system, cloud billing, data platform, and logging platform, runs queries one by one, and compiles the results for a group chat. The workflow is highly repetitive, and the rules are relatively clear. The problem is not its difficulty, but that someone has to be there.
Ordinary agents can ease some of this work. They can help write SQL, explain anomalies, and polish reports. In most cases, however, a person still has to initiate the task, provide context, confirm credentials, and copy results into the target system. The agent speeds up one step, but the entire chain remains tied to a person. With Cloud Use, the task can wake up on its own.
A cloud agent can be triggered by cron in the cloud or by various unexpected events. It can use a task-level identity to access data sources and cloud tools, use controlled credentials through a Vault, and invoke BI, logging, storage, compute, and other capabilities through MCP. It runs queries, identifies anomalies, generates reports, and sends the results back to IM, documents, webhooks, or business systems. No one has to open a page at the same time every day.
The real change in recurring tasks is not just faster report writing. It is that the task no longer depends on a particular person being online.
This does more than save a few minutes; it changes how responsibility is organized. Previously, "someone has to remember to do it every day." Now, "a delegated task runs on schedule, and people handle only exceptions and decisions." In the example tasks we discussed, one BI analysis involved 111 tool calls and ran for approximately 21.5 minutes (21 minutes and 32 seconds), with 0 human interventions along the way; one ETL task generated 116 events, ran for 13 minutes, and completed after being triggered by cron. These figures come from specific example tasks and do not represent a consistent SLA across all scenarios. Their point is not to show off call counts, but to demonstrate that an agent is no longer merely an answerer in a chat window: it can take on a cloud task with a lifecycle.
CI failures, slow queries, and production alerts are another typical class of tasks. Previously, when CI failed for an MR, a developer had to open pipeline logs, inspect test failures, look up recent dependency changes, verify the build image, and then check build machines, caches, networking, and permission settings in the cloud. Often, the problem is not particularly deep; the context is simply scattered across too many systems. Ordinary agents are useful here too: paste logs into one and it can summarize the errors; paste in configuration and it can suggest possible causes. But this still amounts to "bringing the material to the agent." The agent cannot enter the environment itself or trace the evidence chain on its own. It can only analyze the fragments you feed it.
Cloud Use changes how diagnostic tasks work. When a CI failure event occurs, the agent API is triggered directly in the cloud. The agent uses its cloud identity to read pipeline logs, look up related MRs, inspect dependency changes, and access the state of the build environment. When needed, it calls logging and monitoring systems, connects the evidence, and writes its findings back to an MR comment, IM group, or ticket. It is doing more than "summarizing logs": it is actively gathering evidence.
The real change in diagnostic tasks is not just a better explanation of an error. It is that the agent can enter the cloud workplace itself, gather context, and build an evidence chain.
Scenarios such as ELK slow-query diagnosis and CI failure diagnosis make this distinction especially clear. In the examples we discussed, slow-query diagnosis could deliver end-to-end findings within 2–5 minutes, while CI diagnosis could post its analysis back to an MR within 3–8 minutes. Actual durations depend on system scale, tool response times, and the complexity of the context. The number of minutes is not meaningful on its own. What matters is that the agent no longer waits for someone to copy material over: it starts gathering evidence proactively around an event.
Execution tasks are the easiest to misunderstand. If an agent can diagnose a problem, can it fix it directly? Can it create preview environments, trigger pipelines, clean up temporary resources, or adjust configuration? In the cross-border seller example, the agent can automatically generate restocking recommendations and simulate logistics options. But when it comes to changing advertising budgets, altering fulfillment strategies, or handling high-risk orders, it must stop and wait for human confirmation. Technically, sufficient permissions would allow it to act—but that is precisely where the real risks lie.
Many teams already have scripted automation. Scripts have keys, permissions, scheduled jobs, and logs. But they usually lack dynamic judgment and cross-system context, and they are not good at explaining results. Ordinary agents add judgment, but may also amplify risk: they can act on context, yet if identity, credentials, permissions, and auditing do not keep pace, stronger automation means a larger blast radius.
Cloud Use does not aim to let agents execute automatically without boundaries. Quite the opposite: it aims to make execution safe to delegate. Low-risk actions can run automatically, such as reading logs, generating reports, creating temporary sandboxes, and cleaning up expired resources. High-risk actions must go through confirmation, such as deleting production resources, expanding permissions, changing production configuration, or triggering releases that affect users. An agent can provide recommendations and evidence, but it cannot cross those boundaries.
The real change in execution tasks is low-risk automation, approval for high-risk actions, and end-to-end traceability—not fully automated replacement of people.
Together, recurring, diagnostic, and execution tasks outline a new role: the agent is no longer an assistant in a chat window, but a software actor with an identity, boundaries, and a lifecycle. Automation with ordinary agents often relies on trust: trust the prompt, trust the model, trust the tool wrappers. Cloud Use relies on governance: the agent's identity can be established, credentials are not visible to the agent, permissions are revocable, actions are subject to approval, processes are auditable, and failures are recoverable.
Once the theory is clear, it needs to be tested in a real scenario to see whether it actually works. In this section, we take the model above into a coffee business review meeting.
It is nine o'clock on Monday morning, and a coffee chain's business review meeting is about to begin. The CEO does not want a weekly report that says "overall performance is good." He wants three answers: Which store format has the highest daily sales per square meter? Which category is emerging as the next growth driver? Which city should be prioritized for new stores next quarter? Across Hangzhou, Shenzhen, Chengdu, and Guangzhou, there are 15 stores, with data scattered across 4 tables and 320 rows of fact data. It is not a big problem, but it is enough of a headache. The traditional workflow is familiar: the business submits a request, a data analyst schedules it, agrees on metric definitions, writes SQL, queries MaxCompute or the data warehouse, organizes tables, and writes a business report. That takes a few days at best, or a week or two at worst. It is not about how hard analysts work. The problem is that these tasks always have to queue for time on someone's calendar.
The appeal of Cloud Use has never been that an agent "can write SQL too." That is nothing special. The real change is that this work can be delegated as a cloud task. The agent moves from a question-and-answer partner in a chat window to a software actor with an identity, credential boundaries, a runtime, event delivery, and acceptance criteria.
The value of the coffee BI case is not that it generated a report, but that it ran a complete chain: business question → data access → query execution → error recovery → result delivery → proof of acceptance.
This chain can be mapped to six engineering questions. They are not a breakdown of product modules, but six hurdles that a real task must clear as it moves forward:
At the start of the task, the first obstacle is neither the model nor SQL. It is credentials. The agent needs to query a data warehouse, and the most blunt approach is to put the AK/SK into the prompt. Fast. Also dangerous. The keys enter the model context, may appear in tool logs, and could be carried into a webhook payload by an intermediate result. In real production, this would not pass a security review.
So the credentials go into the Vault first. The agent receives a reference such as vault_credential_id , not plaintext keys. When the runtime accesses DataWorks, MaxCompute, or other cloud services, the platform or tool layer handles credential exchange and controlled injection. This distinction is crucial: an agent may use the cloud, but it must not possess a master key that can be copied away.
Once credentials are handled, a second problem appears: which path should the agent take? Knowing that it needs to analyze MaxCompute data does not mean it knows that, in a real enterprise environment, it should submit ODPS SQL through DataWorks. It might look for an apparently more direct interface, or repeatedly try APIs that do not apply. The "smarter" the model, the more readily it can invent a path that looks reasonable. This is where a Skill proves its value. It is more a record of an organization's hard-won lessons than a prompt template: which APIs not to use, which ODPS SQL syntax pitfalls to watch for, what to check first when a resource group is frozen, and which fields a report must contain. In this example, the Skill avoided approximately 13 minutes of exploration down the wrong path. That figure comes from this particular example task and is not a general promise. It illustrates that what Cloud Use needs to reuse is a verified execution path, not a one-off prompt.
Once the path is settled, the question shifts to role boundaries. "You are a data analyst" is far too broad—broad enough for an agent to write a polished but untraceable report. Before execution in the cloud, the agent's scope must be narrowed: which tools it can use, which metric definitions it must follow, which errors it can recover from on its own, and which actions require it to stop.
A simplified task contract might look like this:
You are a senior data analyst.
Analyze MaxCompute data by executing ODPS SQL through DataWorks.
For each analytical dimension, provide:
1. A conclusion supported by numerical evidence;
2. A table of query results;
3. Actionable business recommendations.
Do not make claims about the data that cannot be traced to evidence.
If a resource group is unavailable, first check for available resource groups.
If necessary, follow the predefined recovery plan to create a temporary resource group and record the action.This is not a demonstration of prompt tricks. It is more like a small task contract: conclusions must include numbers, those numbers must be traceable to query results, and error handling must not exceed authorized permissions.
Once the task is actually running, the runtime is put to the test. This example ran for 21 minutes and 32 seconds, producing 111 tool calls and 312 events, with 0 human interventions along the way. These figures are neither a platform SLA nor a performance promise for all BI tasks. They demonstrate something else: Cloud Use can support a multistep task that lasts longer than an ordinary chat turn, with a process that can be traced, replayed, and integrated with business systems. This is the fork between "running an agent locally" and "delegating a task to the cloud." After the user initiates the task, the agent continues executing in a cloud session. Closing the browser, putting the computer to sleep, or disconnecting the chat window should not affect the task's lifecycle.
After the report is generated, another frequently underestimated question remains: how does it get back to the business system? If the final output is just text in a chat window, the BI digital worker has still not entered the business workflow. A more reliable approach is for the business system to subscribe to task-ending events—for example, retrieving the complete result after session.thread_idled. Listen too early and you get an unfinished result; wait until the thread is idle before retrieving the report, and the result is stable.
A practical code example makes this clearer than more explanation:
import hmac
import hashlib
import time
def verify_webhook(secret: bytes, raw_body: bytes, header: str, tolerance: int = 600) -> bool:
parts = dict(item.split("=", 1) for item in header.split(","))
timestamp = int(parts["t"])
if abs(time.time() - timestamp) > tolerance:
return False
payload = f"{timestamp}.".encode() + raw_body
expected = hmac.new(secret, payload, hashlib.sha256).hexdigest()
return hmac.compare_digest(expected, parts["v1"])
def handle_event(event):
if event["data"]["type"] == "session.thread_idled":
session_id = event["data"]["id"]
enqueue_report_pull(session_id)The code is short, but the boundaries are clear: the webhook must be verifiable as coming from a trusted source, task completion must be event-driven, and report retrieval must be handled asynchronously. Otherwise, the agent may finish its work while the result is lost along the way, leaving the chain incomplete.
Finally, a task cannot be considered complete just because the agent says it is. Whether a BI task is complete depends not on whether there is a report-like block of text at the end, but on whether it answers the business questions: Which store format has the highest daily sales per square meter? Which category is growing fastest? Which city should be prioritized for expansion? Does every conclusion include numbers? Can those numbers be traced back to SQL query results?
| Acceptance Item | Criterion |
|---|---|
| Data source access | Was access performed using controlled credentials, with plaintext keys kept out? |
| Query execution | Were traceable SQL statements and query results produced? |
| Analytical completeness | Were task requirements such as daily sales per square meter, GMV, and city scores covered? |
| Quality of conclusions | Does every conclusion include numbers, and are those numbers traceable? |
| Action recommendations | Can the recommendations be translated into actionable business steps, rather than vague generalities? |
| Result delivery | Did the results reach downstream systems through a webhook or business API? |
| Failure recovery | Were errors, retries, or self-recovery paths recorded? |
| Auditability | Can key parts of the process be replayed from the event stream? |
The final output is an inspectable business assessment, not just "analysis complete": pickup stores have average daily sales per square meter of approximately ¥85+/m², about 2.2 times the approximately ¥38/m² of flagship stores; coffee accounts for 81.3% of GMV, tea beverages grew 18.5% period-over-period, and merchandise grew 45.0% period-over-period; city expansion scores are 0.92 for Hangzhou, 0.85 for Shenzhen, 0.78 for Chengdu, and 0.70 for Guangzhou. These numbers are what move a BI agent from "able to generate reports" to "able to answer business questions."
The example also encountered an unavailable resource group. An ordinary script would typically fail and exit; an ordinary agent might keep trying the wrong path until a person intervenes. A more appropriate Cloud Use approach is to record "resource group unavailable" as a known failure mode in a Skill: first check for available resource groups, create a temporary one within preauthorized boundaries if necessary, record the operation, and then continue executing the remaining SQL. Actions that exceed cost, permission, or resource limits still require human confirmation. This kind of self-recovery must not be understood as "the agent can change cloud resources however it likes." Rather, it shows that Cloud Use maturity is not about never failing. It is about whether the agent can recover within governance boundaries after a failure—and whether it knows how to stop cleanly when it cannot recover.
An agent that is truly safe to delegate work to does not establish completion by declaring it itself. Its completion status is demonstrated jointly by events, logs, artifacts, and acceptance criteria.
Looking back, the coffee BI workflow is more than a case study. It brings the theory of Cloud Use into a concrete setting: credentials must not be exposed, hence the Vault; execution paths must not be guessed, hence the Skill; execution must not depend on someone being online, hence the Session; results must not remain in a chat window, hence the Webhook; and completion must not rest on self-declaration, hence Verification. This is also a key step in moving Cloud Use from "looks automated" to "ready for production."
Stepping back from the coffee BI scenario, we can now define Cloud Use more abstractly. Cloud Use is an agent's ability to use cloud compute, data, tools, identity, and runtime to complete tasks in a controlled, auditable, and recoverable way. These form a dependency chain rather than a feature checklist: without identity, there can be no credentials; without credentials, there can be no tools; without tools, there can be no runtime. That is only a change in the point of entry. The real change is that an agent moves from "a model that calls tools" to "a software actor that a cloud platform can host and manage."
This requires at least four layers of capability. These form a dependency chain rather than a feature checklist: without identity, there can be no credentials; without credentials, there can be no tools; without tools, there can be no runtime.
The essence of Cloud Use is not to give an agent one more tool, but to provide identity, credentials, tools, and a runtime so it can become a software actor that the cloud platform can host and manage.
Without these, an agent is still just a clever assistant in a conversation. It can help, but it is hard to entrust work to it.
Once the four layers are in place, the relationship between the cloud and its users is already quietly changing: people are no longer the only frontline operators. Consoles, CLIs, SDKs, and IaC all address the same question: how can people operate cloud resources more efficiently? The console turned the data center into pages. CLIs and SDKs turned pages into commands and code. IaC turned sets of resources into declarative, reusable, auditable configurations. Each evolution hid more of the underlying detail, letting people operate the cloud at a higher level of abstraction.
Agents do more than raise the abstraction level another notch. They make it possible for the task itself to become a new cloud abstraction. People no longer operate resources one by one; they define goals, boundaries, and acceptance criteria. In the cloud, agents create environments, access data, call tools, explore in parallel, verify results, and release resources. They resemble a new kind of workload: their lifecycles may be short, their permissions should be granular, their resource use is highly dynamic, and their behavior must be traceable.
Historically, the cloud's core abstraction was the resource. In the agent era, the cloud also needs new abstractions for tasks and software actors.
This is also where Cloud Use repositions old and new interfaces. It does not replace consoles, CLIs, SDKs, or IaC. Instead, those existing interfaces become the agent's tool layer. An agent does not need to click through a console, but it can perform the operations behind it through controlled interfaces. It does not need to type CLI commands manually, but it can call equivalent cloud APIs. It does not need to handwrite a complete Terraform configuration, but it can generate, validate, and submit changes, leaving high-risk parts for human confirmation. The new interface does not eliminate existing tools; it incorporates them into its execution layer.
| Existing Way of Using the Cloud | Problem It Solves | New Role in the Agent Era |
|---|---|---|
| Console | Lets people manage cloud resources visually | Becomes an interface for human review and visual replay |
| CLI / SDK | Enables programmatic operations on cloud resources | Becomes the underlying execution interface through which agents invoke cloud capabilities |
| IaC | Makes resource state declarative and versionable | Becomes subject to governance as agents generate, validate, and submit changes |
| Cloud Use | Lets agents take on cloud tasks within governance boundaries | Becomes a new way for software actors to use the cloud |
This is why "safe to delegate work to" matters more than "fully automated." Enterprises will not hand their cloud over to a black-box agent. They are willing to entrust work to a software actor with an identity, boundaries, logs, recovery mechanisms, and the ability to stop at critical points and wait for human confirmation. Cloud Use seeks to establish verifiable trust, not blind trust.
So far, we have described a paradigm shift, and it sounds complete. But real production does not become cooperative just because a conceptual model is complete. Showing only success stories would make Cloud Use look like a sales pitch. The real engineering divide often emerges after a failure. Real cloud tasks will encounter failures: unsuitable APIs, insufficient permissions, unavailable resource groups, query timeouts, lost webhooks, or results that do not meet business standards. The key to production readiness is to design the failure paths themselves—not hide failures or try to reason around them at greater length.
What Cloud Use really needs to ensure is that agent failures are observable, containable, and recoverable—and that the agent can stop cleanly when recovery is impossible. "Always succeeding" was never the goal.
1. Wrong Paths: Agents Can Choose APIs That Look Reasonable but Do Not Actually Work
The stronger an agent's reasoning capabilities, the more readily it can propose a path that "looks reasonable." For example, it knows it needs to query MaxCompute data, so it looks for an API that executes SQL directly. But in the actual cloud product workflow, the correct route may be through a temporary workflow in DataWorks or a designated execution entry point. Without Skills and tool boundaries, an agent can waste time on the wrong path, even trying it repeatedly. The solution is not to make the model "a little smarter," but to capture both correct and incorrect paths in a Skill: tell the agent which APIs are available, which to avoid, and how to switch paths when it encounters specific error codes.
2. Infrastructure Failures: A Frozen Resource Group Should Not Automatically Mean Stopping for Human Intervention
A frozen resource group, an unavailable queue, or temporarily invalid permissions usually becomes a point of human intervention in traditional workflows. Cloud Use can turn some of these into controlled self-recovery paths: first check for available resource groups, then determine whether there is a preauthorized policy for creating a temporary resource group. If the action is within bounds, create the group, bind it, and record the operation. If it exceeds the boundaries, stop execution and request human confirmation. The point is not that "the agent fixed it itself," but that it did not exceed its authority. Recover within bounds when recovery is possible; stop explicitly when it is not.
3. Result Delivery Failures: Listening for the Wrong Event Can Return an Unfinished Result
A cloud agent generates many events during execution. If a business system listens too early—for example, retrieving the report as soon as it sees a status update—it may get an unfinished result. A safer approach is to retrieve the complete result after the task thread becomes idle, and to apply signature verification, idempotent processing, and retries to webhooks. These are small details, but they determine whether Cloud Use is a demo or a production workflow that can connect to business systems.
4. Loose Acceptance Criteria: The Agent Looks Finished, but the Business Has No Answer
An agent can easily generate something that looks like a report. It has headings, tables, and recommendations. But without acceptance criteria, it may not answer the actual questions: Which store format has the highest daily sales per square meter? Which category is growing fastest? Which city should be prioritized for expansion? Does every conclusion include numbers? Can those numbers be traced back to SQL query results?
If the rubric is too broad, an agent can pass too easily; if it is too detailed, the task may go through repeated revisions. One of the engineering capabilities of Cloud Use is to define "what counts as complete" in executable, checkable criteria. This is also one of the clearest ways to distinguish Cloud Use from ordinary agents. When they fail, ordinary agents often provide a plausible explanation. Cloud Use is more concerned with which step failed, whether permission boundaries were crossed, whether retries were triggered, whether audit events were generated, and whether a person needs to take over.
A cloud agent's maturity is measured not by whether it encounters errors, but by whether its failures leave the system in a worse state.
Recoverable failures do not mean that any task can be handed straight to an agent. Choosing what to delegate first matters more than asking "what can it do?" Any new paradigm can invite inflated expectations.
Cloud Use is no exception. Start by saying "let an agent manage the production cloud environment automatically," and technical readers will instinctively be wary. They are right to be. Production changes, permission expansion, data deletion, and billing operations in the cloud should not be automatically allowed just because an agent can reason. A more realistic path begins with low-risk, frequent tasks whose results can be verified, then gradually advances to execution with confirmation, and only then approaches high-risk changes. This path can be drawn as a three-stage maturity curve:
Specific tasks can be placed along this curve: recurring inspections, cost anomaly analysis, CI failure diagnosis, analysis of slow queries in logs, temporary environment creation, expired resource cleanup, report generation, and data task status checks. These tasks share common traits: they read more than they write, their results are easy to verify, failures can be retried, and risk boundaries are clear.
Once these tasks are working, gradually expand to execution actions that require confirmation. For example, an agent proposes a fix and triggers a pipeline after human confirmation; generates an IaC change that is merged after human review; creates temporary resources that are automatically reclaimed on expiry; or detects a cost anomaly, sends a notification first, and waits for human approval before adjusting the strategy.
| Stage | Tasks Suitable for Delegation to Agents | Human Control Points That Must Remain |
|---|---|---|
| Reading and analysis | Log analysis, cost reports, CI diagnosis, daily inspection reports | Scope of data access, masking of sensitive fields, accountability for interpreting results |
| Low-risk execution | Creating temporary environments, cleaning up expired resources, triggering test pipelines | Resource quotas, expiration policies, rollback on failure |
| High-risk changes | Production configuration adjustments, permission changes, releases | Human confirmation, change approval, rollback plans, audit trails |
Cloud Use maturity is not reflected in whether an agent can bypass people, but in whether it knows when it must stop and wait for them.
This boundary must be clear. Otherwise, Cloud Use is easily mistaken for "letting AI operate cloud resources automatically." The real goal is to bring permissions, credentials, and execution back to where the cloud platform can govern them—not simply keep expanding the model's permissions.
The three-stage path ultimately leads to a simple question: What do we want the cloud to become when people are no longer its only users? If consoles, CLIs, SDKs, and IaC address how people can use the cloud more efficiently, Cloud Use addresses something else: how a cloud platform can accommodate, constrain, and host a software actor when people are no longer its only users. This is its fundamental difference from ordinary agents. An ordinary agent can help a person complete an operation; Cloud Use aims to make agents a new kind of cloud workload—with an identity, an environment, tools, a lifecycle, an audit trail, and boundaries they must respect.
This change will not replace existing ways of using the cloud overnight. Consoles, CLIs, and IaC will remain, but their roles will change: from interfaces people use directly to a tool layer through which agents can invoke operations, validate and submit changes, and replay execution. The value of Cloud Use is not that it helps agents understand the cloud, nor that it lets them make a few more cloud API calls. What it really changes is the relationship between the cloud and its users: agents are no longer just an add-on for people. They are becoming software actors that cloud platforms can identify, authorize, host, and audit.
The next step worth taking is to start with frequent, low-risk, verifiable tasks: let the agent run scheduled inspections, diagnose failures, analyze costs, generate reports, and create temporary environments—then stop at every high-risk point to wait for human confirmation. Handing the highest-risk cloud operations straight to an agent should not be the starting point. Only when this path works does cloud computing truly move from "people operate resources" to "agents take on tasks."
Introducing Cloud Use in Qoder Cloud Agents—try it for yourself.
Better Harness Is Here: Make Your Agent Better with Every Task
1,559 posts | 524 followers
FollowAlibaba Cloud Native Community - June 2, 2026
Alibaba Cloud Native Community - January 21, 2026
Alibaba Cloud Native Community - March 25, 2026
Alibaba Cloud Native Community - October 12, 2026
Alibaba Cloud Native Community - June 5, 2026
Alibaba Cloud Native Community - July 8, 2026
1,559 posts | 524 followers
Follow
QwenWork
QwenWork is dedicated to helping employees strengthen their professional competitiveness in the AI era and to enabling enterprises to improve organizational effectiveness.
Learn More
Qoder
From Assisted to Autonomous — Adapting to Every Programming Need
Learn More
Token Plan
Build more, spend less. One plan, every modality.
Learn More
IDaaS
Make identity management a painless experience and eliminate Identity Silos
Learn MoreMore Posts by Alibaba Cloud Community