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 Implementer 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 worker 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, create and refine workspace 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 notices structure worth keeping while it clears the task in front of 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. Proposals cover tasks, projects, goals, teams, agents, skills, connectors, workflows, child chats, promoted workflows, ready-made playbook installations, and generated playbooks.

Approval-gated proposals wait with the agent's rationale attached and route to your inbox. Tasks, projects, goals, teams, agents, skills, connectors, and workflows also collect their pending records on a Proposed tab, while playbook promotions and installations appear in the Proposed view on the Playbooks page. The Inbox keeps each decision self-contained, including child-chat and connector context and actions. Child chats allowed by the agent's autonomy settings start immediately instead and never enter review or create an approval item.

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 and declares whether your answer should land in its memory or in its standing instructions. 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.

Task Machine also reviews the decision record when an agent has enough approvals and rejections to judge its reliability but has not earned the next autonomy level. The review may conclude that the instructions should stay as they are, which creates no interruption. When the evidence supports a precise change, the Inbox proposal shows the approval record, observed patterns, cited decisions, expected effect, and exact instruction diff. You still decide whether to apply it. Approval starts a fresh reliability record for the changed behavior, while a later manual instruction edit dismisses any proposal that no longer matches.

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 for each area of Task Machine it can act on. They span the things an agent does as it works: reading and writing documents, keeping its memory and its references, working tasks and goals, planning and reviewing work, managing teams and budgets, chatting, reacting to nudge another agent, raising proposals, and discovering or generating ready-made playbooks. Each is a first-party skill that explains how to use the corresponding tama commands, so the agent knows how to operate the tools 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, worker, model, and the gates that decide what the agent does alone.