diff --git a/docs/docs.json b/docs/docs.json
index 7a350f41de..39fb6c7eeb 100644
--- a/docs/docs.json
+++ b/docs/docs.json
@@ -252,10 +252,26 @@
{
"tab": "Guides",
"groups": [
+ {
+ "group": "Getting Started",
+ "icon": "rocket-launch",
+ "pages": ["guides/overview"]
+ },
+ {
+ "group": "Cloud Agents",
+ "pages": [
+ "guides/cloud-agents/cloud-agents-taxonomy",
+ "guides/cloud-agents/guide-to-cloud-agents",
+ "guides/cloud-agents/when-to-use-cloud-agents",
+ "guides/cloud-agents/from-task-to-automation",
+ "guides/cloud-agents/cloud-agents-vs-ci",
+ "guides/cloud-agents/operating-cloud-agents-safely",
+ "guides/cloud-agents/automated-security-remediation-with-snyk"
+ ]
+ },
{
"group": "Guides",
"pages": [
- "guides/overview",
{
"group": "Understanding Continue",
"pages": [
@@ -287,26 +303,26 @@
"guides/notion-continue-guide",
"guides/github-pr-review-bot"
]
+ },
+ {
+ "group": "Cookbooks",
+ "icon": "book-open-cover",
+ "pages": [
+ "guides/posthog-github-continuous-ai",
+ "guides/continue-docs-mcp-cookbook",
+ "guides/github-mcp-continue-cookbook",
+ "guides/atlassian-mcp-continue-cookbook",
+ "guides/sanity-mcp-continue-cookbook",
+ "guides/sentry-mcp-error-monitoring",
+ "guides/snyk-mcp-continue-cookbook",
+ "guides/supabase-mcp-database-workflow",
+ "guides/dlt-mcp-continue-cookbook",
+ "guides/netlify-mcp-continuous-deployment",
+ "guides/chrome-devtools-mcp-performance",
+ "guides/klavis-mcp-continue-cookbook"
+ ]
}
]
- },
- {
- "group": "Cookbooks",
- "icon": "book-open-cover",
- "pages": [
- "guides/posthog-github-continuous-ai",
- "guides/continue-docs-mcp-cookbook",
- "guides/github-mcp-continue-cookbook",
- "guides/atlassian-mcp-continue-cookbook",
- "guides/sanity-mcp-continue-cookbook",
- "guides/sentry-mcp-error-monitoring",
- "guides/snyk-mcp-continue-cookbook",
- "guides/supabase-mcp-database-workflow",
- "guides/dlt-mcp-continue-cookbook",
- "guides/netlify-mcp-continuous-deployment",
- "guides/chrome-devtools-mcp-performance",
- "guides/klavis-mcp-continue-cookbook"
- ]
}
]
},
diff --git a/docs/guides/cloud-agents/automated-security-remediation-with-snyk.mdx b/docs/guides/cloud-agents/automated-security-remediation-with-snyk.mdx
new file mode 100644
index 0000000000..be4322f865
--- /dev/null
+++ b/docs/guides/cloud-agents/automated-security-remediation-with-snyk.mdx
@@ -0,0 +1,279 @@
+---
+title: "Automatically Remediate High & Critical Vulnerabilities with Cloud Agents"
+description: "How teams use cloud agents to automatically investigate and remediate high and critical Snyk vulnerabilities safely, reviewably, and without a dedicated security team."
+sidebarTitle: "Snyk Remediation"
+---
+
+## Why This Workflow Exists
+
+Most teams don’t struggle to *detect* security vulnerabilities. They struggle to *keep up with fixing them*.
+
+- alerts pile up
+- critical issues linger
+- fixes get deferred behind feature work
+- security becomes reactive instead of routine
+
+This guide shows how teams use cloud agents to automatically remediate high and critical Snyk vulnerabilities without introducing risk or losing control.
+
+
+**Who this is for?**
+Full-stack teams without a dedicated AppSec or DevOps function who still need to ship securely.
+
+
+## The Core Problem
+
+
+
+ Snyk finds real issues, but teams can’t keep up with triage and fixes.
+
+
+ Security work interrupts feature delivery and breaks focus.
+
+
+ Many fixes are repetitive, low-risk, and still handled manually.
+
+
+
+
+The risk isn’t that vulnerabilities exist. The risk is that known high-severity issues remain unfixed.
+
+
+## Why use an Agent? (vs. Snyk's Native Auto-PRs)
+
+Snyk has an excellent "Automatic Fix" feature that opens PRs to upgrade vulnerable dependencies. However, because Snyk cannot run your application's build or test suite, these PRs often break the build and require human cleanup.
+
+Continue's Cloud Agent sits *on top* of Snyk to complete the engineering work:
+
+| Feature | Snyk Native Auto-PR | Continue Cloud Agent |
+| :--- | :--- | :--- |
+| **The Fix** | "Bump `lodash` to v4.17.21" | "Analyze security issue and create PR with fix" |
+| **Context** | Vulnerability Database | Vuln DB + Security Impact Analysis |
+| **Intelligence** |Deterministic (Always bumps version) | Reasoning: "Analyzes dependency risks" and suggests updates |
+| **Result** | A PR that might break the build | A PR that is green and ready to merge |
+
+
+Snyk tells you *what* to upgrade. The Cloud Agent does the *engineering work* to make that upgrade safe.
+
+
+## What Does the Cloud Agent Do?
+
+A [Snyk remediation cloud agent](https://hub.continue.dev/integrations/snyk) owns the *handling* of security issues, but not the final decision.
+
+
+
+ - High & critical Snyk vulnerability events
+ - Repository context
+ - Dependency graph and version constraints
+
+
+
+ - Draft or ready PR with remediation
+ - Clear summary of risk and fix
+
+
+
+
+The agent doesn’t silently change production code. It produces **reviewable security PRs**.
+
+
+## How the Workflow Runs
+
+
+
+ A new **high or critical** vulnerability is detected by Snyk
+ (event-driven) or during a scheduled scan.
+
+
+
+ The agent investigates:
+ - the vulnerable dependency
+ - available remediation paths
+ - breaking-change risk
+
+
+
+ The agent:
+ - applies the minimal safe update
+ - avoids unnecessary refactors
+ - preserves existing behavior
+
+
+
+ A PR is created with:
+ - a clear title
+ - summary of the vulnerability
+ - explanation of the fix
+
+
+
+ A developer reviews and merges (or adjusts) the fix.
+
+
+
+## The Agent Configuration
+
+Continue's Snyk Cloud Agent is built from these core components:
+
+
+
+ **Webhook:** Snyk new vulnerability event
+
+
+ **Snyk MCP:** Fetch vulnerability details
+
+
+ **GitHub CLI:** Tells the agent how to create PRs
+
+
+
+
+```markdown Remediation Prompt expandable
+A new Snyk vulnerability has been detected. Please investigate and resolve the issue. This should include the following steps:
+
+**Step 1: Investigate the Issue**
+Make sure you understand the vulnerability, the options for resolution, and what their consequences are.
+
+**Step 2: Implement Fix**
+- Focus on fixing the immediate issue identified
+- Avoid overdoing it with error handling, cleaning up other problems, etc.
+- Avoid making breaking changes
+- Ensure the solution is robust and follows best practices.
+
+**Step 3: Create Draft Pull Request**
+Create a draft pull request with the following structure:
+
+--
+**PR Title:** [Snyk]
+
+## Issue
+
+**Snyk Link:** []()
+**Issue Type:** ``
+**Priority:**
+**Summary:**
+
+```
+
+## Governance: How This Stays Safe
+
+
+
+ **Assisted automation**
+
+ - Agent runs automatically
+ - PRs require human approval
+ - CI must pass before merge
+
+ *This is where most teams should live.*
+
+
+
+ **Manual / On-Demand**
+
+ - Agent is triggered manually
+ - Used to validate behavior and build trust
+
+
+
+ **Selective Automation**
+
+ - Narrow classes of fixes only
+ - Patch-level updates
+ - Strict constraints and rollback paths
+
+
+
+## What This Replaces (and What It Doesn’t)
+
+
+
+ - manual dependency bump PRs
+ - repetitive vulnerability triage
+ - security work that constantly interrupts feature delivery
+
+
+
+ - security design reviews
+ - architectural threat modeling
+ - decisions about major upgrades or breaking changes
+
+
+
+
+## Why Cloud Agents (Not Just CI or Scripts) for Automatic Security Remediation
+
+
+
+ CI can *detect* vulnerabilities,
+ but it can’t reason about fixes or propose patches.
+
+
+
+ Cloud agents:
+ - interpret Snyk findings
+ - choose appropriate fixes
+ - produce PRs developers can review
+
+
+
+
+CI enforces. Cloud agents **respond**.
+
+
+## Security Benefits Teams See
+
+
+
+ High-severity issues are fixed days or weeks sooner.
+
+
+ Developers review PRs instead of context-switching to triage.
+
+
+ Vulnerabilities stop piling up and become routine maintenance.
+
+
+
+
+## A Good First Setup
+
+
+- Only **high & critical** vulnerabilities
+- One repo or service
+- PRs only (no direct merges)
+- CI required before merge
+- Named owner for review
+
+
+## Where This Fits in the Bigger Picture
+
+This workflow is often a team’s **first successful cloud agent** because:
+
+- the ROI is immediate
+- the risk is bounded
+- the output is reviewable
+- leadership already cares about the problem
+
+Once this is working, teams often expand into:
+- error remediation
+- dependency hygiene
+- operational cleanup
+
+## Where to Go Next
+
+
+
+ More information on the Continue Snyk Integration and how you can get started today.
+
+
+
+ Get started by adding the Snyk integration to your projects
+
+
+
+
+## One Sentence to Remember
+
+
+Cloud agents turn security remediation from an interruption into routine maintenance.
+
\ No newline at end of file
diff --git a/docs/guides/cloud-agents/cloud-agents-taxonomy.mdx b/docs/guides/cloud-agents/cloud-agents-taxonomy.mdx
new file mode 100644
index 0000000000..4b2b16e5bd
--- /dev/null
+++ b/docs/guides/cloud-agents/cloud-agents-taxonomy.mdx
@@ -0,0 +1,238 @@
+---
+title: "The Cloud Agents Taxonomy"
+description: "A practical taxonomy of cloud agents for software teams, including definitions, categories, triggers, and when to use them safely in production."
+sidebarTitle: "Cloud Agents Taxonomy"
+---
+
+## Why This Taxonomy Exists
+
+“Cloud agents” is a term that gets used to describe everything from cron jobs to IDE copilots.
+
+That ambiguity causes teams to:
+- choose the wrong abstraction
+- automate too early
+- or avoid cloud agents entirely because they feel risky
+
+This guide exists to:
+
+> **Define what cloud agents actually are, how they differ from other agents, and when they make sense for software teams.**
+
+## A Clear Definition of Cloud Agents
+
+
+A **cloud agent** is an AI-driven process that runs on remote infrastructure, is triggered by tasks, schedules, or external events, and uses reasoning over changing inputs to produce reviewable outcomes across shared engineering systems.
+
+
+Key characteristics:
+- runs outside a developer’s local environment
+- operates on shared team context (repos, alerts, analytics, infra)
+- produces reviewable outcomes (PRs, reports, actions)
+- can run asynchronously and repeatedly
+
+Cloud agents exist to **handle work that benefits from reasoning, shared context, and reviewability.**
+
+## What Cloud Agents Are Often Confused With
+
+Cloud agents are often confused with other tools.
+
+
+
+ IDE agents focus on individual productivity and local context. Cloud agents operate on shared systems and team-owned work.
+
+
+
+ Cron is a trigger. Cloud agents reason over changing inputs and produce reviewable outcomes.
+
+
+
+ Scripts execute fixed logic. Cloud agents apply reasoning and shared context even for a single run.
+
+
+
+ Cloud agents still require review, ownership, and guardrails.
+
+
+
+## The Two Axes That Matter
+
+Cloud agents are best understood along **two dimensions**:
+1. **What triggers them**
+2. **How they’re governed**
+
+Everything else is implementation detail.
+
+```mermaid
+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](../continuous-ai).*
+
+## Axis 1: Cloud Agent Trigger Type
+
+### 1. One-Off Cloud Agents
+*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.*
+
+
+
+ - Analyze the top recurring Sentry errors
+ - Audit a repo for security issues
+ - Summarize system behavior
+
+
+ - Unknown scope
+ - Exploratory work
+ - Building confidence before automation
+
+
+
+### 2. Scheduled Cloud Agents
+*Time-based triggers that run on a fixed cadence (daily, weekly, hourly).*
+
+
+
+ - Weekly vulnerability scans
+ - Nightly analytics summaries
+ - Regular dependency updates
+
+
+ - Predictable recurring work
+ - Backlog prevention
+ - Drift detection
+
+
+
+### 3. Event-Driven Cloud Agents
+*Signal-based triggers that react to real-time events from external systems.*
+
+
+
+ - New high-severity alert
+ - Failed deployment
+ - Critical security finding
+
+
+ - Operational workflows
+ - Incident response
+ - Time-sensitive fixes
+
+
+
+## Axis 2: Cloud Agent Governance Level
+
+This is where most teams get into trouble.
+
+
+
+ - Human decides when the agent runs
+ - Human reviews everything
+
+ *Safest starting point.*
+
+
+
+ - Agent runs automatically
+ - Human approves outcomes
+
+ *Where most teams should live first.*
+
+
+
+ - Agent runs unattended
+ - Outcomes merge or act directly
+
+ *Earned over time — not assumed.*
+
+
+
+
+Cloud agents don’t fail because they’re autonomous. They fail because teams skip the control phase.
+
+
+## Cloud Agents vs Local / IDE Agents
+
+| 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.
+
+## Why Cloud Agents Exist at All
+
+Most engineering pain is recurrence.
+
+- alerts repeat
+- security issues resurface
+- operational work interrupts feature work
+
+Cloud agent workflows exist to:
+- notice repetition
+- respond consistently
+- reduce future interruptions
+
+The goal is not more automation. The goal is less work over time.
+
+## When Cloud Agents Make Sense
+
+Use cloud agents when:
+- the same class of issue keeps returning
+- the cost is in handling, not solving
+- work spans multiple systems
+- review and traceability matter
+
+Avoid them when:
+- the problem is novel
+- ownership is unclear
+- blast radius isn’t understood yet
+
+## The Architectural Reality
+
+As teams adopt cloud agents, they discover:
+
+> **Agents alone don’t scale without control and visibility.**
+
+Production cloud agents eventually require:
+- a shared place to review runs
+- a record of decisions
+- adjustable prompts and rules
+- gradual automation
+
+Without this, cloud agents become brittle fast.
+
+---
+
+## Where to Go Next
+
+
+
+ Learn how cloud agents are implemented and used in practice.
+
+
+
+ Explore how teams manage cloud agents safely at scale.
+
+
+
+---
+
+## One Sentence to Remember
+
+
+Cloud agents are how teams take ownership of work that happens after code ships.
+
diff --git a/docs/guides/cloud-agents/cloud-agents-vs-ci.mdx b/docs/guides/cloud-agents/cloud-agents-vs-ci.mdx
new file mode 100644
index 0000000000..88b540e5a1
--- /dev/null
+++ b/docs/guides/cloud-agents/cloud-agents-vs-ci.mdx
@@ -0,0 +1,127 @@
+---
+title: "Cloud Agents vs CI/CD"
+description: "Understand when cloud agents complement CI/CD jobs and when CI is the better tool."
+sidebarTitle: "Vs CI/CD"
+---
+
+
+Many teams see cloud agents and think: “Isn’t this just CI?” Sometimes the answer is yes and that’s good. CI is excellent. This guide explains the boundary so you choose the right tool.
+
+
+
+## What CI/CD Is Great At
+
+
+
+ - **Deterministic** — the same inputs produce the same results
+ - **Repeatable** — runs consistently on every commit
+ - **Policy-enforced** — clear pass/fail rules
+ - **Strongly testable** — success can be verified automatically
+
+
+
+ - Run tests
+ - Build artifacts
+ - Enforce lint rules
+ - Run static analysis
+ - Execute fixed scripts
+
+
+
+## Where CI/CD Breaks Down
+
+CI/CD is weaker when the work requires:
+- interpretation of changing signals
+- multi-system context (errors + analytics + issues)
+- generating patches with reasoning
+- summarizing incidents across tools
+- deciding next steps based on incomplete information
+
+
+## What Cloud Agents Add
+
+Cloud agents are useful when the job is:
+- triage + propose
+- interpret + summarize
+- patch + open a PR
+- coordinate across systems
+
+
+CI is the best executor of deterministic checks. Cloud agents are best at interpreting signals and producing reviewable outcomes.
+
+
+
+## Practical Pairings for CI + Cloud Agents
+
+```mermaid
+sequenceDiagram
+ participant Dev as Developer
+ participant Repo as Code Repository
+ participant CI as CI Pipeline (GitHub Actions)
+ participant MC as Mission Control
+ participant Agent as Cloud Agent (Continue)
+
+ Dev->>Repo: git push (feature-branch)
+ Repo->>CI: Trigger Build & Test
+
+ rect rgb(255, 240, 240)
+ Note over CI: ❌ Build Fails (Lint/Test Error)
+ CI->>MC: Emit failure + logs
+ MC->>Agent: Dispatch "Fix Build" task (attach logs + repo context)
+ end
+
+ Note over Agent: 1. Analyzes error logs
2. Proposes minimal fix
+ Agent->>Repo: Push fix to agent branch
+ Agent->>Repo: Open **draft PR** ("[Fix Build] ")
+
+ Repo->>CI: Trigger Build & Test (PR checks)
+
+ rect rgb(240, 255, 240)
+ Note over CI: ✅ Build Passes (PR checks)
+ end
+
+ CI->>MC: Report status on PR
+ MC->>Dev: Notify "Draft PR ready for review"
+ ```
+### Pattern 1: CI detects, Agent responds
+
+- CI detects failure or policy issue
+- Cloud agent proposes fix and opens PR
+- Human reviews
+
+### Pattern 2: Agent prepares, CI verifies
+- Cloud agent proposes changes
+- CI runs tests and checks
+- PR is only mergeable if CI passes
+
+### Pattern 3: Agent maintains, CI enforces
+- Agent keeps dependencies tidy weekly
+- CI ensures nothing breaks on merge
+
+
+## A Simple Decision Table
+
+| If your work is... | Prefer... |
+|---|---|
+| deterministic & testable | CI/CD |
+| interpretive & contextual | Cloud agent |
+| needs a patch proposal | Cloud agent + CI validation |
+| needs strict policy enforcement | CI/CD |
+
+---
+
+## Where to Go Next
+
+
+
+
+ Browse ready-to-use AI agents in Continue Mission Control.
+
+
+
+
+
+ Get started with Continue Mission Control.
+
+
+
diff --git a/docs/guides/cloud-agents/from-task-to-automation.mdx b/docs/guides/cloud-agents/from-task-to-automation.mdx
new file mode 100644
index 0000000000..f9f633c50d
--- /dev/null
+++ b/docs/guides/cloud-agents/from-task-to-automation.mdx
@@ -0,0 +1,118 @@
+---
+title: "From Task to Automation: How Cloud Agents Earn Trust"
+description: "A practical path from one-off tasks to safe automation, including governance levels, review, and failure modes."
+sidebarTitle: "Task → Automation"
+---
+
+## The Core Idea
+
+Cloud agents are powerful, but the real skill is **governance**: knowing what should be manual, assisted, or automated.
+
+
+ If you want the taxonomy first, including more information on trigger types + governance levels, check out the [Cloud Agents Taxonomy guide](/guides/cloud-agents/cloud-agents-taxonomy).
+
+
+## The Cloud Agent Trust Ladder
+
+```mermaid
+flowchart TD
+ A[Manual / One-Off Task] --> B[Assisted Runs]
+ B --> C[Scheduled Automation]
+ C --> D[Event-Driven Automation]
+ B --> E[Stop / Re-scope]
+ C --> E
+ D --> E
+ %% Styling
+ classDef stage fill:#F4F1FF,stroke:#7B61FF,stroke-width:2px,rx:12,ry:12,color:#1F2937;
+ classDef exit fill:#FFFFFF,stroke:#7B61FF,stroke-width:2px,rx:12,ry:12,color:#1F2937;
+
+ class A,B,C,D stage
+ class E exit
+
+ %% Layout hints
+ linkStyle 0,1,2 stroke:#7B61FF,stroke-width:2px;
+ linkStyle 3,4,5 stroke:#9CA3AF,stroke-width:2px,stroke-dasharray:4 4;
+```
+
+
+
+ Most teams should spend the most time in **Assisted** mode. That’s where trust compounds.
+
+
+## Stage 1: Manual Tasks (Human-Triggered)
+
+ *Goal: Learn the pattern and define review criteria.*
+
+ What you do
+ - Dispatch a task
+ - Review the output carefully
+ - Capture what “good” looks like
+
+ Exit criteria
+ - You can describe expected output in plain language
+ - Failures are understandable (not mysterious)
+ - The work is clearly recurring
+
+⸻
+
+## Stage 2: Assisted Runs (Auto-run, Human Approval)
+*Goal: Reduce handling cost without increasing risk.*
+
+What changes
+- The agent runs based on a trigger (schedule/event)
+- A human reviews outcomes before merge/action
+
+Best practices
+ - Require PRs/diffs as outputs
+ - Use checklists for review
+ - Keep blast radius small (one repo, one class of issues)
+
+⸻
+
+## Stage 3: Scheduled Automation
+
+*Goal: Prevent backlog by handling predictable work on a cadence.*
+
+Best fits
+ - dependency hygiene
+ - weekly security remediation
+ - routine cleanup
+
+Guardrails
+ - bounded scope
+ - predictable triggers
+ - clear rollback path
+
+⸻
+
+## Stage 4: Event-Driven Automation
+*Goal: Respond quickly to high-signal events.*
+
+Best fits
+ - high-severity security findings
+ - production regressions with clear patterns
+ - incident triage summaries
+
+Guardrails
+ - tight scope
+ - rapid feedback loops
+ - human review of outcomes
+
+## Common Cloud Agent Failure Modes (and Fixes)
+
+
+ **Fix:** Start manual. Write explicit acceptance criteria. Move to assisted only after you can review quickly.
+
+
+ **Fix:** Restrict to one repo, one class of issues, one trigger.
+
+
+ **Fix:** Assign ownership before automation. Automation without ownership creates invisible work.
+
+
+ **Fix:** Prefer PRs, diffs, and reports over “actions taken silently.”
+
+
+
+
+
diff --git a/docs/guides/cloud-agents/guide-to-cloud-agents.mdx b/docs/guides/cloud-agents/guide-to-cloud-agents.mdx
new file mode 100644
index 0000000000..e1f5302052
--- /dev/null
+++ b/docs/guides/cloud-agents/guide-to-cloud-agents.mdx
@@ -0,0 +1,188 @@
+---
+title: "The Developer’s Guide to Cloud Agents"
+description: "Learn how Cloud Agents are implemented and used in practice, from on-demand tasks to automated workflows in Mission Control."
+---
+
+
+This guide assumes you already understand what Cloud Agents are and when to use them. If you’re looking for a clear definition, categories, and mental models, start with the **[Cloud Agents Taxonomy](../cloud-agents/cloud-agents-taxonomy)**.
+
+
+## Introduction: Moving Beyond "Chat"
+
+For the last few years, AI coding has been defined by the Local Copilot: a chat window in your IDE that helps you write a function or explain a snippet. It is a powerful tool, but it has a hard limit because it requires *you* to be the driver. If you close your laptop, it stops working. If you switch contexts, it loses focus.
+
+
+
+ Cloud Agents move AI execution from your local machine to remote infrastructure. Instead of just "chatting" with a model, you **dispatch work** to it. Whether you trigger it manually from a task list or set it to run automatically on a schedule, the heavy lifting happens in the cloud, unblocking your local environment and enabling true automation.
+
+
+
+## How Cloud Agents Are Implemented in Practice
+
+Cloud Agents are AI-driven processes that run on remote infrastructure and are triggered by tasks, schedules, or events across a team’s engineering systems.
+
+With Continue, Cloud Agents run in [Mission Control](../../mission-control), where teams configure execution, connect tools, review outcomes, and decide which workflows become automated over time.
+
+
+
+ Because they run on persistent cloud infrastructure, these agents are not limited to the files currently open in your text editor. They maintain secure connections to your broader engineering ecosystem—GitHub, Linear, Sentry, Snyk, and more—allowing them to read code, open Pull Requests, and triage alerts without human supervision.
+
+
+
+### Common Components in a Production Cloud Agent
+
+Most production Cloud Agents share a common structure that balances reasoning, action, and guardrails.
+
+
+
+
+ The core instruction defining the task.
+
+
+
+
+
+ The LLM powering the reasoning.
+
+
+
+
+
+ The capabilities to fetch data or take action.
+
+
+
+
+
+ The guardrails ensuring the output matches your team's coding standards.
+
+
+
+
+## The Two Modes: Interactive vs. Automated
+
+This section focuses on *how* Cloud Agents are executed day to day, not *whether* they should be used.
+
+The defining feature of a Cloud Agent isn't just *automation*; it is **availability**. Because the compute is remote, you can interact with Cloud Agents in two distinct ways depending on the complexity of the task:
+
+
+
+
+ ### Human-in-the-Loop Approach
+
+ You can trigger agents manually (with Continue, use the [Continue CLI](../../cli/overview) or [Mission Control](../../mission-control)) when you need a one-off task that you want to review.
+
+
+
+ You send a "Refactor" task to a Cloud Agent. It clones the repo, runs the refactor in the cloud, and creates a PR for you to approve. **You can close your laptop while it works.**
+
+
+
+ **Best for:**
+ - Exploring agent capabilities
+ - Fixes you don't want to break your focus for
+ - Tasks requiring human review before deployment
+
+
+
+
+
+ ### Headless Approach
+
+ You configure these agents to run in the background based on triggers, with no human intervention required until the final PR review.
+
+
+
+ A "[Security Agent](https://hub.continue.dev/integrations/snyk)" automatically opens PRs for Snyk issues with high and critical security vulnerabilities and implements the fixes.
+
+
+
+ **Best for:**
+ - Continuous security monitoring
+ - Automated dependency updates without breaking things
+ - Event-driven workflows
+
+
+
+
+
+## Why "Cloud" Matters
+
+The distinction between running an agent locally (TUI/IDE) and in the cloud (Mission Control) comes down to **scope** and **reliability**.
+
+
+
+
+ - **Local Agents:** Run on your local machine
+ - **Cloud Agents:** Run on remote cloud infrastructure
+
+ Cloud Agents free up your local resources for development work while heavy AI tasks run in the background.
+
+
+
+
+
+ - **Local Agents:** Fast, private iteration and "single-player" coding
+ - **Cloud Agents:** Collaborative tasks, heavy processing, and reliable automation
+
+ Choose local for quick iterations, cloud for team-wide workflows.
+
+
+
+
+
+ - **Local Agents:** Limited to open files and local git state
+ - **Cloud Agents:** Full repository access + [integrated tools](https://hub.continue.dev/integrations) (Sentry, Snyk, Linear, etc.)
+
+ Cloud Agents can access your entire engineering ecosystem, not just what's visible in your IDE.
+
+
+
+
+
+ - **Local Agents:** Manual Chat / CLI
+ - **Cloud Agents:** Hybrid approach—Manual Chat, Cron Schedules, or Event Webhooks
+
+ Cloud Agents support both manual execution and automated scheduling.
+
+
+
+
+
+ - **Local Agents:** Stop when you close your laptop
+ - **Cloud Agents:** **Always On**—Runs asynchronously in the background
+
+ This is the key differentiator: Cloud Agents work 24/7, even when you're offline.
+
+
+
+
+## Getting Started
+
+Ready to build your first Cloud Agent? Check out these resources:
+
+
+
+
+ Browse ready-to-use AI agents in Continue Mission Control.
+
+
+
+
+
+ Learn how to build custom Cloud Agents.
+
+
+
+
+
+ Connect your agents to external services.
+
+
+
+
+
+ Get started with Continue Mission Control.
+
+
+
diff --git a/docs/guides/cloud-agents/operating-cloud-agents-safely.mdx b/docs/guides/cloud-agents/operating-cloud-agents-safely.mdx
new file mode 100644
index 0000000000..a6c427e4a6
--- /dev/null
+++ b/docs/guides/cloud-agents/operating-cloud-agents-safely.mdx
@@ -0,0 +1,233 @@
+---
+title: "Operating Cloud Agents Safely"
+description: "Guardrails for running cloud agents in production: ownership, permissions, review, auditability, and blast radius."
+sidebarTitle: "Operate Safely"
+---
+
+
+
+Cloud agents should reduce risk and interruptions not introduce new ones. This guide covers practical guardrails that make cloud agents safe for real teams.
+
+
+## The Safety Baseline for Cloud Agents
+
+
+
+ Every workflow has a named owner and an escalation path.
+
+
+ Outputs are diffable, explainable, and revertible.
+
+
+ One repo →
+ one workflow →
+ one trigger.
+ *Expand only after success.*
+
+
+
+
+## A Safe Adoption Path
+
+
+
+ Run as a one-off task. Validate cloud agent outputs and define acceptance criteria.
+
+
+
+ Allow automated triggering, but keep human approval before merge/action.
+
+
+
+ Only automate workflows with predictable blast radius, clear rollback, and stable output quality.
+
+
+
+
+Cloud agents don’t fail because they’re autonomous.
+They fail because teams automate before they’ve defined review criteria and ownership.
+
+
+## 1) Ownership Comes First
+
+Before you automate anything, make these true:
+
+
+
+ One person is responsible for:
+ - reviewing outcomes
+ - tuning prompts/rules
+ - responding to failures
+
+
+
+ Decide what happens when:
+ - the cloud agent can’t complete work
+ - output confidence is low
+ - a run fails repeatedly
+
+
+
+
+
+ - The workflow has a dedicated Slack channel or notification route
+ - There is a “stop the line” decision owner
+ - Ownership does not rotate implicitly (it’s explicit)
+
+
+
+ - “Whoever sees it first” is the owner
+ - Alerts route to a general channel with no responder
+ - No one feels safe turning it off
+
+
+
+## 2) Constrain Blast Radius
+
+The fastest path to trust is a smaller blast radius.
+
+
+
+ Pick a low-risk repo or a single service to prove value.
+
+
+
+ Narrow the scope: one recurring error type, one vuln class, one cleanup task.
+
+
+
+ Set expectations like “no more than N files” or “single dependency PRs.”
+
+
+
+
+Prefer PRs and reports over direct writes or production actions.
+
+
+## 3) Review Is the Safety Rail
+
+Treat every cloud agent run like you’d treat a teammate’s PR.
+
+
+
+ Use a lightweight checklist:
+
+ - [ ] Does the change match the prompt intent?
+ - [ ] Is the blast radius clear?
+ - [ ] Are tests updated or unaffected?
+ - [ ] Are failure cases acceptable?
+ - [ ] Is rollback straightforward?
+
+
+
+ Reviewable outputs are:
+
+ - **Diffable** (PRs, patches, file changes)
+ - **Explainable** (short rationale, linked inputs)
+ - **Revertible** (easy rollback path)
+
+
+
+ Block merge when:
+
+ - scope is unexpectedly broad
+ - behavior changes are unclear
+ - it introduces new dependencies without justification
+ - it “fixes” by deleting or disabling core functionality
+
+
+
+## 4) Permissions: Least Privilege by Default
+
+Give agents the smallest set of permissions required for the job.
+
+
+
+ - Prefer **read-only** until the workflow proves reliable
+ - Prefer **PR creation** over direct push
+ - Scope external tools (Sentry/Snyk/etc.) to the minimum endpoints
+
+
+
+ - Level 1: Read repo + create report
+ - Level 2: Create PRs (drafts first)
+ - Level 3: Update PRs based on review comments
+ - Level 4: Automate merges only for narrow, proven workflows
+
+
+
+
+Do not start with permissions that allow silent writes to main or production mutations.
+
+
+## 5) Observability & Auditability
+
+If you can’t answer these questions, you don’t have a safe system yet:
+
+
+
+ - What ran?
+ - Why did it run?
+ - What inputs did it use?
+
+
+
+ - What did it change?
+ - Who reviewed/approved it?
+ - Did it succeed or require intervention?
+
+
+
+
+Auditability turns “AI did something” into “we can explain what happened.”
+That’s the difference between experimentation and production.
+
+
+## 6) Failure Handling & Safe Defaults
+
+Set defaults that fail safely.
+
+
+
+ - **Fail closed** (no silent actions)
+ - If uncertain, produce a **report** instead of a change
+
+
+
+ - External tool API is unavailable
+ - Repo state changed mid-run
+ - Cloud agent proposes a fix that doesn’t pass CI
+ - Output becomes noisy (too many PRs/reports)
+
+
+
+ - Pause the workflow
+ - Reduce scope / increase constraints
+ - Move back a governance level (Automated → Assisted → Manual)
+ - Update acceptance criteria and rerun
+
+
+
+## Pre-Flight Checklist
+
+
+- [ ] Workflow owner is named
+- [ ] Trigger is defined and bounded
+- [ ] Outputs are reviewable (PR/report)
+- [ ] Permissions follow least-privilege
+- [ ] Blast radius is constrained
+- [ ] Failure handling is defined
+- [ ] There is a way to pause/disable quickly
+
+
+## Where to Go Next
+
+
+
+ The trust ladder for moving from manual to automated safely.
+
+
+
+ Proven starter workflow with clear triggers and review points.
+
+
\ No newline at end of file
diff --git a/docs/guides/cloud-agents/when-to-use-cloud-agents.mdx b/docs/guides/cloud-agents/when-to-use-cloud-agents.mdx
new file mode 100644
index 0000000000..28caf7a0af
--- /dev/null
+++ b/docs/guides/cloud-agents/when-to-use-cloud-agents.mdx
@@ -0,0 +1,89 @@
+---
+title: "When to Use Cloud Agents (and When Not To)"
+description: "A decision guide for choosing cloud agents vs scripts, CI jobs, or local agents—plus a checklist for safe adoption."
+sidebarTitle: "When to Use"
+---
+
+## When Cloud Agents Make Sense
+This guide helps you decide whether **cloud agents** are the right abstraction for your problem.
+
+
+Use cloud agents when the work is **recurring**, spans **multiple systems**, and needs **team-owned outcomes**. If you want the canonical definition and taxonomy first, read: [Cloud Agents Taxonomy](/guides/cloud-agents/cloud-agents-taxonomy).
+
+
+Use cloud agents when:
+
+- The same class of issue returns weekly (or daily)
+- The work is mostly handling (triage, patching, cleanup), not discovery
+- Inputs come from tools like GitHub, error monitoring, security scanners, analytics
+- You need a reviewable outcome (PR, report, ticket update)
+- You want to reduce interruptions, not just respond faster
+
+
+
+
+ - security remediation
+ - recurring error triage
+ - dependency hygiene
+ - analytics-driven fixes
+
+
+
+ - task dispatch
+ - schedules
+ - event webhooks
+
+
+
+## When Cloud Agents Are a Bad Idea
+
+Avoid cloud agents when:
+
+- The problem is novel and poorly understood
+- The blast radius is unclear
+- Ownership is ambiguous (“someone should handle this”)
+- You can’t define review criteria
+- The work is better solved by eliminating the root cause directly
+
+
+Cloud agents amplify whatever system you already have. If ownership is unclear, automation will make it worse.
+
+
+
+## Cloud Agents vs Alternatives
+
+## Comparison Matrix
+
+| Feature | Scripts / CI Jobs | Local Agents (TUI) | Cloud Agents (Headless) |
+| :--- | :--- | :--- | :--- |
+| **Logic** | Deterministic (If/Then) | AI / Probabilistic | AI / Probabilistic |
+| **Context** | Inputs only | Full Repo + User Chat | Repo + Integrations (Snyk/GitHub/etc.) |
+| **Interaction** | None (Logs only) | Interactive (Conversations) | Autonomous (Fire & Forget) |
+| **Tool Access** | Unlimited | All (Ask permission supported) | Safe (No "Ask" tools) |
+| **Best For** | Testing, Building, Linting | Debugging, Refactoring, Exploration | Triage, Remediation, Reporting |
+
+## The Decision Checklist
+
+Use cloud agents if you can say “yes” to most of these:
+
+- [ ] We’ve seen this problem at least twice
+- [ ] Inputs come from shared systems (alerts, issues, analytics)
+- [ ] We can define what “good output” looks like
+- [ ] A PR/report is an acceptable artifact
+- [ ] Someone owns reviewing the result
+- [ ] We can start in a manual or assisted mode
+
+
+If you’re unsure, start with a one-off [task](../../mission-control/tasks) and treat it like an experiment.
+
+
+## Where to Go Next
+
+
+
+ Customize an agent for your team in minutes.
+
+
+Explore pre-built integrations for common tools and workflows.
+
+
\ No newline at end of file
diff --git a/docs/guides/overview.mdx b/docs/guides/overview.mdx
index f6eae2c063..fc601ca63e 100644
--- a/docs/guides/overview.mdx
+++ b/docs/guides/overview.mdx
@@ -9,6 +9,17 @@ description: "Comprehensive collection of practical guides for Continue includin
- [How to Self-Host a Model](/guides/how-to-self-host-a-model) - Self-hosting AI models
- [Running Continue Without Internet](/guides/running-continue-without-internet) - Offline development setup
+## Cloud Agents
+
+- [Cloud Agents Taxonomy](/guides/cloud-agents/cloud-agents-taxonomy) - Different types of cloud agents and their use cases
+- [Developers Guide to Cloud Agents](/guides/cloud-agents/guide-to-cloud-agents) - Overview of cloud agents and their benefits
+- [When to Use Cloud Agents](/guides/cloud-agents/when-to-use-cloud-agents) - Deciding when cloud agents are the right tool
+- [From Manual to Automated Cloud Agents](/guides/cloud-agents/from-task-to-automation) - Transitioning from manual to automated workflows
+- [Cloud Agents vs CI/CD](/guides/cloud-agents/cloud-agents-vs-ci) - When to use cloud agents vs CI/CD pipelines
+- [Operating Cloud Agents Safely](/guides/cloud-agents/operating-cloud-agents-safely) - Best practices for secure cloud agent operation
+- [Automated Security Remediation with Snyk](/guides/cloud-agents/automated-security-remediation-with-snyk) - Using cloud agents for security fixes
+
+
## Continuous AI
- [Continuous AI: A Developer's Guide](/guides/continuous-ai) - Integrating AI into development workflows
diff --git a/docs/mission-control/integrations/index.mdx b/docs/mission-control/integrations/index.mdx
index 273cc9cd1c..3b8810bc42 100644
--- a/docs/mission-control/integrations/index.mdx
+++ b/docs/mission-control/integrations/index.mdx
@@ -21,7 +21,7 @@ Mission Control currently supports these first-class Cloud Agent integrations:
- Trigger Agents automatically when new Sentry issues appear.
+ Trigger Cloud Agents automatically when new Sentry issues appear.