How it works

From one sentence to a proven change.

SnapFlow runs a change the way a careful senior engineer would — plan it, pressure-test it, get a human's sign-off on the risky part, execute it in isolation, prove it, and keep watching. Here's each stage.

01 · Understand

Cortex reads intent and returns a plan you can inspect.

Cortex is the planner. It converts "provision a Redis cluster for staging" into a typed, ordered execution plan — discrete steps, in dependency order — before a single command touches your cloud. Attached to that plan up front: the exact actions, the resources they touch, the blast radius (what else depends on them), the estimated cost, and the rollback path. You're never staring at a blank "approve?" prompt.

02 · Govern

Guardrails run before anything executes — and again at command time.

Teams write their own policy-as-code — "no public S3," "prod needs approval," "no weekend prod changes" — and SnapFlow enforces it deterministically, at plan time and again at the moment of execution. Anything risky pauses for a human, who approves against evidence, not vibes. Everything safe just runs.

📐
Environments as boundaries
Dev / staging / prod, each with its own approval policy and cloud role — first-class, not a tag.
🧾
Evidence-rich approval
Before a human approves, they see the exact action, resources touched, blast radius, cost, and rollback plan.
⚖️
Policy-as-code, twice-checked
Guardrails are enforced deterministically at plan time — and re-checked at command time so nothing slips through.

03 · Execute

Every step runs in a throwaway, credential-scoped container.

Execution happens in an isolated worker container on an internal-only network — spun up for the task, scoped to only the permissions that step needs, and destroyed after. A step that hasn't been approved can't obtain mutating credentials in the first place: the approval gate lives in the credential layer, not just the UI. Nothing persistent runs on your network.

📦
One task, one container
Ephemeral by default — created for a single step, torn down immediately after. No standing agent runtime.
🔐
Least-privilege credentials
Short-lived, scoped-to-the-step credentials, issued via OIDC federation — never a standing key.
🚧
Un-bypassable action gate
Destructive or permission-changing commands are classified server-side and blocked without a recorded human decision.

04 · Prove

Done means proven, not reported.

When a step completes, SnapFlow checks the result against the real cloud estate — real resource identifiers in the execution trace — rather than believing the model's "done." Each mission's receipt records how it was verified: proved against cloud, graded, or human-confirmed. This is the foundation everything else stands on — you can safely automate only what you can safely prove.

Verification method ✓ Proved against cloud
vpc-04b1, rds-read-replica, iam-policy-cache-ro — resolved by live API lookup, not model self-report
Trace: 3 resource IDs cross-checked against AWS describe-* calls
Hash: sha256:c41d…0a9b

05 · Watch

It watches what it built — and can undo it.

Every resource SnapFlow creates is tagged to its mission, so teardown is deterministic and complete. After a deploy, a post-deploy watch monitors the new resources and can automatically roll back on a critical incident — safe-by-default for production.

Detect
Scheduled monitors
Polls your estate on a cadence and raises incidents the moment something drifts from expected state.
Respond
Full incident lifecycle
Notify → escalate through an on-call rota → acknowledge → resolve. The same rigor as the mission itself.
Recover
Auto-rollback + postmortems
Critical incidents can trigger an automatic revert. On resolution, a blameless postmortem is drafted from the flight log — root cause always flagged as a hypothesis for a human to confirm.

The execution core

Built LLM-agnostic, not LLM-dependent.

SnapFlow isn't a conversational agent looping on its own transcript. Control flow, retries, and branching are governed by a deterministic state machine — not by asking a model to reason about what happens next. That one architectural choice is what lets SnapFlow run on any model, keep runs fast and cheap, and stay reliable as a mission grows longer.

🧠
No context rot
Each step receives a scoped, pruned payload from its predecessor — not the full run history. Context doesn't balloon as a mission gets longer, so quality doesn't degrade on long, multi-step runs.
⚖️
Right-sized model per step
Routine, well-defined steps route to small, cheap models. Judgment-heavy steps — root-cause reasoning, ambiguous intent — route to frontier models. A dynamic router picks per step on cost, latency, and uptime, not a hard-coded vendor.
🧩
Structural output guarantees
Steps that must return structured data are constrained at the token level to a schema, not just prompted to follow one — eliminating malformed JSON and structural hallucination even from smaller models.
🔓
No vendor lock-in
Because orchestration logic doesn't live inside a model's reasoning, SnapFlow runs against frontier APIs, open-source models, or fully on-prem/air-gapped deployments — a hard requirement for regulated buyers. Pairs with bring-your-own-model on Trust →
Internal research
We measured this architectural difference directly. Moving from an unconstrained conversational agent loop to SnapFlow's deterministic execution kernel cut token consumption and cost by roughly two-thirds to four-fifths across a simulated multi-step pipeline benchmark, with average step latency dropping by a similar margin. The mechanism: an open-ended loop's context grows roughly with the square of the number of steps as history piles up; SnapFlow's scoped-context design grows only linearly with step count — the difference compounds fast on long-running missions.
O(N) vs O(N²)
context growth: linear under SnapFlow, quadratic in a naive agent loop
~68%
lower token burn in simulated benchmark runs
~81%
lower per-run cost in the same benchmark
~⅔ faster
average step latency vs. an unconstrained loop

From SnapFlow's internal architecture research (simulated benchmark). A model of the mechanism, not a customer-facing production metric — see the honesty framing on Why SnapFlow →

Everything it does

Core capabilities

Grouped the way a buyer actually thinks about them.

Provisioning & change
  • Natural-language intent → typed, ordered execution plan
  • Real provisioning across AWS, GCP, and Azure via OpenTofu/Terraform
  • Idempotent, mission-scoped changes — a retried step adopts what already exists
  • Change-as-PR: changes can land as a pull request into your own repo
Governance & control
  • Environments (dev/staging/prod) as first-class boundaries
  • Evidence-rich approval gate — action, blast radius, cost, rollback plan
  • Policy-as-code, enforced at plan time and command time
Verification & proof
  • Proof-carrying verification against the live cloud estate
  • Tamper-evident receipts with a SHA-256 content hash
Reliability & recovery
  • Full rollback — every resource is tagged to its mission for deterministic teardown
  • Post-deploy watch with auto-revert on critical incident
Observability & incident response
  • Scheduled monitors that poll the estate and raise incidents
  • Full lifecycle: detect → notify → escalate → acknowledge → resolve
  • Auto-drafted, blameless postmortems from the flight log
Economics
  • Escrow + deliver-based settlement
  • Complexity-aware pricing — priced by the actual work, not a flat fee

How we secure all of it

Least-privilege credentials, no long-lived keys, per-tenant isolation, and an action gate the model can't bypass.

Read the Trust page →