How It Works

One sentence in.
A proven change out.

SnapFlow runs a change the way a careful engineer would. Plan it, check it against policy, get sign-off on the risky part, run it in isolation, prove it, then keep watching.

0
Stages, one system
0
Clouds supported
0
Standing cloud keys
/ (plan) Illustrative
Pre-Flight Manifest
"Provision a staging Redis cluster on AWS"
Elevated Guarded ~2–4 credits
✅ Credit balance sufficient
✅ No blocking security-rule violations
▶ Blast radius: 3 resources
01

Cortex returns a plan you can inspect

Cortex turns "provision a Redis cluster for staging" into a typed, ordered plan before anything touches your cloud. It arrives with the exact actions, the resources they touch, what else depends on them, an estimated cost and a rollback path.

/ (approval) Illustrative
Gate Evidence
terraform apply — sg-0a13ff, prod
prod Elevated
Blast radius: 2 dependent services · Rollback plan attached
02

Policy runs before and during

Write the rules once. No public buckets. Production needs approval. Nothing ships on a Friday night. SnapFlow enforces them when the plan is built and again when each command is issued. Safe work runs. Risky work waits for a person who can see what they're approving.

/tasks/[id] Illustrative
🏗Terraform Task
Running
TOOL$ terraform apply tfplan
SYS2 to add, 0 to destroy
03

Containers that get thrown away

Each step runs in an isolated worker on an internal network, scoped to the permissions that step needs and destroyed afterwards. An unapproved step can't obtain mutating credentials at all, because the gate sits in the credential layer rather than the interface.

Done means proven

When a step finishes, SnapFlow checks the result against your live cloud estate using real resource identifiers, rather than trusting the model's "done". Every receipt records which method was used: proved against cloud, graded, or human-confirmed.

"vpc-04b1, rds-read-replica and iam-policy-cache-ro exist, in that account, with those settings. Checked by live API lookup, not self-report."

Proved against cloud
Receipt hash sha256:c41d…0a9b

It watches what it built, and can undo it

Every resource is tagged to its mission, so teardown is complete rather than best-effort. After a deploy, a post-deploy watch monitors the new resources and can revert them automatically when a critical incident fires.

Detect

Scheduled monitors poll your estate and raise an incident the moment something drifts from expected state.

Respond

Notify, escalate through an on-call rota, acknowledge, resolve. Slack and PagerDuty natively.

Recover

Critical incidents can trigger an automatic revert. On resolution a blameless postmortem is drafted from the flight log, with root cause flagged as a hypothesis for a human to confirm.

Built LLM-agnostic

SnapFlow is not an agent looping on its own transcript. Control flow, retries and branching are governed by a state machine, not by asking a model what should happen next. That choice is what lets it run on any model, stay cheap, and hold quality as a mission gets longer.

No context rot

Each step receives a scoped payload from the one before it, not the full run history. Context doesn't balloon, so quality doesn't decay on long runs.

Right-sized per step

Routine steps route to small, cheap models. Judgment-heavy ones route to frontier models. A router picks per step on cost, latency and uptime.

No vendor lock-in

Steps that must return structured data are constrained to a schema at the token level. Run on frontier APIs, open models, or fully on-premise.

0%
Fewer tokens
0%
Lower cost per run
O(N)
Context growth, not O(N²)

From our own architecture research on a simulated multi-step pipeline, measured against an unconstrained agent loop. It models the mechanism rather than customer traffic: an open loop's context grows with the square of the step count, ours grows linearly. On long missions that gap compounds.

Core capabilities

Grouped the way a buyer thinks about them.

Provisioning & change
  • Plain language to a typed, ordered plan
  • Real provisioning on AWS, GCP and Azure through OpenTofu and Terraform
  • Idempotent steps that adopt what already exists on retry
  • Change-as-PR into your own repository
Governance & control
  • Dev, staging and production as real boundaries
  • Approval screens with action, blast radius, cost and rollback
  • Policy-as-code checked at plan time and command time
Verification & proof
  • Results checked against the live cloud estate
  • Tamper-evident receipts carrying a SHA-256 content hash
Reliability & recovery
  • Every resource tagged to its mission for complete teardown
  • Post-deploy watch with automatic revert on a critical incident
Observability & incidents
  • Scheduled monitors that raise incidents from real telemetry
  • Detect, notify, escalate, acknowledge, resolve
  • Postmortems drafted from the flight log
Economics
  • Credits frozen up front, settled on the result
  • Priced by the work a mission actually does
Live estate & controls
  • A map of everything you actually run, across clouds, repos and your own servers
  • Every node opens a full property page — not a truncated summary
  • Console-grade actions on each resource, deletes included
  • Every one runs as a governed mission, so nothing skips the approval gate
Interruptions, not failures
  • A missing permission pauses the run — it does not kill it
  • Fix it in your own console and the mission resumes itself, on any provider
  • An agent out of time hands over to a fresh one with what’s left
  • Credits stay held while paused: nothing charged, nothing refunded
Forward-deployed engagements
  • Hand over a migration end to end, gated separately at cutover
  • Ongoing ownership of one of your own on-premises servers
  • A bespoke automation built for your stack, handed back as yours to re-run
  • Settled on the same verified-outcome rule as everything else