DEV Community: Burrowbox

Embed your AI agent's live view in your app so customers can watch it work

Burrowbox — Tue, 20 Oct 2026 23:44:17 +0000

How to embed an AI agent's live view

To embed an AI agent's live view in your app, create a signed, short-lived link on your server with POST /api/machines/{id}/live-view, put the returned URL in an <iframe>, and lock it to your own origin with allowedOrigins. The link is watch-only by default, and input is blocked on the machine itself. You can crop the stream to a single element or a rectangle, and switch to interactive: true when a person needs to take over.

Below, we build it step by step in Node, from the server route to a takeover flow. The reference for every field is Embed the live view.

Why let customers watch

If your product runs an agent on your customers' accounts, they'll want to see what it's doing before they trust it with more. A screenshot afterwards helps, but a live picture of the agent's browser lets them catch a wrong page while it's happening, and step in when the agent gets stuck on a login or a judgment call.

The examples below assume each customer has their own machine, as in machines for your customers and our post on giving every user a cloud computer.

Step 1: create the link on your server

The link is created with your API key, so it has to happen on your server. Your tmk_ key must never reach the browser (Authentication).

// server.js (Node 18+, Express)
import express from "express";
const app = express();

app.get("/api/agent-view", async (req, res) => {
  const customer = await currentCustomer(req); // your auth
  const r = await fetch(`https://burrowbox.dev/api/machines/${customer.machineId}/live-view`, {
    method: "POST",
    headers: { Authorization: `Bearer ${process.env.BURROWBOX_KEY}`, "Content-Type": "application/json" },
    body: JSON.stringify({
      mode: "browser",          // or "desktop", or "app" for one window
      interactive: false,       // watch only
      ttlSeconds: 900,          // 15 minutes
      allowedOrigins: ["https://app.example.com"],
    }),
  });
  const { url, expiresAt } = await r.json();
  res.json({ url, expiresAt });
});

What the fields do:

mode: desktop streams the whole screen, browser streams the machine's browser, and app streams one window, cropped. With app, pass app (part of the window's class or title, such as gimp), or it defaults to the focused window.
interactive: false (the default) means watch only.
ttlSeconds: from 60 to 86,400. The default is 3,600.
allowedOrigins: the origins allowed to embed the link. Burrowbox enforces it with a Content-Security-Policy: frame-ancestors header, which tells the browser which pages may frame the viewer (MDN). Leave it out and any site can embed the link.
showControls: true by default. It shows a small status pill and a fullscreen button.

The response has the url, expiresAt, mode, interactive, and a ready-made iframe string.

Step 2: put it in an iframe

<iframe
  id="agent-view"
  style="width: 100%; aspect-ratio: 16 / 10; border: 0"
  allow="clipboard-read; clipboard-write; fullscreen">
</iframe>
<script type="module">
  const { url } = await fetch("/api/agent-view").then((r) => r.json());
  document.getElementById("agent-view").src = url;
</script>

Watch-only is enforced on the machine, so editing the page in dev tools doesn't give anyone the mouse. Links are signed and expire on their own, but anyone who has one can watch until then. Keep TTLs short and handle the URL like a session token: don't log it or put it on a page other people can open.

Step 3: stream only part of the screen

The agent's browser might have other tabs open, or a page with data the customer doesn't need. Use selector (browser mode) or region (desktop or browser) to stream part of the machine.

// Only the #agenda element, following it as the page scrolls or changes
const agendaOnly = { mode: "browser", selector: "#agenda", interactive: false };

// The top-left quarter of the desktop, in screen pixels
const topLeft = { mode: "desktop", region: { x: 0, y: 0, width: 720, height: 450 } };

Send either object as the body of the same POST /api/machines/{id}/live-view call.

For browser, a region is in CSS pixels of the 1280×800 browser viewport. For desktop, it's in screen pixels.

The machine cuts out the area before anything is sent, so pixels outside it never reach the viewer, even if someone inspects the page.

A few details from the docs:

Until the selected element is on screen, the viewer shows "Waiting for that part of the page".
In an interactive area, clicks and typing work inside it and clicks outside it are dropped.
A browser area can't navigate, go back or switch tabs, and it doesn't show the page's URL or title.

You can test a crop before writing code: in the dashboard, Share → Area → Part of it… lets you drag a rectangle on a live screenshot or enter a selector.

Step 4: listen to the viewer's events

The viewer posts messages to the page that embeds it. Check the origin before reading anything. MDN's advice for message listeners is to always verify the sender's identity using origin (MDN).

window.addEventListener("message", async (e) => {
  if (e.origin !== "https://burrowbox.dev" || e.data?.source !== "burrowbox") return;
  switch (e.data.type) {
    case "connected":    showStatus(`Live (${e.data.mode})`); break;
    case "disconnected": showStatus("Reconnecting…"); break; // it reconnects on its own
    case "url":          showStatus(`On ${e.data.title}`); break; // browser mode: e.data.url too
    case "expired": {
      const { url } = await fetch("/api/agent-view").then((r) => r.json());
      document.getElementById("agent-view").src = url;
      break;
    }
  }
});

Refreshing on expired lets you keep TTLs short without the view going blank for someone who leaves the tab open. Your route still checks that the customer is signed in and should see that machine, so a refresh can't outlive their access.

Step 5: let a person take over

When the agent reaches something it shouldn't do alone, such as an SSO prompt or a payment confirmation, create a second link with interactive: true and a short TTL, and show it in place of the watch-only one.

const takeover = { mode: "browser", interactive: true, ttlSeconds: 600, allowedOrigins: ["https://app.example.com"] };

The customer types into the machine's browser directly, so their password never goes through the model. Browser cookies are kept when a machine stops, so they usually sign in once. Our ChatGPT agent post walks through this takeover pattern. For logins the agent can do on its own, the vault and browser_login are often simpler, and our 2FA login tutorial covers that path.

The agent can also ask for help itself:

The live-view endpoint accepts the machine's own mcpToken as well as your API key, so an agent holding only its machine token can create a link and send it to you to show the customer.
An agent connected to the platform MCP with your API key can call machine_live_view, which takes the same options, including region and selector (MCP).

Either way, route the link through your app to the right customer. An interactive link gives whoever holds it the mouse and keyboard until it expires.

Building your own player

If you'd rather build your own player than use the iframe, the three WebSocket streams behind it (desktop over VNC, window events, and browser frames) are documented in Live view. Those streams use the dashboard session, so proxy them from your backend with your API key.

Key takeaways

Create live-view links on your server. The API key stays there.
Set allowedOrigins and a short ttlSeconds, and refresh the link on expired.
Watch-only is the default and is enforced on the machine.
selector and region crop on the machine, so hidden pixels never leave it.
Switch to interactive: true only for the step that needs a person.

Create an account to try it, or start with Embed the live view.

FAQ

Can the customer click inside the embedded live view?

Only if you create the link with interactive: true. With the default false, input is blocked on the machine, not just in the page.

Is it safe to send the live-view link to the browser?

The link is signed and expires on its own, but anyone holding it can watch until then. Create it on your server for an authenticated customer, keep ttlSeconds short, and set allowedOrigins so other sites can't frame it.

How do I show only one part of the agent's screen?

Pass selector (a CSS selector, browser mode only) or region (a rectangle in whole pixels) when you create the link. The machine crops the stream before sending it.

What happens when the link expires?

The viewer posts an expired message to your page. Ask your server for a new link and set it as the iframe's src.

Sources

Burrowbox docs, Embed the live view: https://burrowbox.dev/docs/embed
Burrowbox docs, Live view: https://burrowbox.dev/docs/live-view
MDN, CSP frame-ancestors: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/frame-ancestors
MDN, Window.postMessage(): https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

Originally published on the Burrowbox blog.

Windows 365 for Agents checks Cloud PCs out to agents. Build the same check-out pool with Microsoft Agent Framework

Burrowbox — Thu, 15 Oct 2026 16:22:22 +0000

What Windows 365 for Agents does

