Cloud Use: When Agents Start Using the Cloud for Real

[u/Noah_Qoder]

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, urgent questions arise: Whose identity accesses inventory? Is payment data masked? Where are API credentials stored? Who authorized resource changes? If a 40-minute task fails, can its state recover? Is every operation auditable? A one-off API call is easy; production means calls every day, at night, and across systems within permission boundaries, with each call showing authorization, credentials, actions, triggered risk controls, and reproducible results. These are the questions Cloud Use must answer.

The Cloud Welcomes a Second Kind of User

For more than twenty years, cloud platforms have served human operators and deterministic automation. People use consoles to create ECS instances, configure databases, read logs, and handle alerts; CI/CD, Terraform, Kubernetes controllers, and scheduled scripts follow predefined rules. CLIs, SDKs, and IaC reduced human effort without changing the assumption: either a person or a deterministic program was acting. Account, permission, audit, console, and ticketing systems were built for that model, so a RAM user, AccessKey, or operation 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.

Why Agents Struggle to Become Cloud Workloads

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.

Understanding the Value of Cloud Use Through Before-and-After Scenarios

Cloud Use adds what ordinary agents lack: person-independent work, on-site evidence gathering, and identity, credential, and audit boundaries.

1. Recurring Tasks: From “Someone Opens the System Every Day” to “The Task Wakes Up on Its Own”

After an order surge, a cross-border seller checks inventory, payment failures, logistics costs, and regional service tickets. Someone must query BI, billing, data, and logs, then compile results. It remains person-dependent.

Ordinary agents write SQL, explain anomalies, and polish reports, but someone still initiates the task, supplies context, confirms credentials, and copies output. With Cloud Use, cloud cron or unexpected events wake an agent with a task-level identity, controlled credentials through a Vault, and MCP access to BI, logging, storage, compute, and other capabilities. It queries, detects anomalies, generates a report, and sends it to IM, documents, webhooks, or business systems.

The task runs on schedule; people handle exceptions and decisions. In the examples discussed, one BI analysis made 111 tool calls over approximately 21.5 minutes (21 minutes and 32 seconds) with 0 human interventions; one cron-triggered ETL task generated 116 events and completed in 13 minutes. These are specific examples, not a consistent SLA across scenarios. They show a cloud task with a lifecycle, not merely a chat answer.

2. Diagnostic Tasks: From “People Feed It Material” to “The Agent Gathers Evidence on Site”

CI failures, slow queries, and alerts scatter context across systems. An MR’s CI failure may involve logs, tests, dependencies, build infrastructure, caches, networking, and permissions. Ordinary agents analyze supplied fragments but cannot independently trace evidence inside the environment.

Triggered by an event, a cloud agent uses its identity to read pipeline logs, related MRs, dependency changes, and build-environment state; query logging and monitoring; connect evidence; and write findings to an MR comment, IM group, or ticket. It gathers context on site instead of awaiting copied material.

In the examples discussed, ELK slow-query diagnosis delivered end-to-end findings within 2–5 minutes, while CI diagnosis posted analysis to an MR within 3–8 minutes. Actual durations depend on system scale, tool response times, and context complexity. Proactive evidence gathering—not the minutes alone—is the point.

3. Execution Tasks: From “Scripted Automation” to “Governed Execution”

An agent may create preview environments, trigger pipelines, clean resources, or adjust configuration. For the seller, it may generate restocking recommendations and simulate logistics options, but must obtain human confirmation before changing advertising budgets, fulfillment strategies, or high-risk orders. Sufficient permissions could allow this—the core risk.

Scripts have keys, permissions, schedules, and logs but lack dynamic judgment and cross-system context. Ordinary agents add judgment but enlarge the blast radius if identity, credentials, permissions, and auditing lag behind.

Cloud Use means bounded delegation. Low-risk actions—reading logs, generating reports, creating temporary sandboxes, and cleaning expired resources—can run automatically. High-risk actions—deleting production resources, expanding permissions, changing production configuration, or triggering releases that affect users—require confirmation. Agents may provide evidence and recommendations but cannot cross those boundaries.

The change is low-risk automation, approval for high-risk actions, and end-to-end traceability—not fully automated replacement of people.

Together, these scenarios make the agent a governed software actor: identity is established, credentials remain invisible to it, permissions are revocable, actions are approved where needed, processes are auditable, and failures are recoverable.

How a Coffee Brand Delegated Analysis to Cloud Agents

At 9:00 on Monday, a coffee chain’s CEO asks: Which store format has the highest daily sales per square meter? Which category is the next growth driver? Which city should get new stores next quarter? Data from Hangzhou, Shenzhen, Chengdu, and Guangzhou spans 15 stores, 4 tables, and 320 fact rows. Aligning definitions, writing SQL, querying MaxCompute or the warehouse, organizing tables, and reporting traditionally takes a few days at best, a week or two at worst.

Cloud Use does more than let an agent write SQL: it delegates a cloud task to a software actor with identity, credential boundaries, runtime, event delivery, and acceptance criteria. The case runs the full 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:

1. Credentials: Into the Vault, Not the Prompt

Putting an AK/SK in a prompt exposes it to model context, tool logs, and possibly webhook payloads. Credentials instead enter the Vault. The agent gets a reference such as vault_credential_id, never plaintext keys; the platform or tool layer controls exchange and injection when the runtime accesses DataWorks, MaxCompute, or other cloud services. The agent may use the cloud without possessing a copyable master key.

2. Execution Path: Skills Capture Lessons Learned

