todo: turn a chat into a commander or a bot, carrying its context

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-27 08:46:36 +00:00
parent 68f3643df7
commit 6762a32ea6
2 changed files with 54 additions and 3 deletions
@@ -0,0 +1,51 @@
+---
+id: agent-coordination/turn-a-chat-into-a-commander-or-a-bot
+title: 'Turn an ordinary chat into a commander or a bot, carrying its context along'
+theme: agent-coordination
+status: open
+created: 2026-08-27
+date_source: stated
+order: 4
+---
+
+**Every chat should have a "turn into commander" / "turn into bot" action, carrying the conversation's
+context into the new one.** Wanted 2026-08-27. The case: a conversation has already built up real
+context — you were investigating something, chatting through a problem — and only partway through does
+it become clear this should be a standing watcher or a standing job, rather than something to
+re-explain from a blank commander or bot.
+
+**Bot and commander are two real, different things today, not one feature with two names** — worth
+being precise about which is meant when this is built. Both are just "a conversation whose working
+directory is set to a special folder", per `permissions/registry.ts:312`: _"a bot IS a conversation
+whose working directory is `bots/`."_ But their briefs are opposite in size on purpose
+(`api/bots/brief.ts`'s own comment): **a bot is one sentence and a watch, arm-on-first-message, no
+interview.** **A commander is a job** — procedures, a ledger, a dispatch policy, a setup conversation.
+So "turn into bot" and "turn into commander" are different destinations with different expectations of
+how much ceremony happens next, not two labels for the same button.
+
+**The real obstacle, and it is structural, not a missing button:** both are created fresh today.
+`POST /command-hq/commanders/new` takes a `prompt`, a `name`, a `referencePath` — nothing that accepts
+an existing conversation's history — and starts a **new** transcript in the commander's own directory.
+Bots work the same way. And a Claude Code transcript's identity is scoped to the working directory it
+started in (verified this session: `~/.claude/projects/<slug-of-cwd>/<id>.jsonl`) — so there is no
+"just move this transcript" version of this feature. An ordinary `/chat` session's transcript lives at
+a different cwd than `commanders/<id>/` or `bots/`, and nothing repoints one transcript's directory
+after the fact.
+
+So "carrying context" has to mean actually transplanting something into the new session, and which
+something is the design question to settle before building, not after:
+
+- **Replay the full transcript** into the new commander/bot's directory as its opening — complete, but
+  potentially large, and a commander/bot's brief is deliberately short (arm-on-first-message for a bot;
+  a lean setup conversation for a commander) — dumping a long unrelated history in front of that
+  may work against the brief's own point.
+- **Summarize** what happened and seed the new session with the summary as its first message —
+  cheaper, but a summary is a lossy claim about a conversation, the same caveat this platform's own
+  email-recall design already states about summarizing versus retrieving.
+- Some hybrid: summary up front, full transcript kept alongside as a file the new session can go read
+  if it needs the detail rather than carrying it in every future turn's context.
+
+Related, not the same problem: `sub-agents/an-api-endpoint-for-spawning-an-agent-with-a` already
+answered "how do you start a commander from code" (`POST /api/sub-agents/spawn` / commander creation) —
+this item is specifically about carrying an EXISTING conversation's context across that boundary, which
+neither existing endpoint does.