Windows 365 for Agents is Microsoft's class of Cloud PCs built for agents to use. An agent checks out a Cloud PC when it needs one for a task, then checks it back in when the task is done so another agent can use it. (Microsoft Learn)

The same overview and Microsoft's related pages add more detail:

Governed machines. The Cloud PCs are managed by Intune and governed by Microsoft Entra ID. Admins get session logs, observability tools and human-in-the-loop controls.
A session lifecycle. A session goes Prepare, Acquire, Connect, Act, Release. On release the Cloud PC is reset and goes back to its pool. A session with no MCP activity for 30 minutes is evicted, and there's no maximum runtime. (Agent session lifecycle)
Generally available. Windows 365 for Agents went GA in the week of June 1, 2026 (What's new). Copilot Studio computer use went GA in May 2026, and the Windows 365 for Agents MCP server in June 2026 (Copilot Studio what's new).
Copilot Studio Cloud PC pools are still in preview. They're Entra joined and Intune enrolled, run Windows 11 Enterprise, and scale automatically. Each environment can have up to five pools of up to 10 Cloud PCs. Each tenant gets 50 free hours for published agents running autonomously. (Use a Cloud PC pool)

The pattern

A pool of ready machines sits behind an API. An agent checks one out for a task and works on it while a person can watch. When the task ends, the machine is checked back in with nothing carried over. Every hand-off is recorded, and the cost lands on the team or customer the work was for.

If your company runs on Entra and Intune and your agents need Windows apps, Microsoft's version fits. If you run agents for many outside customers, or Linux desktops are enough, you can build the same loop with a few REST calls. The Project Mariner post used a pool to run many tasks at once, and the Manus post gave each task a durable workflow. Here the focus is governance: check-out, check-in, an audit trail and cost per customer.

Build it with Microsoft Agent Framework and Burrowbox

Microsoft Agent Framework reached 1.0 for Python and .NET on April 3, 2026. Its MCPStreamableHTTPTool connects an agent to a remote MCP server (Microsoft Learn), and every Burrowbox machine has its own MCP endpoint. Burrowbox isn't involved with Microsoft or Windows 365.

1. A warm pool

A warm pool keeps booted machines waiting. A template runs on each one before it counts as ready, so a checked-out machine already has your tools.

curl -X POST https://burrowbox.dev/api/pools \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"name": "agents", "size": "small", "target": 3,
       "setup": [{"type": "tool", "tool": "apps_install", "arguments": {"kind": "apt", "packages": ["libreoffice"]}}]}'

2. Check out, run the agent, check in

pip install agent-framework httpx

import asyncio, os
import httpx
from agent_framework import Agent, MCPStreamableHTTPTool
from agent_framework.openai import OpenAIChatClient

POOL_ID = os.environ["POOL_ID"]
auth = {"Authorization": f"Bearer {os.environ['BURROWBOX_KEY']}"}

async def run_task(customer_id: str, team: str, task: str) -> str:
    async with httpx.AsyncClient(base_url="https://burrowbox.dev", headers=auth, timeout=120) as http:
        # Check out: a machine from the pool, tagged with who the work is for.
        r = await http.post(f"/api/pools/{POOL_ID}/claim", json={
            "externalId": customer_id, "labels": {"team": team},
            "ttlMinutes": 60, "onExpire": "destroy",  # backstop if check-in never runs
        })
        r.raise_for_status()
        m = r.json()
        token = m["mcpToken"]  # reaches this machine only
        try:
            async with Agent(
                client=OpenAIChatClient(),
                name="DesktopAgent",
                instructions="You operate a Linux desktop with the machine tools. Save results under ~/out.",
                tools=MCPStreamableHTTPTool(
                    name="machine",
                    url=m["mcpUrl"],
                    header_provider=lambda _kwargs: {"Authorization": f"Bearer {token}"},
                ),
            ) as agent:
                result = await agent.run(task)
                return result.text
        finally:
            # Check in: delete the machine, so nothing carries over.
            await http.delete(f"/api/machines/{m['id']}")

print(asyncio.run(run_task("cus_8f2a", "finance", "Open ~/inbox/march.csv in LibreOffice and total column C")))

The agent gets the machine's tools: shell_run, apps_launch, get_app_state, click, browser_navigate, browser_snapshot and the rest of the machine MCP. A claimed machine is brand new, pool machines are never reused, and the pool refills itself in the background.

Deleting is the closest match to Microsoft's reset on release. If the customer might send a follow-up, stop the machine instead with POST /api/machines/{id}/stop. A stop keeps its files, installed apps and browser logins, and costs $0.001 an hour while it's off. The Oct 6 post covers when each one makes sense.

3. The audit log

Burrowbox sends a signed event webhook for each hand-off: machine.claimed at check-out, then machine.stopped (with detail.reason), machine.expired or machine.destroyed. Each event carries the machine's externalId and labels, so the events can serve as your audit trail.

curl -X POST https://burrowbox.dev/api/event-webhooks \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"url": "https://api.example.com/burrowbox/events",
       "events": ["machine.claimed", "machine.stopped", "machine.expired", "machine.destroyed"]}'

Save the whsec_… secret it returns once. In your handler, check the signature with the verify function from the events docs, then write a row:

import json, os, sqlite3

db = sqlite3.connect("audit.db")
db.execute("""create table if not exists machine_events (
  id text primary key, type text, created_at text,
  machine_id text, customer text, labels text, reason text)""")

def record(raw_body: bytes, signature_header: str) -> int:
    if not verify(raw_body, signature_header, os.environ["BURROWBOX_WHSEC"]):
        return 400
    e = json.loads(raw_body)
    m, detail = e["data"]["machine"], e["data"].get("detail") or {}
    db.execute("insert or ignore into machine_events values (?,?,?,?,?,?,?)",
               (e["id"], e["type"], e["createdAt"], m["id"], m.get("externalId"),
                json.dumps(m.get("labels") or {}), detail.get("reason")))
    db.commit()
    return 200

Events can arrive more than once and out of order. The primary key on id handles the duplicates, and created_at gives you the order.

4. Cost per customer

Usage is billed by the minute and attributed to the externalId the machine had at that minute (Billing):

curl "https://burrowbox.dev/api/usage?groupBy=externalId" -H "Authorization: Bearer $BURROWBOX_KEY"
# → { "groups": [{ "externalId": "cus_8f2a", "usageMicros": 2980000, "machines": 2 }, …] }

Amounts are in micro-dollars (1,000,000 = $1). The row with externalId: null holds untagged usage, including idle pool time before a claim. A small machine costs $0.11 an hour while running, and a pool of three idle small machines about $0.33 an hour.

5. A person in the loop

To let someone watch the session, create a short-lived live-view link on your server with POST /api/machines/{id}/live-view. With interactive: false, input is blocked on the machine itself. Create a new link with interactive: true when a person needs to take over.

Where it differs from Windows 365 for Agents

Linux only. Burrowbox machines are Linux desktops. If the agent needs a Windows-only app, this won't run it.
No Entra or Intune. Access is your API key plus one machine-scoped mcpToken per check-out. You enforce policy in your own code.
No idle timer. Microsoft evicts a session after 30 minutes without MCP activity. On Burrowbox, ttlMinutes is a fixed deadline, after which onExpire stops or destroys the machine.
Check-in can keep state. Besides a clean delete, you can stop a customer's machine and start it later with their logins still there.

Key takeaways

Windows 365 for Agents lends Windows Cloud PCs to agents through check-out and check-in, governed by Entra and Intune.
The same loop works with a warm pool: claim to check out, delete or stop to check in.
Tag every claim with externalId. The event webhooks become your audit log and /api/usage becomes your chargeback report.
Agent Framework's MCPStreamableHTTPTool connects an agent to the checked-out machine with a token that reaches only that machine.

Create an account to try it.

FAQ

What is Windows 365 for Agents?

It's a class of Windows Cloud PCs for AI agents, built on the Windows 365 platform. Agents check out a Cloud PC for a task and check it back in afterwards, and the Cloud PC is reset before the next session. It went GA in June 2026.

Do I need Entra ID and Intune to use Copilot Studio Cloud PC pools?

