Agents

An agent is a worker you bring into a workspace the same way you bring in a person, and you assign work to it, mention it, and hold it to rules just as you would a teammate. This chapter is about putting agents to work: what an agent is, how its profile configures and bounds it, the machines that execute its work, and the coding tools it runs on. Start with the agent itself, because everything after it is in service of getting an agent to do a piece of work you can trust.

An agent is a first-class member

Agents and people are both members of a workspace, and the symmetry is deliberate. A member is either a person or an agent, and both can be assigned a task, mentioned in a comment, put on a team, and held to a workspace role that decides what they may do. You do not manage agents in a separate place with separate concepts. When you assign a task, the assignee picker offers people and agents together; when you @-mention in a comment, you can reach either; when you build a team, an agent can sit on it next to its human colleagues. Wherever a person can act in the workspace, an agent can be the one acting instead.

What makes an agent an agent rather than a person is that it carries a profile — the operational settings that say how it works: its instructions, a short summary of what it is for, the runtime it runs on by default, its model and reasoning settings, and the boundaries on what it may do alone. The profile is the subject of the next chapter; for now, the point is that every agent has one, and it is where the agent stops being a name and becomes a configured worker.

Agents do the same work people do

An agent does work by being assigned a task, the same durable record of one piece of work that a person picks up. It reads the task, does the work, posts progress to the task timeline, and raises a question or an approval when it needs your judgment — all of it on the task, where the full history lives. When it finishes, the agent writes a short completion summary onto the task — what it did and how it turned out — so the outcome reads at a glance without scrolling the timeline. The summary is required, not optional: a task that completes without one prompts the agent to write it before the work is considered done. Work that begins in a chat or on a schedule still lands on a task, so there is always one place to look at what an agent did and why. The path from a trigger to that run and back into these records is the agent loop — the engine under everything an agent does, and the chapter to read once you want the full mechanics.

Beyond doing the task in front of it, an agent can do the things a capable teammate does as work unfolds: write to its memory so what it learns carries forward, produce artifacts and reference documents, and — when its profile allows — hand work to another agent, bring a new agent into the workspace, or set a workflow running. Which of those an agent may do on its own, and which wait for you, is not a global setting. It is decided per agent, in the profile.

Agents build the operating system around them

A capable agent does not only clear the task in front of it — it notices structure worth keeping and proposes it. When an agent sees activity that recurs, a process worth capturing, or a workflow proven enough to reuse, it can propose the corresponding workspace object rather than create it outright: a recurring or scheduled task that runs on its own, a workflow that captures repeated steps once, a template promoted from a workflow that already works, a ready-made template bundle from the catalog, or a new task, project, goal, team, agent, or skill. A proposal is the real record created in a held state with the agent's rationale attached; it routes to your inbox, and the object only becomes active once a permitted person approves it. You clear proposals from two places: each lands in your inbox the moment it is raised, and every kind that can be proposed also gathers on a Proposed tab beside the Active and Archived views on its own page — proposed agents on the agents page, proposed projects on the projects page, and so on — where you can browse what is pending, open a row to preview the actual record, and approve or reject it in place. Proposing is therefore always safe — nothing the agent proposes takes effect until you say so — and it is how the workspace accretes the recurring work and repeatable processes that pay off over time.

An agent can also turn its judgment inward and ask how it should improve. When it notices a pattern in your corrections or a gap in its own guidance, it raises a self-improvement question — declaring whether your answer should land in its memory or in its standing instructions — and that question routes to your inbox for a written answer. An answer aimed at memory is appended to the agent's notes directly; an answer aimed at instructions becomes a proposed instruction change you approve before it takes hold. This is how an agent gets better at recurring work with your input rather than only your correction.

Agents know how to operate Task Machine out of the box

None of this requires you to teach an agent how to drive the system. Every agent carries a set of built-in capability skills out of the box — one per area of Task Machine it can act on: documents, artifacts, memory, agents, goals, tasks, teams, templates, and proposals. Each is a first-party skill that explains how to use the corresponding tama commands, so an agent knows how to read and write artifacts, keep its memory, discover ready-made bundles, raise a proposal, and the rest without that knowledge being baked into your instructions or depending on which skills a workspace has configured. These built-in skills are always available and sit alongside any skills you attach to a profile, so your instructions stay about what the agent should do rather than how to operate the tools.

Control is set per agent, where the work happens

An agent is bounded by the same two layers that bound a person, plus one. Its workspace role decides what it can see and change across the workspace, exactly as a role does for a human member. Its profile then adds the agent-specific boundary: which actions it may take on its own, and which it must propose and wait for a human to approve. There is no single autonomy dial for the whole product — control is expressed at the point where the work happens, so you can let an agent run freely on one kind of work while requiring your sign-off on another.

When an agent reaches one of those gates, it does not act and then ask forgiveness. It records the action it wants to take, routes it to your inbox, and waits for someone permitted to decide. This is how you raise an agent's autonomy gradually: start it cautious, watch what it proposes, and loosen the gates as you learn to trust it. The boundaries, the approvals, and the audit trail are covered in Stay in Control.

From here, the agent profile is where you set all of this — instructions, runtime, model, and the gates that decide what the agent does alone.