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.
A bot's face and status line live in bot_user_faces, one row per bot and
user, set by jobs for the user whose conversation they're in. Needs-you
and working only show to that user; every bot read overlays the viewer's
face (botFaceSql) and pushes go to the user a face change is for.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Deleting a bot only changed the page after a reload. The delete route now
reads who could see the bot before removing it, since its assignments and
workspace places go with it, then pushes server:bot-removed
(BotRemovedData) to them. useLiveBots drops the row, so every tab and
every workspace the bot was in updates together.
The rail was built from page props and only knew bots it already had, so a
bot the coordinator created did not appear until a reload.
create_bot and add_bot_to_workspace now push server:bot-created
(BotCreatedData) to everyone who sees the bot: its rail row, the
workspaces it is in, and whether it belongs in that user's own chat list.
useLiveBots inserts it, after the pinned coordinator outside a workspace
and only when the open workspace is one it joined. liveRelay pushes created
bots too, so a bot added by another process still shows.
Bots, workspaces and computers now belong to the install. Users reach
workers only through bot_users (assigned by a super admin or admin) and
workspace_users; the coordinator and main computer are one per install,
and only the super admin sees the coordinator. Conversations are per
user (bot_sessions.user_id), jobs run for the session's user, and live
updates go only to who should see them.
A bot's core memory is now general knowledge shared by every user it
works for; what it learns about a user lives in bot_user_memories.
One-off scripts move existing installs over: move-bot-memory-to-owners
(run first), then share-crew.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Rail: Add icon with stacked form modals (bot, workspace, computer),
coordinator, recent bots with "See all bots", Workspaces section, and
a workspace mode listing only its crew
- Workspaces: page for context, bots (per-workspace instructions and
memory), computers (default, link, unlink), models and delete;
conversations scoped per bot per workspace
- Sessions: conversations split into searchable, reopenable sessions
with carry-over summaries; sessions and new-session header icons
- Computers: created and provisioned over the docker socket, home dir
kept at DATA_DIR/computers/<id> after delete; super admins only
- Models: workspace settings win over a bot's own, then the defaults
- Pictures for bots and workspaces; bots editable from the header
- Coordinator tools: update_workspace, set_bot_workspace_instructions
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Serve each computer to its owner under /computers/<id>/ (HTTP and
websockets proxied to the AIO sandbox) and show it in a shared
ComputerView with browser, terminal and code modes, opened from the
computers modal or a take-over button in the thread.
- ask_user_to_take_over lets a bot hand a computer to the user for a
login or captcha; the message gets a take-over button and needs-you,
and the viewer hands it back with a chat message.
- While a task runs the thread shows "<bot> is working..." with the
task's latest step; steps read as plain words, not tool names.
- A coordinator with no workers no longer claims to delegate, and bots
describe started tasks in the first person.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Bots have a current computer (bots.computer_id), switched from the chat
header beside the model button or by clicking a computer the bot names
([computer:ID]); tasks run on it by default
- search_computers runs one read-only command on all of a bot's computers;
chat replies know their computers (compose-computers-note)
- The coordinator can use every computer and grants or revokes crew access
with assign_computer
- Delegated jobs record requested_by_bot_id; the worker's result or failure
is reported back in the coordinator's conversation
- bots_queue_updates records each model turn of a job, pushed live and shown
in the working-on panel
- Live relay: every process pushes new messages, job steps and bot changes
from the database to its own sockets, so work done elsewhere shows live
- Bot messages render as markdown (react-markdown + remark-gfm, no raw HTML)
with twui components; rail previews are plain text
- Fix header button overflow in the model and computer selects
- Bump @moduletrace/twui to 0.1.2
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Harness: providers, model catalog synced hourly, automatic free picks,
cooldowns, tool loop with context trimming, MCP computer tools
- Bots queue runs replies and tasks through the harness; jobs wait
(attempt refunded) while every model is resting
- Envs: Settings > Environment, scoped general/workspace/computer,
written to computers and redacted from tool output
- Models: Settings > Models, per-harness provider select defaulting to
OpenRouter, and a models modal on each bot's chat (the coordinator's
edits the defaults)
- Chat: thinking row while a reply runs, file attachments (upload,
paste, drop) that replies read as images, audio and document text
- Fix media uploads failing after a user's first file, and private
files being served from the public media path
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Schema: workspaces (+ workspace_bots, workspace_computers), containers,
computers, bot_computers, bots.memory, workspaces.system_prompt, and
bots_queue as a bun-sqlite isQueue table
- Main computer (and its container record) ensured with the coordinator on
signup, seed and /admin/bots; the coordinator's access to it is locked
- Effective computer access: direct grants plus workspace computers
- Full bot prompt: core instructions, workspace prompts, then memory;
bots can rewrite their memory and system prompt
- Queue helpers on the native BunSQLite.queue API, plus a handler that
heartbeats, serializes per computer, recovers after restarts, reports
lost jobs, supports cancelling and pushes outcomes over the WebSocket
- Enable SQLite foreign keys at startup so schema cascades fire
- Prune finished jobs daily
Co-Authored-By: Claude Opus 5.5 <[email protected]>
tben
