Towards a Systems Foundation for Agentic Cloud Management

Daqian Ding; Minghao Li; Qingwei Lin; Tianyin Xu; Yiming Qiu; Yu Kang; Ziqian Liu; Ziyu Mao

REVIEW 3 major objections 4 minor 43 references

Agentic cloud management needs a systems foundation that blocks conflicting operations before they reach the provider, not just more capable AI reasoning.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-01 01:12 UTC pith:J6PKCWOR

load-bearing objection A promising design vision that should be refereed, but the lock-rule inconsistency undercuts the one safety demonstration. the 3 major comments →

arxiv 2607.25883 v1 pith:J6PKCWOR submitted 2026-07-28 cs.MA

Towards a Systems Foundation for Agentic Cloud Management

Minghao Li , Ziqian Liu , Ziyu Mao , Daqian Ding , Yu Kang , Qingwei Lin , Tianyin Xu , Yiming Qiu This is my paper

classification cs.MA

keywords agentic cloud managementcoordination substratesemantic concurrency controlmulti-granularity locksescrow lockssession-scoped viewscloud API semanticsTLA+ verification

verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper argues that AI agents operating cloud infrastructure will keep failing to coordinate unless coordination is built into the cloud management stack itself, rather than left to agent reasoning. It proposes a systems foundation in which each agent session sees a policy-controlled projection of a global resource graph, and every cloud operation is checked as a semantic transaction before it reaches the provider. Conflicting operations—such as two writes to different subnets of the same VNet—are serialized or rejected up front, while independent operations run in parallel. A six-operation Azure trace shows the substrate finishing 22.6% faster than serial execution and succeeding where unconstrained parallel execution fails. The paper positions CloudWeaver as the missing layer for safe, concurrent agentic cloud management.

Core claim

CloudWeaver is a coordination substrate for agentic cloud management that maintains a global graph of authoritative shared state and per-session local views projected from it. Each intercepted API request is matched to a provider plugin rule, checked against the session's view, and lowered into a graph delta. The execution phase turns deltas into semantic transactions: Multi-Granularity Locks protect topology and lifecycle dependencies, while Escrow Locks reserve capacity and quota, and admission is decided before the request is forwarded to the provider. If an operation would conflict, the session receives an attributable conflict report naming the blocking resource, constraint, and intent.

What carries the argument

The load-bearing mechanism is the semantic transaction layer: each cloud operation becomes a transaction that binds a session, a global graph delta, structural lock requirements (Multi-Granularity Locks over resource containment, attachment, and dependency relations), and escrow capacity reservations. A two-phase protocol prepares the lock plan outside the critical section, then revalidates and commits by acquiring MGLs and reserving escrow capacity; admission or rejection happens before provider submission, and a rejected transaction returns a conflict report with the blocking intent. The bidirectional projection between local and global graphs keeps every session's context reconciled with

Load-bearing premise

The safety guarantee rests on the assumption that the rules describing each cloud provider's API semantics are complete and correct; a rule that misses a conflict lets the conflict through.

What would settle it

Run a two-session trace where one session updates a VM while the other resizes its attached disk, submit both through CloudWeaver, and check whether both operations are admitted; if the provider rejects one or shared state diverges, the semantic-conflict guarantee fails.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

Conflicting intents can be resolved deterministically before provider execution, removing the race between retry loops that currently decides which intent wins.
Independent operations on disjoint resources continue to run in parallel, so the substrate does not pay the cost of serializing all management.
Agents receive attributable feedback—a conflict report naming the blocking resource, constraint, and intent—enabling revision instead of blind retry.
The same substrate can sit beneath existing cloud-user interfaces (SDK, CLI, IaC) and future agent-native interfaces.
Formal validation with TLA+ (bounded safety and progress checks plus a deadlock-freedom proof) supports the claim that the transaction protocol itself is safe.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

If provider plugin rules can be derived automatically from API specifications and traces, the substrate's safety guarantee becomes portable across providers; the paper leaves this derivation as future work, but the architecture is designed for it.
The session-scoped projection could also serve as a natural training harness for RL agents, since it gives each agent a clean, isolated observation while real infrastructure is shared underneath—an implication the paper sketches in its RL discussion.
A larger test suite that includes parent-resource mutations, quota exhaustion, and lifecycle dependencies would stress whether MGL and escrow locks cover all conflict classes; the current single VNet-conflict trace is suggestive, not exhaustive.
The attribution claim is directly testable: two agents with conflicting intents should each be able to learn the other's intent from the first rejection and revise their plans accordingly.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Desk Editor's Note

A promising design vision that should be refereed, but the lock-rule inconsistency undercuts the one safety demonstration.

read the letter

Short version: this is a well-written, honest design/position paper about a coordination substrate for agentic cloud management. The combination—session-local graph projections, a global graph, semantic transactions with MGL and escrow locks, and attributable conflict feedback—is new in this space and addresses a real gap. The paper states clearly that the implementation is in progress, so the evaluation is preliminary. I'd send it to peer review, but only after the authors fix a load-bearing inconsistency in the concurrency control description.

