Goals

A goal names the outcome you want, such as shipping new onboarding or cutting response time in half. Give it an agent lead and the numbers it depends on, and the goal keeps watching the work for you, so you decide what to do instead of asking how it is going.

This page covers what a goal is, how its lead reviews it, and how goals, projects, teams and their leads work together. Everything an agent proposes along the way arrives in your Inbox, because you stay the one who decides.

A goal names an outcome that spans projects

Link the tasks that contribute to a goal when you need to coordinate work across projects, rather than creating a goal for every individual job.

A goal is a workspace-level record: it has a Title, a unified Description containing context and success criteria, a status, a due date, and a set of linked tasks.

Because outcomes rarely live inside one project, a goal can be assigned to several projects at once, and a task can only link to a goal that is assigned to the task's project. A task contributes only when its project is part of the goal's work.

When you create a goal, on the Goals page or from a project's Manage goals dialog, you can pick the existing projects it spans and also name new ones to create on the spot, so a goal that needs a fresh workstream does not send you off to set the project up first.

After a goal is created, the same optional Generate playbook offer appears. Its install form asks which project the playbook installs into. Search for a project, or, when it does not exist yet and you may create projects, type its name and choose Create project. The usual create form opens above with the name filled in, and the project you create is the one the playbook installs into. Closing the create form creates nothing and keeps your design.

For an existing goal that is not archived, choose Generate playbook from its … menu on the Goals list in Settings. The same option appears on desktop and phone when your role allows you to manage goals and install playbooks, generation is available, and you have a project to install into.

Use Chat to discuss the direction and the linked tasks to steer specific work. Creating a goal names the outcome, but does not by itself start agent execution.

An agent lead reviews its goal on its own

An Agent that leads a goal reviews it on its own, without you assigning a Task. The review checks whether the work in the goal's projects can still reach the outcome, proposes what is missing for your approval, and asks you only for a decision that is yours. It runs fifteen minutes after the goal or its linked Tasks change, and on the goal's Frequency when nothing does. Set the Frequency in the Lead section of the goal's Settings, which shows it while an agent leads the goal: describe the schedule in plain words, such as "every Monday at 9", and pick its timezone.

New goals check twice a day by default, and you can choose a more frequent schedule. Changes to the work, the goal or its numbers wake the lead sooner whatever you choose. After a successful review, the next scheduled check is the next occurrence of your chosen schedule.

A goal led by a person, or by nobody, is not reviewed automatically.

A goal can also follow metrics, the numbers its outcome depends on. Choose them when you create or edit a goal. The lead then sees each metric's latest value, trend and whether it is still being collected, and a new value that differs from the one before it prompts a review. A metric that has not been collected, or whose collection failed, is unknown to the lead, never zero. Linking gives the lead no access of its own: it needs permission to read metrics itself. The goal's Metrics tab appears once a metric is linked, and a metric's page lists the goals it informs. For each followed metric you can also set an optional target value, in the metric's own unit, and an optional target date, in the same form. Both are optional and independent, and a metric that serves several goals can have a different target in each, because the target belongs to the goal's link to the metric, not to the metric. The lead sees the target and date next to the metric's recent values. A target records what you aim for: the goal's description still defines success, and a number never completes a goal by itself.

Reviews use the lead's configured Worker and count toward the goal's, the lead's and the workspace's budgets. Failed reviews retry on their own, and Inbox shows Check-in failed from the third failure in a row.

The goal's Runs tab lists every review its lead has performed, newest first, with its status, what it found and the model it used. It appears once the first review exists and keeps the whole history when you change the lead. Open a review to read its transcript. That needs Task read access as well as Goal access, because a review quotes Task content. A reply to one of the lead's updates also wakes it for its next review.

In Settings, open Goals and choose Edit goal from a goal's … menu to review its outcome and configuration. Choose the Tasks tab to open the main Tasks page with that Goal filter selected. This shows Tasks linked to the Goal, not every Task in its assigned Projects. The tab requires Task read access. Reading or leading a Goal does not grant it.

Goals, projects, teams and leads work together

A goal says what you want. A project holds the Tasks that get it done, and a team holds the people and agents who handle a queue of work. Each can have a lead, and the leads look at the same work from different angles, so the gaps get noticed before you have to go looking for them.

Each lead works inside its own boundary. A goal lead cares about the result across projects. A project lead cares about how the project's Tasks are delivered, and a team lead cares about who picks up the next piece of queued work. A team check-in only triages the queue, so strategy stays with the goal lead.

flowchart TD
  Metrics[Metrics the goal follows] --> GoalLead[Goal lead reviews the outcome]
  GoalLead -->|assigned to| Projects[Projects hold the Tasks]
  ProjectLead[Project lead reviews Tasks and goals] --> Projects
  Projects -->|Backlog work| Queue[Team queue]
  TeamLead[Team lead triages and routes] --> Queue
  GoalLead -->|proposals| Inbox[Your Inbox]
  ProjectLead -->|proposals and goal conflicts| Inbox
  TeamLead -->|routing decisions| Inbox

Here is how a goal moves work in practice:

1. You name the outcome as a goal and assign it to the projects it spans. If it follows metrics, the numbers start to inform its lead.
2. The goal lead reviews on its own when the goal, its linked Tasks or a metric changes, and on its Frequency. It proposes the Tasks or Projects that are missing.
3. A project lead keeps its project moving. When several goals direct one project and pull in different directions, the lead does not pick a side. It asks the people who manage the project to decide, and a newly saved Task plan also gets a Project lead check against those goals.
4. Backlog work reaches a team's queue, where the team lead recommends who handles it. A Backlog Task with no team is triaged by its project's lead, who prefers handing it to a team.
5. Every proposal, question and conflict lands in your Inbox. How much an agent lead may do without asking you follows its autonomy and workspace role, because the lead role adds no permissions of its own.

