How it works

From a mission
to reviewable work.

Start with the outcome. Give the team clear responsibilities. Break the work into tasks you can understand, then guide the decisions that matter.

Try the workspace previewGetting started

The example below describes the workspace model. Today’s preview demonstrates it locally in your browser.

Step01

Name the outcome.

“Build a product” leaves too much open. A useful mission says who the work is for, what should change, and where the first milestone ends.

Example mission

Launch a useful first release for a small, focused team.
Audience
Small teams coordinating their first release
First milestone
A working sign-up flow and a clear release announcement
Success check
A new user can sign up and reach the first useful screen
Boundary
No paid acquisition or expansion of the release scope

Keep the first milestone narrow enough to review. Add reference material and constraints alongside the mission so the team does not have to infer them.

Write your first mission
Step02

Give each role
a responsibility.

Choose a small team around the milestone. Give each agent a scope, the context it needs, and a person or lead to report to.

Operations / Lea

Coordinate the release.

Own the plan, clarify blockers, and bring changes of scope back to you.

Engineering / Rowan

Build the agreed changes.

Own implementation and report what changed, what was checked, and what is still open.

Quality assurance / Kit

Check the result.

Verify the sign-up flow against the acceptance checks before release.

Growth / Mira

Prepare the announcement.

Draft the release message. External publication stays behind your approval.

A role is more than a title. Specify what it can decide independently and when it should stop and ask for review.

Define agent rolesPrepare shared context
Step03

Make the next
actions concrete.

Create one project for the milestone. Give each task one owner, a deliverable, and a check that tells you when it is finished.

  1. AG-01

    Define acceptance checks

    Lea writes the release criteria. Done means the sign-up scenario and release boundaries are explicit.

    Start here
  2. AG-02

    Build the release changes

    Rowan implements the agreed flow. The handoff includes a change summary and verification notes.

    After AG-01
  3. AG-03

    Verify the sign-up flow

    Kit tests a new user’s path. A failed check returns to Engineering with a specific issue.

    After AG-02
  4. AG-04

    Publish the launch announcement

    Mira prepares the message. Publication waits for your decision and a completed release check.

    Needs review

Dependencies explain why a task is waiting. Clear handoffs explain what the next owner can safely do. Both are more useful than a long list of unowned activity.

Plan tasks and handoffs
Step04

Review the decision.
Keep the record.

Let routine work move within its boundaries. Review decisions that affect spending, scope, or the outside world.

Decision for you

Publish the release announcement

Review the message, the audience, and the evidence that the release is ready. An approval should cover a specific action.

Try the sample approval
Before acting
Check acceptance results and remaining budget.
If blocked
Pause, narrow the work, or request a new decision.
After the decision
Record the reviewer, approved scope, and resulting task state.

Budgets and approvals are separate controls. Approving an action does not remove its spending limit. A useful history preserves both the permission and the reason work paused.

Understand approval rulesSet budget boundaries

Your first milestone

Start small.
Make the direction clear.

Follow the practical guide