The strongest part is the problem framing: provider errors are late, ambiguous feedback; agents need intent attribution; and serialization is too coarse. The architecture is coherent, and the idea of projecting a global graph into session-scoped views is sensible. The six-operation Azure trace is an illustrative anecdote, not a validation, and the paper mostly presents it that way. The 22.6% makespan improvement over serial is plausible and the trace does show the motivating conflict.

The soft spot is exactly where the stress-test note lands. §4.2 says modified resources get exclusive locks and ancestors get intention locks. For two subnet creates under the same VNet, each takes an X on the new subnet and IX on the VNet. IX is compatible with IX, so both transactions are admitted and both go to Azure concurrently—which is precisely the provider conflict §5 claims CloudWeaver avoids by serializing "at the VNet scope." The paper does not explain what rule makes the shared parent exclusive. Maybe the real rule is X on any ancestor whose child collection is mutated, but that contradicts the stated "ancestors receive intention locks" and needs to be explicit. As written, the described mechanism cannot produce the paper's one concrete result. The safety claim therefore rests on an unspecified provider-plugin rule, and §6 concedes those plugins are future work. That is not a cosmetic issue; it is the gap between the abstract's "strong safety guarantees" and what is actually demonstrated.

Also, no code or data is shipped, and the TLA+ validation is only mentioned, not described. For a systems paper with a safety guarantee, that is thin. But none of this kills the idea. The design is a reasonable starting point, and the paper is honest about its status.

Who is this for: people working on AIOps, agent-cloud interfaces, or platform-level coordination. It deserves a serious referee, with the expectation of a rewrite: fix the lock rule, add more evidence or soften the claims.

Referee Report

3 major / 4 minor

Summary. The paper argues that agentic cloud management lacks a systems abstraction for coordinating scoped management intents over shared cloud resources, and proposes CloudWeaver, a coordination substrate that sits below cloud-user interfaces. CloudWeaver maintains session-scoped local graphs projected from a global graph (Principle 1), and coordinates concurrent operations before provider execution using multi-granularity locks (MGL) and escrow locks (Principle 2). The authors validate CloudWeaver on a six-operation Azure trace involving three sessions, showing that it preserves concurrency among independent operations while serializing conflicting subnet writes on a shared VNet, achieving a 22.6% makespan improvement over serial execution.

Significance. If correct, this is a valuable direction: it identifies a real gap in agentic cloud management and proposes a concrete architectural solution. The paper's strengths include a clear separation of planning and execution phases, a principled use of MGL and escrow locks for semantic concurrency control, and an explicit comparison against serial and parallel baselines. The absence of fitted parameters and the use of a real Azure trace are also positive. However, the evidence for the central safety and performance claims is thin: a single hand-picked trace with no repeated runs, no error bars, no released code/data, and the TLA+ validation is mentioned but not included. More importantly, the lock-derivation rule as stated does not explain the paper's own conflict case. The contribution is promising but needs a corrected protocol description and substantially stronger empirical backing.

major comments (3)

[§4.2, Table 1, §5/Fig. 6] The claimed prevention of the VNet conflict is not entailed by the specified lock rule. The paper states that "modified resources receive exclusive locks, while their ancestors receive intention locks." For two "add subnet" operations, the modified resources are the two new subnet nodes; the shared VNet is an ancestor and would therefore receive an IX lock. Under standard MGL semantics, IX is compatible with IX (Table 1 defines IX as "intention to acquire exclusive locks below this node"), so both transactions are admitted and forwarded to Azure concurrently. Nothing in §4.2 or Table 1 explains why the VNet parent becomes exclusive. The paper must either revise the rule to state that mutating a child collection takes X on the parent, or specify the plugin rule that makes the VNet exclusive. As written, the design permits the exact 409/AnotherOpInProgress failure that Fig. 6 claims to avo
[§6, 'Scalability and safety'] The safety guarantee is delegated to per-provider plugin rules whose development is explicitly left as future work. The paper's only demonstrated conflict case—two subnet creates on one VNet—requires a plugin rule about Azure VNet parent serialization, but no such rule is specified or quoted. Thus the claim of "strong safety guarantees" is not substantiated for any provider, including the one used in the validation. Additionally, the TLA+ validation described in §6 (TLC for safety/progress, TLAPS for deadlock freedom) is not accompanied by a spec, a link, or a statement of the checked properties, so it cannot be assessed or reproduced.
[§5, 'Latency comparison'] The empirical claim rests on a single, unrepeated run of a six-operation trace. No error bars, number of trials, or variance is reported. The 22.6% makespan improvement over serial (25.55s vs 33.03s) depends on one timing measurement, and provider-side API latency can vary significantly across runs. The paper should report multiple runs with medians/confidence intervals, and ideally release the trace and implementation so the result can be reproduced. As presented, the evidence is anecdotal.

