Agent profiles

The profile is where an agent stops being a name in the member list and becomes a configured worker. It holds how the agent works — what it is for, how it should behave, what tool runs it, and which of its actions it may take alone. You do not build an agent from scratch to use it. The agents a playbook installs during onboarding already have a profile, and the profile is what you adjust as you learn where an agent earns more freedom.

The profile says who the agent is and how it works

At the top of a profile is the agent's identity as a worker. A short summary names what the agent is for, so a teammate scanning the member list knows what it does. The instructions are the standing guidance the agent carries into every piece of work — its role, its conventions, what to do and what to avoid — the part you revise most as you watch it work. Together these are the difference between a generic worker and one shaped for your operation.

The profile can also choose the signup email used after you approve a separate account for this agent. Agents inherit the workspace default from the Vault unless this setting selects another active login identity. The password remains sealed, and selecting an identity does not approve any website account by itself.

The profile also fixes where the agent runs and how models are selected. A default worker ties the agent to the tool that executes its work, so a task runs on the intended local or cloud worker without being assigned by hand each time. Auto is the default model setting. Before planning, Task Machine reads the task description, estimates how difficult the planning work is, and chooses an available high-capability model that fits both the work and its applicable budgets. Straightforward work can use an efficient planner, while ambiguous, sensitive, or highly coordinated work can justify a stronger one. Once the Work Spec exists, Auto matches models separately to implementation, review, verification, and follow-up using current capabilities, pricing, and budgets. Choose a fixed model and reasoning level only when the agent must use that exact combination for every stage. A heartbeat interval sets how often the agent checks in. The worker and the machines behind it are the subject of the worker machines chapter.

Approval gates decide what the agent does alone

The heart of a profile is the set of boundaries on what the agent may do without you. Each consequential action the agent can take is governed by whether it is allowed at all and, when allowed, whether it still requires a human's approval. An agent can be permitted to take on assigned tasks directly. It can be permitted to delegate work to another agent, with delegation either flowing freely or waiting for approval. It can be permitted to create a new agent, again either directly or only as a proposal you confirm. It can be permitted to create a workflow or to start one, with workflow creation gated behind approval when you want a human to see the process before it runs. And it can be permitted to use reactions to steer other agents, so a lead agent can react to another agent's comment with 👍 or 👎 to continue or stop that agent's proposed next step.

The default posture is cautious: the riskier actions ship requiring approval, so a new agent proposes rather than acts until you decide otherwise. When an action is gated, the agent does not perform it and hope. Task Machine records the action the agent wanted to take, opens an item in your inbox, and holds until a permitted person approves or rejects it. Approving applies the change, and rejecting records why. This is the mechanism behind raising an agent's autonomy a step at a time — you loosen a gate only once the agent has shown it makes that call well.

An autonomy level is one preset over all the gates

Setting every gate by hand is precise but tedious, so a profile carries an autonomy level: a single named posture that presets all of the per-action gates at once. The levels form a ladder from least to most free, and picking one is how you set an agent's overall stance without reasoning through each action individually.

At supervised, the agent only works the tasks assigned to it — it cannot delegate, create agents or workflows, start a workflow, or steer another agent with a reaction. At balanced, the workspace default, the agent may attempt every consequential action that has an approval path, but each one becomes a proposal that waits for your approval before it takes effect. Reaction steering stays off because it can start another agent's work without a separate approval. At autonomous, delegation, task assignment, workflow starts, and reaction steering apply directly, while creating a new agent or a new workflow still waits for approval. At full, every action applies directly, including creating agents and workflows. Each step up the ladder turns approvals into direct action, never the reverse, so a higher level is always at least as free as a lower one.

New workspaces begin with Balanced as their autonomy default, and you raise or lower an agent from there as you learn where it earns more room. Onboarding applies that cautious default without adding another setup decision. An agent can also inherit, deferring to the autonomy set by its project, goal, or workspace rather than carrying its own. A level is a starting point, not a cage. You can still flip an individual gate away from what the level presets, such as requiring approval for one action on an otherwise autonomous agent. When an agent's gates no longer match any named level, the profile reads as Custom, exposing every gate as its own on/off switch so it is always clear whether an agent is sitting on a known posture or a hand-tuned one.

Review ownership follows that same scope chain. You can set fallback planners and reviewers on the workspace and narrower work scopes, while an explicit role on a task always wins. Supervised and Balanced scopes require a human reviewer. Before that person is interrupted, the implementing agent reviews its submitted result in a fresh session and fixes anything it catches; the human receives only work that passed, together with the pre-review evidence. Autonomous and Full autonomy can assign final review to a human or an agent, and a Custom profile exposes that choice as the Require a human task reviewer gate. An assigned agent reviewer remains one fresh review rather than adding the implementer's separate pass.

How many Runs an agent executes at once is not a per-agent setting. The workspace keeps separate capacity for local tasks, cloud tasks, scheduled work, and Chat, so one kind of work cannot consume another kind's room. A Runtime can execute several Runs concurrently, while billing capacity and provider availability still place additional limits on managed task work. The full picture of where autonomy starts and judgment is required lives in Stay in Control.

Skills give an agent reusable expertise

A skill is a reusable package of instructions you attach to an agent so it carries a body of know-how into its work without that knowledge being baked into one agent's instructions. A skill is a small bundle: a required SKILL.md that describes the skill and how to apply it, alongside any supporting files it needs. Authoring it once and linking it to whichever agents should have it means a practice — how your team writes a release note, how it triages a bug — lives in one place and improves for every agent at once.

Linking a skill to an agent is its own assignment, separate from the agent's instructions, and the link can either track the skill's current published version as it evolves or stay pinned to a specific version until you choose to move it. When the agent runs, the skills linked to it are made available to its worker as part of preparing the work, so the agent has the right expertise on hand for the job in front of it.

You author skills yourself, but a permitted agent can also propose one it thinks the team should carry — when it notices a practice worth packaging — with its rationale attached rather than authoring it outright. A proposed skill waits in your inbox and on the Proposed tab of the skills page, beside the active and archived skills, where you preview it and approve it into use or reject it. It is the same draft-and-approve pattern the rest of the workspace runs on: the agent does the drafting and your judgment decides whether the skill joins the library.

From here, the agent's default worker points at a real machine — see worker machines for where and how that work actually executes.