One term, one meaning — the same word in the interface, the API, and this
documentation. Where a term has a page that goes deeper, the definition links to
it. For the conceptual model behind the tenancy terms, start with
Workspaces and Organizations.
| Term |
Meaning |
| Organization |
The top tenant. It owns billing, seats, single sign-on, and invitations. Every account belongs to exactly one organization, and a personal one is created for you when you sign up. The interface labels an organization either Personal or Organization — never Team. See Workspaces and Organizations. |
| Workspace |
The container everything else lives in: projects, tasks, runs, workflows, schedules, secrets, connections, and API tokens. Membership is per person, and you switch workspaces from the sidebar or with workspace switch. The word team is never used for this concept. |
| Seat |
What an organization is billed for. Workspace membership grants access; a seat is the billing unit, and every active member holds one. A member’s seat type can narrow or widen what they are entitled to do. See Manage seats and billing. |
| Project |
A named repository or codebase target inside a workspace. It carries the git and issue-tracker connection, the automation settings, and the tasks, issues, and workflows that belong to it. See Automations. |
| Term |
Meaning |
| Task |
A durable definition of agentic work — project, prompt, agent, model, and issue link. You create a task once and can run it many times. It is the unit you follow, logs, intervene, or cancel. See Runs and tasks. |
| Run |
One execution. A task can have many runs — a restart is a new run with a clean event log — and a workflow execution is a run whose children are its per-node runs. See Runs and tasks. |
| Schedule |
A recurring or one-time trigger that launches a task or workflow on a cron-like cadence. See Set up a schedule. |
| Workflow |
A graph of nodes — agent, code, database query, connector, gate, human approval — that executes as a run. Build it in the visual builder or write it as YAML. See Build your first workflow. |
| Term |
Meaning |
| Agent |
The coding-agent process SupaCloud starts in a container to carry out a run. Which agent it is, and how freely it behaves, comes from the agent profile. See Your first agent run. |
| Agent profile |
A saved, reusable agent configuration: model, reasoning effort, the tools the agent may call, and its pre- and post-flight checks. One profile can be marked the workspace default. See Entitlements and the MCP tool tiers. |
| Teammates |
A group of agents spawned to work on one task together. Team and teammates always refer to agents in SupaCloud, never to the tenant. See Workspaces and Organizations. |
| Skill |
A named piece of reusable instruction, written in Markdown, that agents can draw on. You edit skills in Settings; an agent can also propose one it found useful, which you then approve or reject with skills proposals. See Web terminal commands. |
| Council |
Several agents deliberating on the same question, with their answers synthesised into one recommendation. Councils have their own surface under Intelligence, and a pipeline stage can be set to use one. See Automations. |
| Memory |
Durable knowledge handed to agents as context, scoped to you, a project, or the whole workspace. You can write a memory yourself, and agents propose memories at the end of a task for you to approve. See Manage memories. |
| MCP |
Model Context Protocol — the tool interface between SupaCloud and an agent. Tools are grouped into four tiers (baseline, read, ops, deploy), and an agent profile decides which tiers the agent may use. See Entitlements and the MCP tool tiers. |
| Term |
Meaning |
| Autonomy level |
One number from 0 to 100, set per workspace, project, or agent profile, deciding how far SupaCloud may go unattended: whether it picks up work itself, how readily it stops to ask you something, and how far it may merge. It snaps to five named stops, Manual through Unleashed. See Autonomy and the delivery engine. |
| Approval (gate) |
A point where work stops and waits for a person — either an agent pausing mid-run on a risky tool call, an open question, or a visual check, or a workflow’s human gate. Pending approvals collect in the Inbox and in approvals. See Approve or reject agent actions. |
| Backlog |
The queue of imported, classified issues a project dispatches from, in priority order, bounded by the autonomy level, the concurrency caps, and the budget. See Run the backlog. |
| Backlog item |
One unit of work in that queue. It carries the classification the backlog sorts by — kind, priority (which maps to a severity), and scope (small, medium, or large) — plus its dispatch state and any reason it is blocked. See Run the backlog. |
| Concept approval mode |
An approval mode in which the agent first writes a code-grounded implementation concept and pauses for you to read it. Once you approve, the same run continues and implements it. See Automations. |
| Completion action |
What happens to the linked issue when an issue-linked task finishes: comment on it and close it, comment only, or do neither. See Automations. |
| Closeout |
The ritual an agent runs when a task finishes — close the source issue, update project documentation, update user documentation, write a wiki note, propose a memory. Each step is turned on independently, per workspace, per project, or for a single run. See Configure the standard closeout. |
| Term |
Meaning |
| App |
A small web surface you build and deploy from SupaCloud, with its own source tree and, optionally, its own database schema. Apps live under Build. |
| Script |
A self-contained piece of code — JavaScript, TypeScript, or Python — that SupaCloud runs in a sandbox. It reaches the network only through a connection you bind to it. Scripts live under Build. |
| Connector |
A sandboxed component that wraps a third-party API so a workflow can call it as a node. Install one from the marketplace or build your own. See Install a marketplace connector. |
| Resource |
A named, credential-backed integration — a mail server, a bot token, a database, a storage library. The interface calls these Connections. See Create a custom connection. |
| Runner |
A separate machine registered to your SupaCloud install that pulls and executes runs. With no runner, everything runs on the server itself. See The runner fleet. |
| Term |
Meaning |
| Marketplace |
The catalog of installable listings: apps, workflows, scripts, connectors, bundles, and runner offers. A listing can be free or paid, and passes a review gate before anyone can install it. See Install a marketplace connector. |
| Bundle |
One marketplace listing that carries several primitives together — an app plus the workflow behind it, say — so a single install brings the whole product. A bundle needs at least two. See Publish a marketplace bundle. |
| Term |
Meaning |
| Live mode |
The streaming view you land in after run or follow: events arrive as they happen, and anything you type is sent to the agent as an intervention. Available in the web terminal, Telegram, and Discord. See Web terminal commands. |
| Verbosity |
How much a live feed shows — reduced for a calm feed, or chatty for the full stream including the agent’s thinking and tool detail. Set it with density. See Set the live-feed verbosity. |
| Debug mode |
A per-session switch that reveals internal operations in the live feed: tool calls, scope resolution, gate auto-resolves, danger escalations. It takes effect only while a workspace admin has opened the debug ceiling, and never outlives the session. See Use debug mode. |
| Delivery board |
The overview of in-flight agent work, grouped by agent profile and delivery state. You reach it under Reports. It is not a tenancy concept. See Navigation and hubs. |
The vocabulary above is the user-facing half. For the authoritative table and
column behind each term, and the naming rules that govern them, see the
data dictionary.