minor comments (4)

[Table 1] The MGL mode table is helpful, but the paper never gives the MGL compatibility matrix. Without it, the reader cannot verify the claims about conflicts (e.g., why IX on a subnet conflicts with X on a subnet). Consider adding the standard compatibility table or a reference.
[Figure 6] The timeline figure would benefit from axis labels and a clearer indication of which operations belong to which session. In grayscale, the shaded bars are hard to distinguish. Also, the VNet conflict wait and the failed add subnet are not explicitly labeled in the parallel policy row.
[§4.1] The term "provider plugin rule" is central to admission, but its form is never defined. A small example (e.g., the rule that blocks a subnet create while a VNet update is in progress) would make the design concrete and would also address the major concern about the validation trace.
[Abstract] The abstract says CloudWeaver "offers strong safety guarantees," but the validation is preliminary and the safety claim depends on unspecified plugin semantics. Consider tempering this to "can provide" or "aims to provide" until the plugin layer is specified.

Circularity Check

0 steps flagged

No significant circularity; the main validation gaps are correctness/completeness issues, not definitional or fitted-input circularity.

full rationale

The paper contains no fitted parameters, no empirical constants derived from its own output, and no equation-level reduction; the evaluation is a direct comparison of three execution policies on a constructed six-operation trace, so the 22.6% makespan improvement is a measured result, not a prediction forced by construction. The design principles are requirements, not derived from the evaluation. Self-citations appear only in background (e.g., [33] in §2 for "existing IaC systems are explicitly designed to exploit concurrency among independent changes"), are not load-bearing for the safety/concurrency claims, and are independently published; they do not raise the circularity score. The TLA+ validation mentioned in §6 is self-reported and not externally checkable from the manuscript, which is an evidence limitation but not a circular derivation. Per the reviewing rule, two explicit gaps are flagged: (1) §6 says developing provider plugins "may be largely automated ... which we leave as future work," so the provider-semantic coverage of the stated safety guarantee is unvalidated; (2) §4.2's stated rule "modified resources receive exclusive locks, while their ancestors receive intention locks" would give only IX locks on the shared VNet for two subnet creates, and IX is compatible with IX under standard MGL, so §5's claimed serialization "at the VNet scope" is not derivable from the stated lock rule alone and depends on an unspecified additional plugin/admission rule. These are internal-consistency and omitted-proof issues, not cases where the claimed result is equivalent to its input by construction. Therefore no significant circularity.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 2 invented entities

The central design rests on domain assumptions about provider semantics being representable and the global graph being reconcilable; these are stated but not proven. No numeric free parameters are fitted. Two new design abstractions (coordination contract, semantic transaction) are introduced with no external falsifiable handle beyond the paper's own prototype.

axioms (4)

domain assumption Provider API semantics can be captured by finite, per-provider plugin rules that parse each API request into a semantic delta.
§4.1 says the API parser matches each request to a provider plugin rule and performs preflight checks; §6 admits plugin development is future work.
domain assumption The authoritative global graph is complete and up to date so that admission decisions and projections reflect true shared state.
§3.2 Principle 1 assumes session views are 'grounded in global state'; §4.1 describes the global graph as 'reconciled shared state'.
standard math MGL with intention modes and escrow locks preserve safety and deadlock-freedom when applied to the resource tree.
§4.2 invokes MGL and escrow locks; no proof is given, the paper relies on standard concurrency-control theory.
domain assumption Quota and capacity values are known and escrow reservations are accurate, so capacity constraints are not overbooked.
§4.2 says each capacity bucket tracks reserved capacity bounds; this assumes provider quota visibility and accurate counters.

invented entities (2)

Coordination contract no independent evidence
purpose: A system-level abstraction that binds each session's context and actions to authoritative shared state and returns attributable feedback (Abstract, §1).
Introduced as the paper's core vision; no formal specification or outside-the-paper artifact is provided.
Semantic transaction no independent evidence
purpose: Internal execution unit combining session intent, global delta, locks, capacity reservations, and status; §4.2.
Defined only inside the proposed substrate; the paper's trace is the only demonstration and it covers a single conflict class.

pith-pipeline@v1.3.0-alltime-deepseek · 10022 in / 13643 out tokens · 123444 ms · 2026-08-01T01:12:07.730983+00:00 · methodology

0 comments

read the original abstract

Agentic cloud management is emerging as a practice to automate laborious operations, minimize toil, and improve responsiveness. Despite the rapid development of autonomous management agents, we argue that the fundamental missing piece is a systems foundation to enable safe, effective operations across agents and between agents and human operators. In this paper, we advocate for the need of such a systems foundation and share our efforts on developing CloudWeaver, an agentic management substrate that works across existing cloud-user interfaces and future agent-native interfaces. Specifically, we discuss how CloudWeaver (1) scopes the context of individual agent sessions with local views of cloud resources and (2) coordinates concurrent management operations on shared cloud resources. CloudWeaver offers strong safety guarantees and attributable feedback in the presence of conflicting intents, while preserving concurrency between independent operations. We validate CloudWeaver using a representative Azure API workload.

