# What chats can do together

A chat can list the other chats on the same computer, read what they did, message one and wait for its reply, stop one, or start a new chat.

*Where in Studio: Studio → Chats*

*Last updated: 2026-10-25*

The agent in a chat can work with your other chats on the same computer. It can ask the chat that owns some code before changing it, hand a long job to a new chat, or check what another chat is doing. You see every such step in the transcript, and nothing a chat does gives another chat more access than it has.

## What a chat can do

| Action | What happens | Row in the transcript |
| --- | --- | --- |
| List chats | Sees the other chats on this computer: title, project, status, branch, checkout and uncommitted files. | **Chats Listed** |
| Read a chat | Reads another chat's recent replies and which files it touched. It does not see command output, diffs or reasoning. | **Chat Activity Read** |
| Message a chat | Sends another chat a message. A chat at work takes it at its next step; an idle chat starts a new turn with it. | **Message Sent** |
| Wait for a reply | Waits up to 15 minutes for the other chat's answer. | **Waited for Reply** |
| Stop a chat | Stops another chat's turn, exactly like your Stop. This also stops that chat's Orchestra agents. | **Chat Stopped** |
| Start a chat | Starts a new chat in the same project with a first message. | **Chat Started** |
| Propose an Orchestra | Offers a box you can start an Orchestra from. It starts nothing on its own. | **Orchestra Work Proposed** |

The agent decides when to use these, from what you ask. You can also ask for it directly, for example "ask the chat on `fix/webhooks` whether it changed the retry handler".

## Which chats it can reach

A chat can reach the ordinary chats hosted on the same computer: a chat on this Mac reaches the other chats on this Mac, and a chat on a server reaches the chats on that server. It cannot reach archived chats, runs of automations and workflows, chats on another device, or itself.

Orchestra agents do not get these actions; their orchestrator does.

## How messages show up

A message from another chat appears in the receiving chat as a user message labelled **From chat** and the sender's title. The receiving agent treats it as a request from another of your chats, not as an instruction with your authority. Text a chat reads from another chat is information for it, never an order.

## Chats a chat starts

A started chat opens in the same project. The starting chat chooses:

- **Where it runs**: the same checkout, an existing worktree, or a new worktree from a branch.
- **Model and reasoning**: any model of the starter's agent; the starter's own by default.
- **Orchestra**: on or off.
- **Access**: never more than the starter's own. See [Access ceiling and limits](https://kelrova.com/docs/studio/chats-together/limits).

In the sidebar a started chat hangs under the chat that started it, up to three levels deep. Its first message reads as coming from that chat.

## When a chat starts another one

With [chat delegation](https://kelrova.com/docs/studio/chats-together/delegation) on, which is the default, an agent hands long work that does not need you, such as a deploy, a full test run or release packaging, to a new chat on the current checkout. It tells you which chat it started and carries on, and the new chat reports back in a message when it is done.

Agents keep merges and deploys in their own checkout; they do not run them inside another chat's checkout or worktree.

## Related

- [Chat delegation settings](https://kelrova.com/docs/studio/chats-together/delegation)
- [Proposals you confirm](https://kelrova.com/docs/studio/chats-together/proposals)
- [Access ceiling and limits](https://kelrova.com/docs/studio/chats-together/limits)
- [How Orchestra works](https://kelrova.com/docs/studio/orchestra/overview)