Projects

A project groups related tasks and gives each a readable identifier. Use the project your setup or playbook already created, and add another when a separate stream of work needs its own context, labels, or delivery rules.

A project groups related work

A project holds the tasks that belong together, along with the labels that classify them, the board states they move through, and the goals assigned to it. Each project carries a short uppercase prefix, such as OPS or WEB, chosen at creation. Tasks use that prefix in their readable identifiers.

The prefix is unique within the workspace, so identifiers never collide across projects.

Goals are not owned by a single project. A goal is a workspace-level outcome that can span several projects, and projects and goals are linked through explicit assignments. A task may only attach to a goal that is assigned to that task's project. Goals covers that relationship from the other side.

Open a project to review its Tasks, Runs, Settings, Labels, Memories, Budget, and Intake when your permissions allow. Runs appears once the project's lead has reviewed it. Choose the Tasks tab to open the main Tasks page with that Project filter already selected. Projects do not keep a separate Task list, so List and Board use the same filters and current Task information wherever you start.

The Labels tab is where the project's native vocabulary moves through Active, Proposed, and Archived states. Agent proposals and their approval context live there as well as in your Inbox, while archived projects keep the page read-only. If you can read a Project but cannot manage it, Settings keeps its saved details, linked goals, Git, and Autonomy values in locked fields, without Save buttons or archive and restore actions.

Define the work that belongs here

Create a project with a recognizable Name, a short Prefix, and a Description explaining its scope. The prefix is suggested from the name and remains editable before creation. Describe what agents should include, the context they need, and any exclusions you have already decided.

When coaching is available, Create project reviews only the Name and Description. A weak brief returns editable suggestions for those fields. You can apply your edited version or choose Create original. A strong result still waits for confirmation, and an unavailable review lets you retry or create the original.

Coaching does not change your prefix or autonomy settings. When the Project uses Workspace default and its brief clearly points to source work, coaching may suggest one matching repository that already exists. If none matches, it can recommend choosing or creating one instead. The suggestion is advisory: review the rationale and repository choice before accepting it. Coaching never creates a repository on its own or turns source access into a requirement.

After creation, an optional Generate playbook offer can help turn that project into an operating setup. The project already exists at this point. Closing the offer keeps it, and generating a design does not install it until you confirm the installation.

For an existing project, ordinary Settings saves apply directly. Improve project is the separate, optional coaching action: review and edit its suggested Name and Description before applying them, or keep the current version. Coaching uses Task Machine's managed model and needs no Local Worker. Getting started explains the separate guided conversation that prepares your first job. Task specs explains planning and review after work exists, while Constitution explains the separate policy-admission boundary.

Repository defaults apply to new tasks

The Project's Repository picker controls what new Tasks receive when they use Project default:

• No repository required: keep the work repository-free.
• Workspace default: inherit the Workspace's selected repository, when one exists.
• A specific repository: use that repository for the Project.

A manager can remove the Workspace default from Repositories. New Tasks using the inherited default can then remain repository-free until another default is selected.

In Project Settings or a coaching recommendation, an authorized manager can search the picker and choose Create repository without leaving the page. The shared setup first creates the repository, then shows the SSH public key to add at the Git provider. From Project Settings, the new repository is selected in the Git form but does not change the Project yet. Review the other Git setting and choose Save to apply the association.

The separate Require pull requests switch controls delivery without changing repository selection. It applies to all of the Project's repository-backed Tasks, including existing Tasks.

The Require human review of pull requests switch is on by default. While it is on, a person decides every pull request in the Project. Turn it off to let low-risk pull requests of an agent with Automatic Merging pull requests be approved without an Inbox item, as Pull requests and delivery explains. Only people with project-management permission can change it, and agents cannot change it by proposal.

A task can still choose No repository required, Project default, or another repository. Repository-free work has no pull-request gate, even when the project switch is on. When the switch is off, agents may still link a pull request as optional delivery evidence.

Recurring task occurrences preserve their template's repository choice, while workflow-created tasks use the workflow repository when configured and otherwise use the project default.

Archiving keeps the history

When a project is done, you archive it rather than delete it. An archived project stops appearing as an active destination for new work, but every task, comment, label, and timeline entry it held stays available for review, and you can restore the project if work resumes.

Creating and archiving projects, like editing their details, requires the project-management permission. Members with only read access can see projects and their work but not change them. An agent can propose a project.

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.

A project can have a lead

Every project can name a lead, the person or agent who coordinates how its Tasks are delivered. Choose the lead in the project's Settings, under Lead, and clear it to leave the project without one. The Lead list shows people and agents 25 at a time and searches everyone in the workspace as you type. When the name you type matches nobody and you may manage agents, choose Create agent: the usual create form opens above with the name filled in, and the agent you create becomes the lead you are choosing until you Save. Closing the form creates nothing and keeps your choice. A person cannot be created this way, because people are invited.

An Agent that leads a project reviews it on its own, the same way a goal lead reviews its goal. The review looks at the project's Tasks, at the goals that direct it, and at what changed since last time, and it proposes what is missing for your approval. It runs fifteen minutes after the project, its Tasks or a goal that directs it change, and on the project's Frequency when nothing does. Set the Frequency in the Lead section of the project's Settings, which shows it while an agent leads the project: describe the schedule in plain words, such as "every weekday at 9", and pick its timezone.

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

When several goals direct one project and pull in different directions, the lead does not choose between them. It reports the conflict for a person to decide. A project led by a person, or with no lead, has no automatic review.

Several goals can direct one project, and they can pull in different directions. When two or more active goals conflict, the lead does not pick a side. It asks the people who manage the project to decide, and shows each goal's direction next to its own recommendation. Choose Follow or Ignore for every goal and press Apply to settle it, Discuss to start a chat with the lead first, or Dismiss to leave it as it is. You can add a short note for the lead, which it reads as context in its next review. Your choice replaces the project's one always-on direction note in Memories, so every agent starting work in the project receives it. It names the goals followed and ignored, the reason, date and who decided. Long names keep their beginning and ending, and reasons shorten before any goal is left out. The direction is the default, and a concrete decision may differ. Earlier choices remain in history and the lead sees a few as examples, not binding rules. Archive the current note to withdraw the direction. A direction agreed in Discuss uses the same note after its normal review. Applying the original Inbox decision later replaces it again. Changes to an approved task plan still belong in its Amendments tab. How the lead asks is its Resolving conflicting Goal direction setting in Autonomy: Ask first by default, or Automatic, where the lead saves its own recommendation and tells you in the Inbox what it decided for each goal.

When the Project has at least two active Goals, a newly saved Task plan also starts a short Project lead check. This is separate from the scheduled Project review. It checks the plan against the Goals and the Project's living direction note, and skips without blocking when the lead cannot answer within five minutes. When it finds a conflict, decide in Inbox or in the Conflicts tab in the Plan modal for that revision.

The project's Runs tab lists the reviews its lead has performed in the same way, newest first and with the same transcript access, and it keeps the history when the lead changes.

Agents working on a Task can also ask a project's lead directly. Passing a project, goal or team to --assignee of tama tasks question or tama tasks approval sends the question to that lead. If nobody leads it, the request fails instead of going to someone else.

Goals give projects their direction

Projects organize Tasks. A goal names the outcome those Tasks should achieve, can span several projects, and can have its own lead that reviews whether the work can still reach it. See Goals for the outcome side, and for how goals, projects, teams and their leads work together.