Figures

Figures reproduced from arXiv: 2607.25883 by Daqian Ding, Minghao Li, Qingwei Lin, Tianyin Xu, Yiming Qiu, Yu Kang, Ziqian Liu, Ziyu Mao.

**Figure 1.** Figure 1: Modern cloud management stack. plan, and schedule the corresponding API operations. Despite their different abstractions, these interfaces ultimately converge at the same boundary: they translate tenant management intent into provider operations over shared cloud state. This stack has been increasingly used by AI agents. Platforms are exposing infrastructure state, operation context, and actions to agent… view at source ↗

**Figure 2.** Figure 2: presents a scenario involving two agents operating on the same VM. Agent A intends to permanently destroy the VM, while Agent B concurrently intends to replace it through a destroy–then–recreate workflow. If Agent B’s destroy executes first, Agent A’s subsequent destroy fails because the VM no longer exists. Agent B then recreates the VM, while Agent A continues retrying until it destroys the replacement,… view at source ↗

**Figure 3.** Figure 3: CLOUDWEAVER overview. Coordination under semantic constraints. Cloud coordination must reason about the semantic scope and effects of operations rather than resource identity alone. Many conflicts arise from identifier, lifecycle, and configuration semantics, such as scoped uniqueness, in-flight resource mutations, and compatibility constraints across related resources. For example, if one agent is upda… view at source ↗

**Figure 4.** Figure 4: Global and local views of shared resources. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗

**Figure 5.** Figure 5: Transaction state transitions. locks. For example, creating a VM may acquire 𝐼𝑋 locks on its parent region, VNet, and subnet, and 𝑋 locks on the new VM and NIC; deleting the subnet would require an 𝑋 lock on the subnet and therefore conflict with this child-resource creation [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗

**Figure 6.** Figure 6: Timeline of the preliminary validation trace. [PITH_FULL_IMAGE:figures/full_fig_p006_6.png] view at source ↗

discussion (0)

Reference graph

Works this paper leans on

43 extracted references · 3 linked inside Pith

[1]

https://www.aboutama zon.com/what-we-do/amazon-web-services

Amazon Web Services — aboutamazon.com. https://www.aboutama zon.com/what-we-do/amazon-web-services. [Accessed 29-06-2025]

2025
[2]

https://www.hashicorp

Detecting and Managing Drift with Terraform. https://www.hashicorp. com/blog/detecting-and-managing-drift-with-terraform
[3]

https://cloud.google.com/products/gemini

Gemini for Google Cloud. https://cloud.google.com/products/gemini
[4]

https://www.localstack.clo ud/localstack-for-aws

LocalStack for AWS — localstack.cloud. https://www.localstack.clo ud/localstack-for-aws. [Accessed 29-06-2025]

2025
[5]

https://azure.microsoft.com/en-us/product s/copilot

Microsoft copilot in Azure. https://azure.microsoft.com/en-us/product s/copilot
[6]

https://www.pulumi.com/blo g/patterns-drift-detection/

Patterns for Drift Detection with Pulumi. https://www.pulumi.com/blo g/patterns-drift-detection/
[7]

https://www.pulumi.com/docs/concepts /how-pulumi-works/

[Pulumi] How Pulumi works. https://www.pulumi.com/docs/concepts /how-pulumi-works/
[8]

https: //www.pulumi.com/

Pulumi: Infrastructure as code in any programming language. https: //www.pulumi.com/
[9]

https://www.pulumi.com/docs/concepts /resources/providers/

[Pulumi] Resource Providers. https://www.pulumi.com/docs/concepts /resources/providers/
[10]

https://www.terraform.io/

Terraform by Hashicorp. https://www.terraform.io/
[11]

https://developer.hashicorp.com/terraf orm/tutorials/state/resource-lifecycle

Terraform Resource Life Cycle. https://developer.hashicorp.com/terraf orm/tutorials/state/resource-lifecycle
[12]

https://developers.cloudflare.com/terraform/tutor ial/revert-configuration/

Terraform Rollback. https://developers.cloudflare.com/terraform/tutor ial/revert-configuration/
[13]

https://developer.hashicorp.com/terraform/lang uage/state/workspaces

Terraform workspaces. https://developer.hashicorp.com/terraform/lang uage/state/workspaces
[14]

https://spacelift.io/

The IaC Orchestration Platform Engineers Trust. https://spacelift.io/
[15]

https://snyk.io/blog/tools- infrastructure-drift-detection/

Tools for Infrastructure Drift Detection. https://snyk.io/blog/tools- infrastructure-drift-detection/
[16]

https://learn.microsoft.com/en-us/azure/storage /common/storage-use-azurite?tabs=visual-studio%2Cblob-storage

Use Azurite emulator for local Azure Storage development — learn.microsoft.com. https://learn.microsoft.com/en-us/azure/storage /common/storage-use-azurite?tabs=visual-studio%2Cblob-storage. [Accessed 02-07-2025]

2025
[17]

Artac, T

M. Artac, T. Borovssak, E. Di Nitto, M. Guerriero, and D. A. Tamburri. Devops: introducing infrastructure-as-code. In2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE- C), pages 497–498. IEEE, 2017

