Missions¶

A mission is an effort that runs over weeks and needs steering along the way. "Launch the self-serve tier." "Win the comparison against our closest competitor." "Rebuild the outbound sequence."

It is the largest unit in Questo, and it is the one that earns its keep slowly. A mission gives every task inside it a frame, so you stop restating the goal in every prompt, and it gives the daily routines something to plan against.

Two ways in¶

A mission holds two things at once: the pursuit (the direction of the work) and the checkpoints (its milestones: what must be true, and by when).

Which one you start from depends on how you think. Product and content marketers usually start from the pursuit: "rebuild the docs experience". Growth and sales operators usually start from a checkpoint: "trial-to-paid at 15% by June". Both are legitimate ways to open a mission, and Questo will not make you invent the other half before you can save.

If you have a goal but no metric yet, write the goal. If you have a number but have not decided how you will move it, write the number as a milestone. The missing half tends to arrive within a week.

Campaigns and motions¶

There is no field for the type of a mission. There is one dial: whether it has a target date.

A mission with a target date is a campaign. It ends. "Ship the pricing page by 30 September." The date is what the agent measures urgency against, and a mission drifting towards a date it will miss is what a health verdict is for.

A mission without one is a motion. It is always on. "Keep the comparison pages current." Nothing about it is worse for being open-ended, and forcing a fake deadline onto a motion just makes every status report wrong.

The playbook¶

The mission's summary is its one line, so anyone can see what this mission is at a glance. Under the header sits the playbook proper: five sections the agent reads before every plan it writes, and writes back to as the mission moves.

The playbook is the highest-leverage thing on a mission, for the same reason the knowledge base is the highest-leverage thing in the workspace: it is read on every run, so a sentence you sharpen once pays off every morning afterwards.

Two of them deserve a note.

Each part of the strategy binds differently. Target customers and output destinations are fixed: the agent works for those people and ships only to those places, so a place you do not list is out of scope. Example outputs are only examples, so the agent may make something else that serves the objective. Insight sources tell the agent where to look first for this mission's signal; they never stop it noticing signal anywhere else.

Rules here are mission-scoped. A constraint that applies to all your work belongs in a workspace rule instead. "No competitor names in this campaign" is a mission rule. "Never claim we are the market leader" is a workspace rule.

The playbook shows who last wrote it and when, so you can tell your own words from the agent's.

Status¶

A mission is in one of four states.

• Idea is the parked state. It is written down and it is not being worked.
• Active means the daily routines plan against it.
• Paused means stop planning it, keep everything.
• Completed means it is finished.

Only active missions get daily planning. This is the control worth reaching for when your inbox is noisy: a workspace with nine active missions produces plans for nine missions every morning, and no one has nine priorities.

Intensity¶

Intensity says how hard the daily planner pushes a given mission. It has three settings and the default is Auto, which is not the middle of a scale but the absence of an override: plan at whatever pace the mission's own strategy, milestones and target date imply.

Min is reactive only. Plan when something happens, otherwise leave it alone. Good for a mission you want tracked but not driven.

Max searches wider for signal and plans more boldly against the roadmap. Good for the one mission this quarter that actually matters.

Intensity is not a task quota and not a cadence. It does not promise you three tasks a day at Max and one at Min.

Stages¶

A mission carries the funnel stages it touches: awareness, acquisition, conversion, activation, retention, monetization, operations.

A mission can carry several, because real work rarely sits in one. The agent picks them when it creates a mission, and you can change them any time. This is labelling for you, so the missions list is scannable; it changes nothing about how the mission runs.

Milestones¶

A milestone is a checkpoint on the way: the state that will be true, not the work that produces it. "Pricing page live", not "Write the pricing page"; the second one is a task.

A mission can have as many milestones as it needs, and none is a valid answer: an always-on mission like a changelog may never have one. Give a milestone a date only when the date is a commitment. An undated milestone is fine.

A number you want to hit is a milestone too: "Trial-to-paid at 15%". Add, rename, date and delete milestones from the mission page, or ask the agent to.

Milestones are updated, not versioned¶

This trips people up, so it is worth being precise.

The milestone itself is a spec, and you edit it in place. Fixing a typo in "Sign 3 desing partners" does not create a second milestone.

The milestone updates are the history. Each weekday morning the planning routine writes a one-line update on each pending milestone ("blocked on legal review", "on track, ships Friday"), and earlier ones are never overwritten. Open a milestone's options on the mission page to read them. That series is the mission's actual progress, and it is what a health verdict reads.

So: one milestone, many updates over time. If you want to change what you are checking rather than record where it stands, edit the milestone, and the old updates will sit under a slightly different question. That is usually fine. If the change is fundamental, delete the milestone, which deletes its updates too, and add a new one.

