Let the coordinator create workspaces and write findings in tasks

create_workspace gives the coordinator a way to start a workspace with its shared context, and the tool list is shared, so a new id can be used by create_bot or add_bot_to_workspace in the same reply.

A coordinator's tasks now get create_workspace and update_workspace too: the research task that had the material could only report it, never write it into the workspace, so the coordinator promised an update it had no turn to make.

A workspace created from chat is pushed as server:workspace-created, from the tool and from the live relay, so the rail shows it without a reload.

AGENTS.md

@@ -99,8 +99,8 @@ Inspect live data with `bun llm-code-assistant/query-db.ts "<sql>"` - a read-onl
 - **Prompt and memory (self-learning):** a bot has `system_prompt` (core instructions) and a separate core `memory` (markdown, general knowledge about its job, the same for every user it works for, never about one user). What it remembers about a user lives in `bot_user_memories` (one row per bot and user, seen only by that user's runs; `grab-bot-user-memory`, `update-bot-user-memory`), like workspace memory stays in its workspace. The bot rewrites them as it adapts (`update-bot-system-prompt`, `update-bot-memory` in `src/functions/backend/db/bots/`; whole-text replace, capped at `AppData.PromptMaxLength`). `grab-bot-prompt` builds the full prompt for the run's user via `composeBotPrompt` (`src/utils/compose-bot-prompt.ts`): core instructions, then (in a workspace only) `# Workspace: <name>` with its description and `system_prompt`, the bot's `# Your instructions in <name>` (`workspace_bots.system_prompt`), `# Memory`, `# Memory about the user`, then `# Memory in <name>` (`workspace_bots.memory`). `update_memory` saves to `user` by default (`workspace` in a workspace) and to `core` only for what holds for everyone. In a workspace the bot learns into the workspace's instructions and memory by default (`scope: workspace` on `update_instructions`/`update_memory`, `WorkspaceLearningNote`) and into its core ones only when told to, or after suggesting it. `src/scripts/move-bot-memory-to-owners.ts` (run once per install) moved core memory written before this into the owner's.
 - **Queue:** every bot job goes through `bots_queue`, with `kind` (`BotJobKinds`): `reply` (answers the user in chat, no task row) or `task` (long-running work, typically on a computer). Long-running work goes through `bots_queue`, a bun-sqlite `isQueue` table worked with the native `BunSQLite.queue` API (`status` pending|processing|completed|failed, `attempts`, `available_at`, `locked_at`/`locked_by`, `last_error`; options in `AppData.BotQueue*`). Not every message needs a job: the bot replies right away that it's on it and `enqueueBotJob` queues the brief (`instructions`, `params`, optional `message_id`/`computer_id`, the computer checked against the bot's access; a `bot_tasks` row is created unless `task_id` is given). DB helpers in `src/functions/backend/db/bots-queue/`: `claimBotJobs`, `updateBotJob` (renews the lock, saves `progress`/`checkpoint`; false once lost or cancelled), `completeBotJob` (result message, task done, face done/needs-you for the job's user), `failBotJob` (backoff retry, or `fatal`; out of attempts posts a needs-you message via `notifyBotJobFailed`), `cancelBotJob` (failed with `BotJobCancelledError`, `src/dict/bot-queue-dict.ts`), `releaseWorkerBotJobs`. Every model turn of a job is a step in `bots_queue_updates` (`kind` tool|note, one-line `text`, JSON `metadata`; tool names, never arguments; `describe-job-step.ts`), written through the job context's `report` (the text loop's `onStep`), which also sets `progress` and pushes `server:bot-job-update` (`BotJobUpdateData`). Steps are deleted with their job when it's pruned. The active task's latest `AppData.BotJobUpdatesShown` steps ride on `BotTaskWithSteps.updates` (`grabBotJobUpdates`); the conversation (`bot_task` page prop, `use-task-progress`) shows the latest one under `BotThinkingRow`'s "<name> is working…" while a task runs. Step text is the first line the model wrote, else plain labels for its tools (`JobStepToolLabels` in `src/dict/bot-queue-dict.ts`).
 - **Queue handler:** `src/bots-queue/index.ts`, started from `server.ts` after cron and gated the same way. It releases its own cut-off jobs on startup (stable worker `AppData.BotQueueWorker`), then polls every `BotQueuePollMs`: reports jobs bun-sqlite failed on a lock timeout (`report-lost-bot-jobs`), claims per kind (`claimBotJobs` mirrors bun-sqlite's atomic claim plus `kind`, since `queue.claim` has no filter) up to `BotQueueReplyConcurrency` replies and `BotQueueConcurrency` tasks on separate slots, and runs each with `processBotJob` (heartbeat at a quarter of the lock timeout, abort on cancel/loss, one task per computer and one reply per bot via `createKeyLock`, face `working` once it starts, outcome pushed live). The actual work is `run-bot-job.ts` (`BotJobRunner`, context in `types.ts`), which dispatches to `run-bot-reply.ts` and `run-bot-task.ts`. Throw `BotJobFatalError` for failures retrying can't fix. When every model is resting (`HarnessError.resting`, nothing was tried) the job is put back with `deferBotJob` until the first comes back, its attempt refunded and the bot's face `asleep`; other retryable harness errors retry no sooner than their `retry_at`. The `prune-bots-queue` cron deletes finished jobs after `BotQueueRetentionDays`.
-- **Live updates:** server push only. `sendToUser` (`src/websocket/(functions)/send-to-user.ts`) sends to one user's sockets; `pushBotNotice` sends `server:bot-message` (the message row, user messages too, for other tabs) and `server:bot-updated` (`BotUpdatedData`: face, status line, active task). The bots layout opens one socket (twui `useWebSocket`); components listen with `useServerEvent` (`src/hooks/`), and `useLiveBots` keeps the rail and header current. The conversation dedupes messages by id. Every process also runs `liveRelay` (`src/live-relay/`): every `AppData.LiveRelayPollMs` it reads new `bot_messages`, new `bots_queue_updates`, changed faces and changed bots from the database and pushes them to its own sockets, so work done by another process still shows live; clients drop what they already have. `server:bot-updated` carries the bot's `computer_id` when known, which keeps the header's computer in step across tabs. A bot that joins the crew or a workspace is pushed as `server:bot-created` (`BotCreatedData`: its rail row, the workspaces it's in, and whether it belongs in that user's own chat), from the tool that created it and from the live relay for other processes, so the rail lists it without a reload. A deleted bot is pushed as `server:bot-removed` (`BotRemovedData`) to the audience read before the delete, since its assignments go with it, so its rail row goes at once. A rail row's subtitle is the bot's status line while it has one, else (coordinator) the crew counts while a worker is busy or needs you, else its last message as plain text (`src/utils/message-preview.ts`).
+- **Live updates:** server push only. `sendToUser` (`src/websocket/(functions)/send-to-user.ts`) sends to one user's sockets; `pushBotNotice` sends `server:bot-message` (the message row, user messages too, for other tabs) and `server:bot-updated` (`BotUpdatedData`: face, status line, active task). The bots layout opens one socket (twui `useWebSocket`); components listen with `useServerEvent` (`src/hooks/`), and `useLiveBots` keeps the rail and header current. The conversation dedupes messages by id. Every process also runs `liveRelay` (`src/live-relay/`): every `AppData.LiveRelayPollMs` it reads new `bot_messages`, new `bots_queue_updates`, changed faces and changed bots from the database and pushes them to its own sockets, so work done by another process still shows live; clients drop what they already have. `server:bot-updated` carries the bot's `computer_id` when known, which keeps the header's computer in step across tabs. A bot that joins the crew or a workspace is pushed as `server:bot-created` (`BotCreatedData`: its rail row, the workspaces it's in, and whether it belongs in that user's own chat), from the tool that created it and from the live relay for other processes, so the rail lists it without a reload. A workspace a bot created is pushed the same way as `server:workspace-created` (`WorkspaceCreatedData`: its rail row), from the tool and from the live relay. A deleted bot is pushed as `server:bot-removed` (`BotRemovedData`) to the audience read before the delete, since its assignments go with it, so its rail row goes at once. A rail row's subtitle is the bot's status line while it has one, else (coordinator) the crew counts while a worker is busy or needs you, else its last message as plain text (`src/utils/message-preview.ts`).
-- **Workspaces:** `workspaces` (`name`, `description`, `system_prompt` shared by every bot in it, `computer_id` its default computer (not a foreign key), `archived`), with bots assigned through `workspace_bots` (plus that bot's `system_prompt` and `memory` there; the coordinator is an implicit member) and computers through `workspace_computers`. The first computer linked becomes the default; the user (workspace settings, chat header), any bot there (`set_workspace_computer`) or the coordinator can switch it. A workspace with no computer has none: tasks needing one fail. Workspace models (`workspace_harness_settings`) win over a bot's own, then the defaults. Helpers in `src/functions/backend/db/workspaces/` (`create-workspace`, `update-workspace`, `delete-workspace`, `add/remove-bot-*`, `update-workspace-bot`, `add/remove-computer-*`, `set-workspace-computer`, `grab-user-workspaces`, `grab-workspace-bots`, `grab-workspace-computers`, `grab-workspace-activity`), all access-checked against the session user, the structural ones for super admins and admins only; API in `api/admin/workspaces/`. The coordinator sets a member's instructions there with `set_bot_workspace_instructions`, and changes any workspace's name, description or context with `update_workspace` (chat replies).
+- **Workspaces:** `workspaces` (`name`, `description`, `system_prompt` shared by every bot in it, `computer_id` its default computer (not a foreign key), `archived`), with bots assigned through `workspace_bots` (plus that bot's `system_prompt` and `memory` there; the coordinator is an implicit member) and computers through `workspace_computers`. The first computer linked becomes the default; the user (workspace settings, chat header), any bot there (`set_workspace_computer`) or the coordinator can switch it. A workspace with no computer has none: tasks needing one fail. Workspace models (`workspace_harness_settings`) win over a bot's own, then the defaults. Helpers in `src/functions/backend/db/workspaces/` (`create-workspace`, `update-workspace`, `delete-workspace`, `add/remove-bot-*`, `update-workspace-bot`, `add/remove-computer-*`, `set-workspace-computer`, `grab-user-workspaces`, `grab-workspace-bots`, `grab-workspace-computers`, `grab-workspace-activity`), all access-checked against the session user, the structural ones for super admins and admins only; API in `api/admin/workspaces/`. The coordinator sets a member's instructions there with `set_bot_workspace_instructions`, creates a workspace with `create_workspace`, and changes any workspace's name, description or context with `update_workspace` (chat replies, and its own tasks so findings it was asked to record land in the workspace; a chat-created one is pushed as `server:workspace-created`).
 - **Computers:** a computer is an AIO sandbox in its own docker container on the `AppData.DockerNetworkName` network. `containers` records every docker container the app knows about except the main app container (`name` doubles as the hostname, plus `docker_id`, `image`, `network`, `port`, `status`, `metadata`). `computers` (the install's, `kind` main|sandbox, `container_id`) and `bot_computers` (direct access). The app creates and manages every computer's container over the docker socket (`src/functions/backend/docker/`; `DOCKER_SOCKET` or `AppData.DockerSocketPath`): `createComputer` records it and `provisionComputer` (in the background, status `creating`, then the container's or `failed` with `metadata.error`, pushed as `server:computer-updated`) pulls `AppData.ComputerImage`, binds the home dir and starts `<ComputerContainerPrefix>-<id>` limited to the computer's `cpus` and `memory_mb` (set at creation, default `AppData.ComputerDefaultCpus`/`ComputerDefaultMemoryMb`: 1 CPU, 2 GB), attached to the network in the same create call, with a docker health check (`AppData.ComputerHealthcheck`: the sandbox API on `ComputerPort` and its browser); the computer stays `creating` until it passes (`waitForHealthyContainer`), then records its IP address on the network (`containers.ip_address`, refreshed by `sync-computers`). `updateComputer` (`api/admin/computers/update-computer`) saves name, description and resources; new resources stop, remove and recreate the container (`provisionComputer`), the home dir kept. A computer's home (`/home/gem`) is `DATA_DIR/computers/<id>` (`AppData.ComputerDataDir`, owned by uid 1000); deleting the computer (`deleteComputer`, never the main one) removes the container and keeps that directory. Run in docker, the app resolves host paths from its own container's mounts and joins the network; outside docker (dev) it can't resolve container hostnames, so it reaches them at their IP address (`pickReachableAddress`: hostname first, then the IP, the pick cached for `AppData.ComputerAddressCacheMs`). Only super admins create, delete or retry computers (`api/admin/computers/`). The `sync-computers` cron records container states every five minutes. The install has one main computer, created at signup (`bun run seed`) and as a fallback by the super admin's `/admin/bots` via `ensureMainComputer` (`src/functions/backend/db/computers/ensure-main-computer.ts`, idempotent), which grants the coordinator access; with `MAIN_COMPUTER_URL` set (dev) it isn't provisioned. That one grant can't be removed (`isLockedComputerAccess`, enforced in `remove-bot-from-computer` and the `bot_computers` CRUD handler); every other grant can. A bot's effective computers (`grab-bot-computers`): in a workspace, the workspace's computers, its default first; otherwise its direct grants (the coordinator's are every computer), the one it's on first: `bots.computer_id` (not a foreign key; null or a lost grant means its main one), so `computers[0]` is where its tasks run by default. The user switches it from the chat header (`(partials)/bot-computers-modal.tsx`, a ghost icon beside the model icon; the header names the current computer and the text model and provider under the bot's name) or by clicking a computer the bot named in a message: bots write `[computer:ID]` (`src/utils/computer-ref.ts`, turned into `#computer-ID` links by `link-computer-refs.ts`, rendered by `(partials)/computer-ref-chip.tsx`), both sharing `BotComputersContext` / `use-bot-computers`, saved by `api/admin/bots/set-computer.ts` (`setBotComputer`). Enums in `src/dict/computer-dict.ts`.
 - **Opening a computer:** the app serves each computer to whoever sees it (`computersSql`) under `/computers/<id>/` (`ComputerProxyPrefix`): `src/server.ts` hands those paths to `handleComputerProxy` (`src/functions/server/computers/`: `userAuth`, access via `grabUserComputer`, then the sandbox's address from `grabComputerMcpUrl`), which fetches plain requests (app session cookies dropped, `X-Forwarded-Host/Proto/Prefix` set so the sandbox builds its links and CDP address under the prefix, framing headers and redirects fixed) and bridges websockets (`computerProxySocket`, dispatched from `src/websocket/` when `ws.data.proxy` is set). `ComputerView` (`src/components/general/computer-view.tsx`) shows a computer in one of `ComputerViewModes` (browser `/browser-ui`, terminal `/terminal`, code `/code-server/`, desktop: the sandbox's noVNC at `/vnc/vnc.html`, its socket pointed back through the proxy by the `{prefix}` placeholder that `computerViewUrl` fills in; desktop is the only view with Chrome's toolbar (extensions) and a clipboard panel, since the browser view streams pages over CDP and hides `chrome-extension://` targets; more of the sandbox's apps can be added there), keeping visited modes loaded. In the chat, `(partials)/computer-viewer-modal.tsx` shows it, opened from a computer card's open button in the computers modal or a take-over button (`openComputer` on `BotComputersContext`).
 - **Take-over:** a bot asks the user to take over a computer with `ask_user_to_take_over` (`src/harness/tools/computer/ask-to-take-over-tool.ts`, chat replies and tasks, defaulting to the task's computer). It writes `[take-over:ID:mode]` (`src/utils/take-over-ref.ts`; `withTakeOverRefs` adds it if the bot left it out and flags the message needs-you), linked by `link-computer-refs.ts` and rendered by `(partials)/take-over-chip.tsx`. The viewer then offers "Hand back to <bot>", which sends a chat message so the bot carries on; a task stops and reports instead of waiting.
@@ -130,7 +130,7 @@ Envs are set in Settings, under Environment (super admin only), not in `.env`. T
 - **Automatic picks** (`rank-auto-models`): free models that can do the job (on the setting's provider when it has one; a provider without free models needs a picked model) (`model-serves-harness`: text needs tools), by vendor `AutoModelVendorPreference` (DeepSeek, Qwen, NVIDIA, Liquid), then other vendors that look competent (`AppData.HarnessAutoMin*`), then routers; within a vendor by intelligence index, then full-size before small, newest first. Transcription puts real speech-to-text models first.
 - **Calling:** `resolveHarnessCandidates` (pinned, then automatic) -> `withCandidates` tries them in order with process-wide cooldowns (`resolve/harness-cooldowns.ts`): rate limits and outages rest the model (until `Retry-After` when given), 401/402 rest the whole provider, 403/404 rest the model for an hour. Errors are `HarnessError` (`code` provider|unavailable|aborted, `retryable`), classified in `to-harness-error.ts`. Entry points: `text/generate-text.ts` (one turn), `text/run-text-loop.ts` (tool loop, sticks to one model, wraps up after `HarnessMaxToolSteps`, trims the oldest tool output before each turn to fit the model's context, `fit-transcript-to-context.ts`), `media/read-image.ts`, `media/read-media.ts` (documents locally via `fileToText`, images and audio through their harnesses), `audio/transcribe-audio.ts`, `audio/speak-text.ts`, `image/generate-image.ts`. A text model that can't take an image or audio part gets it read by the vision/transcription harness first (`prepare-messages-for-model.ts`).
 - **Per-bot models:** in a workspace, its `workspace_harness_settings` row wins (`source: "workspace"`). Otherwise a worker bot inherits the defaults per harness unless it has a `bot_harness_settings` row (same fields as `harness_settings`, unique per bot and harness). `grabHarnessSetting({ harness, bot_id })` returns the bot's row (`source: "bot"`) or the default; the coordinator always gets the default. Every entry point takes `bot_id` and passes it on (text loop -> media reading/transcription), so a bot's run uses its own models throughout. Saved by `saveBotHarnessSetting` (`inherit` deletes the row); the page data is `grabBotHarnessOverview`. A bot's chat header has a ghost model icon (`(partials)/header-icon-button.tsx`; the text model and provider show under the bot's name) that opens a modal with every harness (`(partials)/bot-models-modal.tsx`); the modal and `/admin/bots/[bot_id]/models` both use `(partials)/bot-harness-form.tsx`. On the coordinator the modal edits the defaults themselves (`api/admin/harness/save-settings`, the same settings as Settings, under Models, without the providers): super admins only, the icon is disabled for everyone else. Every one of these wraps `settings/models/(partials)/harness-settings-form.tsx`: per harness a provider select first (`harness-provider-select.tsx`: any provider, one provider, or on a bot "Same as the default"), then the model select narrowed to it. Removing a provider (`deleteHarnessProvider`) puts default and bot settings that picked it or its models back on any provider (`save` prop; "Same as the default" shows when the overview item has `default`).
-- **Tools:** `HarnessTool` (built per run with its bot bound): own tools validate with a zod `schema`; tools described elsewhere pass a JSON schema as `parameters` and validate themselves. `run-tool-call.ts` reports bad calls and failures back to the model as `Error: ...`. Bot tools in `src/harness/tools/bot/`: `update_memory`, `update_instructions` (`grabBotTools`, every run), `start_task` and, for the coordinator with workers, `delegate_task` (`grabBotChatTools`, chat replies only; the job's `requested_by_bot_id` is the coordinator, and `relayJobToRequester` posts the worker's result or failure in its conversation, pushed as `relay` by `pushBotNotice`), `ask_user_to_take_over` (see Take-over), plus for the coordinator `create_bot` (add a worker with its name, role and instructions, and join it to a workspace straight away) and, in its own chat, `add_bot_to_workspace` (put an existing worker in one of the user's workspaces) and `assign_computer` (grant or revoke a worker's direct access, `add/remove-bot-to/from-computer`; access through a workspace stays and the result says so). `search_computers` (`src/harness/tools/computer/search-computers-tool.ts`, chat replies and tasks) runs one read-only command on all of a bot's computers at once over the sandbox REST API (`run-computer-command.ts`), each output under its `[computer:ID]`, secrets redacted, capped by `AppData.ComputerSearch*`.
+- **Tools:** `HarnessTool` (built per run with its bot bound): own tools validate with a zod `schema`; tools described elsewhere pass a JSON schema as `parameters` and validate themselves. `run-tool-call.ts` reports bad calls and failures back to the model as `Error: ...`. Bot tools in `src/harness/tools/bot/`: `update_memory`, `update_instructions` (`grabBotTools`, every run), `start_task` and, for the coordinator with workers, `delegate_task` (`grabBotChatTools`, chat replies only; the job's `requested_by_bot_id` is the coordinator, and `relayJobToRequester` posts the worker's result or failure in its conversation, pushed as `relay` by `pushBotNotice`), `ask_user_to_take_over` (see Take-over), plus for the coordinator `create_workspace` and `update_workspace` (a new workspace with its shared context, or changing one; both also in its tasks, so a task that gathers material can write it into the workspace), `create_bot` (add a worker with its name, role and instructions, and join it to a workspace straight away) and, in its own chat, `add_bot_to_workspace` (put an existing worker in one of the user's workspaces) and `assign_computer` (grant or revoke a worker's direct access, `add/remove-bot-to/from-computer`; access through a workspace stays and the result says so). `search_computers` (`src/harness/tools/computer/search-computers-tool.ts`, chat replies and tasks) runs one read-only command on all of a bot's computers at once over the sandbox REST API (`run-computer-command.ts`), each output under its `[computer:ID]`, secrets redacted, capped by `AppData.ComputerSearch*`.
 - **MCP:** `src/harness/mcp/`: `connectMcpServer` (Streamable HTTP, SSE fallback), `grabMcpTools` (each server tool becomes a `HarnessTool` with its JSON schema), `mcpResultToText` (text as is, images read by the vision harness, `isError` thrown). Computers are reached this way: `openComputerTools` (`src/harness/tools/computer/`) connects to the computer's AIO sandbox at `grabComputerMcpUrl` (the `MAIN_COMPUTER_URL` app setting for the main computer, for a dev server outside docker, e.g. `http://localhost:8170`, else `http://<hostname>:<port>/mcp`, or its IP address when the hostname can't be reached), leaves out `ComputerMcpExcludedTools`, and sets the computer's envs (see Envs).
 - **Replies and tasks:** `run-bot-reply.ts` answers from the last `BotReplyHistoryMessages` messages (`botMessagesToHarness`) with `ChatReplyNote`, the bot's computers (`compose-computers-note.ts`: what they are and that they're reached through `start_task`) and the chat tools, at most `BotReplyMaxToolSteps` steps, and finishes silently if the bot already had the last word (`enqueueBotReply` reuses a pending reply, so a burst of messages gets one). `run-bot-task.ts` runs the brief (`compose-job-brief.ts`) with `TaskRunNote`, the bot tools and the job's computer tools, closing the MCP connection after. Retryable harness errors go back to the queue's backoff, the rest are `BotJobFatalError`.
 - **API:** `api/admin/harness/` (`save-provider` also syncs, `sync-provider`, `delete-provider`, `save-settings`), super admin only, each returning the fresh `grabHarnessOverview()` page data.

src/bots-queue/push-workspace-created.ts

@@ -0,0 +1,38 @@
+import type { WorkspaceWithActivity } from "@/src/types";
+import grabWorkspaceAudience from "@/src/functions/backend/db/access/grab-workspace-audience";
+import { sendToUser } from "@/src/websocket/(functions)/send-to-user";
+
+type Params = {
+    workspace: WorkspaceWithActivity;
+    /**
+     * Only these users (the connected ones, for the live relay); else
+     * everyone who sees the workspace.
+     */
+    users?: Set<string>;
+};
+
+/**
+ * Pushes `server:workspace-created` to everyone who sees a workspace that
+ * was just created, so it shows in their rail without a reload.
+ */
+export default async function pushWorkspaceCreated({ workspace, users }: Params) {
+    if (!workspace.id) return;
+
+    const data: WorkspaceWithActivity = {
+        ...workspace,
+        unread: 0,
+        last_activity_at: null,
+    };
+
+    for (const user_id of await grabWorkspaceAudience({ workspace_id: workspace.id })) {
+        if (users && !users.has(String(user_id))) continue;
+
+        sendToUser({
+            user_id,
+            data: {
+                event: "server:workspace-created",
+                data: { workspace: data },
+            },
+        });
+    }
+}

src/bots-queue/run-bot-task.ts

@@ -1,9 +1,13 @@
+import type { BUN_SQLITE_COBBLE_BOTS } from "@/db/types/db";
 import { TaskRunNote, WorkspaceLearningNote } from "@/src/data/harness-prompts";
 import grabBotComputers from "@/src/functions/backend/db/computers/grab-bot-computers";
 import grabBotPrompt from "@/src/functions/backend/db/bots/grab-bot-prompt";
+import grabUserWorkspaces from "@/src/functions/backend/db/workspaces/grab-user-workspaces";
 import runTextLoop from "@/src/harness/text/run-text-loop";
 import openComputerTools from "@/src/harness/tools/computer/open-computer-tools";
 import grabBotTools from "@/src/harness/tools/bot/grab-bot-tools";
+import createWorkspaceTool from "@/src/harness/tools/bot/create-workspace-tool";
+import updateWorkspaceTool from "@/src/harness/tools/bot/update-workspace-tool";
 import askToTakeOverTool from "@/src/harness/tools/computer/ask-to-take-over-tool";
 import searchComputersTool from "@/src/harness/tools/computer/search-computers-tool";
 import computerRef from "@/src/utils/computer-ref";
@@ -14,7 +18,7 @@ import withTakeOverRefs from "./with-take-over-refs";
 import type { BotJobContext, BotJobOutcome } from "./types";
 
 type Params = BotJobContext & {
-    bot: { id: number };
+    bot: Pick<BUN_SQLITE_COBBLE_BOTS, "kind"> & { id: number };
     /**
      * The user whose conversation the job is in.
      */
@@ -53,6 +57,15 @@ export default async function runBotTask({
         const session_id = await jobSessionId({ job });
         const prompt = await grabBotPrompt({ bot_id: bot.id, user_id, workspace_id });
         const computers = await grabBotComputers({ bot_id: bot.id, workspace_id });
+
+        /**
+         * A coordinator's task can also change workspaces: the findings
+         * it was asked to record go there, not only in the report.
+         */
+        const coordinator_workspaces =
+            bot.kind == "coordinator"
+                ? (await grabUserWorkspaces({ user_id })).filter((w) => !w.archived)
+                : [];
         const carry_over = await grabSessionCarryOver({
             session_id,
             bot_id: bot.id,
@@ -75,6 +88,9 @@ export default async function runBotTask({
                 carry_over,
                 TaskRunNote,
                 workspace_id ? WorkspaceLearningNote : "",
+                bot.kind == "coordinator"
+                    ? `If this brief asked you to record something in a workspace (its context, or a new one), do it yourself with update_workspace or create_workspace before you report: the report alone changes nothing.`
+                    : "",
                 computer
                     ? `You're working on the computer "${computer.name}" (a Linux sandbox with a shell, files, code runners and a browser). Use its tools; don't ask the user to run anything. When only the user can go on (a login, a captcha, a code sent to them), ask them to take over with ask_user_to_take_over.`
                     : workspace_id
@@ -103,6 +119,20 @@ export default async function runBotTask({
             ],
             tools: [
                 ...grabBotTools({ user_id, bot_id: bot.id, workspace_id, computers }),
+                ...(bot.kind == "coordinator"
+                    ? [
+                          createWorkspaceTool({ user_id, workspaces: coordinator_workspaces }),
+                          ...(coordinator_workspaces.length
+                              ? [
+                                    updateWorkspaceTool({
+                                        user_id,
+                                        workspaces: coordinator_workspaces,
+                                        workspace_id,
+                                    }),
+                                ]
+                              : []),
+                      ]
+                    : []),
                 ...(computers.length
                     ? [
                           searchComputersTool({ computers, workspace_id }),

src/data/coordinator-system-prompt.ts

@@ -14,6 +14,7 @@ You lead a ${SiteData["SiteName"]} crew: a small team of AI worker bots that run
 - **Understand the request.** If it's unclear, ask one short question. Otherwise get started.
 - **Delegate.** Break the work into tasks and hand each one to the worker whose role fits best. Do it yourself only when no worker fits, or when it's a quick answer that doesn't need a task.
 - **Grow the crew.** If nothing in the crew fits and the job will come up again, say what's missing and propose a bot: a short name, its job in one line, and what it should handle. Once the user agrees, create it with create_bot and give it a workspace, or put it in one later with add_bot_to_workspace.
+- **Give work a home.** A workspace is where a group of bots works on one thing, from a context every bot there gets. Create one with create_workspace when the user is starting something new, and keep any workspace's name, description or context current with update_workspace.
 - **Track the work.** Know what every bot is doing, what's done, and what's stuck.
 - **Report back** in plain words when work is finished or needs the user.
 - **Lead the way.** Don't wait to be told what's next. Read where the conversation is going and, after each answer or report, propose the next step or ask the one question that decides it. Suggest one thing, specific to what the user is after.

src/data/harness-prompts.ts

@@ -38,7 +38,7 @@ Be proactive. Follow where the conversation is heading and, once you've answered
 /**
  * Added to the coordinator's chat prompt: it hands work to the crew.
  */
-export const CoordinatorReplyNote = `As the coordinator, hand work that fits a crew member's role to them with delegate_task. They post the result in their own conversation, and it's reported back here when they finish or fail, so tell the user who is on it. When a report comes back, pass on what matters to the user, follow up on anything left, and propose what comes next: the next piece of work, which bot would take it, or a question that settles the direction. Once the user agrees, you can also grow the crew with create_bot, and put a worker in a workspace with add_bot_to_workspace.`;
+export const CoordinatorReplyNote = `As the coordinator, hand work that fits a crew member's role to them with delegate_task. They post the result in their own conversation, and it's reported back here when they finish or fail, so tell the user who is on it. When a report comes back, pass on what matters to the user, follow up on anything left, and propose what comes next: the next piece of work, which bot would take it, or a question that settles the direction. Once the user agrees, you can also grow the crew with create_bot, put a worker in a workspace with add_bot_to_workspace, and create or change a workspace with create_workspace and update_workspace.`;
 
 /**
  * Added to the coordinator's chat prompt instead while it has no workers,

src/functions/backend/db/access/grab-workspace-audience.ts

@@ -0,0 +1,21 @@
+import BunSQLite from "@moduletrace/bun-sqlite";
+
+type Params = {
+    workspace_id: number | string;
+};
+
+/**
+ * Every user who sees a workspace (`workspacesSql`), for live updates
+ * about it: super admins and admins, and the members added to it
+ * (`workspace_users`). A new workspace has none of those yet.
+ */
+export default async function grabWorkspaceAudience({ workspace_id }: Params): Promise<number[]> {
+    const res = await BunSQLite.sql<{ user_id: number }>({
+        sql: `SELECT user_id FROM user_types WHERE user_type IN ('super_admin', 'admin')
+            UNION
+            SELECT user_id FROM workspace_users WHERE workspace_id = ?`,
+        values: [workspace_id],
+    });
+
+    return (res.payload || []).map((row) => Number(row.user_id)).filter(Boolean);
+}

src/harness/tools/bot/create-workspace-tool.ts

@@ -0,0 +1,90 @@
+import { z } from "zod";
+import type { BUN_SQLITE_COBBLE_WORKSPACES } from "@/db/types/db";
+import { AppData } from "@/src/data/app-data";
+import pushWorkspaceCreated from "@/src/bots-queue/push-workspace-created";
+import logEvent from "@/src/functions/backend/logger";
+import createWorkspace from "@/src/functions/backend/db/workspaces/create-workspace";
+import grabUserWorkspaces from "@/src/functions/backend/db/workspaces/grab-user-workspaces";
+import type { HarnessTool } from "../../types";
+
+type Params = {
+    user_id: number | string;
+    /**
+     * The user's live workspaces, which the new one is also added to at
+     * run time so later tool calls in the same reply can use its id.
+     */
+    workspaces: BUN_SQLITE_COBBLE_WORKSPACES[];
+};
+
+type Args = {
+    name: string;
+    description?: string;
+    context?: string;
+};
+
+/**
+ * Lets the coordinator create a workspace: a place a group of bots works
+ * from shared context, with its own computers and models. Creating one is
+ * a structural change, so it only runs once the user has asked for it or
+ * agreed to it.
+ */
+export default function createWorkspaceTool({ user_id, workspaces }: Params): HarnessTool<Args> {
+    const list = workspaces.map((w) => `${w.id}: ${w.name}`).join("; ");
+
+    return {
+        name: "create_workspace",
+        description: `Create a workspace: a place where a group of bots works on one thing, sharing a context every bot there gets in its prompt, its computers and its models. Give it a short name, one line on what it's for, and the context (markdown: what the work is, who it's for, what everyone there should know). It starts empty: put bots in it with add_bot_to_workspace, or pass its id to create_bot. Only do this when the user has asked for it or agreed to it.${list ? ` Workspaces that already exist: ${list}.` : ""}`,
+        schema: z.object({
+            name: z.string().trim().min(1).max(60),
+            description: z.string().trim().max(240).optional(),
+            context: z.string().trim().max(AppData.PromptMaxLength).optional(),
+        }),
+        run: async ({ args }) => {
+            const existing = workspaces.find(
+                (w) => w.name?.trim().toLowerCase() == args.name.trim().toLowerCase(),
+            );
+
+            if (existing?.id) {
+                throw new Error(
+                    `There's already a workspace called ${existing.name} (#${existing.id}). Change it with update_workspace instead, or pick another name.`,
+                );
+            }
+
+            const workspace_id = Number(
+                await createWorkspace({
+                    user_id,
+                    name: args.name,
+                    description: args.description,
+                    system_prompt: args.context,
+                }),
+            );
+
+            const created = (await grabUserWorkspaces({ user_id })).find(
+                (workspace) => workspace.id == workspace_id,
+            );
+
+            /**
+             * The tool list is built once per reply: adding the row here
+             * lets create_bot and add_bot_to_workspace use the new id in
+             * the same turn.
+             */
+            if (created) {
+                workspaces.push(created);
+            }
+
+            await logEvent({
+                title: "Workspace created",
+                category: "system",
+                user_id: Number(user_id),
+                plain_text: `Bot created the workspace ${args.name}.`,
+                metadata: { workspace_id },
+            });
+
+            if (created) {
+                await pushWorkspaceCreated({ workspace: created });
+            }
+
+            return `Workspace #${workspace_id} "${args.name}" is ready. The user sees it in their rail. Add bots to it with add_bot_to_workspace, or pass ${workspace_id} to create_bot; its context can change later with update_workspace.`;
+        },
+    };
+}

src/harness/tools/bot/grab-bot-chat-tools.ts

@@ -7,6 +7,7 @@ import searchComputersTool from "../computer/search-computers-tool";
 import addBotToWorkspaceTool from "./add-bot-to-workspace-tool";
 import assignComputerTool from "./assign-computer-tool";
 import createBotTool from "./create-bot-tool";
+import createWorkspaceTool from "./create-workspace-tool";
 import delegateTaskTool from "./delegate-task-tool";
 import grabBotTools from "./grab-bot-tools";
 import updateWorkspaceTool from "./update-workspace-tool";
@@ -45,12 +46,13 @@ type Params = {
  * in a workspace switching its default computer), start_task for longer
  * work, search_computers to find what's on its computers,
  * ask_user_to_take_over when only the user can do something on one, and
- * for the coordinator (the super admin's alone) create_bot to grow the
+ * for the coordinator (the super admin's alone) create_workspace and
- * crew, delegate_task to every worker (the workspace's in a workspace)
+ * update_workspace (a workspace and its shared context), create_bot to
- * plus, in its own chat, add_bot_to_workspace and assign_computer (which
+ * grow the crew, delegate_task to every worker (the workspace's in a
- * workspace and which computers each crew member gets) or, in a
+ * workspace) plus, in its own chat, add_bot_to_workspace and
- * workspace, set_bot_workspace_instructions. Anything else on a computer
+ * assign_computer (which workspace and which computers each crew member
- * goes through a task, never mid-reply.
+ * gets) or, in a workspace, set_bot_workspace_instructions. Anything else
+ * on a computer goes through a task, never mid-reply.
  */
 export default async function grabBotChatTools({
     bot,
@@ -83,6 +85,8 @@ export default async function grabBotChatTools({
 
     const workspaces = (await grabUserWorkspaces({ user_id })).filter((w) => !w.archived);
 
+    tools.push(createWorkspaceTool({ user_id, workspaces }));
+
     if (workspaces.length) {
         tools.push(updateWorkspaceTool({ user_id, workspaces, workspace_id }));
     }

src/layouts/bots/(hooks)/use-live-workspaces.ts

@@ -1,7 +1,7 @@
 import { useState } from "react";
 import type { BUN_SQLITE_COBBLE_BOT_MESSAGES } from "@/db/types/db";
 import useServerEvent from "@/src/hooks/use-server-event";
-import type { WorkspaceWithActivity } from "@/src/types";
+import type { WorkspaceCreatedData, WorkspaceWithActivity } from "@/src/types";
 
 type Params = {
     workspaces: WorkspaceWithActivity[];
@@ -12,11 +12,29 @@ type Params = {
 };
 
 /**
- * The user's workspaces, marked unread as bot messages arrive in them.
+ * The user's workspaces, marked unread as bot messages arrive in them and
+ * kept current when one is created (a bot can create one, so it shows
+ * without a reload).
  */
 export default function useLiveWorkspaces({ workspaces, open_workspace_id }: Params) {
     const [live, setLive] = useState(workspaces);
 
+    useServerEvent({
+        event: "server:workspace-created",
+        onData: (data: WorkspaceCreatedData) => {
+            setLive((prev) => {
+                if (prev.some((workspace) => workspace.id == data.workspace.id)) return prev;
+
+                /** The rail lists them oldest first (`grabUserWorkspaces`). */
+                const at = prev.findIndex((workspace) => Number(workspace.id) > Number(data.workspace.id));
+
+                if (at < 0) return [...prev, data.workspace];
+
+                return [...prev.slice(0, at), data.workspace, ...prev.slice(at)];
+            });
+        },
+    });
+
     useServerEvent({
         event: "server:bot-message",
         onData: (message: BUN_SQLITE_COBBLE_BOT_MESSAGES) => {

src/live-relay/index.ts

@@ -4,15 +4,16 @@ import { logError } from "@/src/functions/backend/logger";
 import grabConnectedUserIds from "@/src/websocket/(functions)/grab-connected-user-ids";
 import relayChangedBots from "./relay-changed-bots";
 import relayCreatedBots from "./relay-created-bots";
+import relayCreatedWorkspaces from "./relay-created-workspaces";
 import relayNewBotMessages from "./relay-new-bot-messages";
 import relayNewJobUpdates from "./relay-new-job-updates";
 import type { LiveRelayCursor } from "./types";
 
 /**
  * Keeps this process's sockets current with work done anywhere: every
- * `AppData.LiveRelayPollMs` it reads new bot messages, new job steps and
+ * `AppData.LiveRelayPollMs` it reads new bot messages, new job steps,
- * changed bots from the database and pushes them to the sockets here
+ * new workspaces and changed bots from the database and pushes them to
- * of the users they're for. The process that did the work pushes at once
+ * the sockets here of the users they're for. The process that did the work pushes at once
  * (`pushBotNotice`); this catches the rest, e.g. a job run by another
  * server on the same database. Clients ignore what they already have.
  * Runs in every server process, ungated.
@@ -54,6 +55,7 @@ export default async function liveRelay() {
             const bots_since = cursor.bots_at - AppData.LiveRelayPollMs;
 
             await relayCreatedBots({ since: bots_since, users });
+            await relayCreatedWorkspaces({ since: bots_since, users });
             await relayChangedBots({ since: bots_since, users });
             cursor.bots_at = now;
         } catch (error) {

src/live-relay/relay-created-workspaces.ts

@@ -0,0 +1,35 @@
+import BunSQLite from "@moduletrace/bun-sqlite";
+import type { WorkspaceWithActivity } from "@/src/types";
+import pushWorkspaceCreated from "@/src/bots-queue/push-workspace-created";
+
+type Params = {
+    /**
+     * Unix ms: workspaces created since then are pushed.
+     */
+    since: number;
+    users: Set<string>;
+};
+
+/**
+ * Pushes `server:workspace-created` for every workspace created since
+ * `since` to the connected users who see it (`pushWorkspaceCreated`), so a
+ * workspace another process created still shows in the rail. Pushes are
+ * idempotent, so overlapping windows only repeat them.
+ */
+export default async function relayCreatedWorkspaces({ since, users }: Params) {
+    if (!users.size) return;
+
+    const workspaces =
+        (
+            await BunSQLite.sql<WorkspaceWithActivity>({
+                sql: `SELECT w.*, 0 AS unread, NULL AS last_activity_at
+                    FROM workspaces w
+                    WHERE w.created_at > ? AND w.archived = 0`,
+                values: [since],
+            })
+        ).payload || [];
+
+    for (const workspace of workspaces) {
+        await pushWorkspaceCreated({ workspace, users });
+    }
+}

src/types/index.ts

@@ -167,6 +167,14 @@ export type BotCreatedData = {
     in_own_chat: boolean;
 };
 
+/**
+ * `server:workspace-created` data: a workspace the user can now see, as
+ * their rail lists it.
+ */
+export type WorkspaceCreatedData = {
+    workspace: WorkspaceWithActivity;
+};
+
 /**
  * `server:bot-removed` data: the bot that was deleted.
  */
@@ -617,6 +625,11 @@ export const WebSocketEvents = [
      * A bot's face or status line changed (`data`: `BotUpdatedData`)
      */
     "server:bot-updated",
+    /**
+     * A workspace the user can see was created (`data`:
+     * `WorkspaceCreatedData`)
+     */
+    "server:workspace-created",
     /**
      * A running job took a step (`data`: `BotJobUpdateData`)
      */