Goals
A is an outcome you want to make happen, written down with how you’ll know it happened. You shape a small plan of steps, choose when each step runs, and review what comes back. Agents do the work in your workspaces; you decide when the goal is achieved.
Open Goals from the sidebar. Home also shows a short summary of your active goals.
Goals belong to your account, not to one workspace. A goal can exist before any workspace does, and one goal can draw on up to 20 workspaces.
Shaping a goal
Choose + New goal, describe what you’d like to make happen under Your intention, and choose Draft a starting plan . YOLO Assistant drafts a first plan; if it needs one detail first, it asks a single question. Where the assistant isn’t available, choose Start with editable steps instead to begin from a template.
The draft opens as Here’s a way forward. From there you can:
- Edit steps, or ask the assistant to ✧ Make this smaller.
- Set a check-in rhythm and the goal’s repository.
- Open Edit goal details for success checks and to connect existing workspaces.
- Open Talk it through to refine the draft with the assistant.
Choose Use this plan → to save. Saving sets the direction and the check-in rhythm; it does not start any work. Close and keep draft saves the draft to your account so you can resume it later.
YOLO Assistant can also create or revise a goal from the command bar. It always shows a confirmation card first, and success checks and the repository are set on the Goals page, not by the assistant.
What a goal holds
| Field | What it’s for |
|---|---|
| Goal name | A short title (up to 160 characters). |
| Desired outcome | What you want to make happen. |
| Why it matters | Optional context for you and for the agents doing the work. |
| What success looks like | A description of the finished state. |
| Constraints and boundaries | Limits the work must respect. Shown as Boundaries. |
| Open questions | What you still need to learn. Shown as Still to learn. |
| Success checks | Up to 12 checks that decide whether the goal is achieved (below). |
| Repository | The goal’s primary repo (GitHub, GitLab or Internal Git). |
Success checks
A success check is either A result I can review (a judgement you make from evidence) or A numeric measurement with an optional starting value, a target, a unit, and whether the number should Increase or Decrease.
Each check also has a freshness window (Check freshness after (days), 30 by default). Evidence older than that no longer counts toward the check. Once a check has evidence recorded against it, its type and unit can’t be changed.
The plan
A plan is up to 20 steps. Each step has:
- a title and What to prepare — the instructions the agent receives,
- A useful output means… — the acceptance criteria,
- an output type: Report (findings you review) or Code change (commits in the work home’s repo, landed through a PR),
- optionally, the steps it depends on and the workspace it runs in.
A step that has been queued keeps the instructions it was queued with. For follow-up work, add a new step.
Work homes
A step runs in a work home: the workspace chosen for that step, or the goal’s default work home. Under Work homes on the Overview tab you can add a work home, make one the default, or clear the default. When you choose a work home for a step you can Use a workspace I have or Launch a new one, starting it from the goal’s repo, empty, from one of your repos, or as a copy of a public Studio git repo. A new workspace uses one of your workspace slots.
Queuing a step
Nothing runs until you queue it. When a step is ready — every step it depends on has succeeded — choose Review queue handoff. The handoff shows the step, its useful output, where it will run, the work home’s landing mode, and whether that workspace’s Background Runner is running.
- Queue and start work adds the step as a in the Ready column of the work home’s Runner board and starts the Runner in drain-once mode, so it stops once the queue is empty.
- Queue only adds the card and leaves the Runner as it is.
If the work home has no board yet, one is created and connected to the Runner. Dependencies between steps in the same work home become card dependencies. A step that depends on work in another workspace waits until that step has succeeded and its output is retained.
Code steps land under the work home’s landing mode (After success in the Runner settings). A code step counts as succeeded for the steps after it only once its commit has landed.
Step states
A step’s state follows its card; you don’t set it by hand.
| State | Means |
|---|---|
| Ready to queue | Every step it depends on has succeeded. |
| Blocked | It is waiting on another step. |
| Queued / Running | The card is waiting in the Ready column, or an agent is working on it. |
| Awaiting merge | A code step finished, and its commit hasn’t landed yet. |
| Succeeded / Failed | The attempt finished. A cancelled attempt counts as failed. |
| Needs attention | The agent reported it is blocked and needs you. |
| Deferred | You set the step aside; steps waiting on it are deferred too. |
A failed step offers Retry or Change work home & retry; earlier attempts stay listed under the step. Defer sets a step aside and Resume brings it back. To attach work that already exists, use Link existing work on the Plan tab.
Results and review
Everything that might show progress is recorded as evidence and waits for your review:
- Agent results. An agent working on a step records its result with the goal tools. You get an Inbox message, Review a result for the goal, and the goal shows how many results are ready for review.
- Your own observations. + Record evidence lets you note what you found, which success check it relates to, and a value for numeric checks.
- Workspace outputs. Keep workspace output retains an exact version of an output from a connected workspace, so it stays available with your goal.
- Failed attempts are recorded automatically so you can see what happened.
Open a result to review it. Choose Accept as useful evidence or Does not support this goal, pick the success check it counts toward, and write a review note. For a step’s latest finished attempt on an active goal, Send back with guidance queues the step again with your guidance and marks that result as not accepted.
Numbers an agent reports are suggestions. A measurement counts toward a numeric check only when you accept it with a value.
Achieving a goal
Finishing work never marks a goal achieved — only you can, from the ⋯ menu with Mark achieved. The goal must have:
- at least one accepted result,
- accepted evidence for every success check that is still within its freshness window,
- for every numeric check, a target that the latest accepted value meets.
If any of these is missing, the dialog tells you which check needs evidence.
Check-ins and next moves
A goal’s check-in rhythm can be Weekly, Every two weeks, Monthly, a single date, or Only when I ask. When a check-in comes due, the assistant prepares a proposed next move. Missed check-ins are not caught up; the next one is simply scheduled. Use Check in now → or Find the next move → to ask for one yourself.
A proposed next move offers Apply proposed plan, Keep current plan or Dismiss. Applying it changes the plan only; you still queue each step yourself.
Goal status
A goal is Active, Paused, Achieved or Archived. The ⋯ menu offers:
| Current status | Options |
|---|---|
| Active | Mark achieved, Pause goal, Archive |
| Paused | Resume goal, Archive |
| Achieved | Reopen goal, Archive |
| Archived | Reopen goal |
Every change except archiving asks for a note. Pausing or archiving stops new goal work; cards already queued or running continue under their workspace’s controls. Only an active goal can queue, start or retry steps. You can edit a paused goal’s plan, but an achieved or archived goal must be reopened first.
Agents and goals
An agent working in a workspace linked to a goal can use the goal tools (see Workspace MCP Server):
- read the goal and the step its card is working on,
- record a result or observation, which waits for your review,
- report progress on its step: working, blocked or done. A blocked report also sends you an Inbox message.
- archive the goal, when you asked for that.
Agents can’t change the plan, set a step’s state, or mark a goal achieved, and they can only see goals linked to their own workspace. Their results and progress reports are accepted only while the goal is active.
Related pages
- Background Runner — runs queued steps as Kanban cards
- YOLO Assistant — drafts plans and proposes next moves
- Concepts — cards, outcomes and dependencies
- Inbox notifications — where result and blocked messages arrive