Teams, projects, boards, and cards
Understand where work, access, priorities, and results live in Delegate.
Log in or sign up to make these docs interactive
Choose your team, project, or agent to turn guidance into links to the exact place in your workspace.
Delegate organizes work from durable ownership down to a specific delegated outcome. Each level answers a different question.
Select a project above and open its board to see this hierarchy in the product.
Teams own the operating environment
A team is the durable boundary for people, agents, roles, shared content, provider connections, security policy, and billing. Create separate teams when those things need genuinely separate ownership or governance, not merely to sort a list of projects.
Team roles define broad access. Project-scoped membership can narrow where a person participates. Agents also belong to the team and can be made available only where their job is relevant.
Projects hold related outcomes
A project gives a body of work a purpose, participants, description, resources, and budget boundary. It is usually durable enough to contain multiple milestones but focused enough that its board tells one coherent story.
The project description gives agents project-specific context. Keep an agent's durable professional methods in its own instructions; keep goals, stakeholders, conventions, and constraints that apply only here in the project.
Boards make flow visible
A project's board groups work into epics, which act as visible work streams or rows. Each epic has its own columns, so a team can express the stages that fit that stream. The backlog holds work that is known but not yet scheduled, and sprints provide a time-bound view when the team works that way.
Project card execution can be serial or parallel. In serial work, sequence is part of the plan. In parallel work, independent cards can progress together. Explicit dependencies still block a card until its prerequisite is complete; parallel does not mean “ignore order.”
Cards are the unit of delegation
A card is a bounded outcome that a person or agent can own. It can include:
- a title and milestone description;
- a checklist of tasks and links to dependencies;
- labels, people, and agents;
- attachments and linked team-drive files;
- comments, activity, and one or more agent runs;
- resulting files, evidence, and cost.
Put information on the card when someone needs it to understand, perform, or review that outcome. If a discussion changes the finish line, update the card instead of leaving the decision buried in chat.
A simple example
A “Spring launch” project might have epics for website, customer communications, and support readiness. “Publish launch FAQ” is one card in the communications epic. It depends on “Approve pricing,” links the current product brief, and asks a writing agent to produce a reviewed wiki page. The board shows its state; the card explains and records the work.
Choose the smallest useful structure
Do not model every action as a project or every sentence as a card. Use a team for shared governance, a project for a coherent body of work, an epic for a visible stream, and a card when an outcome needs ownership, context, or a record.