The assistant sees your other chats

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 — start a new one, and write into one that already exists. Two tools only read, one creates a chat, and one sends a message into a chat in the same workspace. Three more let a supervising chat read and answer the question another chat is waiting on, and stop a chat that is running in circles.

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 can message it, answer its questions or stop it like any other chat of yours (below) — it can't take it back.

What it can send

A message into another chat of yours, in the same workspace — and that message wakes it. If the chat is idle, its assistant starts working on the message right away. If it's in the middle of something, the message joins what it's doing and is read at its next step.

This is what lets one chat supervise others: ask a chat to check on your running chats every so often, and when one has stalled or stopped short, it writes to it — "you stopped at step 3; carry on with the import" — and that chat picks the work back up without you.

You see every such message. It appears in the chat that received it, outlined rather than filled, under From another chat · «name of the sending chat» — never as if you had typed it. The receiving assistant is told the same thing: the message is from another assistant of yours, it carries no authority of its own, and it can't override what you asked that chat to do.

The sender gets back only whether the message was delivered — never an answer. To see what the other chat did, it reads that chat.

What a supervising chat can also do

A chat that has stopped to ask a question — a card with options, waiting for a tap — isn't helped by a message: it reads the message only after the question is answered. And a chat stuck repeating the same failing step isn't helped by one either. So a supervising chat can also:

• See the questions another chat is waiting on, with their options.
• Answer one of them, the way you would by tapping the card — but only a question the chat is still waiting on right now, and only with one of its options or, where the card allows it, its own words. Its answer is marked in that chat: [Ответ дал агент чата «name of the supervising chat», не человек] (an answer by another chat, not by a person). A card that only takes its own options can't carry that mark; the option is answered as is, and Plank keeps a record of which chat answered it.
• Stop a chat's running turn — the same as your Stop button. It answers no question and writes nothing into that chat; if the chat (or you) should know why, the supervisor sends a message after it.

It is told to read a chat before touching it, and to leave alone a chat that is making progress. A question that needs your decision — money, a customer, anything that can't be undone — is yours; tell the supervisor which kinds of questions it may answer for you.

Limits that stop chats waking each other in circles

• A chat that received a message can't message the sender back for 30 minutes. It answers in its own chat, where the sender reads it.
• A chat woken by a message can pass it on to at most one more chat. A chain stops there.
• Each chat can send up to 12 messages an hour, and a chat can be woken by messages at most 4 times in 10 minutes. Answers and stops count toward both limits, together with messages.
• An answer wakes a chat just like a message, so the first two rules apply to it. A stop wakes nobody, so a supervisor can stop a chat that just wrote to it.
• Only chats in the same workspace, and only your own chats. A shared team chat can't be written into, answered or stopped this way. The list marks every chat it can act on (can_send), so a chat with the same name in another workspace is never the one it picks.

What it can't do

• Change a chat's instructions, delete it, or take it over. A message can ask; it can't force.
• Answer a question left over from a run that already ended, or the same question twice — whoever answers first wins, you or it.
• Stop, answer or write into a chat in another workspace, or a shared team chat.
• 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 these 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.

Shared team chats in your other spaces

From one of your personal chats the assistant can also look across your spaces at once: ask it what is going on in all of them, and it lists your own chats there and the shared team chats of those spaces, marked as shared. It can read a shared team chat too — its status, its title and its messages — which are fetched from that space's team container, since that is where a shared chat lives.

• Read-only. It never writes into, answers, or stops a shared team chat from here.
• Only spaces you are in right now. Membership is checked on every request, so a space you left disappears at once.
• Never a colleague's private chat. Asking for one gets the same "not found" as a chat that does not exist.
• Up to 60 spaces in one request; a space that does not answer in time is named, and the rest still show.
• If the space's team container is off, the list still shows the chat and its status, but its messages cannot be read until the team container runs again.

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 and sending a message are refused there too (and so are answering and stopping), for the same reason: with nobody specific behind the container, there's no "your workspace" for the new chat to land in and no "your chats" to write to.

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. And when a long piece of work stalls overnight, a supervising chat can notice and nudge it, instead of the work waiting for you to come back.