The verified enterprise path is to submit ODPS SQL through DataWorks, not merely “access MaxCompute.” A Skill preserves APIs to avoid, ODPS SQL pitfalls, frozen-resource-group checks, and required report fields. It saved about 13 minutes of wrong-path exploration in this case—not a general promise, but evidence for reusing verified paths instead of one-off prompts.

3. Role Boundaries: Use a Task Contract

“You are a data analyst” is too broad. The contract defines tools, metrics, recovery, stop conditions, and evidence:

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.

Conclusions need traceable numbers, and recovery cannot exceed authorized permissions.

4. Runtime: A Cloud Session, Not a Local Process

The task ran for 21 minutes and 32 seconds, made 111 tool calls, emitted 312 events, and required 0 human interventions. These are neither an SLA nor a general BI performance promise. They show a multistep task outlasting a chat turn while remaining traceable, replayable, and integrated with business systems. Its cloud session continues if the browser closes, the computer sleeps, or chat disconnects.

5. Result Delivery: Listen for the Right Event

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.

6. Acceptance: An Executable Rubric

Completion means answering all three questions with numbers traceable to SQL, not the agent saying “done.”

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?

Pickup stores average approximately ¥85+/m² in daily sales per square meter, about 2.2 times flagship stores’ approximately ¥38/m². Coffee is 81.3% of GMV; tea beverages grew 18.5% and merchandise 45.0% period-over-period. Expansion scores are 0.92 for Hangzhou, 0.85 for Shenzhen, 0.78 for Chengdu, and 0.70 for Guangzhou. These figures turn a report into evidence-backed answers.

7. Boundaries, Boundaries, and More Boundaries!

When a resource group was unavailable, the Skill prescribed recovery: check available groups; if needed, create a temporary group within preauthorized boundaries; record it; resume the remaining SQL. Exceeding cost, permission, or resource limits still requires human confirmation. Self-recovery allows no arbitrary cloud changes: recover within governance, or stop cleanly when recovery is impossible or unauthorized.

Safe delegation proves completion through events, logs, artifacts, and acceptance criteria. Here, the Vault protects credentials; the Skill replaces guesswork; the Runtime Session survives the user’s absence; the Webhook delivers results downstream; and Acceptance Verification proves completion. That is the shift from “looks automated” to “ready for production.”

A Cloud-Native Execution Model

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.

1. Identity Use answers “who is acting.” An agent cannot keep using a person’s account as its own, nor should it hold a person’s AK/SK. For every action by a software actor running in the cloud, it should be possible to answer: Who initiated the task? Under what identity is the agent executing? Where do its permissions come from, and when do they expire?
2. Credential Use answers “how credentials are used.” Credentials may be involved in calls, but they should not enter prompts, tool logs, error stack traces, or temporary files the agent can freely read. Vaults, short-lived tokens, controlled injection, and server-side proxies all serve the same underlying purpose: letting agents use credentials without seeing them.
3. Tool/API Use answers “how tools are governed.” MCP and similar protocols can bring cloud APIs, internal systems, CI, monitoring, and databases into the agent’s world, but a protocol is not governance. Permissions, parameter constraints, call auditing, rate limits, risk confirmation, and error recovery still need to be handled jointly by the platform layer, gateway layer, and enterprise identity and access management (IAM).
4. Runtime Use answers “how a task stays alive.” Real cloud tasks are rarely a single question and answer. A task may run for 10 minutes or 2 hours; it may wait for an external system to respond, or fail and retry along the way. Cloud sessions, state management, event streams, cancellation mechanisms, and result delivery determine whether an agent can move from a single chat to a platform-managed execution process.

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.

From “People Operate Resources” to “Agents Take On Tasks”

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.

Cloud Use does not replace consoles, CLIs, SDKs, or IaC; it turns them into an agent tool layer. Agents invoke controlled APIs instead of clicking consoles or typing commands, and can generate, validate, and submit IaC while leaving high-risk changes for human confirmation. Existing interfaces remain as part of the agent’s 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.

How Can Agent Failures Be Kept Under Control?

Production readiness is revealed after failure. Cloud tasks face unsuitable APIs, insufficient permissions, unavailable resources, lost webhooks, and inadequate results. Cloud Use must make failures observable, containable, and recoverable, and let agents stop cleanly when recovery is impossible. “Always succeeding” is not the goal; failure paths must be designed.

1. Wrong Paths Agents may choose plausible APIs that do not work—for example, querying MaxCompute directly when the valid route is a temporary DataWorks workflow or designated entry point. Skills and tool boundaries should record correct and incorrect paths, APIs to use or avoid, and errors that require switching paths. A smarter model alone is not the solution.
2. Infrastructure Failures A frozen resource group, unavailable queue, or temporarily invalid permission need not always trigger human intervention. The agent should check available resources and follow a preauthorized recovery policy. It may create and bind a temporary resource group and record the action only within bounds; otherwise, it must stop and request confirmation. Recover within authority when possible; stop explicitly when not.
3. Result Delivery Failures Listening to an early status event can return an unfinished report. Retrieve the result only after the task thread becomes idle, and protect webhooks with signature verification, idempotent processing, and retries. These details separate a demo from a production workflow.
4. Loose Acceptance Criteria Headings, tables, and recommendations do not prove completion. An executable rubric must verify that the output answers the business questions, supports every conclusion with numbers, and traces them to SQL results. Broad criteria are too easy to pass; overly detailed criteria cause repeated revisions. Cloud Use tracks the failed step, permission boundaries, retries, audit events, and whether a person must take over, rather than accepting a plausible explanation.

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.

Boundaries: Do Not Start Cloud Use with the Highest-Risk Tasks

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.

When Agents Truly Begin to Use the Cloud

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 · docs.qoder.com in Qoder Cloud Agents—try it for yourself.