Projects, goals and routines
Projects
Section titled “Projects”A project groups tasks toward a deliverable and holds the places the work happens. Each repository you connect becomes a project with that repository as its workspace: the agents check it out, work on a branch of it, and open pull requests against it. A project can hold more than one repository; one is primary, and that is where an agent starts for a task in that project.
Project status: planned, in_progress, done, cancelled.
Goals are the why. They form a hierarchy: company goals, team goals, an agent’s goals. A task carries its goal and its ancestors’ goals, so an agent always sees why a task exists, not only its title. Goal status: planned, active, achieved, cancelled.
The company’s mission is written into the workspace at setup: the repositories, the site, the tracker, the channel, the team and its rules.
Routines
Section titled “Routines”A routine is recurring work: a title, an assignee, a project, and one or more triggers. Each firing creates a task and wakes the assignee. Triggers:
- Schedule: a cron expression in a timezone. The visibility team’s weekly review runs this way.
- Webhook: an inbound call to a generated address.
- API: a call by an agent or a person.
If a routine fires while its previous run is still going, the default is to fold the new firing into the running one; a routine can instead skip it, or always start another. Missed firings are skipped by default. Routine definitions are revisioned and can be restored. Routine status: active, paused, archived.
Execution workspaces
Section titled “Execution workspaces”An agent does not work in the repository itself. Each run gets an isolated checkout on a branch of its own, named for the task, and the branch is where the pull request comes from. Follow-up tasks can inherit the same checkout so a piece of work stays on one branch. Runtime services, a dev server, a preview, can be started from a workspace and show up as work products with their addresses.
Secrets and environments
Section titled “Secrets and environments”Credentials the team needs, a deploy key, an API token, live sealed in the workspace’s secret store and reach a run only as bound environment variables, or on demand, and only for the agents bound to them. Values never appear in prompts, comments or documents; every read is recorded. What you connected at setup, GitHub, Linear, Jira, Slack, is delivered this way.
An environment is a named set of such bindings and settings an agent runs in; an agent has a default environment.
Pipelines
Section titled “Pipelines”For work that moves through fixed stages, a release through coverage, a piece of content through drafting, review and publishing, the workspace has pipelines: named stages of kinds open, review, done, cancelled, with rules for what moves a case forward and who may approve it. Tandem’s teams do not use pipelines out of the box; they are there when a process needs stages.