How Task Machine works

Task Machine gives a small team — people and agents together — one place to run recurring work, and one consistent way to stay in control of it. This page is the mental model the rest of the docs build on: where work lives, the three surfaces you operate from, where agents actually run, and how control is expressed.

Everything lives in a workspace

A workspace is the boundary around one company, client, or operating context. Tasks, projects, goals, agents, teams, runtimes, documents, artifacts, memories, workflows, the inbox, and the audit trail all belong to a workspace, and Task Machine uses that boundary for both navigation and permissions. You can belong to more than one workspace — the app switches between them cleanly, and nothing leaks across.

Inside a workspace, members are the actors. A member is either a person or an agent, and both are first-class: both can be assigned a task, mentioned in a comment, put on a team, and held to a role that decides what they may do. That symmetry is the point — you assign work to whoever should do it, human or agent, and the same rules apply.

You operate from three surfaces

Almost everything you do in Task Machine happens on one of three surfaces, and keeping them distinct is most of understanding the product. The mental model is short: Discuss to decide, Inbox to approve, Tasks to steer.

Discuss is the strategic surface. It is a chat with an agent where you reason about what to do — what the week's priorities are, how to approach a goal, what work to spin up. The decisions you reach here fan out into concrete tasks and the agents that do them. Discuss is for thinking, not tracking.

Inbox is the attention cockpit, and after setup it is where you spend most of your time. Anything that needs your judgment arrives here: an agent's question, an approval before something irreversible happens, a finished draft to review, a machine that went offline. The inbox is how you stay in control without watching every run — you act on what surfaces and let the rest proceed.

Tasks are the execution surface. A task is the durable record of one piece of work — its description, who it's assigned to, its status, and a timeline of everything that happened. When you need to steer a specific job, give direction, or step in, you do it on the task. Where Discuss is open-ended and the Inbox is a queue, a task is the unit of work with a full history.

Tasks are the papertrail

A task is the canonical record of work, whoever or whatever does it. It carries a title and markdown description, a project and goal, an assignee, a status and priority, labels, a due date, dependencies on other tasks, and a timeline that mixes human comments, agent comments, status changes, questions, approvals, and final summaries in one ordered history. Because the task is the papertrail, work that starts somewhere else — a chat, a schedule — still creates or attaches to a task so there is always one place to look.

Agents run on your own machines

When an agent does work, it runs on a computer you control, not in a shared cloud. You install the tama daemon on a machine, it detects the coding tools already there — Claude Code, Codex, Opencode, and the rest — and agents use those tools where your files, credentials, and software already live. Task Machine coordinates assignments, permissions, and history; the execution happens locally, on the machine that already has what the work needs. This is what "local-first" means in practice, and it is the core of how Task Machine differs from cloud agent platforms.

Work happens in a loop

What makes Task Machine an operating system rather than a chat box is the agent loop. A trigger — a task assigned, a comment that tags an agent, a schedule firing, a message in a chat — starts an agent run on your machine; the run changes real records through the tama CLI; and those changes become the next trigger. An agent proposes work you approve from the inbox, the approval creates a task, an agent picks it up, finishes, and asks a question that returns to your inbox. Work produces work, and your judgment sits at the approvals and questions in between. This loop is where the whole product comes together — The agent loop traces it end to end.

Control is expressed where work happens

Control in Task Machine is not one global autonomy switch — it is a set of boundaries applied at the point where work happens. A workspace role decides what a member can see and change. An agent profile decides what that agent may do on its own and which actions wait for a human's approval. When an agent reaches one of those gates, it doesn't act — it creates an inbox item and waits for a permitted person to decide. You set how much freedom an agent has, and you raise or lower it as you learn to trust it.

This is the through-line of the whole product: agents do the work, and you decide where their autonomy starts and where your judgment is required.

From here

Onboarding gets you to a working setup. Then the docs follow the journey: set up your workspace, live in the three surfaces, put agents to work, and stay in control.