Yes. Microsoft's setup guide lists a working Intune and Microsoft Entra tenant as a prerequisite, and the pools are Entra joined and Intune enrolled.

How do I connect Microsoft Agent Framework to a remote MCP server?

Use MCPStreamableHTTPTool with the server's url, and add an Authorization header through header_provider. Pass the tool to an Agent with tools=.

Can I see what each customer's agent cost?

Yes, if you tag each claim with your customer's id as externalId. GET /api/usage?groupBy=externalId then returns usage per customer.

Sources

Microsoft Learn, What is Windows 365 for Agents?: https://learn.microsoft.com/en-us/windows-365/agents/introduction-windows-365-for-agents
Microsoft Learn, Agent session lifecycle: https://learn.microsoft.com/en-us/windows-365/agents/agent-session-lifecycle
Microsoft Learn, What's new in Windows 365 for Agents: https://learn.microsoft.com/en-us/windows-365/agents/whats-new
Microsoft Learn, What's new in Copilot Studio: https://learn.microsoft.com/en-us/microsoft-copilot-studio/whats-new
Microsoft Learn, Use a Cloud PC pool for computer use runs (preview): https://learn.microsoft.com/en-us/microsoft-copilot-studio/use-cloud-pc-pool
Microsoft Agent Framework, Version 1.0: https://devblogs.microsoft.com/agent-framework/microsoft-agent-framework-version-1-0/
Microsoft Learn, Using MCP tools (Agent Framework): https://learn.microsoft.com/en-us/agent-framework/agents/tools/local-mcp-tools
Burrowbox docs, Warm pools: https://burrowbox.dev/docs/pools
Burrowbox docs, Event webhooks: https://burrowbox.dev/docs/events

Originally published on the Burrowbox blog.

Devin signs in once and remembers. Build a QA agent that tests behind your login with the Claude Agent SDK

Burrowbox — Tue, 13 Oct 2026 15:00:33 +0000

What Devin does with browser logins

Devin is Cognition's AI software engineer (Cognition). Most web apps worth testing sit behind a login, and Devin's docs describe how it gets past one without asking every time (Devin docs):

A person logs in once through Devin's interactive browser, in the session's Desktop tab, and handles SSO redirects, MFA prompts and CAPTCHAs themselves. When they ask Devin to "save the browser profile", Devin zips the browser's cookies, localStorage and other Chrome profile data and attaches it to the organization's blueprint. Later sessions unpack it and start signed in.
Saved passwords and caches are left out of the profile. Restored cookies expire on the app's usual schedule, so the profile has to be saved again when the session runs out. Profiles are shared across the organization, and the docs recommend saving one for a dedicated service account rather than a personal one.

Credentials, site cookies and TOTP codes for two-factor logins can be stored separately as Secrets, at organization, personal or session scope (Devin docs).

Burrowbox isn't involved with Cognition or Devin.

The pattern

A QA agent that logs in on every run spends time on the login page and adds a step that can break before the real test starts. And a model that types a password has that password in its context. Devin's approach handles both:

The agent's browser starts signed in.
It signs in as a test account made for the job.
When it has to log in again, the secrets come from outside the prompt.

Devin stores the signed-in state once per organization, in the blueprint. On Burrowbox, the browser's state lives on the machine's disk, so it's stored once per machine. A machine is a Linux computer with one persistent browser, and stopping it keeps the browser's cookies (session cookies included) along with the rest of its files. The post on sandboxes and persistent machines covers what else survives a stop.

Build it with the Claude Agent SDK and Burrowbox

The QA agent runs in your CI job with the Claude Agent SDK. It connects to a Burrowbox machine's MCP endpoint, works through a checklist in that machine's browser, and finishes with PASS or FAIL. The Claude computer use post wires up the same machine through the Messages API's MCP connector. This one uses the Agent SDK, which runs the tool loop for you and fits a script in CI.

1. Create a machine for QA

Create the machine with "browser": "full" (Chromium). Both modes keep cookies across a stop and start, but the full browser also keeps sign-ins through live agent updates (Browser mode).

curl -X POST https://burrowbox.dev/api/machines \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"name": "qa-staging", "size": "small", "browser": "full", "ttlMinutes": 30}'
# → { "id": "…", "mcpUrl": "https://burrowbox.dev/api/machines/…/mcp", "mcpToken": "tmm_…" }

Save the id as QA_MACHINE_ID in your CI settings. With ttlMinutes, the machine stops by itself after 30 minutes and keeps its state.

2. Put the staging test account in the vault

Each machine has an encrypted vault. The browser_login tool matches a credential to the page by URL, fills in the form, submits it and enters the TOTP code if the account has one. The password never comes back to the model, and vault_list returns only names, URLs and usernames.

curl -X PUT https://burrowbox.dev/api/machines/$QA_MACHINE_ID/vault/staging \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"url": "https://staging.example.com/login", "username": "qa-bot@example.com", "password": "…", "totpSecret": "JBSWY3DPEHPK3PXP"}'

After the first login, the cookies stay on the machine. Most runs start signed in and never touch the vault. When the session expires, the agent calls browser_login and carries on.

3. The QA agent

npm i @anthropic-ai/claude-agent-sdk and npm i -D tsx. The SDK reads ANTHROPIC_API_KEY from the environment of the process that runs it (quickstart).

// qa.ts — run with: npx tsx qa.ts
import { query } from "@anthropic-ai/claude-agent-sdk";

const BB = "https://burrowbox.dev";
const id = process.env.QA_MACHINE_ID!;
const headers = { Authorization: `Bearer ${process.env.BURROWBOX_KEY}`, "Content-Type": "application/json" };
const bb = (path: string, init: RequestInit = {}) => fetch(`${BB}${path}`, { ...init, headers }).then((r) => r.json());

const CHECKLIST = `
1. Open https://staging.example.com/dashboard. If you land on the sign-in page, call browser_login, then continue.
2. The dashboard lists at least one project.
3. Settings > Billing opens without an error message.
4. Create a project named "qa-${Date.now()}" and check that it appears in the project list.
`;

// Start the machine (it may be stopped since the last run). The 30-minute deadline is a safety net.
await bb(`/api/machines/${id}/start`, { method: "POST", body: JSON.stringify({ ttlMinutes: 30 }) });
let machine = await bb(`/api/machines/${id}`); // includes mcpUrl and mcpToken
while (machine.status !== "running") {
  if (machine.status === "error") throw new Error(`Machine failed: ${machine.lastError}`);
  await new Promise((r) => setTimeout(r, 2000));
  machine = await bb(`/api/machines/${id}`);
}

const tools = ["browser_navigate", "browser_snapshot", "browser_click", "browser_fill", "browser_screenshot", "browser_login"];
let verdict = "FAIL";
try {
  for await (const message of query({
    prompt: `You are a QA tester. Work through this checklist in the browser. Use browser_snapshot to read each page. ` +
      `When a step fails, take a browser_screenshot and describe what you see. ` +
      `Report each step as PASS or FAIL with one line of evidence. End with a final line that is exactly PASS or FAIL.\n${CHECKLIST}`,
    options: {
      mcpServers: {
        burrowbox: { type: "http", url: machine.mcpUrl, headers: { Authorization: `Bearer ${machine.mcpToken}` } },
      },
      allowedTools: tools.map((t) => `mcp__burrowbox__${t}`),
      permissionMode: "dontAsk", // anything not listed above is denied
      maxTurns: 60,
    },
  })) {
    if (message.type === "result") {
      const report = message.subtype === "success" ? message.result : `Agent stopped: ${message.subtype}`;
      console.log(report);
      verdict = report.trim().split("\n").pop()!.trim();
    }
  }
} finally {
  await bb(`/api/machines/${id}/stop`, { method: "POST" }); // cookies and files are kept for the next run
}
process.exit(verdict === "PASS" ? 0 : 1);

Some notes on the script:

Only the tools it needs. allowedTools approves six browser tools by their mcp__<server>__<tool> names. With permissionMode: "dontAsk", any other call that would need approval is denied instead of waiting for a prompt that nobody in CI will answer (permissions).
A narrow token. The machine token (tmm_…) works only on this machine's MCP endpoint. It can't list, create, stop or bill anything (Authentication). Your API key stays in the script and never reaches the model.
Stop in finally. A failed run still turns the machine off, so it doesn't keep billing between deploys.

Run it after every deploy

Add a job that runs after your staging deploy. The script's exit code fails the build when the agent reports FAIL.

  qa:
    needs: deploy-staging
    runs-on: ubuntu-latest
    concurrency: qa-staging   # one browser, so one run at a time
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm ci
      - run: npx tsx qa.ts
        env:
          BURROWBOX_KEY: ${{ secrets.BURROWBOX_KEY }}
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          QA_MACHINE_ID: ${{ vars.QA_MACHINE_ID }}

The machine has one browser, so runs share its tabs and cookies. The concurrency group keeps two deploys from testing at the same time. If you need parallel runs, give each one its own machine and its own vault entry.

If you'd rather not run the agent in CI, Burrowbox can run a job inside the machine itself: a webhook with stopAfter: true wakes the machine, runs one action and stops it again, and an event webhook reports the result as run.succeeded or run.failed. The Comet post shows that wiring with a schedule.

When the login needs a person

Some logins can't come from a vault: SSO with a push approval, or a CAPTCHA on the identity provider. As in Devin's setup, a person signs in once. Create an interactive live-view link with "mode": "browser" and "interactive": true and a short ttlSeconds, then open it and sign in as the test account. The cookies stay on the machine for later runs until the app expires them.

What it costs

A small machine costs $0.11 an hour while running, billed by the minute, so a ten-minute QA run comes to about two cents of machine time. Stopped between deploys, it costs $0.001 an hour, about $0.72 a month. Model usage is billed separately by Anthropic. See Billing.

Create an account to try it.

Key takeaways

Devin keeps a signed-in browser profile per organization. A Burrowbox machine keeps its browser's cookies on its own disk, once per machine.
Use a dedicated test account, keep its password and TOTP secret in the vault, and let browser_login handle expired sessions.
Give the agent only the machine token and an explicit tool list, and stop the machine when the run ends.

FAQ

How does Devin stay logged in to websites?

A person logs in through Devin's interactive browser, then asks Devin to save the browser profile. Devin adds the cookies, localStorage and Chrome profile data to the organization's blueprint, and new sessions start from it. Saved passwords aren't included, and cookies still expire normally.

Does the QA agent see the test account's password?

No. browser_login fills and submits the form from the vault and returns a result, not the secret. vault_list shows names, URLs and usernames only.

What happens when the session cookie expires?

The agent lands on the sign-in page, calls browser_login, and the vault credential (with its TOTP code, if set) signs it in again. If the login needs a person, for example an SSO push, open an interactive live-view link and sign in yourself.

Can I use Python instead of TypeScript?

Yes. The Python Agent SDK takes the same server config through ClaudeAgentOptions(mcp_servers=…, allowed_tools=…), with "type": "http", the machine's mcpUrl and an Authorization header (Agent SDK MCP docs).

Sources

Cognition, Introducing Devin: https://www.cognition.ai/introducing-devin
Devin docs, Browser authentication: https://docs.devin.ai/work-with-devin/browser-auth
Devin docs, Secrets & site cookies: https://docs.devin.ai/product-guides/secrets
Claude Agent SDK, Connect to external tools with MCP: https://code.claude.com/docs/en/agent-sdk/mcp
Claude Agent SDK, Quickstart: https://code.claude.com/docs/en/agent-sdk/quickstart
Claude Agent SDK, Configure permissions: https://code.claude.com/docs/en/agent-sdk/permissions
Burrowbox docs, Vault: https://burrowbox.dev/docs/vault
Burrowbox docs, MCP: https://burrowbox.dev/docs/mcp

Originally published on the Burrowbox blog.

Ephemeral sandbox vs persistent machine: what an AI agent keeps between runs

Burrowbox — Tue, 06 Oct 2026 16:33:47 +0000

Ephemeral sandbox or persistent machine: the short answer

Use an ephemeral sandbox when every run should start clean: running untrusted code, reproducible tests, one-off tasks that share nothing. Use a persistent machine when the agent needs something from last time: a signed-in browser, installed apps, files it wrote, or windows it left open.

Most comparisons of the two focus on code execution, where the state worth keeping is a cloned repo and some installed packages. An agent that uses a computer has more to lose, usually starting with a browser session it took a password and a 2FA code to get.

What each model keeps

Here's what survives between runs in each model. The persistent column describes a Burrowbox machine after stop and start, as documented in Machines.

State	Ephemeral sandbox	Persistent machine (Burrowbox)
Files the agent wrote	Gone	Kept
Installed apps and packages	Gone, unless baked into the image	Kept
Browser cookies, including session cookies	Gone	Kept
Open browser tabs and desktop windows	Gone	Reopened on start
Stored credentials (the vault)	Gone	Kept
Running processes and memory	Gone	Not kept: programs are relaunched

A Burrowbox stop snapshots the whole filesystem and records the open windows and tabs, but it doesn't keep memory. A script that was halfway through a loop starts over. If your agent's progress lives only in a process, write it to a file.

Two more details from the docs:

While a machine runs, a save point is taken every 30 minutes. If a machine stops unexpectedly, lastStopMode is crashed and it restores from the last save point.
The default light browser keeps its cookies across stop and start, but a live agent update makes it forget sign-ins. The full browser (Chromium) keeps them in both cases, so pick "browser": "full" for machines whose logins you care about.

Three ways a throwaway sandbox breaks a stateful agent

Starting an agent in a fresh environment every time tends to fail in one of three ways.

It logs in on every run

The agent opens the CRM, gets a login page, types the password, and only then starts the task, every time. On a persistent machine the browser still has yesterday's cookies, so the next run often skips the login page.

It reinstalls its toolchain

A sandbox that starts from a base image has to apt install the PDF tool, download the AppImage and configure the desktop app before it does anything useful. You can bake some of that into an image. You can't bake in per-customer setup, such as a desktop app signed in to that customer's account.

It hits a 2FA prompt nobody can answer

If the account uses an authenticator app, a fresh sandbox needs a code on every login, and there's no one at the keyboard. On a Burrowbox machine you store the TOTP secret in that machine's vault once, and the browser_login tool fills the form and the code without the model seeing either:

curl -X PUT https://burrowbox.dev/api/machines/$MACHINE_ID/vault/crm \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"url": "https://crm.example.com/login", "username": "agent@acme.com", "password": "…", "totpSecret": "…"}'

Combine the two and most runs never see a login page at all: the session cookie is still there, and when it expires, the agent calls browser_login and signs in again without asking anyone for a code.

When an ephemeral sandbox is the right call

A clean environment is the better default in plenty of cases:

Code a user uploaded, or a file you don't trust, should run somewhere you throw away afterwards.
Tests and evaluations should start from the same state every time. Leftovers from the last run make results hard to compare.
Ten research tasks that share nothing don't need to share a machine, and keeping them apart means one can't affect another.

Burrowbox covers this with warm pools. A claimed pool machine is brand new, nothing from other customers is on it, and pool machines are never reused after a claim. That's the model the Manus post builds on: a fresh machine per task, stopped when the task ends.

The hybrid: a pool for tasks, a machine per customer

You rarely need to pick one model for everything. A common split:

Clean work goes to a machine claimed from a pool, set up from the pool's template, and stopped or deleted afterwards.
Stateful work goes to one persistent machine per user or customer, which holds their logins, vault, files and apps. This is the one-computer-per-user model.

The two look similar in code. A task machine comes from a pool:

curl -X POST https://burrowbox.dev/api/pools/pool_3fa91c/claim \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"externalId": "cus_8f2a", "ttlMinutes": 30}'

A customer's machine is created once, tagged with their id, and then started and stopped for each session:

# first time
curl -X POST https://burrowbox.dev/api/machines \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"name": "acme", "size": "tiny", "browser": "full", "ttlMinutes": 30, "externalId": "cus_8f2a"}'