A person can lead any of the three, and only agent leads review automatically. A goal or project led by a person, or by nobody, has no automatic review, so you keep the same structure and decide how much to hand to agents.

A goal has a lead, a person or an agent

Every goal can name a lead, the person or agent responsible for it. In the Goal's Settings tab, the Lead section holds that choice. Choose the lead and, for an agent lead, the Frequency of its scheduled check (the ? explains it), then Save them together, independently of Goal details and Autonomy. The Lead list works as it does for a project, in Settings and in the Create goal dialog, so you can type a new agent's name and choose Create agent without leaving the form.

The lead role adds no permissions of its own. What an agent lead may do directly, and what it can only propose, follows its agent profile autonomy and its workspace role, as it does for every agent. An agent that leads a goal can also keep that goal's memory up to date directly, the way a Team lead does for its Team.

If you can read the Goal but cannot manage it, Settings keeps the saved values in read-only fields. Save buttons, Improve goal, and archive or restore actions are hidden.

An agent with proposal permission can suggest Tasks or Projects for an active, approved Goal without being its lead. Goal-linked Task and Project proposals have no pending-count limit. The agent's permissions and effective autonomy still determine whether its proposal waits for review in the Inbox or applies directly.

When the same agent repeats a pending suggestion with the same Task title or Project name for the same Goal from the same Chat, Task, Goal run or Team check-in, Task Machine reuses that proposal. Matching work from a different source creates a separate proposal, keeping each source's intent and history.

Naming an agent as Goal lead schedules the goal's own review: it runs fifteen minutes after the goal or its work change and on the goal's Frequency, as described above. A Team check-in only triages the Team's queue, so an agent that leads both a goal and a Team reviews the goal once, not once for every Team it leads.

An agent lead remains subject to its agent profile and workspace role. Human goal creation and editing require goal-management permission. An agent can propose a goal. When its effective approval settings require review, the proposal waits in the inbox and the Proposed tab beside the Active and Archived views.

Otherwise, the permitted proposal applies directly.

The Goals page shows where each goal stands

Goals sits in the sidebar right after Tasks for everyone who can read goals. It opens a list of your active goals, then your completed ones, and within each group the goal changed most recently comes first. Each goal shows its lead (or Unassigned), due date and status. When agents have proposed Tasks or Projects for a goal and nobody has decided yet, a waiting badge sits next to its status. Hover it, focus it with the keyboard or tap it to see how many Task and Project proposals wait and how long the oldest has waited. The list loads 25 goals at a time as you scroll. If you can manage goals, Create goal at the top right, here and on every goal page, opens the same create dialog as Settings, and closing it after creating a goal opens that goal's page.

Above the list, one tab per active goal lets you jump between goals. The tabs hold up to eight goals: your most recently changed active goals and the goal you have open. A long title is cut with its full text on hover. The list always shows every active and completed goal.

Open a goal to see its outcome, an Activity history and a side column. Activity lists the goal's lead updates and applied changes to it, newest first. A lead update is a report from the agent that leads the goal or one of its projects. It is a post you read in full, with its related work and a comment thread under it, and you reply to it right there. When it asks you something, the same question also arrives in your Inbox, and answering in either place answers it once for everyone. A report that only informs shows up in your Inbox as a notice you can reply to or dismiss. Every other entry shows who changed the goal, when, and what changed, such as the title (with removed and added words marked), the due date, the lead, the autonomy level, the projects it spans and the metrics it follows. A proposed change appears only after approval, at the time it was approved. The side column shows the latest value and trend of up to five active metrics it follows (a metric without a value yet shows a dash and a flat line, and paused or archived metrics stay off the card), and each project's finished Tasks against its counted Tasks. Open Metrics at the top right of the Metrics card opens all of the goal's metrics, and Open Tasks on the Projects card opens the Tasks page filtered to the goal.

When proposals are waiting, a bar at the top of the goal says so and Review proposals opens your Inbox on its Proposals tab, already filtered to that goal. The settings button at the top right opens the goal's Settings, Metrics, Budget, Memories and Runs pages, whichever you may open. Archiving and configuring goals stays under Settings, then Goals, where you can create goals too.

Coaching helps you write a goal worth pursuing

A goal is only as useful as it is clear, so Task Machine guides the Description before reviewing it. The form asks you to mention why the outcome matters, the current situation or process, inputs and destinations, constraints, dependencies, judgment points, and a measurable definition of success.

When available, coaching on creation or through Improve goal checks the two fields a complete Goal needs: a specific, measurable Title and a substantive Description with concrete success criteria. A timeframe is optional, and coaching preserves one you provide instead of inventing one.

A thin or vague goal comes back with editable suggestions for the complete Title and Description. On creation, you can apply those edits or create the original. A strong result still asks you to confirm, and an unavailable review lets you retry or create the original. Ordinary goal Settings saves apply directly.

Improve goal is optional and leaves the current goal unchanged until you apply the edited suggestion. The review runs on Task Machine's managed model, so it works before you have connected a computer of your own.

Agents are held to the same bar: when one proposes a goal for your approval, it is asked for the same complete, specific shape rather than a one-line placeholder.

Goals show up where work needs context

A goal earns its place by appearing wherever someone needs to understand why a piece of work exists: on task detail and task cards, in project views, in search, and in workflow context. The aim is for a goal surface to explain the outcome and where it stands, not to become a parallel task system.

The tasks remain the unit of execution, and the goal is the thread that ties them to a result.

Getting started shows how guided setup shapes the first job before you approve it. Task specs covers later planning and review, and Constitution covers policy admission. Use Labels when the Tasks contributing to an outcome need a shared vocabulary.