docs/guides/cloud-agents/cloud-agents-taxonomy.mdx
“Cloud agents” is a term that gets used to describe everything from cron jobs to IDE copilots.
That ambiguity causes teams to:
This guide exists to:
Define what cloud agents actually are, how they differ from other agents, and when they make sense for software teams.
Key characteristics:
Cloud agents exist to handle work that benefits from reasoning, shared context, and reviewability.
Cloud agents are often confused with other tools.
<CardGroup cols={2}> <Card title="Not IDE Agents"> IDE agents focus on individual productivity and local context. Cloud agents operate on shared systems and team-owned work. </Card> <Card title="Not Just Cron Jobs"> Cron is a trigger. Cloud agents reason over changing inputs and produce reviewable outcomes. </Card> <Card title="Not One-Off Scripts"> Scripts execute fixed logic. Cloud agents apply reasoning and shared context even for a single run. </Card> <Card title="Not Magic Automation"> Cloud agents still require review, ownership, and guardrails. </Card> </CardGroup>Cloud agents are best understood along two dimensions:
Everything else is implementation detail.
quadrantChart
title Cloud Agents Taxonomy
x-axis One-Off --> Event-Driven
y-axis Manual --> Automated
quadrant-1 Automated & Event-Driven
quadrant-2 Manual & Event-Driven
quadrant-3 Manual & One-Off
quadrant-4 Automated & Scheduled
"Weekly dependency updates" : [0.65, 0.85]
"Security scan with PR review" : [0.75, 0.60]
"One-off repo audit" : [0.25, 0.25]
"Nightly analytics summary" : [0.45, 0.75]
"Incident response triage" : [0.85, 0.40]
Most teams start bottom-left and move diagonally as trust increases to create their Continuous AI Workflow.
Manually triggered when a human explicitly dispatches work to an agent. One-off cloud agents are first-class agents that differ by trigger, not by capability.
<Columns cols={2}> <Card title="Examples"> - Analyze the top recurring Sentry errors - Audit a repo for security issues - Summarize system behavior </Card> <Card title="Best for"> - Unknown scope - Exploratory work - Building confidence before automation </Card> </Columns>Time-based triggers that run on a fixed cadence (daily, weekly, hourly).
<Columns cols={2}> <Card title="Examples"> - Weekly vulnerability scans - Nightly analytics summaries - Regular dependency updates </Card> <Card title="Best for"> - Predictable recurring work - Backlog prevention - Drift detection </Card> </Columns>Signal-based triggers that react to real-time events from external systems.
<Columns cols={2}> <Card title="Examples"> - New high-severity alert - Failed deployment - Critical security finding </Card> <Card title="Best for"> - Operational workflows - Incident response - Time-sensitive fixes </Card> </Columns>This is where most teams get into trouble.
<Tabs> <Tab title="Manual"> - Human decides when the agent runs - Human reviews everything*Safest starting point.*
*Where most teams should live first.*
*Earned over time — not assumed.*
| Local / IDE Agents | Cloud Agents |
|---|---|
| Individual context | Team context |
| Short-lived | Long-running |
| Developer-initiated | System-initiated |
| Productivity focus | Reliability & ownership focus |
Both are useful. They solve different problems.
Most engineering pain is recurrence.
Cloud agent workflows exist to:
The goal is not more automation. The goal is less work over time.
Use cloud agents when:
Avoid them when:
As teams adopt cloud agents, they discover:
Agents alone don’t scale without control and visibility.
Production cloud agents eventually require:
Without this, cloud agents become brittle fast.