# every later session
curl -X POST https://burrowbox.dev/api/machines/$MACHINE_ID/start \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"ttlMinutes": 30}'

With ttlMinutes, the machine turns itself off when the time runs out. The default onExpire is stop, which keeps all state. Either way the agent connects to the machine's mcpUrl with its mcpToken, as in the quickstart.

What it costs to keep a machine

A persistent machine costs money while it's stopped, but not much. Per Billing, usage is charged by the minute:

Running: $0.07 an hour for tiny up to $0.26 an hour for large.
Stopped: $0.001 an hour, or $0.72 per 30 days, whatever the size.
Idle warm pool machines are billed like running machines.

Keeping state costs the stopped rate. Not keeping it costs the minutes each run spends signing in and reinstalling, billed at the running rate.

Key takeaways

Ask what the agent needs from the last run. If the answer is nothing, use a clean sandbox.
For computer-use agents, the state worth keeping is mostly logins, installed apps and files.
A Burrowbox stop keeps the disk, vault, cookies and open windows and tabs, but not memory.
Many products need both: pool machines for isolated tasks, and a persistent machine per customer.

FAQ

Does a persistent machine keep running processes?

Not on Burrowbox. Stopping keeps the filesystem and reopens windows and tabs on the next start, but memory isn't kept, so running programs are relaunched. Some sandboxes do keep memory: E2B's pause saves the filesystem and memory, including running processes, and a paused sandbox is kept until you delete it (E2B docs). Burrowbox isn't involved with E2B.

Is an ephemeral sandbox more secure?

It limits what one run can leave behind for the next. A persistent machine per customer keeps customers apart from each other instead of runs apart from each other: each machine has its own disk and vault, and its mcpToken is scoped to that machine. Use a fresh machine for untrusted code even if the customer also has a persistent one.

Can an agent stay logged in between runs?

Yes, on a persistent machine. Stop snapshots the browser's cookies, including session cookies, so the next start comes back signed in until the site expires the session. Use "browser": "full" so live agent updates don't sign it out, and keep the credentials in the vault for when the session does expire.

How do I get rid of a persistent machine?

DELETE /api/machines/{id} permanently deletes its files, apps, vault, browser profile, snapshots, scheduled jobs and webhooks. It can't be undone.

Create an account and try a machine that keeps its state.

Sources

E2B docs, Sandbox persistence: https://e2b.dev/docs/sandbox/persistence
Burrowbox docs, Machines: https://burrowbox.dev/docs/machines
Burrowbox docs, Warm pools: https://burrowbox.dev/docs/pools
Burrowbox docs, Vault: https://burrowbox.dev/docs/vault
Burrowbox docs, Billing: https://burrowbox.dev/docs/billing

Originally published on the Burrowbox blog.

ChatGPT agent works on its own computer. Build the same with the OpenAI Responses API

Burrowbox — Sun, 04 Oct 2026 02:49:54 +0000

What ChatGPT agent does

OpenAI started rolling out ChatGPT agent on July 17, 2025, for Pro, Plus and Team users. It combines Operator's ability to click around websites with deep research, and it can use a terminal. (TechCrunch)

How it uses a computer:

It works in its own isolated environment with a visual browser, a text browser and a terminal. (TechTarget)
When a site needs a password, the user switches to takeover mode and types it in themselves. (TechTarget)
It asks permission before consequential actions, such as purchases or sending emails. Users can also turn on watch mode to supervise it. (TechTarget)

On September 29, 2026, OpenAI added Dots: always-on agents in ChatGPT for Pro and Business Premium users. (TechCrunch) Each dot has its own cloud computer, and the user can view it while it works. Users set rules for what a dot does on its own and what needs their approval. (9to5Google)

The pattern

The agent has a computer of its own. The model never handles the password: a person signs in by taking over the screen. Risky steps wait for an explicit yes. To build this into your product, you need a machine per user, a way for the user to watch it and take control, and an approval step in your agent loop.

Build it with the Responses API and Burrowbox

Burrowbox isn't involved with OpenAI. Each Burrowbox machine has an MCP endpoint, and the OpenAI Responses API can call remote MCP servers directly, so the model can drive the machine with no MCP client on your side.

1. Create the machine

curl -X POST https://burrowbox.dev/api/machines \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"name": "sam", "size": "tiny", "externalId": "user_42", "ttlMinutes": 60}'
# → { "id": "2f6aeedcd3", "mcpUrl": "https://burrowbox.dev/api/machines/2f6aeedcd3/mcp", "mcpToken": "tmm_…", … }

2. Point the model at the machine's MCP endpoint

Reading tools run without asking. Everything else (clicks, form fills, shell commands) comes back as an approval request.

import OpenAI from "openai";
const openai = new OpenAI();

const machineTool = {
  type: "mcp",
  server_label: "burrowbox",
  server_url: process.env.MCP_URL,          // the machine's mcpUrl
  authorization: process.env.MCP_TOKEN,     // the machine's mcpToken
  require_approval: { never: { tool_names: ["browser_navigate", "browser_snapshot", "browser_screenshot", "screenshot"] } },
};

let resp = await openai.responses.create({
  model: "gpt-6-astra",
  tools: [machineTool],
  input: "Find a table for two on Friday at 7pm on example-bookings.com and get it ready to confirm.",
});

3. Ask the user before acting

for (const item of resp.output.filter((o) => o.type === "mcp_approval_request")) {
  const ok = await askUser(`Allow ${item.name}(${item.arguments})?`); // your UI
  resp = await openai.responses.create({
    model: "gpt-6-astra",
    tools: [machineTool],
    previous_response_id: resp.id,
    input: [{ type: "mcp_approval_response", approve: ok, approval_request_id: item.id }],
  });
}
console.log(resp.output_text);

This handles one round of approvals. A real loop repeats it until no requests are left.

4. Takeover for logins

When the agent reaches a login page, create an interactive live-view link and show it to the user. They type their password into the machine's browser, and it never goes through the model. Cookies are kept when the machine stops, so they usually only sign in once.

curl -X POST https://burrowbox.dev/api/machines/$MACHINE_ID/live-view \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"mode": "browser", "interactive": true, "ttlSeconds": 600, "allowedOrigins": ["https://app.example.com"]}'
# → { "url": "https://burrowbox.dev/embed/2f6aeedcd3?t=…", "iframe": "<iframe …>" }

For a watch mode, create the link with "interactive": false. Input is then blocked on the machine itself, not only in the page. To skip takeover entirely, store the login in the machine's vault, and the agent can use browser_login without seeing it.

5. Always on, like Dots

Set "ttlMinutes": null (PATCH /api/machines/{id}) to keep a machine running, or use a scheduled job with wakeIfStopped and stopAfter so it only runs (and bills) while it has work. A tiny machine costs $0.07 an hour while running. See Billing.

Create an account to try it.

Sources

TechCrunch, OpenAI launches a general-purpose agent in ChatGPT: https://techcrunch.com/2025/07/17/openai-launches-a-general-purpose-agent-in-chatgpt/
TechTarget, ChatGPT agent explained: https://www.techtarget.com/whatis/feature/ChatGPT-agents-explained
TechCrunch, OpenAI launches Dots: https://techcrunch.com/2026/09/29/openai-launches-dots-its-bubbly-agentic-avatar/
9to5Google, OpenAI launches Dots: https://9to5google.com/2026/09/29/openai-dots-agent/
OpenAI docs, MCP and connectors (Responses API): https://developers.openai.com/api/docs/guides/tools-connectors-mcp
Burrowbox docs: https://burrowbox.dev/docs

Originally published on the Burrowbox blog.

Claude computer use needs a computer. Give it one through the Claude API's MCP connector

Burrowbox — Sun, 04 Oct 2026 02:49:50 +0000

What Claude computer use does

Anthropic released computer use as a public beta on October 22, 2024. Claude looks at a screen and works it like a person, moving the cursor, clicking buttons and typing text. It's available through the Claude API, Amazon Bedrock and Google Cloud's Vertex AI. (Anthropic)

