Chat and plans
Talk to a member, have it start work, watch the work move, and answer what it asks, in one thread.
What a chat is
A chat is one conversation with one member. The member knows who it is (its role and persona), which tasks it can run, and which of the OS's own tasks anyone may start, so it knows what it can actually do for you before you ask.
You can keep several chats with each member: History in the thread's header lists them, and + starts a new one. A chat you have not read since the member replied is counted in the Chat badge, per member, and per chat in History.
When you can send
The message box is usable only when sending makes sense, so there is one obvious next step instead of a queue of messages:
| You cannot send while | Because |
|---|---|
| The member is replying | One message at a time; a second is refused. |
| Work you asked for is still running | The thread shows it moving instead: how long it has run, and its latest step. |
| A decision from that work is waiting on you | The decision is the next thing to do, and what you type becomes the note on it. |
| The chat is closed | Open a new one. |
Work in the thread
When a member starts a task for you, the run is linked to the thread, and the thread follows it:
- While it runs, a card shows how long it has been going and what it is doing.
- When it finishes, the links it published (the issue, the pull request, the preview) become the thread's result, a click away.
- When it stops at a gate, the decision appears in the thread as a card, and you decide it there with the card's buttons and its note. It is the same decision you would make on Gates. A message typed in the thread never decides a gate.
Only work started from this chat appears in it. A gate from work someone started elsewhere stays on Gates.
Messages from a member's tasks
A task can write to you in chat, so what it has to tell you arrives where you already talk to that member instead
of in another system. A task that declares os.chat_write writes one message, as the member, in the member's open
chat with you (one is opened if there is none). It is counted as unread until you open it, like any reply.
- The message is plain text, shown as written.
- The task does not wait. Nothing you reply goes back to the run that wrote it. A task that needs your answer asks through a gate.
- The member does not remember, in chat, what its task wrote there. If you reply to the message, say what you mean in full.
A task can also read the member's chats, with os.chat_list and os.chat_read. It sees only the chats of the
member doing the run, never another member's.
The same tools work from your side, over the API and the MCP server: an agent
holding an API token lists and reads chats, opens one with os.chat_open, and writes to a member with
os.chat_write. There it writes as the token, and the member replies. Each tool is described in
Built-in tools.
What a member can use in chat
Every chat offers the member four of the OS's own tools: the organisation (teams, members, and who does what), the tasks it can start, starting one, and reading a run's progress. The member checks a run before telling you how it is going, and says so plainly when it has stopped.
It also offers the member's own connected tools: every binding the member reaches through its roles, itself, its teams and the enterprise. A member bound to your analytics can answer a question from them in the conversation, with no task needed.
What a member remembers
A member also reads your enterprise's memory. With every message you send, the OS looks up what memory holds on the subject and shows the member those notes alongside your message, so it can answer from what earlier work established and what you have decided before, not only from the conversation.
- The member treats the notes as prior evidence, not as instructions. What you write always comes first.
- Under your message the thread says how many notes were recalled, or that memory was unavailable. Open that line to see each note: its first line, whether the member was shown it, and a link to the note on the Memory page or to the run it came from.
- How much is read is your choice: Chat memory on Enterprise. A deeper read finds more and uses more tokens with every message.
- A reply waits up to ten seconds for memory, then carries on without it.
- Chat only reads memory. Nothing you say in a chat is saved to it. What you say when you decide a gate is.
- The lookup is made only if your own access includes reading memory.
Asking before a tool that can change something
A connected tool runs straight away only when its server marks it read-only. Any other call pauses the reply and asks you, showing what it will run with:
| Answer | What happens |
|---|---|
| Allow once | The call runs and the reply carries on. |
| Always allow | The same, and the answer is kept for you, this member and this tool, so it does not ask you again. |
| Deny | The call is refused, and the member carries on knowing that. |
Sending a message while a call waits declines it. Allowed tools in the thread's header lists your "Always allow" answers for that member, each with Revoke. An "Always allow" is yours alone: it never lets anyone else's chats skip the question.
A chat has no task, so no task's gates apply to what the member does in it. Work that should wait for your formal approval belongs in a task that declares the gate, which the member can start for you.
When a reply fails
The member says why, in the thread:
- No model connected. Neither the member nor the enterprise has a model connection; add one on Agents.
- Spend cap reached. The reply would go past a day cap that applies. See Spend and models.
- Sign-in refused. The model provider refused the stored credentials; reconnect them.
- Out of credit. The provider's own message is quoted, since it names which limit was hit.
When a reply stops short
A reply takes at most 24 tool steps. A member that uses them all stops there and says where it got to and what is left, and the thread marks the reply Stopped at the step limit. Write to the member and it carries on from there, with a fresh set of steps.
A reply the model's own length limit cut off is marked Cut off by the model's length limit. Ask for the rest, or for a shorter answer.
A reply's model cost counts toward your spend like any run's.
Planned
Plans
A member will be able to propose a change to the company (a new team, a new member, a changed task) as a plan: a list of changes, each shown in full, that you approve, change or reject. Nothing in a plan takes effect until you approve it, and an approved plan is applied as written.
Today, a change like this is designed by one of the OS's own tasks, which the member starts for you: the same task in every enterprise, changed only with a release of the OS. It puts the change to you as a decision to sign off, and the OS makes an approved change as written.
A member will also be able to make a small change directly when you ask, such as adding someone to a team, instead of proposing it. A direct change asks you before every one, and Always allow never applies to it.