pi-roundtable 0.27.1 → 0.28.0

package/CHANGELOG.md

@@ -5,6 +5,26 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [0.28.0] - 2026-10-31
+
+### Added
+
+- The web console's Connectors page manages the owner's MCP connectors (list, add with a write-only token, change a purpose, remove) and the MCP channel authorizations (bundles with their channels, operations and recent audit; authorize, rename, revoke, and a new bundle URL shown once). See pi-roundtable-web and pi-roundtable-mcp.
+- Yolo mode: an `ask_user` card holds the turn only `autonomy.yolo.questionGraceSeconds` (default 30 s); unanswered, the agent goes on with its recommended option, says what it assumed, and ends the turn only for a truly blocking question, while the card stays open for a late answer. The timeout card waits `autonomy.yolo.timeoutCardSeconds` (default 60 s) and an unanswered one continues the turn up to the long-running cap (`TurnTimeout.autoContinue`). `PromptWait.graceMs` carries a turn's own wait to surfaces. A host that is stopping still posts no card.
+- Temp knights follow the yolo and long-running modes of the conversation that made them, live: their own modes cannot be switched, an origin that is gone reads off, and only an owner's turn makes a temp knight follow (`ConversationModes.follow`, `forget`, `trackOrigins`, `ConversationMode.inheritedFrom`, migration `conversation-modes-follows`).
+- Discord keeps intercom cards' full texts in `intercom-texts.json` (newest 300, following `discord.cardCopies`), opened ephemerally with **Show all**.
+- The character kit's `composeSvg` takes `mouth: "open" | "closed"` for the frames of a talking figure.
+- `SkillRegistry.delete(name)` is part of the skill registry interface, so a host surface can remove an agent-written skill as `skill_delete` does.
+
+### Changed
+
+- `message_agent` opens no thread: the exchange shows in the sender's conversation as small intercom cards (`IntercomCard`, `OutboundReply.intercom`, `AgentPost.intercom`) that open to the whole text. `TeamTurnsOptions.threads` is gone.
+- `InterimPosts.tools: false` leaves the tool line out of the progress message; the web app's rooms set it, Discord keeps the line.
+
+### Fixed
+
+- `ask_user` posts no card while the host stops: open cards live in the surface's memory and do not survive the restart, so the tool now tells the turn to ask in its reply instead. A card still waiting when the drain begins is reported lost rather than "stays open".
+
 ## [0.27.1] - 2026-10-31
 
 ### Fixed

package/README.md