2017
[18]

Atlidakis, P

V . Atlidakis, P. Godefroid, and M. Polishchuk. Restler: Stateful rest api fuzzing. In2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), pages 748–758. IEEE, 2019

2019
[19]

Bhatnagar, Y

A. Bhatnagar, Y . Qiu, S. McClure, S. Ratnasamy, and A. Chen. A case for learned cloud emulators. InProceedings of the 24th ACM Workshop on Hot Topics in Networks, pages 69–76, 2025

2025
[20]

E. Bisong. An overview of google cloud platform services.Building Machine learning and deep learning models on google cloud platform: a comprehensive guide for beginners, pages 7–10, 2019

2019
[21]

H. Chen, X. Qiu, K. Ren, and X. Cui. An aiops approach to data cloud based on large language models. InProceedings of the 2024 4th International Conference on Artificial Intelligence, Big Data and Algorithms, pages 634–641, 2024

2024
[22]

Y . Chen, J. Pan, J. Clark, Y . Su, N. Zheutlin, B. Bhavya, R. Arora, Y . Deng, S. Jha, and T. Xu. Stratus: A Multi-agent System for Au- tonomous Reliability Engineering of Modern Clouds. InProceedings of the 39th Annual Conference on Neural Information Processing Systems (NeurIPS’25), Dec. 2025

2025
[23]

Y . Chen, M. Shetty, G. Somashekar, M. Ma, Y . Simmhan, J. Mace, C. Bansal, R. Wang, and S. Rajmohan. Aiopslab: A holistic framework to evaluate ai agents for enabling autonomous clouds, 2025

2025
[24]

Clark, Y

J. Clark, Y . Su, S. M. R. Pial, Y . Tian, L. Gniedziejko, H.-A. Jacobsen, Y . Chen, and T. Xu. SREGym: A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios.arXiv:2605.07161, 2026

Pith/arXiv arXiv 2026
[25]

Coleman, W

C. Coleman, W. G. Griswold, and N. Mitchell. Do cloud developers prefer clis or web consoles? clis mostly, though it varies by task.arXiv preprint arXiv:2209.07365, 2022

Pith/arXiv arXiv 2022
[26]

J. T. Gu, X. Sun, W. Zhang, Y . Jiang, C. Wang, M. Vaziri, O. Legunsen, and T. Xu. Acto: Automatic end-to-end testing for operation correct- ness of cloud system management. InProceedings of the 29th ACM Symposium on Operating Systems Principles, pages 96–112, 2023

2023
[27]

H. Guo, J. Yang, J. Liu, L. Yang, L. Chai, J. Bai, J. Peng, X. Hu, C. Chen, D. Zhang, et al. Owl: A large language model for it operations. In International Conference on Learning Representations, volume 2024, pages 23310–23333, 2024

2024
[28]

S. Jha, R. Arora, Y . Watanabe, T. Yanagawa, Y . Chen, J. Clark, B. Bhavya, et al. ITBench: Evaluating AI Agents across Diverse Real- World IT Automation Tasks. InProceedings of the 42th International Conference on Machine Learning (ICML’25), July 2025

2025
[29]

P. T. J. Kon, J. Liu, Y . Qiu, W. Fan, T. He, L. Lin, H. Zhang, O. M. Park, G. S. Elengikal, Y . Kang, A. Chen, M. Chowdhury, M. Lee, and X. Wang. Iac-eval: A code generation benchmark for cloud infrastructure-as-code programs. InThe Thirty-eight Conference on Neural Information Processing Systems Datasets and Benchmarks Track, 2024

2024
[30]

J. Liu, C. Zhang, J. Qian, M. Ma, S. Qin, C. Bansal, Q. Lin, S. Rajmo- han, and D. Zhang. Large language models can deliver accurate and interpretable time series anomaly detection. InProceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V . 2, pages 4623–4634, 2025

2025
[31]

Moto: Mock AWS Services — Moto 5.1.7.dev documentation — docs.getmoto.org

Moto Contributors. Moto: Mock AWS Services — Moto 5.1.7.dev documentation — docs.getmoto.org. https://docs.getmoto.org/en/latest /, 2025. [Accessed 02-07-2025]

2025
[32]

