#Concepts

Labor0 keeps organization scope, project work, agent execution, QA, and review paths explicit.

#Scope model

Labor0 uses tenant, workspace, and project scope to keep ownership, authorization, and usage attribution clear. Enterprise is an optional parent layer for customers that manage multiple tenants.

• Enterprise groups one or more tenants for inherited administration, billing, policy, and support overlays. A tenant can exist without an enterprise.
• Tenant is the required organization boundary. It owns workspace membership, user groups, and the top-level billing relationship unless an enterprise billing owner is used.
• Workspace is the day-to-day operating scope for teams. Workspaces hold membership, runtime policy, budget enforcement, usage attribution, and MCP endpoint setup.
• Project is a workspace-owned work target. Projects keep repository-scoped engineering work, usage, audit history, and pull request handoff attributable inside the selected workspace.

Public docs summarize these words for readers. Canonical ownership and lifecycle contracts remain internal platform contracts, so public pages do not mirror raw service contracts or private admin procedures.

#Membership and invitations

Memberships give people access at enterprise, tenant, or workspace scope. Product screens may show roles such as administrator, operator, or viewer, but detailed role-to-action tables remain internal.

Invitations are protected app flows. An authorized member invites an email address, the invitee signs in with the invited identity, and the app creates the membership after the invite is accepted. Direct member add, removal, suspension, and resume workflows stay in authenticated product screens.

#User groups

User groups are tenant-owned audiences for routing, notifications, assignment, and other reusable target lists. A group can contain direct members and can be organized under another group in the same tenant.

User groups are not permission inheritance. Access still comes from enterprise, tenant, and workspace memberships; groups provide stable audience references that product workflows can reuse.

#Service principals and runtime credentials

Service principals and workspace runtime credentials are protected admin concepts for first-party automation, MCP-backed execution, and managed runtimes. Public docs name them only to distinguish them from user API tokens.

Creation, revocation, secret resolution, credential rotation, and private admin workflows stay in authenticated or internal operator flows. Public docs should never ask readers to paste service-principal secrets, runtime credentials, or stored token values.

#Task graphs and sessions

Requests become project task graphs so dependent work waits for the right inputs while independent work can move forward in parallel. A project owns one task graph, and the graph may contain separate work groups when the project has unrelated tasks in flight.

Graph task is the user-visible unit of work in the graph. Agent task is a graph task that carries agent execution settings, repository access, and one or more execution sessions over time. Dependencies are depends on edges: a successor waits until its predecessor is complete, while unrelated tasks can run when runner capacity and project policy allow it.

Labor0 can discover dependencies for prompt-submitted work, so operators do not have to precompute the whole graph before starting. The graph planning agent proposes graph update previews that list new task drafts, labels, dependencies, repository bindings, and task execution options. A preview can be approved, rejected, and then committed; it does not change the visible graph until commit. If the graph changed in a conflicting way before commit, Labor0 asks for a fresh preview instead of applying stale work.

Manual graph changes use the same review model. Manual insertion is previewed before commit, and manual removal retires or cancels the task without deleting its history. Downstream tasks stay blocked until another graph update or operator action makes their dependencies valid again.

Task statuses use the same vocabulary in the app and API projections:

Repository access starts with a GitHub account connection for the workspace, then repository registration, then project repository binding. Binding a repository to a project is the execution policy boundary: choose read-only when the repository is only context, choose read-write only when the agent is allowed to change that repository, and enable auto-PR only for read-write repositories where Labor0 should ask the agent to open a pull request. Target repositories do not need repository-defined GitHub Actions workflows for Labor0 agent execution; repository CI can still run after a pull request is opened.

Project agent defaults let operators set the normal runtime for new work. Defaults cover runtime, model, Codex reasoning effort, Codex fast mode, runner setup commands, and coding-session plan mode. A task can override supported settings when it is created or approved, but omitted values inherit from the project. Runner setup commands run before each phase starts or resumes so dependencies can be installed consistently without making setup output part of the agent-authored pull request.

Agent sessions are runner-backed attempts for one agent task. Hosted runners are managed by Labor0 and start work when no active local runner is available for the workspace. Local runners are user-managed daemons that poll Labor0 for authorized work and are useful when the code must execute on your own machine or network. Both runner types use the same task graph, repository bindings, plan review, checkpoint, and stream surfaces.

Plan mode adds a review gate before implementation. Operators can approve the plan, request changes and return the session to planning, or terminate the task. User-input pauses handle blocking questions that need a human answer before the runner can continue. Checkpoints preserve resumable workspace state while a session waits, so hosted compute can stop during long approvals and resume later without using hidden work-in-progress commits or branches.

Pull request completion stays visible on the task. When auto-PR is enabled and the agent changes a read-write repository, the session can link one or more pull requests. Trusted review feedback or failed required CI can create or update a pull request follow-up task so repair work stays attached to the original graph task instead of becoming an untracked side conversation.

Grouped views and streams help operators inspect active work. Grouped views filter the graph by labels, pinned roots, and layout preferences so large projects can be read in slices. Live streams keep graph updates, execution updates, and user notifications current in the app and supported clients without exposing raw runner protocol details.

The normal operator workflow is:

1. Connect the workspace GitHub account.
2. Register the repository and bind it to the project with the least access needed.
3. Set project agent defaults for runtime, model, setup, fast mode, reasoning effort, and plan mode.
4. Submit a task or prompt batch.
5. Review and commit graph update previews when Labor0 proposes task graph changes.
6. Review plan approvals or answer user-input pauses when sessions block.
7. Track the session, grouped view, streams, checkpoints, pull requests, and follow-up tasks from the protected app.

#Assistant context

Labor0 assistant workflows use connected company context from repositories, knowledge sources, and supported work tools. Repository registration and project repository binding decide which repositories can be used for graph-agent work, while connector administration and source indexing decide which non-code context is available.

MCP-backed workflows are mediated through Labor0 services rather than exposing protected runtime internals directly in the browser.

Connector administration, source indexing, and workspace-specific values stay in authenticated workflows.

#Human review and QA loops

Human review, plan approval, user-input pauses, terminal prompts, QA repair loops, checkpoints, and pull request follow-ups keep risky changes observable. Labor0 is designed for teams that want agent work to stay governed while still moving quickly.