Missions & Mission Control

The strategy leaves the deck.

A mission is a promise with the tools to keep it: a goal, an owner, a budget, what done looks like, and how it gets checked. I build it from your plan; your team and my agents do it.

Problem

Between “we decided” and “it shipped”, work goes to die.

Handoffs, lost context, tools that don’t know why the work exists. Project tools watch it die. Missions keep it alive.

Mechanism

You say yes → I plan it → it runs.

Graph

Say yes to a plan, and I propose the mission map: the pieces of work, what waits on what, who does each, the budgets and the checks.

Critical path

You look over the preview first; nothing starts on its own. Then Mission Control runs it: handing out the work, watching time and budgets.

Blocker named

Blockers show up named — missing info · waiting on something · needs your OK · budget · quality · a human call — each with an owner and a deadline.

Verified

Fixes go back to whoever does them, releases line up, and Verify checks what the missions make: done means verified.

Drag sideways to see the rest

What's inside

One mission, opened up.

A real one, from the Aster run:

Mission

goal: Launch the design-partner program
how we'll know: 10 good partners in 30 days
in and out of scope: written down
pieces of work: 6, each with what done looks like
what waits on what: mapped
who does it: 2 people of yours, 3 agents, 1 tool
budget: $80 of AI use + $0 outside spend
what I do on my own: line up the work and run it once you say yes
how it gets checked: included
how results get measured: included

Worked example

The critical path, lit.

Research → positioning → landing page, with the product build running alongside. Pricing waits on you, in amber. Click a step to open it.

drag sideways to pandrag · arrows to pan

Landing page — the work

Outcome: Live page, claims verified
Owner: Agent (coding)
Budget: $14 of AI use
Runs: runs once you say yes

The review desk

Nothing lands in your company without a look.

Each piece of work — copy, data, design, code — shows up as a before-and-after: old next to new for copy, before and after tables for data, version side by side for files. Verify’s notes sit on the exact lines they’re about. You approve, ask for changes, or take over, piece by piece, on the record.

Deliverable · landing page — diff against rev 3

Sample

hero.claim

“Proven to increase win rate 40%.”

“Turns customer interviews into product decisions.”

Verify · finding “‘Proven to raise win rate 40%’ has no proof in what I know about the company.”

Resolved

Verified at rev 4

And the check mark can’t lie: “verified” shows only on the exact version Verify checked. Change the work after the check and it says “verified at rev 4, changed since” — never an old check mark on new words.

Your clients can sit at the same desk. They review in their own portal, and a client’s approval counts as a check, not a Slack thumbs-up.

When it's stuck

Every blocker has an owner and a clock.

Each blocker says what kind it is (missing info · waiting on something · needs your OK · budget · quality · a human call) and who owns it, with a deadline · budgets warn before they stop · a cancelled or replaced mission stays on record, never deleted.

UnderstandDecideDeliverVerifyLearn

Missions come from your plan. Verify checks what they make.

The hard question

What happens when a mission goes wrong?

Loudly, and on the record. Blockers show up with an owner and a next step. Work that fails a check comes back with exact notes to fix. If a budget runs out, I pause and ask. You can cancel or replace a mission, and the record keeps what happened, because “we don’t talk about Q3” is how companies stay stuck.

See the Agent Fleet How work gets checked