The Three Surfaces
Chat
The chat surface where you reason with an agent and that thinking fans out into work.
Chat is the first of the three surfaces, and it is where the work starts. Almost everything you do in Task Machine happens on one of three surfaces — Chat to decide, Inbox to approve, Tasks to steer — and Chat is the strategic one: a conversation with a single agent where you reason about what to do before any of it becomes a task. In the app, the navigation calls this surface Chats, because each conversation is its own chat. You think out loud here, the agent thinks with you, and the decisions you reach fan out into the tasks and agents that carry them out.

A chat is a conversation with one fixed agent
Each chat is a conversation between you and one agent, chosen when the chat is created. The agent is fixed for the life of the conversation, and that is deliberate: the agent's worker history and working-directory state belong to that one conversation, so swapping the agent mid-thread would orphan everything it had built up. A chat carries only its own framing — the workspace it belongs to, its agent, its owner, a title, a status, and when it last saw activity. When you want a different agent, you start a different chat.
Because the agent is fixed, a chat accumulates context the way a working relationship does. The agent reads the workspace knowledge it is entitled to, remembers what it has been told across turns, and stays oriented to the thread you are in. That continuity is what makes Chat the place to reason rather than to issue one-off commands.
Starting a chat keeps the choice small: write the message and pick the agent. The agent's profile supplies its usual worker, model, and reasoning level. Compact model and reasoning controls remain beside the agent picker when you need to override those defaults for this chat, without making configuration a prerequisite for the first message.
The Chats drawer also offers starter presets for common conversations such as building an agent, discussing strategy, and planning a project. A preset fills the composer with questions about your goal, current process, constraints, and exceptions before the agent proposes anything. It never replaces a draft you have already started.

Messages come from the worker, not a message log
What you see in a chat is the worker transcript, not a separate table of chat messages. When you send a prompt, Task Machine compiles it together with the agent's instructions and the knowledge it may read, then starts an agent run for the chat's fixed agent. The agent runs that work on the profile's local or cloud worker, and the transcript events it produces (your message, the agent's reply, and the internal prompt that framed the turn) are what the chat surface renders, in job order. Consecutive tool activity stays collapsed until you need it: web activity names one or two public domains and otherwise counts the sites searched, fetched, or browsed, while Skills, Connectors, and Vault activity retain their own recognizable summaries.
One consequence is worth knowing: a chat runs one turn at a time. Only a single queued, running, or in-flight job may exist per chat, so a new prompt waits until the current turn finishes rather than racing it. Conversations take fair turns across the workspace when several are ready. When a turn needs connector credential access, the same durable Inbox decision appears in the conversation and the composer stays visible but unavailable. A permitted member can review and decide there without losing the thread, and the composer becomes available again after approval or rejection. Local and managed conversations share one Chat capacity lane. A managed Chat keeps its conversation workdir in its cloud sandbox without consuming a paid task slot.
Pasting a long passage offers to save it as a document
Chat stays readable even when the material you bring to it is long. Paste a large block of text into the composer and Task Machine asks whether to keep it as a document instead of letting it swamp the thread. A short dialog opens with a title — seeded from the first line you pasted — a markdown editor holding the text, and a folder button that opens the same "Move to folder" browser the Library uses, including its New folder action, so the document lands exactly where you want it. Create it and the composer drops in an @ reference to the new document rather than the raw text. The agent follows that reference to read the document in full, and it becomes a durable, linkable part of your knowledge base. Prefer to keep the text in the message? Skip the dialog and the passage is inserted as a fenced code block, untouched.
The composer also renders markdown as you write it — a heading shows as a heading and **bold** shows as bold, without the surrounding syntax — so what you compose reads the way the agent will receive it.
Chats are private by default and shared deliberately
A chat starts private to its owner, who holds implicit control over it, and stays that way until you share it. Sharing is explicit and graded: you grant another member or a whole role one of three levels — read to follow the conversation, participate to send prompts into it, or manage to administer it. A private chat simply has no grants. The moment you add one, the conversation opens to exactly the people and at exactly the level you chose.
Chat access and agent administration are kept separate on purpose. Being able to read or join a chat does not let you reconfigure the agent behind it, and being able to manage agents in the workspace does not silently admit you to someone's private conversations. The workspace role still gates whether a grantee can use the underlying action at all, so a grant never hands out more reach than the member's role already allows.
Chat feeds the other two surfaces
Chat is for thinking. It is not a second task system, and it intentionally stops short of becoming one. The reasoning you do here turns into work when it leaves the chat and lands on a task — the durable record with an implementer, a status, and a full history. From there an agent picks the work up, and anything that needs your judgment comes back to the Inbox. That is the loop this chapter traces: you decide in Chat, you steer on Tasks, and you approve in the Inbox.