J. Peng, Y . Qiu, P. T. J. Kon, P. Zhao, Y . Huang, Z. Guo, X. Wang, and A. Chen. Automated lifting for cloud infrastructure-as-code programs. In2025 IEEE/ACM International Workshop on Cloud Intelligence & AIOps (AIOps), pages 4–9. IEEE, 2025

2025
[33]

Y . Qiu, P. T. J. Kon, R. Beckett, and A. Chen. Unearthing semantic checks for cloud infrastructure-as-code programs. InProceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles, pages 574–589, 2024

2024
[34]

Y . Qiu, P. T. J. Kon, J. Xing, Y . Huang, H. Liu, X. Wang, P. Huang, M. Chowdhury, and A. Chen. Simplifying cloud management with cloudless computing. InProceedings of the 22nd ACM Workshop on Hot Topics in Networks, pages 95–101, 2023

2023
[35]

Shah and D

J. Shah and D. Dubaria. Building modern clouds: using docker, kuber- netes & google cloud platform. In2019 IEEE 9th Annual Computing and Communication Workshop and Conference (CCWC), pages 0184–
[36]

Shetty, Y

M. Shetty, Y . Chen, G. Somashekar, M. Ma, Y . Simmhan, X. Zhang, J. Mace, D. Vandevoorde, P. Las-Casas, S. M. Gupta, S. Nath, C. Bansal, and S. Rajmohan. Building ai agents for autonomous clouds: Chal- lenges and design principles. InProceedings of 15th ACM Symposium on Cloud Computing, 2024

2024
[37]

X. Sun, W. Ma, J. T. Gu, Z. Ma, T. Chajed, J. Howell, A. Lattuada, O. Padon, L. Suresh, A. Szekeres, et al. Anvil: Verifying liveness of cluster management controllers. In18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24), pages 649– 666, 2024

2024
[38]

Y . Xu, Y . Chen, X. Zhang, X. Lin, P. Hu, Y . Ma, S. Lu, W. Du, Z. Mao, E. Zhai, and D. Cai. Cloudeval-yaml: A practical benchmark for cloud configuration generation, 2023. 7 Minghao Li 1, Ziqian Liu 1, Ziyu Mao 1, Daqian Ding 1, Y u Kang2, Qingwei Lin 2, Tianyin Xu 3, Yiming Qiu 1

2023
[39]

J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press. Swe-agent: Agent-computer interfaces enable automated software engineering, 2024

2024
[40]

Y . Yang, Y . Deng, Y . Xiong, B. Li, H. Xu, and P. Cheng. Tsguard: Automated user-centric incident diagnosis for ai workloads in the cloud. Proceedings of the ACM on Software Engineering, 3(FSE):253–276, 2026

2026
[41]

Z. Yang, A. Bhatnagar, Y . Qiu, T. Miao, P. T. J. Kon, Y . Xiao, Y . Huang, M. Casado, and A. Chen. Cloud infrastructure management in the age of ai agents.arXiv preprint arXiv:2506.12270, 2025

Pith/arXiv arXiv 2025
[42]

Z. Yang, H. Guan, V . Nicolet, B. Paulsen, J. Dodds, D. Kroening, and A. Chen. Automated cloud infrastructure-as-code reconciliation with ai agents.arXiv preprint arXiv:2510.20211, 2025

arXiv 2025
[43]

Zhang, T

L. Zhang, T. Jia, M. Jia, Y . Wu, A. Liu, Y . Yang, Z. Wu, X. Hu, P. Yu, and Y . Li. A survey of aiops in the era of large language models.ACM Computing Surveys, 2025. 8

2025

[1] [1]

https://www.aboutama zon.com/what-we-do/amazon-web-services

Amazon Web Services — aboutamazon.com. https://www.aboutama zon.com/what-we-do/amazon-web-services. [Accessed 29-06-2025]

2025

[2] [2]

https://www.hashicorp

Detecting and Managing Drift with Terraform. https://www.hashicorp. com/blog/detecting-and-managing-drift-with-terraform

[3] [3]

https://cloud.google.com/products/gemini

Gemini for Google Cloud. https://cloud.google.com/products/gemini

[4] [4]

https://www.localstack.clo ud/localstack-for-aws

LocalStack for AWS — localstack.cloud. https://www.localstack.clo ud/localstack-for-aws. [Accessed 29-06-2025]

2025

[5] [5]

https://azure.microsoft.com/en-us/product s/copilot

Microsoft copilot in Azure. https://azure.microsoft.com/en-us/product s/copilot

[6] [6]

https://www.pulumi.com/blo g/patterns-drift-detection/

Patterns for Drift Detection with Pulumi. https://www.pulumi.com/blo g/patterns-drift-detection/

[7] [7]

https://www.pulumi.com/docs/concepts /how-pulumi-works/

[Pulumi] How Pulumi works. https://www.pulumi.com/docs/concepts /how-pulumi-works/

[8] [8]

https: //www.pulumi.com/

Pulumi: Infrastructure as code in any programming language. https: //www.pulumi.com/

[9] [9]

