🎯

Missions

Score, plan, fix and ship a customer’s codebase — from one live board

A Mission is a live board for one customer’s codebase. It scans the code against your engineering rules and scores it, turns every finding into a priced item the customer can approve, and groups approved work into Sorties — small, scoped jobs that each carry a test for “done”. A fleet of AI agents works the Sorties in parallel, each in its own isolated copy of the repo, healing against the same rules until clean; nothing reaches main except through a gate that re-runs that test, and what ships is verified in a real browser and re-scanned. The customer watches all of it on their own portal: the grade, the sorties, the shopping list they signed off, and proof of what was delivered.

Available Now For: Agencies, platform teams and resellers who develop, review or manage code and cloud for their customers
Get Started

What You Get

1

One live board per customer — DNA grade, open sorties, progress and quoted cost in one shareable link

2

A priced shopping list — recommended work is quoted before it starts; the customer approves it in the portal

3

Sorties, not tickets — each is a scoped group of requirements with one acceptance test that must go green

4

A fleet of agents in isolated worktrees — parallel sweeps, DNA-gated self-healing, serial rebase-gated ship

5

Proof, not promises — what shipped is browser-verified and re-scanned; a regression reopens its sortie

6

Database changes rehearsed against a real database, and cloud cost and waste surfaced across the estate

7

Third-party code review and change-request management with AI-slop detection on incoming changes

8

Honest branch recovery — patches compared, not ancestry, so already-shipped work is never reported abandoned

9

Self-serve for the customer, or run alongside them — one instance per client, in your cloud or theirs

How a Mission works

Three pictures say what a feature list cannot: what a Mission is made of, how the agents work it without treading on each other, and why nothing lands that has not proved itself.

Anatomy — a Mission is a board of Sorties

Missionone board per customer repoDNA gradeBsorties3 open · 12 donerequirements27shopping list£4,250Sortie · migrate authSortie · envelope driftSortie · raw fetch → apiopensSortie · raw fetch → api clientscope: app/src/lib/admin/** · owner @ash-forge · tier standardRequirementsAdminPage.svelte:38 routes through apiFetchcodeAllAppsView.svelte:9 drops API_BASE_URLcodeSales sign-off on the quoted pricedecisionAcceptance criterion — what "done" means, in codefe-raw-fetch-check.ts exits 0 for app/src/lib/admin/**red before the workgreen after it — or the sortie stays opengreen on main → sortie done → the Mission's grade moves upA sortie cannot close by hand: the criterion must go green on main.Requirements without a criterion never dispatch — the board says so.
A Mission holds the grade, the shopping list and the Sorties. Each Sortie groups a handful of requirements under ONE acceptance criterion — a check that is red before the work and must be green after it. A sortie cannot be closed by hand; the criterion proves it done and lifts the grade.

The fleet — one agent per Sortie, each in its own worktree

Batch driverone per boxpicks the model tierfrom each sortie's shapeworktree · sortie Aagent (deep tier)implement → DNA gates → heal ≤ 3 → cleanworktree · sortie Bagent (standard tier)implement → DNA gates → heal ≤ 3 → cleanworktree · sortie Cagent (fast tier)out of scope → PARKED, worktree keptbrief + criterionin parallelserial · one at a timeRebase gaterebase onto mainre-run the criteriongreen → merge · red → parkmaindeploy holds a leaseso no second deploylands on top of itEach lane is a git worktree: agents never share a checkout, and a failed lane can never dirty another.
A batch driver briefs one agent per Sortie with the requirements and the criterion, picking the model tier from the sortie’s shape. Each agent works in an isolated git worktree and heals against the DNA gates until clean. Branches then ship one at a time through a rebase gate that re-runs the criterion on top of main; red parks, green merges, and the deploy holds a lease so nothing lands on top of it.

The loop — scan, plan, sweep, gate, ship, verify, scan

ScanDNA rules, gradePlanfindings → sortiesSweepagents, worktreesGatecriterion + DNAShipPR, merge, deployVerifybrowser-confirmedred → heal again (≤ 3)re-scan: a regression reopens its sortie automaticallyCustomer portalreads the board live: grade, sorties, progress — and a priced shopping list of recommended workapprove → sortiedelivered → invoiced
The scan produces findings and a grade; findings become priced items the customer approves into Sorties; the fleet sweeps them; the gate lets only green through; what ships is verified in a real browser and the repo is scanned again. A regression reopens its Sortie automatically. The customer portal reads the board live throughout.

Every other tool overstates it — measured on our own repo

Case Study Scare

Ancestry read: 59 abandoned branches carrying 177 unmerged commits. A stakeholder said, verbatim, "I'm freaking out about this."

Case Study Truth

Patch read on the same minute: 12 branches were ENTIRELY already applied (squash/rebase/cherry-pick), 47 held 152 genuinely unapplied commits. Same repo, opposite story.

Case Study Lived

We got the diagnosis wrong twice before reaching for `git cherry`. Two-thirds of the surviving branches conflicted — not because they were damaged, but because newer fixes touched the same lines. That is the repo defending itself, not evidence of rot.

Case Study Verify

Run it on your own repo.

bash
git branch --no-merged origin/main | wc -l

is the ancestry scare;

bash
for b in $(git branch --no-merged origin/main --format="%(refname:short)"); do git cherry origin/main "$b" | grep -c "^+"; done | awk '{s+=$1} END{print s}'

is the patch truth. The gap between the two IS the pitch.

Pricing Heading

Per-customer instance, billed monthly. The platform fee covers the board, the scans and the portal; agent work is quoted per sortie before it starts, and AI model usage is never hidden inside the monthly fee.

  • Portal instance — one per customer, from £295/mo: the DNA scan and grade, the mission board, rogue-branch recovery scans and the customer portal. Includes £25 of managed AI a month, pooled across your account. Priced per customer — a separate line from your platform plan.
  • Sortie work — quoted in the shopping list the customer approves. Each quote names the model tier it will run at, so the AI cost is visible per item, or nets to zero when the customer brings their own model subscription.
  • Rogue-branch recovery scan — included; run it as often as you like. Three honest numbers per repo (already-applied, unapplied, safe to delete today) plus a per-branch disposition (delete, merge, regenerate, investigate).
  • Recovery engagement — priced per branch to be LANDED, not per branch scanned. A branch marked safe-to-delete costs nothing; a regenerate is billed at the regeneration cost, not the salvage cost.
  • Bring-your-own-cloud available (Azure today, other clouds on request) — your instance runs in your subscription; billing is portal-only.

Platform fees cover the software, hosting, support and a set allowance of EmberNest-managed AI, shown on each plan. AI model usage is separate beyond that: overage is metered and itemised on your bill, with limits and alerts — or bring your own on eligible plans: an existing Claude, OpenAI or Azure subscription, an OpenRouter account, or local models via EmberConnector.

Powered By

Missions is powered by EmberNest — the same production platform behind every app in the ecosystem.

⚙️ EmberMission
⚙️ EmberDNA
⚙️ EmberConnector
⚙️ EmberObservatory
⚙️ EmberBot

Developer Resources

Try In CLI

$ embernest missions dashboard CLI Reference →

API Reference

Full rest API documentation

View API Docs →

MCP Tools

Connect To MCP

Explore MCP →

Ready To See

Explore How