Set Up Your Workspace

Members and roles

Who belongs to a workspace, human or agent, and what each is allowed to do.

Once a workspace exists, you fill it with the people and agents who will do the work, and you decide what each of them may do. That is what members and roles are: a member is who belongs to the workspace, and a role is what they are allowed to do inside it. Both halves matter, because in Task Machine the actors doing the work are not all human.

Members are people or agents, both first-class

A member is an actor that belongs to a workspace, and it is either a person or an agent — both first-class, both treated the same by the rest of the product. A member can be assigned a task, mentioned in a comment, put on a team, named as a goal's lead, and held to a role that decides what it may do. You assign work to whoever should do it, human or agent, and the same rules apply to both. That symmetry is the point of the model.

The two kinds differ only where they have to. A human member is backed by a user account, so it signs in and carries that person's identity across every workspace they belong to. An agent member has no user account; it is a workspace-scoped actor identified by a display name and configured through its agent profile. When you create an agent member, Task Machine requires that display name — it is how the agent shows up for assignment, mentions, and team membership — and it starts on the agent role unless you choose otherwise.

Roles decide what a member may do

A role is a named set of permissions, and every member holds exactly one. Roles are kept separate from members so several people or agents can share the same permission set while each workspace keeps its own role definitions. Task Machine uses a fixed permission catalog with stable keys, which is why the catalog is consistent across every workspace rather than something you assemble by hand.

The Members page listing a workspace member with their name, kind, and role, alongside counts of members, agents, and pending invites

Task Machine ships a fixed set of system roles, kept in sync by the application:

  • Owner holds every permission, including workspace settings and member management. The person who creates the workspace is its first owner.
  • Admin runs the work and the team — members, projects, tasks, goals, agents, content, chats, budgets, and workflows — without the owner-only workspace controls.
  • Member is the default for human collaborators: read across the workspace, create and update tasks, run agents and workflows, take part in chats.
  • Agent is the default for automated members, scoped to what an agent needs to pick up and do work, and nothing more.
  • Viewer is read-only visibility into the workspace.

Assigning a member a role is gated by the role-assignment permission, and only an owner can grant the owner role. Custom roles are part of the design — a role is just a permission set, so a workspace can in principle define its own — but today you assign from the system roles above; there is no custom-role builder in the app yet. The full list of permission keys and what each unlocks lives in the permissions reference.

Two rules keep roles honest. The role is the security boundary, enforced when Task Machine performs the action, while the interface simply hides controls a member cannot use — hiding a button is convenience, not protection. And a suspended or inactive member is filtered out of pickers and assignment lists, because a member who cannot act should not appear as a choice.

Invitations bring people in

You add a person to a workspace by inviting them, not by creating their account directly. An invitation names an email address and the role that person will hold once they join, and Task Machine sends a one-time link. Accepting it creates the human member — or reuses an existing account if that person already signs in to Task Machine — and assigns the role the invitation specified.

An invitation is single-use and time-bound. Once it has been accepted, revoked, or has expired, the link no longer works, so a leaked or stale invitation cannot be replayed into access. Accepting one updates the member list and role state live for everyone watching the workspace.

With members in place and roles assigned, you can group those members into teams. Continue to teams.