https://www.pulumi.com/docs/concepts /resources/providers/

[Pulumi] Resource Providers. https://www.pulumi.com/docs/concepts /resources/providers/

[10] [10]

https://www.terraform.io/

Terraform by Hashicorp. https://www.terraform.io/

[11] [11]

https://developer.hashicorp.com/terraf orm/tutorials/state/resource-lifecycle

Terraform Resource Life Cycle. https://developer.hashicorp.com/terraf orm/tutorials/state/resource-lifecycle

[12] [12]

https://developers.cloudflare.com/terraform/tutor ial/revert-configuration/

Terraform Rollback. https://developers.cloudflare.com/terraform/tutor ial/revert-configuration/

[13] [13]

https://developer.hashicorp.com/terraform/lang uage/state/workspaces

Terraform workspaces. https://developer.hashicorp.com/terraform/lang uage/state/workspaces

[14] [14]

https://spacelift.io/

The IaC Orchestration Platform Engineers Trust. https://spacelift.io/

[15] [15]

https://snyk.io/blog/tools- infrastructure-drift-detection/

Tools for Infrastructure Drift Detection. https://snyk.io/blog/tools- infrastructure-drift-detection/

[16] [16]

https://learn.microsoft.com/en-us/azure/storage /common/storage-use-azurite?tabs=visual-studio%2Cblob-storage

Use Azurite emulator for local Azure Storage development — learn.microsoft.com. https://learn.microsoft.com/en-us/azure/storage /common/storage-use-azurite?tabs=visual-studio%2Cblob-storage. [Accessed 02-07-2025]

2025

[17] [17]

Artac, T

M. Artac, T. Borovssak, E. Di Nitto, M. Guerriero, and D. A. Tamburri. Devops: introducing infrastructure-as-code. In2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE- C), pages 497–498. IEEE, 2017

2017

[18] [18]

Atlidakis, P

V . Atlidakis, P. Godefroid, and M. Polishchuk. Restler: Stateful rest api fuzzing. In2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), pages 748–758. IEEE, 2019

2019

[19] [19]

Bhatnagar, Y

A. Bhatnagar, Y . Qiu, S. McClure, S. Ratnasamy, and A. Chen. A case for learned cloud emulators. InProceedings of the 24th ACM Workshop on Hot Topics in Networks, pages 69–76, 2025

2025

[20] [20]

E. Bisong. An overview of google cloud platform services.Building Machine learning and deep learning models on google cloud platform: a comprehensive guide for beginners, pages 7–10, 2019

2019

[21] [21]

H. Chen, X. Qiu, K. Ren, and X. Cui. An aiops approach to data cloud based on large language models. InProceedings of the 2024 4th International Conference on Artificial Intelligence, Big Data and Algorithms, pages 634–641, 2024

2024

[22] [22]

Y . Chen, J. Pan, J. Clark, Y . Su, N. Zheutlin, B. Bhavya, R. Arora, Y . Deng, S. Jha, and T. Xu. Stratus: A Multi-agent System for Au- tonomous Reliability Engineering of Modern Clouds. InProceedings of the 39th Annual Conference on Neural Information Processing Systems (NeurIPS’25), Dec. 2025

2025

[23] [23]

Y . Chen, M. Shetty, G. Somashekar, M. Ma, Y . Simmhan, J. Mace, C. Bansal, R. Wang, and S. Rajmohan. Aiopslab: A holistic framework to evaluate ai agents for enabling autonomous clouds, 2025

2025

[24] [24]

Clark, Y

J. Clark, Y . Su, S. M. R. Pial, Y . Tian, L. Gniedziejko, H.-A. Jacobsen, Y . Chen, and T. Xu. SREGym: A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios.arXiv:2605.07161, 2026

Pith/arXiv arXiv 2026

[25] [25]

Coleman, W

C. Coleman, W. G. Griswold, and N. Mitchell. Do cloud developers prefer clis or web consoles? clis mostly, though it varies by task.arXiv preprint arXiv:2209.07365, 2022

Pith/arXiv arXiv 2022

[26] [26]

J. T. Gu, X. Sun, W. Zhang, Y . Jiang, C. Wang, M. Vaziri, O. Legunsen, and T. Xu. Acto: Automatic end-to-end testing for operation correct- ness of cloud system management. InProceedings of the 29th ACM Symposium on Operating Systems Principles, pages 96–112, 2023

2023

[27] [27]

H. Guo, J. Yang, J. Liu, L. Yang, L. Chai, J. Bai, J. Peng, X. Hu, C. Chen, D. Zhang, et al. Owl: A large language model for it operations. In International Conference on Learning Representations, volume 2024, pages 23310–23333, 2024

2024

[28] [28]

S. Jha, R. Arora, Y . Watanabe, T. Yanagawa, Y . Chen, J. Clark, B. Bhavya, et al. ITBench: Evaluating AI Agents across Diverse Real- World IT Automation Tasks. InProceedings of the 42th International Conference on Machine Learning (ICML’25), July 2025

