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 template 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 also fixes how the agent thinks and where it runs. A default runtime ties the agent to the local coding tool that executes its work, so when the agent picks up a task it runs on a machine you control without being told which one each time. A model and a reasoning setting choose how the underlying model behaves, within the choices the selected runtime reports as available. A heartbeat interval sets how often the agent checks in. These are the knobs that decide the texture of the agent's work; the runtime and the machines behind it are the subject of the runtime 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; 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 starts work immediately. 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.

The autonomy level you choose during onboarding becomes the workspace default that new agents start from, and you raise or lower an agent from there as you learn where it earns more room. A level is a starting point, not a cage: you can still flip an individual gate away from what the level presets — requiring approval for one action on an otherwise autonomous agent, for instance. When an agent's gates no longer match any named level, the profile reads as Custom, so it is always clear whether an agent is sitting on a known posture or a hand-tuned one.

A concurrency limit sits alongside the gates and caps how many jobs the agent runs at once, so a single agent never floods your machines. 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 runtime 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 runtime points at a real machine — see runtime machines for where and how that work actually executes.