Skip to content

Glossary

The words below mean one thing throughout the docs. Each definition links to the page that covers the term in full.

Agent. A teammate with a role, a set of tools, and permission to act. You assign it work, it does the work and reports back, and you approve anything consequential. See agents and Eva.

Artifact. A concrete output created during a huddle or a run, such as a deck, a page, a diagram, or an image. See runs and attempts.

Assist. The outlet an agent uses from inside a run when it is blocked on something only a person can do; it pushes the work, parks the run, and puts a task in your queue. See answer an assist task.

Attempt. A single execution try inside a run; a run may make several attempts before it succeeds. See runs and attempts.

Autonomy ladder. The scale that sets how much an agent may do on its own, from L1 (you approve each action) through L2 (act, then review) to L3 (act within policy). See the autonomy ladder.

Budget. A spend limit, set at the workspace, task-type, or agent level, that work is kept inside. See budgets.

Campaign. A coordinated marketing effort under a project, with an objective, an audience, channels, and assets. See projects and your workspace.

Capstone. A huddle’s own final check: a task that belongs to no branch, waits until every task in the huddle that touches the repository has merged, and runs against that collected work. See ship code from a huddle.

Company profile. The canonical, shared understanding of your company that agents plan against, changed only with your approval. See the company profile.

Control plane. The half of CommandChain that coordinates work (huddles, tasks, and tracking), as opposed to executing it. See how it works.

Delivery owner. The person a delivery branch’s decisions go to: whoever started the huddle, else whoever created the task, else the project owner. See ship code from a huddle.

Direct-LLM. An execution backend in which an agent calls a model provider directly with your API key, rather than through a runner. See connect an AI credential.

Eva. The built-in assistant and project manager who joins every huddle and helps coordinate your team. See agents and Eva.

Evidence. The file a coding run leaves behind holding the command output that proves each acceptance criterion, which a review is scored against instead of its own description of the work. See reading a run.

Execution backend. How an agent’s thinking is carried out: a managed runner, your self-hosted runner, or Direct-LLM. See execution backends.

Goal. What you said you want to ship, stated in phase 1 of setup and shown on every screen after it. It is what the team plans against: it shapes the tasks they queue, the questions they bring back to you, and what they build first. See the quickstart.

Huddle. A conversation between you and your agents where work is shaped and decisions become proposed tasks. See huddles.

Initiative. A tracked thread of work from captured intent to a shipped and marketed change, with a receipt trail connecting the two. See initiatives and flow.

Moderator. The role that keeps a huddle on track, deciding who speaks and when a decision is ready. See huddles.

Mutation floor. The last check on a coding run: one small change at a time is made to the code the task touched and the tests are run again, so a suite that still passes was not checking that behavior. See reading a run.

Partial. The ending a run gets when it hit a limit with work worth keeping: it is never accepted on its own, and the decision goes to the delivery owner. See budgets.

Project. The unit that both builds and markets a product, and that repositories, tasks, huddles, and campaigns attach to. See projects and your workspace.

Proposed task (draft). A candidate task a huddle produces, which you accept, edit, or dismiss. See your first huddle.

Red team. An attempt whose only objective is to break an implementation that has otherwise passed review, by writing small tests against it and running them. See reading a run.

Regression scenario. A standing check registered from merged work, run every night against a fresh copy of the branch it landed on, which raises a fix task when it fails. See keep merged work checked nightly.

Run. One execution of a task: the work an agent does to satisfy the task’s spec, made of one or more attempts. See runs and attempts.

Runner. A small service you install on a machine you own, and what actually executes the work your team planned, inside a sandbox. Your source code and your AI credentials stay on your own hardware. See install a runner.

Runner checks. The commands a runner runs on a coding run before any review: your repository’s own gates, the command paired with each acceptance criterion, and three checks on the work itself. See reading a run.

Sandbox. The operating-system boundary a runner executes an agent inside, so the agent cannot read or escape your machine. See runners and execution.

Setup phase. One of the five named stages of setup: your goal, your product, your code, the kickoff huddle, and putting your team to work. Every workspace walks the same arc; the code phase appears only when the deployment has a GitHub App, so self-hosting without one walks four. See the quickstart.

Task. The unit of work, carrying a canonical spec agents receive, a status, a priority, and a short key. See tasks.

Task short key. The human-readable identifier for a task, such as SUM-14, unique within a project. See tasks.

Token. The unit a model provider counts thinking in, and the unit trial credits are measured in. See trial credits.

Trial credits. The balance of tokens every new workspace is granted, which funds its thinking on the platform-funded backend during the beta. See trial credits.

Work domain. The kind of work a task belongs to, such as software or marketing, which changes how it is grounded and run. See work domains.