The assistant sees your other chats

The assistant in any of your chats can look at your other chats — across every one of your workspaces — and it can start a new one. Three tools, and they do three different things: two only read, and the third only creates. None of them can write into a chat that already exists.

What it can see

A list of your chats — which are running right now, what each is doing, which are waiting for your answer, which have stalled, and what is scheduled to wake. Idle chats are shown for the last 14 days. The chat you are talking to is in that list too, marked as itself.

The recent messages of one chat, including the one being written right now. A long conversation is trimmed: the assistant sees the end, not everything.

What it can start

A brand-new chat, in the same workspace as the one you're talking to, with a prompt the assistant writes for it. That chat starts working right away and keeps running after this conversation's turn ends — it shows up in your chat list like any other, and you open, answer, or stop it yourself. The assistant only gets the new chat's id back; once it's created, the assistant has no further hold on it — no way to message it again, stop it, or steer it beyond that first prompt.

What it can't do

• Send a message into a chat that already exists, or add to work another chat is already doing.
• Stop, cancel, or change any chat — including the one it just started.
• Cancel or change someone else's schedule.
• Put a new chat in a different workspace than the one it's running in.
• Reach past your own workspace container — see below.

Whose chats it can see

The list and the reader look in two different places, even though the difference rarely shows.

The list comes from Plank's own records of every chat you've had, across every workspace — so it always covers everything, not just what happens to be loaded anywhere right now.

Reading one chat looks at the copy stored on your container: the private machine Plank runs your assistant on. Normally that's the same set of chats — one container holds every workspace you have, so what's in the list is what the reader can open.

Occasionally it isn't: a chat that ran on a container that no longer exists (for instance, one that was rebuilt) can still show up in the list, but reading it comes back "not found." That's a known limit, not a bug — the record that the chat happened outlives the container it ran on.

Either way, that's the whole boundary. It does not depend on whether a workspace is shared: a chat you open in a shared workspace still runs on your own container, so both tools work there normally. A colleague's chats live on their container, so the assistant never reaches them — not their private chats, and not chats in a workspace you are not a member of.

The one case where the list is refused is the shared assistant itself — the one a whole workspace talks to rather than you personally. It runs on a container that belongs to no single person, so there is nobody whose chats it could honestly list. Starting a new chat is refused there too, for the same reason: with nobody specific behind the container, there's no "your workspace" for the new chat to land in.

Why this exists

Ask "what's going on right now?" and the assistant answers for every chat at once, instead of you opening them one by one. Before starting long work, it can also check whether a neighboring chat is already doing the same thing — and when the work is long enough that it doesn't want to make you wait for it, starting a separate chat lets that work run on its own, with its own history, while this conversation carries on.