Land the UX work: chart sources, search, calm computer start, waiting rows, app cards, owner apps, per-Bot files

CHANGELOG.md

@@ -8,7 +8,7 @@ Newest first. `Unreleased` is what is on `main` and not yet tagged.
 
 ## Unreleased
 
-**Before upgrading.** Eight things change for an existing deployment:
+**Before upgrading.** Nine things change for an existing deployment:
 - A hosted computer's browser is now headed by default. It uses a little more memory than headless
   did; set `COMPUTER_BROWSER_MODE=headless` (Helm: `computers.browserMode: headless`) to keep the old
   behaviour.
@@ -39,6 +39,83 @@ Newest first. `Unreleased` is what is on `main` and not yet tagged.
   research run replaces them.
 - Migration `0062_action_policy_labels` adds a `labels` column to `action_policies`, defaulting to
   empty. Existing boundary rules keep working and show as "Custom rule" until somebody names them.
+- On Helm's `shared` computer and the docker-compose `agent-computer`, each Bot's files now live in
+  `computers/<Bot id>` on the workspace volume (below). Files saved before the upgrade stay at the
+  root of the volume, where no Bot sees them; move them into a Bot's folder to give them back.
+
+### Each Bot on a shared computer has its own files
+
+A computer that serves many Bots kept one folder of files for all of them, so a note one Bot saved
+was a file every other Bot could list and read. Each Bot now gets its own folder, and its commands
+start there. Logins were already kept apart. This is on for Helm's `shared` computer and the
+docker-compose `agent-computer`, and `COMPUTER_SEPARATE_WORKSPACES=on` turns it on for the
+all-in-one image. A command can still read another Bot's folder, so a deployment that needs people
+kept apart should give each Bot a computer of its own (`computers.mode: sandbox`).
+
+### Every chart says where its figures came from
+
+A chart a Bot draws now ends with a line naming what its figures were read from and when they are
+from, such as "Sources: World Bank World Development Indicators · As of 2025". Figures a Bot charted
+from its own knowledge, without looking them up, are marked "From the Bot's own knowledge. Not
+checked against a source." Bots are told to look up figures that change over time before charting
+them. In Slack and Teams the same line follows the chart in the reply. Charts already in a
+conversation are drawn as before, with no such line.
+
+### A Bot searches with its search tool, never its browser
+
+Asked to search for something, a Bot could drive its browser to Google or another search engine
+instead of using the search tool it held. With a search tool it now searches with that, and keeps
+the browser for signing in, clicking through a site, filling in a form or opening a page the person
+named. Without one it answers from what it knows, says it has not checked, and shows a card for a
+search app (Parallel Search, Exa Search or Firecrawl) that the person can ask an administrator for.
+
+### A computer that is starting says so, instead of showing a problem
+
+Opening the Computer panel while a Bot's computer was asleep or starting showed "Can't show the
+screen right now", and an action during a cold start was marked "didn't work". The panel now says
+the computer is starting, or is off until the Bot next uses it, and shows a problem only when it
+can't be reached or has gone two and a half minutes without a picture; a live screen being
+reconnected shows a small "Reconnecting…" badge. An action turned away by a cold start reads "not
+done yet" and the Bot is told to try again. Looking at the panel no longer wakes a sleeping computer,
+a Bot says in one sentence what it is about to do before its first computer action, and a hosted
+computer's cold start answers within 45 seconds, under a load balancer's usual 60-second idle
+timeout. A Docker computer still booting its browser reads as starting once the supervisor is
+upgraded too; an older supervisor works as before.
+
+### A conversation shows who it is waiting on
+
+When a Bot asks another Bot, the end of the conversation now shows that Bot's avatar and "Asking
+Risk Analyst…" until the answer comes back; a routine firing into it reads "Market Scout is running a
+routine…". A Bot whose address this deployment will not dial is reported at once, not after five
+minutes of retries. The sidebar keeps the conversation lit while it waits, and both survive a
+reload. In a shared conversation only the person whose Bot asked sees whom it asked; the others see
+only that it is busy. Migration `0063_work_items_open_thread` adds one partial index to `work_items`.
+
+### A Bot's owner can give it their own apps
+
+The owner of a Bot can now let it use an app they connect for themselves, without an administrator:
+from the app card ("Let Research Bot use your Gmail?"), under Your apps on the Bot's page, or on the
+New Bot sheet, which offers their connected apps. Calls under such a grant always use the asking
+person's own account, even on a published Team Bot, and an owner can take back only what they gave.
+By default this covers apps each person connects for themselves and Routines; an administrator
+decides per app on its page, and can switch it off for people with the "Give apps to their own Bots"
+capability. Migration `0063_owner_app_grants` adds two nullable columns, `mcp_servers.owner_grants`
+and `plugin_grants.granted_as`.
+
+Where an administrator lets owners give a Shared app, an owner's grant works straight away: it lets
+the people who can use the Bot (just the owner, or a Team Bot's audience) use the team account, with
+no separate approval. Writes still ask first. Taking the app back, or the administrator switching the
+app back to admins only, withdraws that. Migration `0064_owner_shared_audience` adds the nullable
+`shared_use_approvals.approved_as`.
+
+### An app card carries the task on once the app is ready
+
+When a Bot stopped because it needed an app, and the person then connected it in another tab or an
+administrator turned it on for the Bot, the card said "Ask again". It now sends "Gmail is ready now.
+Please carry on." for the person, once, and the Bot picks the task back up; a card opened after the
+change offers Continue instead. An administrator looking at the card gets the fix itself, "Turn on
+and give it to Sales" or "Give it to Sales", which grants the app's read-only actions with the same
+checks and trail as approving a request, or a link to the app's page where one press can't do it.
 
 ### Screens share one spacing, row and empty-state design
 

agent-bot/src/history.ts

@@ -7,7 +7,8 @@
  */
 import type { RunAgentInput } from "@ag-ui/core";
 import type OpenAI from "openai";
-import { COMPUTER_GUIDANCE, NO_ANSWER_CAME } from "../../shared/bot-prompt";
+import { computerGuidance, NO_ANSWER_CAME } from "../../shared/bot-prompt";
+import { researchRoleOfToolName } from "../../shared/research";
 import { userContent } from "../../shared/user-content";
 
 export { NO_ANSWER_CAME };
@@ -17,7 +18,19 @@ export function toProviderMessages(
   input: RunAgentInput,
 ): OpenAI.Chat.ChatCompletionMessageParam[] {
   const messages: OpenAI.Chat.ChatCompletionMessageParam[] = [
-    { role: "system", content: COMPUTER_GUIDANCE },
+    /*
+     * Worded for the tools this run offers, which is all this Bot can see of its grants: the names
+     * say whether one of them is a search tool, and that decides whether the browser is told to
+     * leave searching to it or never to search at all.
+     */
+    {
+      role: "system",
+      content: computerGuidance({
+        search: (input.tools ?? []).some(
+          (tool) => researchRoleOfToolName(tool.name) === "search",
+        ),
+      }),
+    },
     // AG-UI application context is separate from history. The A2UI catalog and tool instructions
     // arrive here; omitting them leaves the model guessing component names and action schemas.
     ...(input.context ?? []).map(({ description, value }) => ({

agent-bot/tests/history.test.ts

@@ -1,7 +1,44 @@
 import { describe, expect, test } from "bun:test";
 import type { RunAgentInput } from "@ag-ui/core";
+import { computerGuidance } from "../../shared/bot-prompt";
 import { NO_ANSWER_CAME, toProviderMessages } from "../src/history";
 
+/**
+ * Whether the browser is told to leave searching to a search tool is decided by the tools this run
+ * offers, since the names are all this Bot sees of its grants. "search for X" made a Bot holding
+ * a search tool drive its browser to a search engine instead.
+ */
+describe("the computer guidance this Bot is given", () => {
+  const offered = (...names: string[]) =>
+    ({
+      messages: [{ id: "u1", role: "user", content: "Search for X." }],
+      tools: names.map((name) => ({ name, description: "", parameters: {} })),
+    }) as unknown as RunAgentInput;
+
+  test("leaves searching to a search tool the run offers", () => {
+    const [system] = toProviderMessages(
+      offered("show_app_access", "mcp__exa__web_search_exa"),
+    );
+    expect(system).toEqual({
+      role: "system",
+      content: computerGuidance({ search: true }),
+    });
+  });
+
+  test("never searches in the browser when no search tool is offered", () => {
+    for (const run of [
+      offered("show_app_access", "mcp__google-drive__search_files"),
+      // A reader alone does not find sources.
+      offered("mcp__exa__web_fetch_exa"),
+      { messages: [] } as unknown as RunAgentInput,
+    ])
+      expect(toProviderMessages(run)[0]).toEqual({
+        role: "system",
+        content: computerGuidance({ search: false }),
+      });
+  });
+});
+
 /**
  * The Bot that ships in the box, and the conversation a declined handover used to end.
  *

agent-computer/src/index.ts

@@ -27,8 +27,8 @@ import {
   TAKE_CONTROL_FIRST,
 } from "./control";
 import { describeHumanGesture } from "./demonstration";
-import { enterText, FieldValueError } from "./enter-text";
 import { handleEgressPolicyRequest, startEgressFilter } from "./egress";
+import { enterText, FieldValueError } from "./enter-text";
 import { identity } from "./identity";
 import {
   assertPageAccess,
@@ -51,7 +51,6 @@ import {
   sensitiveRefs,
 } from "./secret-masking";
 import { type BotSession, createSessions } from "./sessions";
-import { createShell } from "./shell";
 import {
   fillSignIn,
   fillSignInCode,
@@ -61,12 +60,12 @@ import {
 import { startVirtualDisplay } from "./virtual-display";
 import { applyWebBotAuthPush } from "./web-bot-auth";
 import {
-  createWorkspace,
   WorkspaceFileError,
   WorkspaceFileNotFoundError,
   WorkspaceFileTooLargeError,
   WorkspacePathError,
 } from "./workspace";
+import { createWorkspaces } from "./workspaces";
 
 /**
  * The Bot's computer: one long-lived browser, reachable over HTTP.
@@ -197,9 +196,9 @@ function botIdOf(request: Request, fallback?: string | null): string {
  * The Bot's durable files.
  *
  * Rooted at WORKSPACE_DIR, which the image creates and docker-compose mounts as a volume, so what a
- * Bot saves outlives the container. Built once at boot: the root is fixed, and resolving it per request
- * would only add a syscall to every call. Everything about why confinement is harder than it looks
- * lives in workspace.ts.
+ * Bot saves outlives the container. Each folder is built the first time its Bot uses it and kept, so
+ * a request adds no syscall after that. Which folder a Bot gets lives in workspaces.ts; everything
+ * about why confinement is harder than it looks lives in workspace.ts.
  */
 /**
  * The two directories this process cannot do its job without, checked before it says it is ready.
@@ -245,8 +244,10 @@ await assertWritable(
   process.env.PROFILES_DIR?.trim() || "/profiles",
 );
 
-const workspace = createWorkspace(
+// One folder per Bot where one process serves many; see workspaces.ts.
+const workspaces = createWorkspaces(
   process.env.WORKSPACE_DIR?.trim() || "/workspace",
+  process.env.COMPUTER_SEPARATE_WORKSPACES?.trim().toLowerCase() === "on",
 );
 
 /**
@@ -286,9 +287,6 @@ const profiles = createProfiles(
     await sessions.get(botId)?.viewer.releaseAll(COMPUTER_STOPPED);
   },
 );
-// Rooted in the same workspace the file tools use, so a command and a written file see one
-// directory rather than two.
-const shell = createShell(process.env.WORKSPACE_DIR?.trim() || "/workspace");
 
 /**
  * The id normally arrives as a header on every request. This is the fallback for a caller that has no
@@ -1209,9 +1207,8 @@ serve<StreamData>({
       // MAY touch a path: the gateway in front of this process does that.
       if (url.pathname === "/files/download" && request.method === "GET") {
         try {
-          const file = await workspace.download(
-            url.searchParams.get("path") ?? "",
-          );
+          const { files } = await workspaces.for(botId);
+          const file = await files.download(url.searchParams.get("path") ?? "");
           return new Response(file.body, {
             headers: downloadHeaders(file.name, file.bytes),
           });
@@ -1228,7 +1225,8 @@ serve<StreamData>({
           path?: unknown;
         } | null;
         try {
-          return json(await workspace.read(String(body?.path ?? "")));
+          const { files } = await workspaces.for(botId);
+          return json(await files.read(String(body?.path ?? "")));
         } catch (error) {
           return json(
             { error: describe(error, "The file could not be read.") },
@@ -1242,8 +1240,9 @@ serve<StreamData>({
           path?: unknown;
         } | null;
         try {
+          const { files } = await workspaces.for(botId);
           return json(
-            await workspace.list(
+            await files.list(
               typeof body?.path === "string" ? body.path : undefined,
             ),
           );
@@ -1283,6 +1282,9 @@ serve<StreamData>({
           return json({ error: timeout.error }, 400);
         }
         try {
+          // Rooted in the same folder the file tools use, so a command and a written file see one
+          // directory rather than two.
+          const { shell } = await workspaces.for(botId);
           return json(
             await shell.run({
               command: body.command,
@@ -1310,8 +1312,9 @@ serve<StreamData>({
           return json({ error: "The contents to write are required." }, 400);
         }
         try {
+          const { files } = await workspaces.for(botId);
           return json(
-            await workspace.write(String(body?.path ?? ""), body.contents, {
+            await files.write(String(body?.path ?? ""), body.contents, {
               append: body.append === true,
             }),
           );

agent-computer/src/workspaces.ts

@@ -0,0 +1,60 @@
+/**
+ * Whose files a request reaches.
+ *
+ * WHY. One computer process can serve many Bots: Helm's default `computers.mode: shared` and the
+ * docker-compose `agent-computer` service with no supervisor both do. Browser profiles were already
+ * kept apart by the id each request names (`bot-id.ts`), but the workspace was one folder, so a note
+ * one Bot saved for one person was a file every other Bot could list and read. With
+ * `COMPUTER_SEPARATE_WORKSPACES=on` each id gets its own folder under the workspace root, and the
+ * shell starts there with HOME pointing at it.
+ *
+ * WHY NOT ALWAYS. A computer the supervisor or the sandbox starts serves one Bot, and the desktop's
+ * computer serves one person. Their files already sit at the root of the volume, and moving the
+ * root under them would hide every file they had. So only the deployments that share one process
+ * turn this on.
+ *
+ * WHAT IT IS NOT. A command is still a process in a shared container and can read any path the
+ * container can. Separate folders keep each Bot's file tools to its own files and keep commands from
+ * landing in another Bot's folder by default. Isolation between people who run commands needs a
+ * computer each, which `computers.mode: sandbox` gives.
+ */
+import { mkdir } from "node:fs/promises";
+import { isPlainBotId, UnusableBotIdError } from "./bot-id";
+import { createShell, type Shell } from "./shell";
+import { createWorkspace } from "./workspace";
+
+export type Workspace = ReturnType<typeof createWorkspace>;
+
+/** The folder an id's files live in. The same allow-list as profiles, so an id is one segment. */
+export function workspaceDirectoryFor(
+  root: string,
+  botId: string,
+  separate: boolean,
+): string {
+  if (!separate) return root;
+  if (!isPlainBotId(botId)) throw new UnusableBotIdError(botId);
+  return `${root}/computers/${botId}`;
+}
+
+export function createWorkspaces(
+  root: string,
+  separate: boolean,
+  sourceEnv: NodeJS.ProcessEnv = process.env,
+) {
+  const made = new Map<string, { files: Workspace; shell: Shell }>();
+  return {
+    /** The files and shell for this id, creating its folder the first time it is used. */
+    async for(botId: string): Promise<{ files: Workspace; shell: Shell }> {
+      const directory = workspaceDirectoryFor(root, botId, separate);
+      const known = made.get(directory);
+      if (known) return known;
+      await mkdir(directory, { recursive: true });
+      const created = {
+        files: createWorkspace(directory),
+        shell: createShell(directory, sourceEnv),
+      };
+      made.set(directory, created);
+      return created;
+    },
+  };
+}