Agents, Missions and Integrations
June 24, 2026
Snap CD 1.6.0 introduces two Enterprise-tier features: Agents (with Missions) and Integrations.
Agents & Missions
An Agent is a self-hosted process that consumes Snap CD events and runs AI-driven Missions in response. When a Module Job fails, succeeds, or reaches an approval gate, the Server dispatches Mission instructions to a connected Agent, which delegates the actual AI work to a Sidecar subprocess. The bundled Sidecar uses Anthropic's Claude, but the Agent itself is provider-agnostic — it holds no AI provider keys, and you can run multiple Sidecars backed by different providers.
Four Mission types ship out of the box:
| Mission | Fires when | Output |
|---|---|---|
| SummarizeJob | Apply or Destroy succeeds | Audit-quality summary of what changed, who approved, and what was anomalous |
| AutoDiagnose | Job fails, is cancelled, or approval is declined | Root-cause classification with the relevant log excerpt |
| ApprovalRecommend | Job enters WaitingForApproval | Approve / Decline recommendation with reasoning, shown to the human approver |
| AutoFix | Job fails, is cancelled, or approval is declined | Opens a PR against the Module's source repo with the proposed fix |
Same permission system, same supply model
Rather than inventing a parallel authorization layer for AI, Agents are governed by the same RBAC and supply model that control human and Runner access. An Agent is backed by a Service Principal, and that Service Principal's role assignments determine what the Agent can do. Give it Contributor on the test Stack and Reader on prod, and it can auto-fix test failures but only diagnose production issues — no special-case logic, no wrapper scripts.
The supply model works the same way as for Runners: an Agent must be explicitly supplied to a scope (Stack, Namespace, or Module) before it can receive Missions there. Without a supply covering prod, the Agent won't receive prod Missions — even if someone creates a prod-scoped Mission for it.
Every action an Agent takes is logged and attributed to its Service Principal with an agent_id claim, so the audit trail distinguishes between "service principal X acting as agent Y" and "service principal X acting as a plain service account."
AutoFix in action
When AutoFix is configured and a deployment fails, the Agent reads the job logs via Snap CD's MCP server, diagnoses the root cause, clones the source repo, makes the minimal fix, and opens a pull request — it never pushes to the default branch directly. A human reviews and merges the PR, Snap CD detects the source change, and the Module automatically re-deploys.
If the failure was transient (a provider rate limit or timeout), AutoFix simply re-triggers the Job — no code change, no PR. And if the root cause isn't something the agent can safely fix in-repo (expired credentials, state drift, a defect in a referenced module), it degrades to a diagnosis with a recommended manual action.
Bring your own AI
The Missions framework is the canonical way to let AI participate in your deployment lifecycle. But if you prefer to use your own AI agent or a different orchestration framework, you can have it interact with Snap CD's REST API directly using a plain Service Principal. The same RBAC governs what the API caller can do, regardless of whether it's a human, a CI bot, or an LLM.
Integrations
An Integration sends Snap CD events to an external system. Slack is the first supported type. Integrations follow the same supply-and-demand model as Agents and Runners:
- Supply — which scopes an Integration serves (per-stack, per-namespace, per-module, or org-wide).
- Demand — an Integration Event that subscribes a trigger to a target Integration on a scope.
A notification is delivered only when both hold. Available triggers include JobSucceeded, JobFailed, JobAwaitingApproval, JobCancelled, and MissionMilestoneReported. Messages support template substitution ({{moduleName}}, {{jobUrl}}, {{missionType}}, etc.) and can be customized per subscription.
Mission milestones from a single Mission are threaded under one Slack message, so a multi-step AutoFix run — diagnosis, attempted fix, retry — shows up as a threaded conversation rather than a wall of unrelated notifications.
Integration credentials (for Slack, the bot token) are stored encrypted in the secret backend and never exposed via the API or Terraform state. The Integration entity is created and managed in the Dashboard; in Terraform it is a data source.
Getting started
- AI on a Leash — the design philosophy behind scoped AI in infrastructure
- Agent documentation
- Integration documentation
- Integration Event documentation
- The sample-deployment includes a working Agent + Missions example (section 7)
Intelligent GitOps for Infrastructure as Code. Automate, orchestrate, and scale your infrastructure deployments with confidence.
© 2026 Snap CD. All rights reserved.