2025

[29] [29]

P. T. J. Kon, J. Liu, Y . Qiu, W. Fan, T. He, L. Lin, H. Zhang, O. M. Park, G. S. Elengikal, Y . Kang, A. Chen, M. Chowdhury, M. Lee, and X. Wang. Iac-eval: A code generation benchmark for cloud infrastructure-as-code programs. InThe Thirty-eight Conference on Neural Information Processing Systems Datasets and Benchmarks Track, 2024

2024

[30] [30]

J. Liu, C. Zhang, J. Qian, M. Ma, S. Qin, C. Bansal, Q. Lin, S. Rajmo- han, and D. Zhang. Large language models can deliver accurate and interpretable time series anomaly detection. InProceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V . 2, pages 4623–4634, 2025

2025

[31] [31]

Moto: Mock AWS Services — Moto 5.1.7.dev documentation — docs.getmoto.org

Moto Contributors. Moto: Mock AWS Services — Moto 5.1.7.dev documentation — docs.getmoto.org. https://docs.getmoto.org/en/latest /, 2025. [Accessed 02-07-2025]

2025

[32] [32]

J. Peng, Y . Qiu, P. T. J. Kon, P. Zhao, Y . Huang, Z. Guo, X. Wang, and A. Chen. Automated lifting for cloud infrastructure-as-code programs. In2025 IEEE/ACM International Workshop on Cloud Intelligence & AIOps (AIOps), pages 4–9. IEEE, 2025

2025

[33] [33]

Y . Qiu, P. T. J. Kon, R. Beckett, and A. Chen. Unearthing semantic checks for cloud infrastructure-as-code programs. InProceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles, pages 574–589, 2024

2024

[34] [34]

Y . Qiu, P. T. J. Kon, J. Xing, Y . Huang, H. Liu, X. Wang, P. Huang, M. Chowdhury, and A. Chen. Simplifying cloud management with cloudless computing. InProceedings of the 22nd ACM Workshop on Hot Topics in Networks, pages 95–101, 2023

2023

[35] [35]

Shah and D

J. Shah and D. Dubaria. Building modern clouds: using docker, kuber- netes & google cloud platform. In2019 IEEE 9th Annual Computing and Communication Workshop and Conference (CCWC), pages 0184–

[36] [36]

Shetty, Y

M. Shetty, Y . Chen, G. Somashekar, M. Ma, Y . Simmhan, X. Zhang, J. Mace, D. Vandevoorde, P. Las-Casas, S. M. Gupta, S. Nath, C. Bansal, and S. Rajmohan. Building ai agents for autonomous clouds: Chal- lenges and design principles. InProceedings of 15th ACM Symposium on Cloud Computing, 2024

2024

[37] [37]

X. Sun, W. Ma, J. T. Gu, Z. Ma, T. Chajed, J. Howell, A. Lattuada, O. Padon, L. Suresh, A. Szekeres, et al. Anvil: Verifying liveness of cluster management controllers. In18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24), pages 649– 666, 2024

2024

[38] [38]

Y . Xu, Y . Chen, X. Zhang, X. Lin, P. Hu, Y . Ma, S. Lu, W. Du, Z. Mao, E. Zhai, and D. Cai. Cloudeval-yaml: A practical benchmark for cloud configuration generation, 2023. 7 Minghao Li 1, Ziqian Liu 1, Ziyu Mao 1, Daqian Ding 1, Y u Kang2, Qingwei Lin 2, Tianyin Xu 3, Yiming Qiu 1

2023

[39] [39]

J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press. Swe-agent: Agent-computer interfaces enable automated software engineering, 2024

2024

[40] [40]

Y . Yang, Y . Deng, Y . Xiong, B. Li, H. Xu, and P. Cheng. Tsguard: Automated user-centric incident diagnosis for ai workloads in the cloud. Proceedings of the ACM on Software Engineering, 3(FSE):253–276, 2026

2026

[41] [41]

Z. Yang, A. Bhatnagar, Y . Qiu, T. Miao, P. T. J. Kon, Y . Xiao, Y . Huang, M. Casado, and A. Chen. Cloud infrastructure management in the age of ai agents.arXiv preprint arXiv:2506.12270, 2025

Pith/arXiv arXiv 2025

[42] [42]

Z. Yang, H. Guan, V . Nicolet, B. Paulsen, J. Dodds, D. Kroening, and A. Chen. Automated cloud infrastructure-as-code reconciliation with ai agents.arXiv preprint arXiv:2510.20211, 2025

arXiv 2025

[43] [43]

Zhang, T

L. Zhang, T. Jia, M. Jia, Y . Wu, A. Liu, Y . Yang, Z. Wu, X. Hu, P. Yu, and Y . Li. A survey of aiops in the era of large language models.ACM Computing Surveys, 2025. 8

2025