@@ -192,6 +192,8 @@ A turn works 10 minutes by default before it asks you whether to go on, and 30 m
 | `turnLimits.cardSeconds` | `300` | How long that card waits for an answer, 30 to 3600; with none, the turn stops |
 | `autonomy.longRunning.maxSeconds` | `14400` (4 h) | The most a long-running conversation's turn works before it asks or stops, 600 to 604800 |
 | `autonomy.yolo.allow`, `autonomy.yolo.card` | none | Hold classes yolo mode may approve beyond its defaults (`shell.rm`, say), and rule names whose calls it approves although the rule reports no classes (`tool:repo_push`, say), and classes or rule names it never approves (`shell.push`, say). By default yolo approves a plain `git push` and writes outside the workspace and cards the other destructive shell classes; see the [plugin guide](docs/plugins.md#hold-classes-and-yolo-mode) |
+| `autonomy.yolo.questionGraceSeconds` | `30` | In a yolo conversation, how long an `ask_user` card holds the turn, 5 to 600; unanswered, the turn goes on with its own best choice and the card stays open |
+| `autonomy.yolo.timeoutCardSeconds` | `60` | In a yolo conversation, how long the timeout card waits, 10 to 3600; unanswered, the turn goes on as if you pressed Continue, up to `autonomy.longRunning.maxSeconds` |
 
 Without `discord` the agents still run when `agents` lists them, in the rooms of a surface that hosts them, such as pi-roundtable-web; the host refuses to start when none does:
 

package/README.zh-TW.md

@@ -187,6 +187,8 @@ export default {
 | `turnLimits.cardSeconds` | `300` | 那張卡片等你回答多久，30 到 3600；時間到沒回答，這一輪就停止 |
 | `autonomy.longRunning.maxSeconds` | `14400`（4 小時） | 長時間執行對話的一輪，工作到這個上限才會詢問或停止，600 到 604800 |
 | `autonomy.yolo.allow`、`autonomy.yolo.card` | 無 | yolo 模式在預設之外可以核准的 hold 類別（例如 `shell.rm`），以及它也核准其呼叫的規則名稱（該規則沒有回報類別，例如 `tool:repo_push`），以及它永遠不核准的類別或規則名稱（例如 `shell.push`）。預設下 yolo 會核准一般的 `git push` 和工作區以外的寫入，其餘破壞性的 shell 類別仍然出卡；見[外掛指南](docs/plugins.md#hold-classes-and-yolo-mode) |
+| `autonomy.yolo.questionGraceSeconds` | `30` | yolo 對話裡，`ask_user` 卡片讓這一輪等多久，5 到 600；沒回答時，這一輪照它自己的最佳選擇繼續，卡片仍然開著 |
+| `autonomy.yolo.timeoutCardSeconds` | `60` | yolo 對話裡，逾時卡片等多久，10 到 3600；沒回答時，這一輪就像按了「繼續」一樣接著做，最多到 `autonomy.longRunning.maxSeconds` |
 
 沒有 `discord` 時，只要 `agents` 列了 agent，它們就在支援房間的 surface（例如 pi-roundtable-web）裡運作；沒有任何 surface 支援房間時 host 拒絕啟動：
 

package/docs/plugins.md

@@ -269,7 +269,7 @@ The built-in plugins provide these, from the main entry:
 | `ChannelContextSourceAttachment` | `pi-roundtable` | type |
 | `ChannelContextVerdict` | `pi-roundtable` | type |
 | `DELEGATION` | `Delegator` | `modules` | `start(request)` a background task, `runningChannels()`, `idle()` |
-| `THREADS` | `DispatchThreads` | `threads` | The threads of background dispatches (coding tasks, delegated tasks, messages between agents), on any surface that hosts them: `open(origin, title, intro?)` opens the thread under the channel `origin` through the `threads` of the surface that serves its prefix and resolves to a `DispatchThread`, or `undefined` when that surface hosts none or the channel cannot. See [Dispatch threads on any surface](#dispatch-threads-on-any-surface) |
+| `THREADS` | `DispatchThreads` | `threads` | The threads of background dispatches (coding tasks, delegated tasks), on any surface that hosts them: `open(origin, title, intro?)` opens the thread under the channel `origin` through the `threads` of the surface that serves its prefix and resolves to a `DispatchThread`, or `undefined` when that surface hosts none or the channel cannot. See [Dispatch threads on any surface](#dispatch-threads-on-any-surface) |
 | `CHANNEL_CONTEXT` | `ChannelContexts` | `channel-context` | `read(message, options?)` gives the context of one addressed message, from the surface whose key prefix its channel carries: the messages posted there since the assistant last posted, or `undefined` for a surface without `channelContext`, a channel that is not shared, and when nothing new was said. See [Channel context](#channel-context-what-was-said-around-an-addressed-message) |
 | `WORKER_SESSIONS` | `WorkerSessions` | `worker-sessions` | Fresh Pi sessions for a plugin's own workers, on the host's model login: `delegation` is the host's delegation `model` and `thinking`, and `run({ task, signal, prompt, extensions, toolNames, model?, thinking?, aborted? })` runs the task in a session that has only the tools `extensions` register and `toolNames` names (no built-in tool, skill, context file, memory or agent tool) and returns the worker's final answer; see [Workers of your own](#workers-of-your-own) |
 
@@ -459,7 +459,7 @@ A conversation can run with less supervision when its owner switches a mode on.
 | Mode | Effect |
 |---|---|
 | `longRunning` | A turn that reaches its time limit goes on by itself, up to `autonomy.longRunning.maxSeconds` of work, instead of asking on a card. See [long-running conversations](#long-running-conversations) |
-| `yolo` | The server approves the held calls whose [hold classes](#hold-classes-and-yolo-mode) it allows itself, before a card is posted, and logs each one. What it allows is `autonomy.yolo.allow` and `autonomy.yolo.card` in the config |
+| `yolo` | The server approves the held calls whose [hold classes](#hold-classes-and-yolo-mode) it allows itself, before a card is posted, and logs each one. What it allows is `autonomy.yolo.allow` and `autonomy.yolo.card` in the config. The cards it still posts do not stop the work: see [cards in a yolo conversation](#cards-in-a-yolo-conversation) |
 
 Both are off for a conversation nobody has set. `MODES` stores them in the `conversation_modes` table, one row per conversation key, so they survive a restart, and works for any key; a surface decides who may toggle them. Read a mode where you act on it, with `peek`, which never waits on the database. Change it with `set`, which writes first and updates the memory afterwards:
 
@@ -473,6 +473,12 @@ modes.peek(channel).longRunning; // true
 
 `set` throws `PluginError` for anyone but an owner, and for the host's own principal (`SYSTEM_PRINCIPAL`), so a webhook or a report turn cannot switch a conversation to run unattended. A change names only the modes it sets. It logs `conversation modes changed` with the channel, both modes and who changed them. `onChange(listener)` hears every change until the function it returns is called; a listener that throws is logged and the rest still hear it.
 
+#### Modes a temp knight inherits
+
+A temp knight's conversations (its Discord thread and its rooms) follow the yolo and long-running modes of the conversation that made it, live: `helper_create` records them with `follow(channels, origin, by)`, and `peek` on each returns the origin's modes with `ConversationMode.inheritedFrom` (`{ channel, name?, gone? }`, `name` the knight's display name). Switching a mode in the knight's conversation applies to its temp knights at once, and `onChange` tells each of their conversations too. `set` refuses a conversation that follows another (`PluginError`), so its modes are switched only where they come from; the web room's banner says "Inherited from <knight>" in place of its switches, and a switch in its menu is refused with that reason. When the origin's agent or group is archived or deleted, the temp knight's modes read off (`gone: true`). The follow is stored in the `follows` column of `conversation_modes` (the migration `conversation-modes-follows`), so it survives a restart; the agent server tells the modes which conversations still follow theirs with `trackOrigins`, so a name an agent takes later follows nothing. A yolo approval in a temp knight's turn names its own conversation in `autoApproved`.
+
+Inheriting adds no permission: an owner turned the modes on in the origin. `follow` takes an owner, as `set` does, so only an owner's turn makes a temp knight follow; a temp knight that a member's turn, or the host's own, made follows nothing and starts with both modes off (`forget(channel)` drops a conversation's modes and what it follows, and needs no speaker since it only turns modes off). A temp knight made before 0.28 keeps the long-running mode it was given.
+
 When a held call is approved by yolo mode, `ApprovedBy.auto` is `"yolo"` (a person's answer never sets it; `ToolTurn.approvedBy` shows it to the tool), and the approver reports it with `autoApproved(entry)`, which logs `held call approved by yolo mode` and tells the `onAutoApproved` listeners, so a surface can show it. What yolo approves, and what it never does, is under [hold classes and yolo mode](#hold-classes-and-yolo-mode).
 
 ## Principals and access
@@ -1116,6 +1122,15 @@ export default {
 
 An approved call runs in the same turn. It is reported as approved by the speaker with `ApprovedBy.auto: "yolo"`, logged as `held call approved by yolo mode` (channel, tool, classes, principal) and told to `MODES.onAutoApproved` listeners. A message that confirms a held call works as before. A turn with no card surface is decided the same way, so an owner's own turn there goes on instead of holding the call.
 
+#### Cards in a yolo conversation
+
+Yolo mode still posts the two kinds of cards meant for a person, but neither stops autonomous work when no one answers:
+
+- An `ask_user` card holds the turn `autonomy.yolo.questionGraceSeconds` at most (`5` to `600`, default `30`; `Autonomy.yolo.questionGraceMs`), passed to the surface as `PromptWait.graceMs`, so Discord and the web app wait that long instead of their own grace. Unanswered, the tool tells the model to keep working: go on with its recommended option, or its best judgment, and say in its reply what it assumed. The card stays open, and a later answer starts a new turn to correct course. Only a question that truly blocks (no safe choice without the answer, such as an irreversible or outward-facing step whose direction only the person can pick) may end the turn, after the work the answer does not affect is done. The turn's system prompt carries the same rule, so the model does not end a yolo turn with a question either.
+- The timeout card waits `autonomy.yolo.timeoutCardSeconds` (`10` to `3600`, default `60`; `Autonomy.yolo.timeoutCardGraceMs`), says that with no answer the turn keeps going, and, unanswered, extends the turn as **Continue** would; its closed card says it continued automatically, and the log says `yolo mode continued the turn; the timeout card went unanswered`. The extensions stop at `autonomy.longRunning.maxSeconds` of work: there the card is the usual one and no answer stops the turn. **Cancel** still stops it. Long-running mode, which extends without a card, is unchanged.
+
+The mode is read when the card is asked for, so a toggle applies to the next card. While the host stops, `ask_user` posts no card and reports a waiting one lost, in yolo as outside it. Outside yolo nothing changes.
+
 **Plain `git push` and writes outside the workspace are approved under yolo**, because they are the non-destructive shell classes (`shell.push`, `shell.write`). A plain push to `main` deploys wherever a push to `main` deploys. To keep it behind a card, put `shell.push` in `autonomy.yolo.card`; to keep every write outside the roots behind one, put `shell.write` there.
 
 #### The shell rule
@@ -3027,7 +3042,7 @@ The agent server claims `discord:` keys, and, only on a surface that declares `a
 |---|---|---|
 | `surface` | The key prefix | (required) |
 | `start(deliver)` | Connects, and calls `deliver(message)` for every incoming message; the host passes its conversation router | (required) |
-| `sendReply(channel, reply)` | Posts an `OutboundReply`: a thinking line, a card, text chunks, then files | (required) |
+| `sendReply(channel, reply)` | Posts an `OutboundReply`: a thinking line, a card, text chunks, then files; a reply with `intercom` is a message between agents, which a surface may draw as a small card in place of its chunks | (required) |
 | `stop()` | Disconnects when the host stops | nothing to stop |
 | `agentRooms` | `true` makes the surface host [agent rooms](#agent-rooms-on-any-surface): a conversation with each agent and group of the team, as `<surface>:agent.<name>` and `<surface>:group.<name>` | no rooms; the agent team answers only in Discord |
 | `threads` | A `SurfaceThreads` that hosts [dispatch threads](#dispatch-threads-on-any-surface): a background dispatch started in one of the surface's channels opens its thread there, and the thread is the conversation `<surface>:<id>` | the dispatch posts in the channel as before |
@@ -3038,7 +3053,7 @@ The agent server claims `discord:` keys, and, only on a surface that declares `a
 | `showStop(channel)` | Shows the owner a stop control until the returned function is called; using it calls `conversations.stop(channel)`. A group's round shows it for the whole round, and stopping ends the round: the member speaking is stopped and the members still waiting do not speak | none is shown |
 | `react`, `unreact` | Adds or removes the bot's reaction on a message | no marks on queued or steered messages |
 | `prompts(channel, scope?)` | How those the turn's `PromptScope` names approve a held action or answer `ask_user` inside a running turn, as `Prompts`: `confirm` and `ask`, and, where the surface declares `asks`, `questionnaire` ([several questions on one card](#several-questions-on-one-card-questionnaire-and-asksupport)); without a scope, the owners | the action is held until a message approves it |
-| `interim(channel, as?)` | Where a running turn posts the text it writes before its final answer, as `InterimPosts`: `post(text)` sends one message of at most 2000 characters and resolves to an `InterimMessage` whose `edit(text)` changes it in place. `as` is a `PostAuthor` (`{ name, agent? }`) when an agent of the team speaks, as `OutboundReply.author` is for the final reply | only the final reply is posted |
+| `interim(channel, as?)` | Where a running turn posts the text it writes before its final answer, as `InterimPosts`: `post(text)` sends one message of at most 2000 characters and resolves to an `InterimMessage` whose `edit(text)` changes it in place. `tools: false` leaves the tool line out of the progress message, for a surface that shows tool use elsewhere. `as` is a `PostAuthor` (`{ name, agent? }`) when an agent of the team speaks, as `OutboundReply.author` is for the final reply | only the final reply is posted |
 | `progress(channel, event)` | Shows a turn run through `context.turns` as it goes, such as a live preview in a web chat. `event` is a `TurnProgress`: `{ type: "text", delta }` (the reply's text, joined over 250 ms and always sent before a tool event, never the thinking), `{ type: "tool_start", id, tool, preview? }` (a one-line preview of the arguments, at most 80 characters, never their full text), or `{ type: "tool_end", id, tool, ok, refused? }` (`refused`, only on a failed end that a hold refused, says how: `declined` on its approval card, `expired` when a card was shown and went unanswered, `pending` while the card stays open, or `held` when no card could be shown (no one may approve it, or it could not be posted); it is absent for a success and for a real failure). The final reply still comes through `sendReply`; a rejection is logged and the turn goes on | only the final reply is shown |
 | `groupRound(channel, round)` | Shows where a group room's round stands: a `RoundProgress`, `{ id, state, current?, next, spoken, replies, limit, ended?, queued? }`, with `id` the group message that opened the round, `state` `running` or `ended`, `current` the member speaking, `next` those still to speak in order (a handoff appended), `spoken` those who replied, `ended` (once it ended) `done`, `limit` or `stopped`, and `queued` the owner's messages waiting for the next round. Called when the round is planned, before and after each member's turn, and when it ends; each call carries the whole state. Called for the room keys of a surface that hosts rooms, never for a Discord channel; a rejection is logged and the round goes on | the surface shows no rounds |
 
@@ -3049,7 +3064,7 @@ A room is a conversation of its own, apart from the agent's or group's Discord c
 A room has its own session and held actions, so a card or an approving message in the web room does not touch the Discord channel's.
 A group's room keeps its own log, `<group>@<surface>`, with the seats `agentgroup:<surface>.group.<group>.<agent>`; the Discord channel's log and seats are untouched.
 A schedule an agent sets from a room belongs to the room, and the agent's own `schedule_list`, `schedule_update` and `schedule_cancel` reach it from every other conversation of that agent (its Discord channel and each room, `AGENTS.team.roomsOf(name)`); `schedule_list` says where each one fires. Only the agent's own schedules: another agent's are still read by name with `agent`, never changed.
-`message_agent` delivers into the target's most recent conversation, the one it last ran a turn in (kept in the table `agent_latest_conversation`, so a restart keeps it), whether that is its Discord channel or a room. An agent that has run no turn yet is reached on the sender's surface: a room's message stays among the rooms. The optional `conversation` chooses another: `"discord"`, `"web"` (the one surface that hosts rooms, or that surface's name), or one of the conversation keys `agent_get` lists. The answer, and the follow-up turn it wakes, return to the conversation the sender wrote from, wherever the target answered. When the surface of the sender hosts [dispatch threads](#dispatch-threads-on-any-surface) the exchange opens its thread there, as it does in a Discord channel, and the request and the answer go there under each agent's name.
+`message_agent` delivers into the target's most recent conversation, the one it last ran a turn in (kept in the table `agent_latest_conversation`, so a restart keeps it), whether that is its Discord channel or a room. An agent that has run no turn yet is reached on the sender's surface: a room's message stays among the rooms. The optional `conversation` chooses another: `"discord"`, `"web"` (the one surface that hosts rooms, or that surface's name), or one of the conversation keys `agent_get` lists. The answer, and the follow-up turn it wakes, return to the conversation the sender wrote from, wherever the target answered. The sender's conversation shows the exchange as cards, through `sendReply` with `OutboundReply.intercom` (an `IntercomCard`: `kind` `sent`, `answered` or `failed`, the agent the request went to as `peer`, and the whole `text`): the request under the sender's name when it is sent, then the answer, or why none came, under the target's. A surface that shows cards draws a small card that opens to the text; `chunks` carry the card's heading and the text for one that does not. An empty answer posts no card, and no thread is opened.
 Starting a room over resets that room's session (or a group room's seats) alone.
 Archiving an agent or group clears the schedules and sessions of every key `AGENTS.team.roomsOf(name)` lists: its Discord channel, when it has one, then its room on each surface, and the room stops being owned: `AGENTS.team.owns(room)` is `undefined`, the agent server's claim no longer takes its messages, and a surface should refuse them (the web disables the composer) instead of delivering them to a room nobody answers in.
 
@@ -3090,7 +3105,7 @@ Both tools are on the `member` tier and are offered to every agent that is not i
 A temp knight is a real agent: an ordinary row of the agent table with a nullable `parent` and `finished_at` (the migration `agents-helpers`, additive), its own prompt, picture and sessions, and a name that defaults to `<parent>-<n>`.
 Its model and thinking level are its knight's unless the call names others.
 It has no group seat, and no agent, group, archive, channel-arrange or schedule tools.
-It follows its knight's routing rules, and whether it counts as a long-running conversation follows the conversation that made it.
+It follows its knight's routing rules, and its yolo and long-running modes follow the conversation that made it, live (see [modes a temp knight inherits](#modes-a-temp-knight-inherits)).
 
 | Rule | What happens |
 |---|---|
@@ -3111,7 +3126,7 @@ defineRoundtable({
 
 #### Dispatch threads on any surface
 
-A background dispatch (a coding task, a delegated task, a message between agents) gets a thread beside the channel that started it: one start line in the channel, then the dispatch's progress and report inside the thread.
+A background dispatch (a coding task, a delegated task) gets a thread beside the channel that started it: one start line in the channel, then the dispatch's progress and report inside the thread.
 A surface hosts them with `threads`, a `SurfaceThreads`:
 
 | Method | What the surface does |
@@ -3192,12 +3207,12 @@ Because anyone who can see the card can copy the text, it holds nothing they may
 #### A prompt that outlives its turn: `PromptWait`
 
 `confirm(title, message, signal?, minTier?, wait?)` and `ask(title, question, signal?, wait?)` take an optional `PromptWait`, whose `late(answer)` hears a `LateAnswer` (`{ kind: "approval", approved, by, approvedBy?, prompt? }`, `approvedBy` naming the approver where the surface knows them and `prompt` the id of the card that was answered, `{ kind: "question", answer, by }`, or `{ kind: "questionnaire", answer: QuestionnaireAnswer, by }`, `by` naming who answered; only a `questionnaire` call can produce the last) and returns the text of the turn that tells the conversation, or undefined for none.
-Given one, a surface may stop the turn's wait after a grace period: `confirm` then resolves `pending` and `ask` resolves `"pending"`, the prompt stays open, and when it is answered later the surface starts a turn in the prompt's conversation with that text, as a message from whoever answered, so the conversation's claim answers it as theirs.
+Given one, a surface may stop the turn's wait after a grace period (`wait.graceMs` when the turn gives one, as a yolo turn's `ask_user` does, else the surface's own): `confirm` then resolves `pending` and `ask` resolves `"pending"`, the prompt stays open, and when it is answered later the surface starts a turn in the prompt's conversation with that text, as a message from whoever answered, so the conversation's claim answers it as theirs.
 Without one, a prompt waits for its answer, or for its turn's stop; a surface that cannot start a turn ignores `wait` and waits too.
 A stop cancels a prompt only while its turn still waits on it; after that the prompt belongs to the conversation.
 
 The runtime gives both of its prompts a `wait`.
-`ask_user` then tells the model the person has not answered yet and to end its turn saying it is waiting, without asking again, and the late answer's turn carries the question and the answer.
+`ask_user` then tells the model the person has not answered yet and to end its turn saying it is waiting, without asking again (in a yolo conversation, to keep working instead; see [cards in a yolo conversation](#cards-in-a-yolo-conversation)), and the late answer's turn carries the question and the answer.
 A held action's call is blocked as awaiting the approval, and is not held for a later message; a late approval lets that exact call (same tool, same canonical input) run once, and its turn tells the model to make it now and report the result, so the call runs under the gate and tier rules every call does. The release is the approval of one call, so it is spent only by that call: in a turn whose speaker is the person who approved on the card (or an owner; a surface that does not say who approved leaves it to any speaker), and only when that person's message started the turn (`TurnRequest.byMessage`, set by the core's message paths: an owner's message in an agent channel, a group round, a web chat or remote MCP message). A schedule's, agent-message (follow-ups included), report, webhook or error-report turn never spends it, whoever its speaker is and whatever their tier, and the system principal never does; they show the card again, within an hour of the answer (`LATE_RELEASE_TTL_MS`), and not after the identical call has run without a hold, which is the run the person approved, so it is dropped then. A release nobody spends in that time is gone, and the same call is held again for a card; a late refusal starts a turn that says so.
 A coding worker's cards give no `wait`, since nothing could resume a worker: it waits for the answer, and the waiting does not count against its time.
 
@@ -3231,7 +3246,7 @@ A model often writes text in an assistant message that then calls tools, such as
 On a surface that gives `interim`, and in the agent server's channels through the agents' webhooks, the host posts that text as the turn goes, sorted in two:
 
 - **Primary** text is posted as ordinary messages as soon as its assistant message ends: text of 400 characters or more, or written with a Markdown heading, list, table or code fence.
-- **Secondary** text, short narration between tool calls, goes to one progress message per run of tool-calling messages, in Discord's small text (`-# ` per line): each text as a line, then the tools called in the run, such as `-# bash ×3 · read · web_search` (names only). It is edited in place at most every 1.5 seconds, its last state always lands, and it stays inside 2000 characters by dropping its oldest lines behind `-# …`. A primary post or a card starts a new progress message.
+- **Secondary** text, short narration between tool calls, goes to one progress message per run of tool-calling messages, in Discord's small text (`-# ` per line): each text as a line, then the tools called in the run, such as `-# bash ×3 · read · web_search` (names only). It is edited in place at most every 1.5 seconds, its last state always lands, and it stays inside 2000 characters by dropping its oldest lines behind `-# …`. A primary post or a card starts a new progress message. Posts that set `InterimPosts.tools` to `false`, as the web app's rooms do because their progress pane shows the tools, get the narration without the tool line, and a run that wrote no narration posts nothing; Discord keeps the line.
 
 Before any card, an `ask_user` question or an approval, the host posts the pending text and brings the progress message up to date, so what the model wrote before the card shows above it.
 The final reply is posted at the end as before, with its thinking line; an intermediate message is never the final one, so nothing is posted twice, and a steered run keeps its final text.
@@ -3740,7 +3755,7 @@ The parts are medieval: the clothes, hats and gear of an agent are what a late-m
 
 ### The picture: `composeSvg`
 
-`ComposeOptions` are all optional: `expr` (one of the 13 `EXPRESSIONS`, by default the one `STATE_EXPRESSION` gives the state), `state` (one of the seven `AVATAR_STATES`: `idle`, `thinking`, `working`, `waiting`, `done`, `error`, `sleepy`), `look` (`modern-light` by default, `modern-dark`, `camelot-light` or `camelot-dark`, which change only the background and ring), `frame` (`disc` or `shield`), `bare` (no frame or background), `still`, `uid`, `size`, `label` and `skins` (six `#rrggbb` skin tones that `CharacterSpec.skin` indexes, in place of `CATALOG.skins`; anything but six valid colors throws a `CharacterError` whose `field` is `skins` or `skins[3]`).
+`ComposeOptions` are all optional: `expr` (one of the 13 `EXPRESSIONS`, by default the one `STATE_EXPRESSION` gives the state), `state` (one of the seven `AVATAR_STATES`: `idle`, `thinking`, `working`, `waiting`, `done`, `error`, `sleepy`), `look` (`modern-light` by default, `modern-dark`, `camelot-light` or `camelot-dark`, which change only the background and ring), `frame` (`disc` or `shield`), `bare` (no frame or background), `mouth` (`open` or `closed`, drawn in place of the expression's own mouth, for the two frames of a talking figure), `still`, `uid`, `size`, `label` and `skins` (six `#rrggbb` skin tones that `CharacterSpec.skin` indexes, in place of `CATALOG.skins`; anything but six valid colors throws a `CharacterError` whose `field` is `skins` or `skins[3]`).
 
 - The output has literal colors only. It has no `style` attribute, variable, `<style>`, script, text, image, link, event handler or `<foreignObject>`, so a page whose content security policy forbids inline styles can inject it, and `canvas` rasterizes it as it is. It is at most 8 KB and the same for the same input. The root is `<svg class="av" data-expr>` and the layers are `<g class="NAME" data-part="NAME">` in a fixed order (`frame`, `ch` holding `back`, `body`, `head`, `hat`, `eyes-brows`, `mouth`, `fx`, `acc`, `prop`, then `state`); the prop group carries `data-prop`.
 - `composeSvg` checks the spec again with `parseCharacter`, so a spec cast from untrusted data throws instead of reaching the markup. `uid` (`/^[a-z0-9]{1,16}$/`, default `a`) ends every clip path id, so each avatar on a page needs its own `uid`: two with the same one share clip path ids and one clips the other. The server-side renders pass an explicit one. `size` (an integer up to 4096) adds `width` and `height`, which `canvas` needs. `label` (at most 200 characters) becomes `aria-label` with `<>"'=()&` written as entities; without it the figure is `aria-hidden`.
@@ -4137,7 +4152,7 @@ On `SIGTERM` or `SIGINT` the bot takes no new work at once, finishes what runs,
 Every call shares the same shutdown.
 Give the service manager a stop timeout longer than the drain limit plus about a minute for the steps after it, such as systemd's `TimeoutStopSec=5min` with the default three-minute drain; a shorter one has the manager kill the process in the middle of the drain.
 The built-in runtime limits a turn to 10 minutes of work by default (`turnLimits.timeoutSeconds`), not counting time spent waiting on the owner's cards. Each message steered into the running turn gives it the full budget again from that moment, up to a cap of 30 minutes of work for the whole turn by default (`turnLimits.maxSeconds`); once the cap is reached the turn takes no more steering, so a message waits for the next turn.
-When a limit fires on a turn that can show a card (an owner's turn or a report turn on a surface with cards, the same turns that can ask with `ask_user` or an approval card), the turn is not aborted: it keeps working and a card asks the owner whether to go on. The card names the limit, how long the turn has worked, what it is doing now (the tool running and for how long, or waiting on the model, or compacting the conversation) and the tools it called so far, by name and count, never their inputs. **Continue** gives the turn another full budget from the answer; at the cap it moves the cap too, to a full budget from the answer, so the owner can keep going in steps. **Cancel** aborts the turn. With no answer within `turnLimits.cardSeconds` of wall time (5 minutes by default) the turn is aborted. The time the card is open counts as work, unlike an `ask_user` or approval card, because the turn keeps working; while it is open the turn takes no steering. If the turn finishes first, the card closes saying so and the reply is posted as usual; a press after that gets the usual "no longer valid" reply. The card's buttons come from `ApprovalOptions.wording` on `Prompts.confirm`, with `supersede` closing it, and `ApprovalOptions.purpose` is `"turn-timeout"` on it (`"action"` or absent on a held call's approval), so a surface can tell the two apart and notify on the first; Discord ignores `purpose`. A surface that shows approvals shows it; one that ignores `wording` shows its own approve and decline labels.
+When a limit fires on a turn that can show a card (an owner's turn or a report turn on a surface with cards, the same turns that can ask with `ask_user` or an approval card), the turn is not aborted: it keeps working and a card asks the owner whether to go on. The card names the limit, how long the turn has worked, what it is doing now (the tool running and for how long, or waiting on the model, or compacting the conversation) and the tools it called so far, by name and count, never their inputs. **Continue** gives the turn another full budget from the answer; at the cap it moves the cap too, to a full budget from the answer, so the owner can keep going in steps. **Cancel** aborts the turn. With no answer within `turnLimits.cardSeconds` of wall time (5 minutes by default) the turn is aborted; in a yolo conversation the card waits `autonomy.yolo.timeoutCardSeconds` instead and the turn goes on (see [cards in a yolo conversation](#cards-in-a-yolo-conversation)). The time the card is open counts as work, unlike an `ask_user` or approval card, because the turn keeps working; while it is open the turn takes no steering. If the turn finishes first, the card closes saying so and the reply is posted as usual; a press after that gets the usual "no longer valid" reply. The card's buttons come from `ApprovalOptions.wording` on `Prompts.confirm`, with `supersede` closing it, and `ApprovalOptions.purpose` is `"turn-timeout"` on it (`"action"` or absent on a held call's approval), so a surface can tell the two apart and notify on the first; Discord ignores `purpose`. A surface that shows approvals shows it; one that ignores `wording` shows its own approve and decline labels.
 A turn that cannot show a card (a schedule's turn, a member's turn, an agent's message, an agent's opening task, a turn without a surface) is aborted at once, as before, unless the conversation is [long-running](#long-running-conversations) or, for a schedule, the schedule has its own `time_limit_minutes`. The failure it posts in the conversation names the limit and, for such a turn, says that no one was in the conversation to ask for more time and how to allow it (`TurnTimeout.unasked`), so the owner sees where it stopped. Either way an aborted turn fails with a `TurnTimeoutError` (an `AgentRunError`) whose `timeout` (`TurnTimeout`) holds the limit, the work time, the running tools, whether it was compacting, the tools so far, and how it ended (`end`: `"timeout"`, `"cancelled"` by the owner, or `"unanswered"`); its message says the same in English, and the failure the conversation posts says it in the host's language instead of the generic failure notice.
 The limits are the config's `turnLimits`, which the runtime plugin passes on to `turnTimeoutMs`, `turnMaxMs` and `turnTimeoutCardMs` of `PiAgentRuntimeOptions` (a host that builds the runtime itself sets those directly):
 
@@ -4153,7 +4168,7 @@ A turn whose model ignores its abort (a subprocess that does not exit) is given
 
 ### Long-running conversations
 
-An owner can switch a conversation to long-running mode, so a turn that reaches its limit goes on by itself instead of asking, or aborting when it cannot show a card. The server extends the limit exactly as **Continue** would, and logs `long-running mode continued the turn`. The cap is per turn: it counts the turn's work since it started, not the time spent on cards, and the extensions stop exactly at it (a `turnLimits.timeoutSeconds` of 3 hours with a 4-hour cap asks or aborts at 4 hours of work, not at 6). It is `autonomy.longRunning.maxSeconds` in the config (`600` to `604800`, default `14400`, four hours). At the cap the turn behaves as an ordinary one: a card whose `ApprovalOptions.purpose` is `"turn-timeout"`, so a surface can push it, or an abort. `ask_user` and approval cards are never answered automatically. `agent_create` takes `long_running: true` to switch the new agent's conversations to this mode before its opening task starts; only an owner's turn may (a lower tier, or the host's own turn, is refused before anything is made), and a host with no `modes` service refuses it.
+An owner can switch a conversation to long-running mode, so a turn that reaches its limit goes on by itself instead of asking, or aborting when it cannot show a card. The server extends the limit exactly as **Continue** would, and logs `long-running mode continued the turn`. The cap is per turn: it counts the turn's work since it started, not the time spent on cards, and the extensions stop exactly at it (a `turnLimits.timeoutSeconds` of 3 hours with a 4-hour cap asks or aborts at 4 hours of work, not at 6). It is `autonomy.longRunning.maxSeconds` in the config (`600` to `604800`, default `14400`, four hours). At the cap the turn behaves as an ordinary one: a card whose `ApprovalOptions.purpose` is `"turn-timeout"`, so a surface can push it, or an abort. `ask_user` and approval cards are never answered automatically (yolo mode lets an unanswered `ask_user` card go on without its answer; see [cards in a yolo conversation](#cards-in-a-yolo-conversation)). `agent_create` takes `long_running: true` to switch the new agent's conversations to this mode before its opening task starts; only an owner's turn may (a lower tier, or the host's own turn, is refused before anything is made), and a host with no `modes` service refuses it.
 In a turn nobody is present in (a schedule's, an agent's message, an opening task) `ask_user` has no card to show: it refuses at once, telling the model to write the question as its final answer, which is posted to the agent's room, and the answer arrives as a new turn.
 
 The mode is the conversation's, set with `MODES.set(channel, { longRunning: true }, speaker)` and read with `MODES.peek(channel)`; see [the `MODES` service](#conversation-modes-modes). A surface decides who may toggle it.
@@ -4461,6 +4476,7 @@ Import from the entries listed below; source area files are internal.
 | `IdentityService` | `pi-roundtable` | type |
 | `ImageDrawer` | `pi-roundtable` | type |
 | `InboundMessage` | `pi-roundtable` | type |
+| `IntercomCard` | `pi-roundtable` | type |
 | `InterimMessage` | `pi-roundtable` | type |
 | `InterimPosts` | `pi-roundtable` | type |
 | `InterimTextMode` | `pi-roundtable` | type |

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "pi-roundtable",
-	"version": "0.27.1",
+	"version": "0.28.0",
 	"description": "A plugin-driven Pi agent server for one owner, reached through Discord or the web",
 	"type": "module",
 	"license": "MIT",

package/src/characters/compose.ts

@@ -30,6 +30,11 @@ export type CharacterLook =
 export interface ComposeOptions {
 	/** Default `STATE_EXPRESSION[state ?? "idle"]`. */
 	expr?: Expression;
+	/**
+	 * The mouth drawn open or closed in place of the expression's own, for the frames of a talking
+	 * figure; the expression's own mouth when absent.
+	 */
+	mouth?: "open" | "closed";
 	/** With `still`: which overlay is baked in. Live output carries every overlay. */
 	state?: AvatarState;
 	/** Background and ring only. Default `"modern-light"`. */
@@ -55,6 +60,7 @@ export interface ComposeOptions {
 
 const LOOKS = ["modern-light", "modern-dark", "camelot-light", "camelot-dark"];
 const FRAMES = ["disc", "shield"] as const;
+const MOUTHS = ["open", "closed"] as const;
 const UID = /^[a-z0-9]{1,16}$/;
 const MAX_LABEL = 200;
 const MAX_SIZE = 4096;
@@ -174,6 +180,10 @@ export function composeSvg(
 		"look",
 	) as CharacterLook;
 	const frame = checkOneOf(FRAMES, options.frame ?? "disc", "frame");
+	const mouth =
+		options.mouth === undefined
+			? undefined
+			: checkOneOf(MOUTHS, options.mouth, "mouth");
 	const uid = options.uid ?? "a";
 	if (typeof uid !== "string" || !UID.test(uid))
 		throw new CharacterError("uid", "must match /^[a-z0-9]{1,16}$/");
@@ -203,6 +213,7 @@ export function composeSvg(
 	const face = faceParts(
 		{ ink: INK, brow: mix(s.hairColor, INK, 0.5), dot: mix(tones.p, INK, 0.1) },
 		expr,
+		mouth,
 	);
 
 	const hair = HAIR[s.hair](tones);

package/src/characters/parts-face.ts

@@ -22,6 +22,22 @@ type MouthShape =
 	| "tongue"
 	| "yawn"
 	| "tilt";
+/** The mouths that show an open mouth; the rest are a closed line. */
+const OPEN_MOUTHS: ReadonlySet<MouthShape> = new Set([
+	"grin",
+	"o",
+	"tongue",
+	"yawn",
+	"tilt",
+]);
+
+/** A talking figure's mouth for one frame: the expression's own when it already is open or closed, else an open "o" or a closed smile. */
+function talking(shape: MouthShape, mouth: "open" | "closed"): MouthShape {
+	const open = OPEN_MOUTHS.has(shape);
+	if (mouth === "open") return open ? shape : "o";
+	return open ? "smile" : shape;
+}
+
 type Extra = "blush" | "sweat" | "tear" | "sparkle" | "dots" | "burst";
 
 interface ExpressionRow {
@@ -263,9 +279,14 @@ const star = (x: number, y: number, r: number, color: string): string =>
 const drop = (x: number, y: number, s: number, color: string): string =>
 	`<path d="M${x} ${y - 3.6 * s}Q${x + 3 * s} ${y + 0.2 * s} ${x} ${y + 2.8 * s}Q${x - 3 * s} ${y + 0.2 * s} ${x} ${y - 3.6 * s}Z" fill="${color}"/>`;
 
-export function faceParts(colors: FaceColors, expression: Expression): Face {
+export function faceParts(
+	colors: FaceColors,
+	expression: Expression,
+	talk?: "open" | "closed",
+): Face {
 	const c = FACE;
 	const row = EXPRESSION_ROWS[expression];
+	const shape = talk === undefined ? row.mouth : talking(row.mouth, talk);
 	const [lx, ly] = row.look;
 	const eye = (cx: number, side: 0 | 1) => {
 		const big = row.big && !side;
@@ -279,7 +300,7 @@ export function faceParts(colors: FaceColors, expression: Expression): Face {
 	) =>
 		`<path d="M${-c.bl / 2} 0H${c.bl / 2}" transform="translate(${cx} ${f1(c.ey + c.bdy + dy)}) rotate(${side ? -tilt : tilt})" stroke="${colors.brow}" stroke-width="${c.bw}" stroke-linecap="round" fill="none"/>`;
 	const brows = `<g class="brows">${brow(c.ex[0], row.bl, 0)}${brow(c.ex[1], row.br, 1)}</g>`;
-	const mouth = `<g class="mouth" transform="translate(${c.mx} ${c.my}) scale(${c.ms})">${mouthShape(row.mouth, colors.ink)}</g>`;
+	const mouth = `<g class="mouth" transform="translate(${c.mx} ${c.my}) scale(${c.ms})">${mouthShape(shape, colors.ink)}</g>`;
 	const [fx, fy] = c.fx;
 	const blush = (cx: number) =>
 		`<ellipse cx="${cx}" cy="${c.ey + c.by}" rx="${c.br}" ry="${f1(c.br * 0.62)}" fill="#ff7a8e" opacity=".5"/>`;

package/src/core/agents/agent-messages.ts

@@ -1,9 +1,9 @@
-import type { ChannelKey } from "../domain/conversation.ts";
+import type { ChannelKey, IntercomCard } from "../domain/conversation.ts";
 import { AgentError, IdentityError } from "../domain/errors.ts";
 import type { AgentTurnScope } from "../domain/ports.ts";
 import { HostStoppingError } from "../errors.ts";
-import { messages } from "../i18n/index.ts";
 import { SYSTEM_PRINCIPAL } from "../identity/principal-store.ts";
+import { intercomPlain } from "../presentation/intercom.ts";
 import { isQuiet } from "../presentation/reply-body.ts";
 import { splitReply } from "../presentation/reply-splitter.ts";
 import { addressee, type Speaker } from "../speakers.ts";
@@ -14,14 +14,12 @@ import {
 	agentReplyText,
 	chainLimitReason,
 	deliveredMessagePost,
-	returnedAnswerPost,
 } from "./agent-prompt.ts";
 import type { Agent } from "./agent-store.ts";
 import { conversationLabel, messageTarget } from "./message-target.ts";
 import { discordIdOf, discordKey, scopeOf } from "./team-keys.ts";
 import {
 	type Chain,
-	type Exchange,
 	MAX_CHAIN_MESSAGES,
 	type TurnHost,
 } from "./team-turn-types.ts";
@@ -90,25 +88,18 @@ export class AgentMessages {
 		chain.messages += 1;
 		// A temp knight is working from the moment a message is handed to it until it has answered.
 		this.#host.helpers.begin(target.name);
-		// The thread opens in the sender's turn channel, on its surface when that hosts threads; a
-		// surface that hosts none leaves the answer returning to the sender's conversation.
-		const exchange = this.#openExchange(parent, sender, target, text);
+		// The request shows in the sender's turn channel as a small card under the sender's name.
+		this.#card(parent, sender, {
+			kind: "sent",
+			peer: this.#peer(target),
+			text,
+		});
 		void queue
 			.run(targetChannel, async () =>
-				this.#deliver(
-					sender,
-					target,
-					text,
-					chain,
-					await exchange,
-					targetChannel,
-					parent,
-				),
+				this.#exchange(sender, target, text, chain, targetChannel, parent),
 			)
 			.catch((error: unknown) => {
 				if (error instanceof HostStoppingError) {
-					// Refused before it started: the thread it opened has nothing more to hold.
-					void exchange.then((opened) => opened?.thread.close());
 					this.#keep({
 						kind: "message",
 						sender: sender.name,
@@ -139,69 +130,36 @@ export class AgentMessages {
 		return `Sent to "${target.displayName}" in its ${conversationLabel(targetChannel)}. It works there; its answer comes back to you as a new turn.`;
 	}
 
+	/** The other agent of a card, as it is named now. */
+	#peer(agent: Agent): IntercomCard["peer"] {
+		const current = this.#host.current(agent);
+		return { name: current.name, displayName: current.displayName };
+	}
+
 	/**
-	 * Opens the message's thread in the sender's turn channel, a Discord channel or a room, and
-	 * posts the request there under the sender's name; undefined where no thread opens. Never
-	 * rejects.
+	 * Posts a card of the exchange in the channel under `as`'s name: the card where the channel's
+	 * surface shows cards, and its heading and text where it shows none. Never rejects.
 	 */
-	async #openExchange(
-		parent: ChannelKey,
-		sender: Agent,
-		target: Agent,
-		text: string,
-	): Promise<Exchange | undefined> {
-		const thread = await this.#host.options.threads?.open(
-			parent,
-			`→ ${target.displayName}`,
-		);
-		if (!thread) return undefined;
-		await this.#host
-			.post(parent, this.#host.current(sender), {
-				chunks: splitReply(
-					deliveredMessagePost(this.#host.current(target), text),
-				),
-				threadId: thread.id,
+	#card(channel: ChannelKey, as: Agent, card: IntercomCard): Promise<void> {
+		return this.#host
+			.post(channel, this.#host.current(as), {
+				chunks: splitReply(intercomPlain(card)),
+				intercom: card,
 			})
 			.catch((error: unknown) =>
 				this.#host.options.logger.warn(
-					{ err: error },
-					"agent request not threaded",
+					{ channel, kind: card.kind, err: error },
+					"agent message card not posted",
 				),
 			);
-		return { parent, thread };
-	}
-
-	/** Runs the target's turn, then posts its answer and wakes the sender; closes the thread either way. */
-	async #deliver(
-		sender: Agent,
-		target: Agent,
-		text: string,
-		chain: Chain,
-		exchange: Exchange | undefined,
-		targetChannel: ChannelKey,
-		senderChannel: ChannelKey,
-	): Promise<void> {
-		try {
-			await this.#exchange(
-				sender,
-				target,
-				text,
-				chain,
-				exchange,
-				targetChannel,
-				senderChannel,
-			);
-		} finally {
-			await exchange?.thread.close();
-		}
 	}
 
+	/** Runs the target's turn, then shows its answer in the sender's channel and wakes the sender. */
 	async #exchange(
 		sender: Agent,
 		target: Agent,
 		text: string,
 		chain: Chain,
-		exchange: Exchange | undefined,
 		targetChannel: ChannelKey,
 		senderChannel: ChannelKey,
 	): Promise<void> {
@@ -223,9 +181,6 @@ export class AgentMessages {
 			chain,
 			{ unattended: true },
 		);
-		const thread = exchange?.thread;
-		if (thread && !result.ok)
-			await thread.close(messages().agentNoReply(result.error.message));
 		// A target with nothing to answer sends nothing back and wakes nobody.
 		if (isQuiet(result)) {
 			logger.info(
@@ -236,29 +191,22 @@ export class AgentMessages {
 		}
 		const current = this.#host.options.store.agent(sender.name);
 		if (current?.status !== "active") return;
-		// With a thread the answer goes there, leaving the sender's channel its own reply.
-		if (result.ok)
-			await this.#host
-				.post(senderChannel, this.#host.current(target), {
-					chunks: splitReply(returnedAnswerPost(result.text)),
-					...(thread ? { threadId: thread.id } : {}),
-				})
-				.catch((error: unknown) =>
-					logger.error({ err: error }, "agent answer not posted back"),
-				);
-		await thread?.close();
+		// The answer, or why none came, shows in the sender's channel as a small card.
+		await this.#card(senderChannel, target, {
+			kind: result.ok ? "answered" : "failed",
+			peer: this.#peer(target),
+			text: result.ok ? result.text : result.error.message,
+		});
 		const followUp = result.ok
 			? agentReplyText(
 					addressee(chain.speaker, this.#host.options.owner),
 					this.#host.current(target),
 					result.text,
-					thread?.mention,
 				)
 			: agentFailureText(
 					addressee(chain.speaker, this.#host.options.owner),
 					this.#host.current(target),
 					result.error.message,
-					thread?.mention,
 				);
 		// The answer is a report back to the sender, so its turn may ask the owner on cards.
 		void queue
@@ -407,7 +355,7 @@ export class AgentMessages {
 			await this.#followUp(sender, entry.channel, entry.text, chain);
 			return;
 		}
-		// Its thread was closed when the host refused it, so the answer returns to the sender's conversation.
+		// Its request card was posted when it was sent; the answer's card follows as it would have.
 		this.#host.helpers.begin(target.name);
 		try {
 			await this.#exchange(
@@ -415,7 +363,6 @@ export class AgentMessages {
 				target,
 				entry.text,
 				chain,
-				undefined,
 				entry.channel,
 				origin,
 			);

package/src/core/agents/agent-ports.ts

@@ -1,4 +1,5 @@
 import type { AgentRuntime, ContextUse } from "../contract/runtime.ts";
+import type { IntercomCard } from "../domain/conversation.ts";
 import type { InterimPosts } from "../domain/interim.ts";
 import type { ThinkingSetting } from "../models.ts";
 
@@ -24,6 +25,8 @@ export interface AgentPost {
 	files?: { name: string; data: Uint8Array }[];
 	/** A thread of the channel to post in instead, such as a dispatch's. */
 	threadId?: string;
+	/** A message between agents, shown as a small card in place of `chunks` where the channel can. */
+	intercom?: IntercomCard;
 }
 
 /**

package/src/core/agents/agent-prompt.ts

@@ -134,16 +134,8 @@ export function agentReplyText(
 	who: OwnerIdentity,
 	from: Agent,
 	text: string,
-	thread?: string,
 ): string {
-	return `(The agent "${from.displayName}" (\`${from.name}\`) answered your message. Continue with it and tell ${who.name} what matters; your reply is posted in your channel.${threadNote(thread)})\n\n${text}`;
-}
-
-/** Where the exchange was posted, when it had a thread. */
-function threadNote(thread: string | undefined): string {
-	return thread
-		? ` The exchange is in the thread ${thread}, now archived; link it when useful.`
-		: "";
+	return `(The agent "${from.displayName}" (\`${from.name}\`) answered your message. Continue with it and tell ${who.name} what matters; your reply is posted in your channel.)\n\n${text}`;
 }
 
 /** What the sender receives when the target could not answer. */
@@ -151,9 +143,8 @@ export function agentFailureText(
 	who: OwnerIdentity,
 	from: Agent,
 	reason: string,
-	thread?: string,
 ): string {
-	return `(The agent "${from.displayName}" (\`${from.name}\`) could not answer your message: ${reason}. Tell ${who.name} briefly, or try again later.${threadNote(thread)})`;
+	return `(The agent "${from.displayName}" (\`${from.name}\`) could not answer your message: ${reason}. Tell ${who.name} briefly, or try again later.)`;
 }
 
 /** A new agent's first turn. */
@@ -192,11 +183,6 @@ export function deliveredMessagePost(to: Agent, text: string): string {
 	return messages().messageDelivered(to.displayName, text);
 }
 
-/** How the target's answer appears in the sender's channel. */
-export function returnedAnswerPost(text: string): string {
-	return messages().answerReturned(text);
-}
-
 /** Why a chain of agent messages stops without the owner in between. */
 export function chainLimitReason(who: OwnerIdentity): string {
 	const o = ownerWords(who);

package/src/core/agents/agent-tools.ts

@@ -425,7 +425,7 @@ function toolDefs(
 			name: MESSAGE_AGENT_TOOL,
 			label: "Message agent",
 			description:
-				'Send a self-contained request to another agent. It returns at once; the agent works in its own conversation and its answer comes back to you as a new turn, in the conversation you are writing from. An agent has one conversation on each surface (Discord, the web app); by default the request lands in the one it used most recently, so work it started in the web app is answered there. Give conversation to choose another: "discord", "web", or one of the conversation keys agent_get lists for it. The exchange shows in its conversation, and a thread in yours.',
+				'Send a self-contained request to another agent. It returns at once; the agent works in its own conversation and its answer comes back to you as a new turn, in the conversation you are writing from. An agent has one conversation on each surface (Discord, the web app); by default the request lands in the one it used most recently, so work it started in the web app is answered there. Give conversation to choose another: "discord", "web", or one of the conversation keys agent_get lists for it. The request shows in its conversation, and the request and the answer show as small cards in yours.',
 			parameters: Type.Object({
 				to: NAME,
 				text: Type.String({ minLength: 1, maxLength: 4000 }),