Goals

Projects hold the tasks; goals name the outcomes those tasks are meant to reach. A goal is a desired result for the workspace — ship the new onboarding, cut response time in half — and the tasks doing that work link to it so the why stays attached to the what. Goals sit alongside projects in your setup because a real outcome usually cuts across more than one project's worth of work.

A goal is an outcome that spans projects

A goal is a workspace-level record: it has a title, a description, a target state describing what success looks like, 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. That keeps the connection honest — a task contributes to a goal only when its project is genuinely part of that goal's work. When you create a goal 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.

A goal carries a progress figure, and it is worth being precise about what that is today. The progress percentage is a stored value on the goal, not yet a number Task Machine computes for you from the state of the linked tasks. The intent is for app surfaces to derive progress from linked work, and the model is built for it, but that derivation has not shipped — so treat the figure as one you maintain, not one the system keeps current on its own. Keep the discussion of a goal on its linked tasks, where the real execution history lives, so a goal stays a lens on work rather than a second place to track it.

Coaching helps you write a goal worth pursuing

A goal is only as useful as it is clear, so Task Machine reviews it as you write it. When you create a goal — or open Improve goal from an existing goal's page — assistive coaching reads what you wrote and checks it against the three parts a complete goal needs: a specific, measurable, time-bound title; a description that gives an agent the context and constraints to pursue it well; and a desired state that says, concretely, what is true when the goal is done. A goal that already has all three passes straight through; a thin or vague one comes back as a sharper version you can edit and apply, or set aside to keep what you wrote. The review runs on Task Machine's managed model, so it works before you have connected a machine 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.

A goal has a lead with explicit capabilities

Every goal can name a lead — the member responsible for it — and the lead can be a person or an agent, since both are first-class members. The lead is not just a label: a goal carries a set of explicit capability flags that decide what its lead may do in service of the goal. Those capabilities cover whether the lead can create tasks under the goal, assign members to them, start workflows, delegate to agents, create artifacts, and create memories. Each is off by default, so a lead starts with no special powers and you grant exactly the ones the goal needs.

When that lead is an agent, the goal also carries a pending proposal limit. During the agent lead's heartbeat, Task Machine gives it the goal's target state, progress, linked task activity, and current pending proposal count. The lead can then propose goal-linked tasks or projects with a rationale instead of creating them outright. The default limit is five pending proposals for the goal, and you can tune it on the goal so useful strategy keeps flowing without turning your inbox into a backlog of repeated suggestions.

These capabilities sit on top of the workspace role system, never around it. An agent lead still obeys its agent profile and its workspace role: a goal capability can scope what a lead does for this goal, but it cannot grant an agent permission its profile and role do not already allow. Creating goals, editing them, and configuring lead capabilities all require the goal-management permission, and — as with projects and teams — an agent can propose a goal for a permitted member to approve, from the inbox or the Proposed tab on the goals page where pending proposals gather beside the Active and Archived views.

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.

With projects holding the work and goals naming the outcomes, the last piece of structure is the labels that classify tasks. Continue to labels.