What matters here is where it runs. Claude doesn't come with a computer. It returns actions such as screenshot, left_click or type, your application carries them out in an environment you control, and the results go back to Claude. The loop repeats until the task is done. Anthropic's reference implementation is a Docker container with a virtual X11 display, a lightweight desktop and some preinstalled apps. (Claude docs)

Anthropic's docs also recommend some precautions (same source):

Use a dedicated virtual machine or container with minimal privileges.
Don't give the model sensitive data such as login credentials.
Limit internet access to an allowlist of domains.
Ask a human to confirm consequential actions.

The pattern

The model supplies the decisions, and you supply the computer. For a demo, that's a container on your laptop. For a product, you need one computer per user or per task, kept between sessions, with credentials the model doesn't see and a way for people to watch.

Build it with the Claude API and Burrowbox

A Burrowbox machine is a Linux desktop with its own MCP endpoint. Its tools include desktop control (screenshot, click, type_text, get_app_state), a persistent browser (browser_navigate, browser_snapshot, browser_login) and shell_run. With the Messages API's MCP connector, Claude calls these tools directly, so you don't need an MCP client or a tool loop of your own. Burrowbox isn't affiliated with Anthropic.

1. Create a machine

curl -X POST https://burrowbox.dev/api/machines \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"name": "ops-desk", "size": "small", "ttlMinutes": 30}'
# → { "id": "…", "mcpUrl": "https://burrowbox.dev/api/machines/…/mcp", "mcpToken": "tmm_…" }

2. Give Claude the machine (Python)

import os
import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY

response = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    betas=["mcp-client-2025-11-20"],
    mcp_servers=[{
        "type": "url",
        "url": os.environ["MCP_URL"],                       # the machine's mcpUrl
        "name": "burrowbox",
        "authorization_token": os.environ["MCP_TOKEN"],     # the machine's mcpToken
    }],
    tools=[{
        "type": "mcp_toolset",
        "mcp_server_name": "burrowbox",
        # allowlist: only the tools this task needs
        "default_config": {"enabled": False},
        "configs": {t: {"enabled": True} for t in [
            "browser_navigate", "browser_snapshot", "browser_click", "browser_fill",
            "browser_login", "screenshot", "file_write",
        ]},
    }],
    messages=[{"role": "user", "content": "Log in to the supplier portal, download this month's invoices and save a summary to ~/invoices.md"}],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

The token only works for this one machine. Claude's tool calls show up in the response as mcp_tool_use and mcp_tool_result blocks, which you can log.

3. How this lines up with Anthropic's precautions

Dedicated machine: every machine is its own isolated container with its own disk.
No credentials in the prompt: put the login in the machine's vault (PUT /api/machines/{id}/vault/{name}). browser_login fills the form without returning the password to Claude.
Human confirmation: embed the live view so a person can watch ("interactive": false) or take over ("interactive": true). For approval on each tool call, run your own tool loop instead of the connector.
Domain allowlist: Burrowbox doesn't filter a machine's outbound traffic. Enforce that in your own network layer if you need it.

4. Let Claude manage machines too

The platform MCP endpoint takes your API key. Through it, an agent can create, start, stop and destroy machines (machine_create, machine_stop, …) and call any machine tool with machine_call_tool:

claude mcp add --transport http burrowbox https://burrowbox.dev/mcp \
  --header "Authorization: Bearer $BURROWBOX_KEY"

A small machine (1 vCPU, 6 GB) costs $0.11 an hour while running, and state is kept when it's off. See Billing.

Create an account to try it.

Sources

Anthropic, Introducing computer use: https://www.anthropic.com/news/3-5-models-and-computer-use
Claude docs, Computer use tool: https://platform.claude.com/docs/en/docs/agents-and-tools/tool-use/computer-use-tool
Claude docs, MCP connector: https://platform.claude.com/docs/en/agents-and-tools/mcp-connector
Burrowbox docs, MCP: https://burrowbox.dev/docs/mcp

Originally published on the Burrowbox blog.

Manus gives every task its own cloud computer. Build it as a durable workflow on Vercel

Burrowbox — Sun, 04 Oct 2026 02:49:46 +0000

What Manus does

Manus is an agent that takes a goal and works on it by itself. Its January 2026 post on the Manus Sandbox explains the computing side (Manus):

Manus allocates a fully isolated cloud virtual machine for each task.
The sandbox works like a personal computer, with networking, a file system, a browser and software tools.
Files survive when the sandbox sleeps and wakes. Sandboxes that sit inactive are recycled after 7 days on the free plan and 21 days on Pro. After that, only artifacts and uploads are restored, not temporary files.

The pattern

A task gets a whole computer: the agent can install what it needs, write files and use a browser without touching anyone else's work. Tasks can run for a long time, so the code driving them has to survive retries and restarts, and it has to clean up when the task ends.

Build it with Burrowbox and the Vercel Workflow SDK

Vercel's Workflow SDK runs durable functions. Each "use step" function is retried automatically when it throws, and the workflow resumes where it left off. Below, each task claims a pre-built Burrowbox machine, runs an agent on it, saves the result and turns the machine off. Burrowbox isn't involved with Manus.

1. A warm pool with your tools preinstalled

Every pool machine runs this template before it counts as ready, so claimed machines don't spend time installing anything.

curl -X POST https://burrowbox.dev/api/pools \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"name": "tasks", "size": "small", "target": 2,
       "setup": [{"type": "tool", "tool": "apps_install", "arguments": {"kind": "apt", "packages": ["python3", "pandoc"]}}]}'

2. The workflow

npm i workflow ai @ai-sdk/mcp, then wrap next.config.ts with withWorkflow from workflow/next.

// workflows/task.ts
import { generateText, isStepCount } from "ai";
import { createMCPClient } from "@ai-sdk/mcp";

const BB = "https://burrowbox.dev";
const bb = (path: string, init: RequestInit = {}) =>
  fetch(`${BB}${path}`, {
    ...init,
    headers: { Authorization: `Bearer ${process.env.BURROWBOX_KEY}`, "Content-Type": "application/json" },
  }).then((r) => r.json());

export async function runTask(userId: string, goal: string) {
  "use workflow";
  const machineId = await claimMachine(userId);
  try {
    const report = await runAgent(machineId, goal);
    await saveReport(userId, report);
  } finally {
    await stopMachine(machineId);
  }
}

async function claimMachine(userId: string) {
  "use step";
  const m = await bb(`/api/pools/${process.env.POOL_ID}/claim`, {
    method: "POST",
    body: JSON.stringify({ externalId: userId, ttlMinutes: 120 }), // stops itself after 2 h at the latest
  });
  return m.id as string; // keep the token out of workflow state
}

async function runAgent(machineId: string, goal: string) {
  "use step";
  const m = await bb(`/api/machines/${machineId}`); // includes mcpUrl and mcpToken
  const mcp = await createMCPClient({
    transport: { type: "http", url: m.mcpUrl, headers: { Authorization: `Bearer ${m.mcpToken}` } },
  });
  try {
    const { text } = await generateText({
      model: "anthropic/claude-sonnet-5.5",
      tools: await mcp.tools(), // shell_run, file_write, browser_navigate, …
      stopWhen: isStepCount(50),
      system: "Work in ~/task. Write the final report to ~/task/report.md, then reply with its contents.",
      prompt: goal,
    });
    return text;
  } finally {
    await mcp.close();
  }
}

async function stopMachine(machineId: string) {
  "use step";
  await bb(`/api/machines/${machineId}/stop`, { method: "POST" }); // files are kept for follow-ups
}

async function saveReport(userId: string, report: string) {
  "use step";
  await db.reports.insert({ userId, report }); // your database
}

Start it from a route:

// app/api/tasks/route.ts
import { start } from "workflow/api";
import { runTask } from "@/workflows/task";

export async function POST(req: Request) {
  const { userId, goal } = await req.json();
  await start(runTask, [userId, goal]);
  return Response.json({ ok: true });
}

Some notes:

