The Next Cloud Workload Won’t Be Humans — It’ll Be AI Agents
AI agents are moving from answering questions to planning, coding, deploying, monitoring, and making decisions. What happens to cloud architecture when the primary workload is no longer a human application, but an autonomous software worker?
The Next Cloud Workload Won’t Be Humans — It’ll Be AI Agents 🤖☁️
For the last two decades, we designed cloud infrastructure around one assumption:
Humans write software, and software serves humans.
But AI agents are changing that assumption.
Imagine a software system that can:
- read a ticket
- inspect a codebase
- create a solution
- run tests
- deploy infrastructure
- monitor the deployment
- detect a failure
- roll back the change
- and continue working toward its goal
No human needs to execute every step.
The human becomes the goal setter and policy owner.
The agent becomes the operator.
And that creates a completely different cloud architecture problem.
From Applications to AI Workers
Traditional cloud architecture looks something like:
1
2
3
4
5
6
7
8
9
Human
↓
Application
↓
API
↓
Database
↓
InfrastructureAn agentic architecture starts looking more like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Human
↓
Goal
↓
AI Agent
↓
Planning
↓
Tools
├── APIs
├── Databases
├── Code repositories
├── Cloud infrastructure
└── Other agents
↓
Results
↓
Agent decides
↓
Next actionThe important difference is the feedback loop.
A traditional application usually waits for another request.
An agent can observe the result of an action and decide what to do next.
That means the cloud isn't simply hosting an application anymore.
It is hosting a decision-making loop.
The Interesting Part: Agents Need Infrastructure Too
An AI agent might need access to:
Compute
To execute code, tools, containers, or workloads.
Storage
To maintain artifacts, files, intermediate results, and long-running state.
Identity
To determine exactly what the agent is allowed to access.
Networking
To communicate with APIs, databases, services, and external systems.
Observability
To understand what the agent did and why something failed.
Security controls
To prevent an agent from turning a small mistake into a large incident.
This makes AI agents surprisingly similar to another class of cloud workload:
production services.
But with one major difference.
A normal service follows predefined logic.
An agent can choose its next action dynamically.
The Permission Problem 🔐
This may become one of the most important problems in agentic cloud computing.
Suppose an agent has permission to:
1
2
3
4
5
Read S3
Write S3
Deploy Lambda
Read DynamoDB
Modify security groupsThe question isn't simply:
"Can the agent perform this action?"
The more interesting question is:
"Should the agent perform this action right now?"
Those are different problems.
IAM can control what an identity is allowed to do.
But agentic systems introduce another layer:
1
2
3
4
5
6
7
8
9
Identity
↓
Permission
↓
Intent
↓
Context
↓
ActionAn agent might technically have permission to delete a resource.
That doesn't mean deleting it is appropriate for the current task.
This is where human approval gates, policies, sandboxing, scoped credentials, and audit trails become extremely important.
What If Agents Become the Cloud Operators?
Consider this scenario.
It's 2:00 AM.
Your production API starts returning errors.
A monitoring system detects the problem.
Instead of simply sending an alert:
1
2
3
4
5
CloudWatch
↓
Alert
↓
Human wakes upan agent could potentially do:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
CloudWatch
↓
AI Agent
↓
Investigate logs
↓
Check recent deployment
↓
Identify likely cause
↓
Generate remediation plan
↓
Run approved diagnostic actions
↓
Request human approval
↓
Rollback
↓
Verify recoveryThe human doesn't disappear.
The human moves up the control hierarchy.
Instead of manually executing commands, the human decides:
"Under what conditions is the agent allowed to act?"
That is a much more interesting engineering problem.
The Future Cloud Architecture Might Have Three Layers
I think agentic systems will increasingly need three distinct layers.
1. Execution Layer ⚙️
Where the work happens.
Examples:
- Amazon ECS
- AWS Lambda
- Amazon EKS
- EC2
- databases
- storage
2. Intelligence Layer 🧠
Where the agent reasons about the task.
This could involve:
- foundation models
- agent frameworks
- tool calling
- retrieval
- planning
- memory
- multi-agent coordination
3. Governance Layer 🛡️
This is the layer I think deserves much more attention.
It answers questions like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
What can the agent access?
What can it change?
What requires approval?
Which actions are reversible?
How much can it spend?
Which tools can it call?
Who authorized the action?
What evidence supports the decision?
Can we reconstruct everything it did?The architecture becomes:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
HUMAN
│
Goals / Policy
│
▼
┌─────────────────┐
│ GOVERNANCE │
│ │
│ Identity │
│ Permissions │
│ Approvals │
│ Budgets │
│ Audit │
└────────┬────────┘
│
▼
┌─────────────────┐
│ AI AGENT │
│ │
│ Plan │
│ Reason │
│ Use Tools │
│ Observe │
└────────┬────────┘
│
▼
┌─────────────────┐
│ CLOUD │
│ │
│ Compute │
│ Storage │
│ Databases │
│ APIs │
└─────────────────┘And Then Comes the Really Difficult Question
What happens when we have multiple agents?
Imagine:
1
2
3
4
5
6
7
8
9
10
11
CEO Agent
│
├── Engineering Agent
│ ├── Coding Agent
│ └── Testing Agent
│
├── Security Agent
│
├── Finance Agent
│
└── Operations AgentNow agents aren't simply calling APIs.
They're communicating with other autonomous systems.
One agent might create a task for another.
Another might reject it.
A third might approve the action.
Suddenly we're dealing with something that looks less like a traditional application and more like an organization implemented in software.
That raises fascinating questions about:
- trust
- delegation
- identity
- accountability
- budgets
- agent-to-agent authentication
- conflicting objectives
- auditability
The Cloud Bill Could Become Interesting Too 💰
Imagine an agent with the goal:
"Optimize our application performance."
Without proper constraints, it might discover that increasing compute capacity improves latency.
Technically successful.
But expensive.
So the real instruction needs to look more like:
"Improve p95 latency while keeping monthly infrastructure cost below $X."
Now the agent is optimizing multiple constraints.
This changes cloud optimization from:
1
2
3
Human checks Cost Explorer
↓
Human makes decisiontoward:
1
2
3
4
5
6
7
8
9
Agent observes metrics
↓
Agent evaluates cost
↓
Agent proposes optimization
↓
Policy evaluates action
↓
Human approves high-impact changeCloud economics becomes part of the agent's operating environment.
We Should Stop Measuring Agents Only by Accuracy
For traditional AI systems, we often ask:
"How accurate is the model?"
For production agents, that isn't enough.
We may eventually need to measure:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Task success
+
Tool reliability
+
Cost
+
Latency
+
Permission violations
+
Recovery capability
+
Human intervention rate
+
AuditabilityAn agent that completes 95% of tasks but occasionally makes an irreversible production change without sufficient evidence may be unacceptable.
Another agent might complete only 90% automatically but safely escalate uncertain cases.
The second system could be more useful in production.
That means agent reliability isn't just a model problem.
It's an architecture problem.
The Future Might Be "Human-on-the-Loop"
We've spent years discussing:
Human-in-the-loop
A human approves individual decisions.
But with capable agents, we may increasingly move toward:
Human-on-the-loop
The agent performs routine operations.
Humans define:
- policies
- boundaries
- budgets
- escalation conditions
- approval requirements
The agent operates inside those boundaries.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Human
│
│ defines boundaries
▼
Policy / Governance
│
▼
AI Agent
│
├── Action
├── Observe
├── Decide
└── Repeat
│
└── Escalate when necessaryThe goal isn't to remove humans.
It's to make human attention available for the decisions that actually require it.
What AWS Engineers Should Start Thinking About
If you're building AI agents today, don't think only about:
"Which model should I use?"
Also ask:
Identity
What identity does the agent run as?
Permissions
What is the minimum access it needs?
Isolation
Can the agent operate inside a sandbox?
Observability
Can I reconstruct every important action?
Cost
What prevents an agent from consuming unlimited resources?
Approval
Which operations require human authorization?
Recovery
Can the system safely undo an incorrect action?
Governance
What happens when the agent encounters a situation outside its intended scope?
These questions may become as important as model selection itself.
The Bigger Shift 🚀
The cloud originally gave developers infrastructure on demand.
Then infrastructure became programmable.
Then applications became increasingly automated.
Now we're moving toward systems where the software itself can decide what infrastructure and tools it needs to accomplish a goal.
That is a very different paradigm.
The future cloud may not simply be:
Infrastructure as Code
It may increasingly become:
Goals → Agents → Policies → Actions → Evidence
And the engineers building these systems won't just be writing applications.
They'll be designing the boundaries within which autonomous software is allowed to operate.
One Question for the Community 👇
If an AI agent can:
write code → deploy it → monitor it → detect failure → roll it back → optimize infrastructure
where should we draw the line?
Should an AI agent ever be allowed to make production changes without human approval?
Or should the answer depend entirely on the risk level of the action?
I'm especially interested in how AWS engineers, DevOps engineers, and AI builders are approaching this today.
Where would you put the human approval gate?
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article