From Intent File to Running Cloud: A Developer’s Guide to Intent-Based Cloud Systems
- Mark Kendall
- 1 day ago
- 10 min read
From Intent File to Running Cloud: A Developer’s Guide to Intent-Based Cloud Systems
What if the intent—not the infrastructure—became the starting point?
For decades, building a cloud application has meant translating a business idea through layer after layer of increasingly technical artifacts:
Requirement → architecture → application code → infrastructure → security → deployment → operations.
Each translation creates work. Each creates opportunities for misunderstanding. And each usually requires another specialist, tool, configuration language, or handoff.
A fascinating 2025 ACM paper, “Intent-based System Design and Operation,” by Vaastav Anand, Yichen Li, Alok Gautam Kumbhare, Celine Irvene, Chetan Bansal, Gagan Somashekar, Jonathan Mace, Pedro Las-Casas, Ricardo Bianchini, and Rodrigo Fonseca, proposes something considerably different.
The authors propose intent as a high-level abstraction for cloud-system design and operation. Instead of manually translating requirements through every stage of the software lifecycle, functional and operational intent can drive automated design, implementation, operation, and eventually evolution of the system. (Jonathan Mace)
That idea is remarkably practical for today’s developer.
With modern agentic coding systems, Infrastructure as Code, cloud APIs, containers, Kubernetes, observability platforms, CI/CD, and policy automation, we can begin building a surprisingly complete implementation of this model right now.
The result looks less like:
AI-assisted coding
and much more like:
Intent → Running Cloud System.
The Paper’s Big Idea
The authors divide intent into two broad categories.
Functional intent describes what the system should do, including functional, security, and design requirements.
Operational intent describes how the system should behave when it is running—including SLAs, metrics, monitoring, performance expectations, deviation detection, and mitigation strategies. (Jonathan Mace)
They add another particularly important concept:
Refinement intent.
A refinement intent represents the delta between the existing intent and the new desired intent. Instead of constantly regenerating a system from scratch, the system can evolve as requirements change. (Jonathan Mace)
That gives us a very useful mental model:
INITIAL INTENT
│
▼
Generated System
│
▼
Running System
│
├──── Observability
│
├──── Runtime Context
│
└──── Desired State
│
▼
Intent Violation?
│
┌─────┴─────┐
│ │
NO YES
│ │
│ ▼
│ Refinement Intent
│ │
│ ▼
└──── Improved System
That last loop changes everything.
We’re no longer simply generating software.
We’re building toward software that can continually be evaluated against the reason it exists.
The Hotel Application Example
The paper gives a wonderfully understandable example: a hotel reservation application.
Its functional intent asks for a microservice application capable of finding hotels near a location, finding nearby activities, reserving and paying for rooms, handling reviews, and managing user information. (Jonathan Mace)
The authors then separately demonstrate operational intent with a requirement such as maintaining a 100ms 99th-percentile latency under high load. (Jonathan Mace)
That’s important.
The intent isn’t simply:
Build me a hotel website.
It contains both:
WHAT THE SYSTEM DOES
+
HOW THE SYSTEM MUST OPERATE
Now imagine expressing that as a developer-friendly Intent file.
hotel-platform/INTENT.md
# Intent
Create a cloud-native hotel reservation platform.
Users must be able to:
- search hotels by location
- view hotel details
- discover nearby activities
- reserve rooms
- process payments
- read and write reviews
- manage account information
# Inputs
- hotel inventory
- user profile
- location
- dates
- room requirements
- payment information
- reviews
# Outputs
- hotel search results
- availability
- reservations
- payment confirmations
- reviews
- account updates
# Operational Requirements
- deploy using approved cloud services
- encrypt data in transit and at rest
- use managed identity and secrets
- expose health and readiness endpoints
- produce logs, metrics, and traces
- scale horizontally
- maintain defined latency objectives
- support rollback
# Success Criteria
- users can complete an end-to-end reservation
- payment is processed exactly once
- failed reservations do not create orphaned charges
- services meet defined availability objectives
- observability exists for every critical transaction
- infrastructure can be recreated automatically
Notice what isn’t specified.
We haven’t necessarily told the agent:
which load balancer to create,
which IAM statements to write,
how many Terraform files are required,
how certificates should be provisioned,
how the deployment pipeline should be structured.
Those decisions can increasingly come from the platform’s established patterns and constraints.
That is where intent becomes powerful.
Intent Becomes the Interface to the Cloud Platform
A modern implementation might look like this:
INTENT
│
▼
┌─────────────────┐
│ Intent Compiler │
│ / Agentic Layer │
└────────┬────────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
Architecture Code Tests
│ │ │
└───────────┼───────────┘
▼
Infrastructure
as Code
│
▼
Platform Policies
│
┌─────────────┼─────────────┐
▼ ▼ ▼
IAM Secrets Certificates
│ │ │
├─────────────┼─────────────┤
│ │ │
Network Compute Storage
│ │ │
└─────────────┼─────────────┘
▼
CLOUD
│
▼
Running Application
│
▼
Logs + Metrics + Traces + SLOs
│
▼
Intent Validation
│
└────► Refinement
The paper specifically points to the convergence of technologies such as Kubernetes, OpenTelemetry, verification tooling, LLMs, compound AI systems, and autonomous agents as reasons this level of automation is becoming feasible. (Jonathan Mace)
That’s an important distinction.
The LLM isn’t the cloud operating system.
The LLM reasons.
The platform executes.
Deterministic tools still perform the dangerous work.
Don’t Give the Model Unlimited AWS Permissions
Intent-driven does not mean:
LLM
│
▼
AdministratorAccess
│
▼
Good luck.
A better enterprise design is:
INTENT
│
▼
AI / AGENT
│
proposes plan
│
▼
POLICY LAYER
│
┌───────────┼───────────┐
▼ ▼ ▼
Allowed? Valid? Approved?
│ │ │
└───────────┼───────────┘
▼
EXECUTION TOOLS
│
┌─────────┼─────────┐
▼ ▼ ▼
CI/CD IaC Cloud APIs
│ │ │
└─────────┼─────────┘
▼
AWS
Permissions should come from the platform.
Certificates should follow platform rules.
Secrets should use approved secret stores.
Networks should use approved topology.
Infrastructure should use approved modules.
Production operations should have deterministic controls and, where risk demands it, human approval.
The paper itself emphasizes that reliability, correctness, action selection, explainability, accurate context, model drift, debugging, and observability remain major challenges. It explicitly argues for robust verification and human oversight rather than blind autonomy. (Jonathan Mace)
So the goal isn’t removing governance.
The goal is encoding governance so developers don’t manually reinvent it.
Now Build Ten of Them
This is where the architecture gets really interesting.
Imagine an enterprise with ten independently deployable systems:
01 customer-platform
02 hotel-search
03 reservation-service
04 payment-service
05 review-service
06 notification-service
07 identity-service
08 activity-service
09 analytics-service
10 operations-service
Each repository owns a bounded capability.
Each has an intent.
Each inherits platform constraints.
Each can be independently generated, tested, deployed, observed, changed, and validated.
ENTERPRISE INTENT
│
▼
PLATFORM CONSTRAINTS
│
┌──────────┬─────────┼─────────┬──────────┐
▼ ▼ ▼ ▼ ▼
Repo 1 Repo 2 Repo 3 Repo 4 Repo 5
│ │ │ │ │
Intent Intent Intent Intent Intent
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
Cloud Cloud Cloud Cloud Cloud
...same model for Repositories 6–10...
This is much easier to reason about than one giant prompt attempting to comprehend an entire enterprise.
Federated Intent
The reusable model can be hierarchical.
ENTERPRISE INTENT
│
▼
PLATFORM INTENT
│
▼
DOMAIN INTENT
│
▼
SYSTEM INTENT
│
▼
REPOSITORY INTENT
│
▼
FEATURE INTENT
Every level answers a different question.
Enterprise
What rules apply everywhere?
Security, compliance, identity, auditability, approved clouds, data policies.
Platform
How do applications run here?
Networking, CI/CD, secrets, certificates, observability, deployment, infrastructure modules.
Domain
What rules belong to this business capability?
For a reservation domain: inventory ownership, reservation semantics, payment relationships, event contracts.
Repository
What does this independently deployable component own?
Feature
What is changing right now?
That last distinction is especially valuable.
You shouldn’t have to describe the entire hotel platform every time somebody asks for:
Add the ability to filter hotels by EV charging availability.
That’s a refinement intent.
Existing System Intent
+
Requested Delta
│
▼
Impact Analysis
│
▼
Smallest Safe Change
│
▼
Implementation
│
▼
Validation
That maps beautifully to the paper’s concept of refinement intent. (Jonathan Mace)
Reuse the Platform, Not the Generated Application
There is another architectural principle hiding here.
Don’t create twenty repositories containing twenty independently invented implementations of:
authentication,
logging,
tracing,
retries,
certificates,
secrets,
networking,
deployment,
health checks,
CI/CD,
error handling.
Instead, make those capabilities available through the platform.
SHARED PLATFORM
│
┌───────────────┼───────────────┐
│ │ │
Security Runtime Operations
│ │ │
IAM Compute Logging
Secrets Containers Metrics
Certs Networking Tracing
Policy Storage Alerts
│ │ │
└───────────────┼───────────────┘
│
Approved Patterns
│
┌────────────┼────────────┐
▼ ▼ ▼
System A System B System C
Now an intent-driven system isn’t being asked to invent enterprise architecture.
It is being asked to compose approved enterprise capabilities to satisfy a new intent.
That is dramatically safer and more reusable.
The Repository Becomes a Deployable Unit of Intent
This changes the role of the repository.
A repository might contain:
hotel-search/
│
├── INTENT.md
├── CLAUDE.md
├── src/
├── tests/
├── infrastructure/
├── observability/
├── policies/
└── .github/
But conceptually it represents:
Intent
+
Implementation
+
Infrastructure
+
Controls
+
Deployment
+
Observability
+
Evidence
The repository is therefore not merely source code.
It becomes a deployable representation of intent.
That is a subtle but extremely important architectural shift.
The Paper’s Four-Part Loop
Anand and the other authors organize their self-managing cloud vision around four major capabilities:
Automated Design
Real-Time Context Awareness
Autonomous Operation
Continuous Improvement (Jonathan Mace)
Translated into something a development team could implement incrementally:
│ 1. DESIGN FROM │
│ INTENT │
└──────────┬──────────┘
▼
┌─────────────────────┐
│ 2. OBSERVE CURRENT │
│ CONTEXT │
└──────────┬──────────┘
▼
┌─────────────────────┐
│ 3. OPERATE TOWARD │
│ DESIRED STATE │
└──────────┬──────────┘
▼
┌─────────────────────┐
│ 4. DETECT DEVIATION │
│ AND IMPROVE │
└──────────┬──────────┘
│
└──────────────► INTENT
The context-awareness component is particularly interesting.
The authors describe context as combining runtime information—metrics, logs, traces and monitors—with domain knowledge such as source code, documentation, and troubleshooting guidance. Intent helps determine which information is actually relevant. (Jonathan Mace)
That’s essentially the runtime equivalent of repo-aware development.
At development time:
Give the agent the right repository context.
At runtime:
Give the operating system the right operational context.
Closing the Loop
Suppose our hotel system’s operational intent says:
P99 search latency < 100 ms
Telemetry eventually shows:
P99 search latency = 187 ms
The important thing isn’t merely generating an alert.
The system can reason about the difference between:
DESIRED STATE
│
│ < 100 ms
│
▼
ACTUAL STATE
187 ms
That difference represents an intent violation.
Now the system can investigate:
Intent Violation
│
▼
Retrieve Relevant Context
│
├── traces
├── metrics
├── logs
├── recent deployment
├── code
└── infrastructure
│
▼
Determine Cause
│
▼
Generate Refinement Intent
│
▼
Configuration Change?
Code Change?
Infrastructure Change?
Architecture Change?
│
▼
Validate
│
▼
Deploy
│
▼
Observe Again
The paper explicitly envisions continuous improvement through detecting intent violations and responding through reconfiguration, code fixes, or redesign. (Jonathan Mace)
That is the closed loop.
A Practical Developer Adoption Path
Nobody needs to start with autonomous production remediation.
Start much smaller.
Level 1 — Intent-to-Code
Intent → Plan → Code → Tests
Level 2 — Intent-to-Cloud
Intent
↓
Code
↓
Infrastructure
↓
Security Configuration
↓
Pipeline
↓
Cloud Deployment
Level 3 — Intent-to-Observable-Cloud
Intent
↓
Running Cloud Application
↓
Logs + Metrics + Traces
↓
Success Criteria
Level 4 — Intent-to-Managed-Cloud
Intent
↓
Desired State
↕
Actual State
↓
Recommended Remediation
↓
Human Approval
↓
Execution
Level 5 — Intent-Based Cloud System
Intent
↓
Design
↓
Build
↓
Deploy
↓
Observe
↓
Reason
↓
Improve
└──────────► Intent
The autonomy can increase as confidence, deterministic controls, validation, and governance improve.
Intent Is Starting to Look Like a Compiler Input
Perhaps the easiest way for a developer to understand this architecture is to think about a compiler.
Traditionally:
Source Code
↓
Compiler
↓
Machine Code
An intent-driven engineering environment begins to resemble:
Business / Engineering Intent
↓
Agentic Compiler
↓
┌──────────┼──────────┐
▼ ▼ ▼
Code Infrastructure Tests
│ │ │
├──────────┼──────────┤
▼ ▼ ▼
Security Deployment Observability
│ │ │
└──────────┼──────────┘
▼
Running System
↓
Evidence
↓
Intent Satisfied?
The word compiler shouldn’t be interpreted literally. LLM behavior is probabilistic, which is precisely why verification, policies, deterministic tools, tests, approvals, and runtime evidence remain essential.
But as a mental model, it’s powerful:
Intent becomes the source language.
Cloud capabilities become the target environment.
And the engineering platform becomes the machinery that translates between them.
From Infrastructure as Code to Intent to Infrastructure
Infrastructure as Code was a massive improvement because infrastructure became reproducible.
Intent-driven engineering adds another abstraction above it.
Yesterday
Human
↓
Terraform
↓
Infrastructure
Today
Intent
↓
Agent + Platform Rules
↓
Terraform / CDK / CloudFormation / Kubernetes
↓
Infrastructure
Tomorrow
Intent
↓
Desired State
↕
Cloud System
↓
Runtime Evidence
↓
Continuous Refinement
Infrastructure as Code doesn’t disappear.
It becomes a generated and governed implementation artifact.
The same is true for application code.
And configuration.
And deployment manifests.
And observability.
The developer increasingly works at the level of what must be true, while the platform increasingly handles how the enterprise makes it true.
Twenty Systems Changes the Organization
One intent-driven repository is useful.
Twenty well-designed intent-driven systems represent something different.
You now have a portfolio of independently understandable, independently deployable, independently observable business capabilities.
BUSINESS
│
▼
Enterprise Intent
│
▼
Cloud Platform
│
┌────────┬────────┼────────┬────────┐
▼ ▼ ▼ ▼ ▼
Customer Orders Hotel Payment Reviews
│ │ │ │ │
Intent Intent Intent Intent Intent
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
Cloud Cloud Cloud Cloud Cloud
│ │ │ │ │
└────────┴────────┼────────┴────────┘
▼
Runtime Evidence
│
▼
Business Outcome
This is where intent-driven engineering starts moving beyond developer productivity.
It becomes an operating model.
The Bigger Idea
The ACM paper deserves credit for articulating a much broader destination than simply AI-generated applications.
Its vision connects intent, automated design, real-time context awareness, autonomous operation, and continuous improvement into a self-managing cloud-system model. (Jonathan Mace)
For developers, however, we don’t have to wait for the complete research vision to become reality.
We can begin with something much more pragmatic:
Define the intent clearly.
Keep repositories bounded.
Reuse platform capabilities.
Generate the implementation and infrastructure.
Apply deterministic governance.
Deploy through controlled automation.
Observe the resulting system.
Validate reality against the original intent.
Express future changes as refinement intents rather than starting over.
And then repeat that pattern across five repositories.
Ten repositories.
Twenty repositories.
Eventually the enterprise begins looking less like thousands of unrelated source files and infrastructure configurations and more like a network of intent-addressable capabilities running in the cloud.
That may be the most important transition.
The developer doesn’t disappear.
Infrastructure doesn’t disappear.
Architecture doesn’t disappear.
Operations doesn’t disappear.
Instead, their accumulated knowledge becomes encoded into the platform so that every new application can inherit it.
The interface to that platform becomes simpler:
Tell the system what outcome you need, define the boundaries under which it may achieve it, define how success will be measured, and let the engineering platform manifest that intent all the way into the cloud.
That’s a very different definition of cloud development.
And we’re much closer to it than many developers realize.
Credit and Further Reading
This article builds on and extends the ideas presented by Vaastav Anand, Yichen Li, Alok Gautam Kumbhare, Celine Irvene, Chetan Bansal, Gagan Somashekar, Jonathan Mace, Pedro Las-Casas, Ricardo Bianchini, and Rodrigo Fonseca in Intent-based System Design and Operation, PACMI ’25. The authors deserve full credit for their intent-based self-managing cloud-system model and the hotel application example discussed above. (Jonathan Mace)
The paper is worth reading directly. It provides the research framing behind automated design, context awareness, autonomous operation, continuous improvement, refinement intent, and the substantial reliability challenges that still need to be solved before fully autonomous cloud systems become commonplace.
Comments