Retries. If a step throws, it's retried. A retried claimMachine claims a second machine, so for strict once-only behavior, look up the user's machine first with GET /api/machines?externalId=….
Follow-ups go to the same machine. POST /api/machines/{id}/start restores its files, installed apps and (with "browser": "full") browser logins. When you're finished with it, DELETE /api/machines/{id}.
Watching. To watch a task live, create a live-view link for its machine.

What it costs

A small machine (1 vCPU, 6 GB) costs $0.11 an hour while running. A stopped machine costs $0.001 an hour. Idle pool machines are billed like running ones, so a pool of 2 small machines costs about $0.22 an hour. See Billing.

Create an account to try it.

Sources

Manus, Understanding Manus sandbox: https://manus.im/blog/manus-sandbox
Workflow SDK, Getting started with Next.js: https://workflow-sdk.dev/docs/getting-started/next
Workflow SDK, Workflows and steps: https://workflow-sdk.dev/docs/foundations/workflows-and-steps
AI SDK, MCP tools: https://ai-sdk.dev/docs/ai-sdk-core/mcp-tools
Burrowbox docs, Warm pools: https://burrowbox.dev/docs/pools

Originally published on the Burrowbox blog.

Meta's Muse gives every user a cloud computer. Here's how to do the same for your customers

Burrowbox — Sun, 04 Oct 2026 02:49:42 +0000

What Muse does

Meta announced Muse on September 8, 2026. It's a personal agent that sends email, books travel, fills out forms and makes purchases for people. (Meta)

From Meta's own posts, here's how it uses computing:

One machine per user. Each user's agent runs on its own virtual machine in Meta's cloud, the "Muse Secure VM". No other user's agent can reach it. (Meta)
A real computer. The agent has a file system, a terminal and a full web browser, and its memory carries over between conversations. (How We Designed Muse)
Secrets it can't see. Passwords and payment details go into secure storage, so Muse can use them without seeing them. A separate Sentinel agent on the same machine has to approve anything that reaches the internet. (Meta) The agent runs in an isolated container and only gets stand-in tokens. Real credentials are added as a request leaves the machine. (Meta engineering)
People approve and audit. Muse checks with the user before sensitive actions, such as sending an email or making a purchase, and keeps a full record of what it has done. (Meta)

The pattern

Each user gets a persistent computer. The agent works there with a browser and files and uses stored logins without seeing them. The user can watch what it does. If your product runs agents for your customers, this is the setup you want, and you don't have to build the machines yourself.

Build it with Burrowbox and the Vercel AI SDK

Burrowbox gives each customer a persistent Linux machine with a browser that stays signed in, an encrypted vault and its own MCP endpoint. Burrowbox isn't involved with Muse. Below, a Next.js app gives each user their own machine.

1. A machine per user (REST)

// lib/burrowbox.ts
export const bb = (path: string, body?: unknown) =>
  fetch(`https://burrowbox.dev${path}`, {
    method: body ? "POST" : "GET",
    headers: { Authorization: `Bearer ${process.env.BURROWBOX_KEY}`, "Content-Type": "application/json" },
    body: body ? JSON.stringify(body) : undefined,
  }).then((r) => r.json());

// Returns the user's machine, running, with its mcpUrl and mcpToken.
export async function machineFor(user: { id: string; machineId?: string }) {
  if (user.machineId) {
    await bb(`/api/machines/${user.machineId}/start`, { ttlMinutes: 30 }); // resumes where it left off
    return bb(`/api/machines/${user.machineId}`);
  }
  const m = await bb("/api/machines", { size: "tiny", browser: "full", ttlMinutes: 30, externalId: user.id });
  await db.users.update(user.id, { machineId: m.id }); // your database
  return m;
}

externalId tags the machine with your user's id. browser: "full" (Chromium) keeps the browser's logins across restarts. When ttlMinutes runs out, the machine turns off and keeps its files, apps and browser cookies, and start brings it back still signed in.

2. Their logins go into their machine's vault

curl -X PUT https://burrowbox.dev/api/machines/$MACHINE_ID/vault/airline \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"url": "https://airline.example.com/login", "username": "sam@example.com", "password": "…"}'

The agent calls browser_login, which fills and submits the form without returning the password to the model. See Vault.

3. Run the agent on the user's machine (AI SDK + MCP)

The AI SDK's MCP client connects to the machine's MCP endpoint with the machine-scoped token, so this agent can't reach any other machine.

// app/api/agent/route.ts
import { generateText, isStepCount } from "ai";
import { createMCPClient } from "@ai-sdk/mcp";
import { machineFor } from "@/lib/burrowbox";

export async function POST(req: Request) {
  const { prompt } = await req.json();
  const user = await currentUser(); // your auth
  const machine = await machineFor(user);

  const mcp = await createMCPClient({
    transport: { type: "http", url: machine.mcpUrl, headers: { Authorization: `Bearer ${machine.mcpToken}` } },
  });
  try {
    const { text } = await generateText({
      model: "anthropic/claude-sonnet-5.5",
      tools: await mcp.tools(), // browser_navigate, browser_login, shell_run, file_write, …
      stopWhen: isStepCount(25),
      prompt,
    });
    return Response.json({ text });
  } finally {
    await mcp.close();
  }
}

4. Let the user watch

Create a short-lived live-view link on the server and show it in an iframe. With interactive: false, input is blocked on the machine itself.

const view = await bb(`/api/machines/${machine.id}/live-view`, {
  mode: "browser", interactive: false, ttlSeconds: 900, allowedOrigins: ["https://app.example.com"],
});
// <iframe src={view.url} style={{ width: "100%", aspectRatio: "16/10", border: 0 }} />

Burrowbox doesn't filter outbound traffic the way Sentinel does. Your agent decides which steps need the user's confirmation. See Embed the live view.

What it costs

A tiny machine costs $0.07 an hour while running and $0.001 an hour while stopped. A user who runs their agent 30 minutes a day costs about $1.05 a month in running time plus $0.72 for storage. See Billing.

Create an account to try it.

Sources

Meta, Introducing Muse: https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/
Meta, How We Designed Muse: https://introducing.muse.ai/
Meta, How We Built Safety Into Muse: https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse
AI SDK, MCP tools: https://ai-sdk.dev/docs/ai-sdk-core/mcp-tools
AI SDK, tool calling and stop conditions: https://ai-sdk.dev/docs/ai-sdk-core/tools-and-tool-calling
Burrowbox docs: https://burrowbox.dev/docs

Originally published on the Burrowbox blog.

Comet puts an assistant in your browser. Put one in a cloud browser that works on a schedule

Burrowbox — Sun, 04 Oct 2026 02:49:38 +0000

What Comet does

Perplexity launched Comet on July 9, 2025. It's a web browser with Perplexity's search built in and an assistant in a sidebar. The Comet Assistant can summarize emails and calendar events, manage tabs and navigate web pages for the user, with the page they're viewing as context. At launch it was open to subscribers of the $200-a-month Max plan and people invited from a waitlist. (TechCrunch)

The pattern

A browsing agent is most useful in a browser that's already signed in to your accounts. Comet does that by living in the browser you use. The other option is a browser in the cloud that stays signed in. It works when your laptop is closed, can run on a schedule, and reports back when it's done. That suits recurring research: a morning digest of a dashboard, a weekly price check, a report from an inbox.

Build it with Burrowbox: schedules and event webhooks

A Burrowbox machine has one persistent browser. Sign in once (yourself, through an interactive live view, or with vault credentials and browser_login), and its cookies survive stops and restarts. Create the machine with "browser": "full" (Chromium); that's the mode that keeps logins across restarts. Burrowbox wakes the machine on a schedule and tells your server when it's ready. Your server runs the agent and turns the machine off again. Burrowbox isn't involved with Perplexity.

1. Wake the machine every weekday morning

The scheduled job starts the machine if it's off and opens the dashboard in its signed-in browser. Cron times are in UTC.

curl -X POST https://burrowbox.dev/api/machines/$MACHINE_ID/schedules \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{
    "name": "Morning digest",
    "cron": "0 7 * * mon-fri",
    "action": { "type": "tool", "tool": "browser_navigate", "arguments": { "url": "https://analytics.example.com/overview" } },
    "wakeIfStopped": true
  }'