A milestone is marked completed when it is true. The agent marks one only when what it has read proves it landed, never on intent, and you can mark one yourself. The agent never moves a date to hide a slip: a pending milestone past its date is exactly what turns a verdict to at risk or off track. When nothing has shown whether a milestone landed, the insight request routine asks you directly, because a milestone nobody has checked is the one thing that blinds the planner.

The roadmap¶

A roadmap is optional. A week gets an entry only when it changes what the daily plan would otherwise do: a launch week, a holiday, a milestone falling due. A mission that ships on its cadence, or acts only when signal hands it something, may never need one. A week that says otherwise overrides the cadence for that week: "No changelog this week, holidays." The new-mission form offers this week as a row to fill; remove it if the week needs nothing special.

A roadmap week is a short block of intent: what that week is for, why, and what it deliberately excludes. It is not a task list. Work specific enough to execute is a task; the roadmap is where work that is not yet concrete enough to be a task waits.

Weeks are sparse. A week nobody has planned simply has no entry, and that is not a gap to fill for tidiness. Near weeks should be specific and far weeks can be a line or two, because the detail genuinely does arrive as the week approaches. Writing week nine in full detail today is work you will throw away.

When a mission has weeks, they stop each morning's plan from being invented from scratch: the planner reads this week's focus before it proposes anything.

When reality breaks the roadmap, and it will, the agent rewrites the affected weeks before planning against them. A slipped launch, a dead bet, a blocked dependency: these move the plan rather than being planned around.

Extending the roadmap is a separate job from repairing it. Every week, right after the weekly report, the roadmap review looks at the next four weeks of each active mission and writes a week only where it would change the plan, so a mission that runs on its cadence often gets nothing. The daily planner only ever fixes a week that broke; it never plans further ahead on its own.

How a mission iterates¶

This is the part that runs without you. Over one day, on an active mission, with the default routines on:

Start of the week. Before Monday's planning, the roadmap review looks at each active mission's next four weeks and writes a week only where it changes the plan: a launch week, a holiday, a slip to absorb. It posts no card: click Updated on the mission's Playbook to see what it changed, alongside every other playbook edit, and revert any of it.

Late afternoon. The extractor reads your connected tools and captures what bears on this mission as insights. Then the insight request routine looks for what it still cannot know: whether a milestone landed when nothing has shown it, a decision only you can make. It asks up to three questions per mission, in one inbox card, each with a reason for asking. Your one-line answers become insights too.

Next morning. The planning routine first writes a diagnosis for each active mission: what changed, where the milestones stand now, and a health verdict of on track, at risk, off track or no signal. It reads the update sequence, not just today, so the verdict is about trajectory rather than a single day. The diagnosis only observes; it proposes nothing.

Then, in the same run. The planning routine takes that diagnosis, this week's roadmap focus, what the cadence makes due and the tasks in flight, and proposes one day plan per active mission: the handful of tasks worth doing, each with a one-line rationale saying what it advances. It arrives in your inbox as one card, together with the diagnosis it was built on. A mission with nothing worth doing that day gets no card.

You decide. Approve the tasks worth doing, reject the rest. Approving turns them into real tasks and the plan goes live.

Sunday. The weekly report recaps what actually happened, in the past tense, per mission. It proposes nothing. You read it and clear it.

The chain is ordered, not just scheduled: the plan is built on the diagnosis written just before it, and the insight request waits for the extractor. Each stage is reading what the one before it wrote.

Day plans¶

A day plan is one mission's gameplan for one day, and it persists rather than evaporating once you have read it: the mission's Plans tab keeps each day's plan.

Its spine is the morning's diagnosis. The card shows the mission update written just before the plan, and every task carries a rationale saying what it advances (a milestone, this week's focus, a cadence slot) with the insights it rests on, so you can check the reasoning before you approve.

While the card is open, you can reshape the plan by talking to the agent: drop a task, add one, change one. Mark the tasks you do not want and approve the rest; a follow-up run then drafts each task's prompt and schedule. Once approved, the plan is settled for that day, and its tasks are ordinary tasks you change like any other.

There is one live plan per mission per day. Rejecting a plan discards it and creates no tasks. A card can also carry up to three questions whose answers would change which tasks belong in it, and a card still open from an earlier day closes when the next day's plan lands.

Mission updates¶

The updates on a mission are its narrative history: short status notes, written each weekday morning, each carrying a health verdict and the milestone updates written with it.

Read as a sequence, they answer the question a status meeting exists to answer. Not "what did we do", which is what the tasks list already tells you, but "is this working". A mission that has been at risk for nine days in a row is a mission whose strategy is wrong, and you can see that in the sequence long before a milestone misses its date.

You can write one yourself whenever you have something the agent could not observe.

When a mission ends¶

Set it to completed. Nothing is deleted, the tasks and outputs stay where they are, and the mission stops consuming a slot in tomorrow's planning.

Deleting a mission is a different act, and it keeps your work: its tasks and their outputs survive, detached from the mission. You lose the frame, not the deliverables.