# The response includes the next three run times in "upcoming".

2. Get told when it ran

curl -X POST https://burrowbox.dev/api/event-webhooks \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"url": "https://api.example.com/burrowbox/events", "events": ["run.succeeded", "run.failed"]}'
# → { "id": "…", "secret": "whsec_…" }   (the secret is shown once)

3. Verify the event, run the agent, turn the machine off

// npm i express ai @ai-sdk/mcp
import crypto from "node:crypto";
import express from "express";
import { generateText, isStepCount } from "ai";
import { createMCPClient } from "@ai-sdk/mcp";

const BB = "https://burrowbox.dev";
const auth = { Authorization: `Bearer ${process.env.BURROWBOX_KEY}` };

function verify(rawBody, header, secret, toleranceSeconds = 300) {
  const parts = Object.fromEntries(header.split(",").map((p) => p.split("=")));
  const expected = crypto.createHmac("sha256", secret).update(`${parts.t}.${rawBody}`).digest("hex");
  const ok = parts.v1 && parts.v1.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(parts.v1), Buffer.from(expected));
  return ok && Math.abs(Date.now() / 1000 - Number(parts.t)) <= toleranceSeconds;
}

const app = express();
app.post("/burrowbox/events", express.raw({ type: "application/json" }), async (req, res) => {
  if (!verify(req.body, req.get("Burrowbox-Signature") ?? "", process.env.BURROWBOX_WHSEC)) return res.sendStatus(400);
  res.sendStatus(200); // answer within 10 s, then do the work
  const event = JSON.parse(req.body);
  if (event.type !== "run.succeeded") return;

  const id = event.data.machine.id;
  const machine = await fetch(`${BB}/api/machines/${id}`, { headers: auth }).then((r) => r.json());
  const mcp = await createMCPClient({
    transport: { type: "http", url: machine.mcpUrl, headers: { Authorization: `Bearer ${machine.mcpToken}` } },
  });
  try {
    const { text } = await generateText({
      model: "anthropic/claude-sonnet-5.5",
      tools: await mcp.tools(),
      stopWhen: isStepCount(20),
      prompt: "The browser is on the analytics overview. Read it with browser_snapshot and write a 5-bullet digest of what changed since yesterday.",
    });
    await sendDigest(text); // email, Slack, …
  } finally {
    await mcp.close();
    await fetch(`${BB}/api/machines/${id}/stop`, { method: "POST", headers: auth }); // state kept, billing drops to storage
  }
});
app.listen(3000);

Events can arrive more than once, so deduplicate on event.id before sending anything. run.failed events include the first 2,000 characters of the run's output, which is useful for alerts.

What it costs

The machine runs only between the schedule waking it and your handler stopping it. A few minutes a day on a tiny machine ($0.07 an hour) comes to well under a dollar a month, plus $0.72 a month to store it while it's off. See Billing.

Create an account to try it.

Sources

TechCrunch, Perplexity launches Comet: https://techcrunch.com/2025/07/09/perplexity-launches-comet-an-ai-powered-web-browser/
AI SDK, MCP tools: https://ai-sdk.dev/docs/ai-sdk-core/mcp-tools
AI SDK, tool calling and stop conditions: https://ai-sdk.dev/docs/ai-sdk-core/tools-and-tool-calling
Burrowbox docs, Scheduled jobs & webhooks: https://burrowbox.dev/docs/automations
Burrowbox docs, Event webhooks: https://burrowbox.dev/docs/events

Originally published on the Burrowbox blog.

Project Mariner runs ten tasks at once on cloud VMs. Fan out your own agents with LangChain

Burrowbox — Sun, 04 Oct 2026 02:49:34 +0000

What Project Mariner does

Project Mariner is Google's agent that browses and acts on websites for people. At I/O in May 2025, Google said the new version runs on virtual machines in the cloud. That lets it handle up to 10 tasks at once while people get on with other work. It launched first for U.S. subscribers to the $249.99-a-month AI Ultra plan. (TechCrunch)

The pattern

When the agent runs in the user's own browser, it does one thing at a time, and it stops when the laptop closes. Moving it to cloud machines means one machine per task. Tasks run side by side, can't interfere with each other, and keep going in the background. The machines have to be ready quickly, though, or the parallelism goes into waiting for boots.

Build it with LangChain and Burrowbox

Here, a Python job takes a list of tasks, claims a ready Burrowbox machine for each one, and runs a LangChain agent on each machine at the same time. Burrowbox isn't involved with Google.

1. Keep machines warm

A warm pool keeps booted machines waiting, so a claim returns one instantly. You can also give it a template, so each machine is already set up (here, the browser is already open on the site).

curl -X POST https://burrowbox.dev/api/pools \
  -H "Authorization: Bearer $BURROWBOX_KEY" -H "Content-Type: application/json" \
  -d '{"name": "browse", "size": "tiny", "target": 5,
       "setup": [{"type": "tool", "tool": "browser_navigate", "arguments": {"url": "https://shop.example.com"}}]}'
# → { "id": "pool_3fa91c", "ready": 0, "warming": 5, … }

2. Fan out

pip install langchain-mcp-adapters langgraph "langchain[anthropic]" httpx

import asyncio, os
import httpx
from langchain_mcp_adapters.client import MultiServerMCPClient
from langchain.agents import create_agent

BB = "https://burrowbox.dev"
POOL_ID = os.environ["POOL_ID"]
auth = {"Authorization": f"Bearer {os.environ['BURROWBOX_KEY']}"}

async def run_task(http: httpx.AsyncClient, task: str) -> str:
    # A fresh machine for this task; it's deleted afterwards (and destroyed on expiry as a backstop).
    m = (await http.post(f"{BB}/api/pools/{POOL_ID}/claim", headers=auth,
                         json={"ttlMinutes": 30, "onExpire": "destroy"})).json()
    try:
        mcp = MultiServerMCPClient({
            "machine": {
                "transport": "http",
                "url": m["mcpUrl"],
                "headers": {"Authorization": f"Bearer {m['mcpToken']}"},
            }
        })
        agent = create_agent("anthropic:claude-opus-5-5", await mcp.get_tools())
        result = await agent.ainvoke({"messages": task})
        return result["messages"][-1].content
    finally:
        await http.delete(f"{BB}/api/machines/{m['id']}", headers=auth)

async def main():
    tasks = [
        "Find the price of the 2 kg bag of espresso beans on shop.example.com",
        "Check whether shop.example.com ships to Portugal and what it costs",
        "List the three newest grinders on shop.example.com with prices",
    ]
    async with httpx.AsyncClient(timeout=120) as http:
        for task, answer in zip(tasks, await asyncio.gather(*(run_task(http, t) for t in tasks))):
            print(f"## {task}\n{answer}\n")

asyncio.run(main())

Each agent gets the machine's tools (browser_navigate, browser_snapshot, browser_click, browser_fill, shell_run, …), scoped to that machine by its token.

Some details from the docs:

Claims never reuse a machine. A claimed machine is brand new, and the pool refills itself in the background. If the pool is empty, the claim boots a new machine in a few seconds ("fromPool": false).
Tag claims with externalId if the tasks belong to different customers. GET /api/usage?groupBy=externalId then shows what each customer cost.
To watch a run, create a live-view link for any machine. Use mode: "browser" to see just the browser.

What it costs

Idle pool machines are billed like running ones: a pool of 5 tiny machines costs about $0.35 an hour. Each task machine costs $0.07 an hour, charged by the minute, until you delete it. Set the pool's target to match how many tasks you usually run at once, or 0 outside working hours (PATCH /api/pools/{id}). See Billing.

Create an account to try it.

Sources

TechCrunch, Google rolls out Project Mariner: https://techcrunch.com/2025/05/20/google-rolls-out-project-mariner-its-web-browsing-ai-agent/
langchain-mcp-adapters README: https://github.com/langchain-ai/langchain-mcp-adapters
Burrowbox docs, Warm pools: https://burrowbox.dev/docs/pools

Originally published on the Burrowbox blog.