Docs · guides

Browser Computer

Give TeamDay agents a persistent hosted browser for user-like web browsing, screenshots, page inspection, and logged-in workflows.

Browser Computer

Browser Computer gives TeamDay agents a persistent browser inside the hosted runner. It is for tasks where normal WebFetch is not enough: JavaScript-heavy apps, screenshots, authenticated pages, dashboards, and multi-step web workflows.

The browser runs with a named profile, so cookies and local storage can persist between runs on the same runner profile.

What It Provides

Agents get the browser-computer skill plus a built-in MCP server named teamday-browser-computer.

Available MCP tools:

ToolPurpose
browser_statusCheck whether a browser profile is running
browser_openOpen or reuse a persistent browser profile and navigate to a URL
browser_snapshotReturn the page title, URL, visible text, links, inputs, and buttons
browser_screenshotCapture a PNG screenshot from the current page
browser_evalRun JavaScript in the page for inspection or automation
browser_clickClick an element by text or CSS selector
browser_typeType into an input by selector
browser_stopStop a running browser profile

When To Use It

Use Browser Computer when the agent needs to:

  • Browse a site as a real user after authentication
  • Inspect a dashboard that requires client-side JavaScript
  • Capture screenshots for QA, support, sales, or reporting
  • Click through a workflow and summarize what it sees
  • Keep a durable session with cookies under a named browser profile

Use normal WebSearch or WebFetch for public static pages where no session, screenshot, or JavaScript execution is needed.

Access For Your Agent

For hosted TeamDay runner chats and jobs, Browser Computer is built in. After the runner image with Browser Computer is deployed, agents do not need a custom MCP installation to use it.

To use it:

  1. Open a TeamDay workspace chat or mission that runs on the hosted runner.
  2. Ask the agent to use Browser Computer and name the profile it should use.
  3. Give the target URL and the outcome you want.

Example:

Use Browser Computer with profile "linkedin-main".
Open https://www.linkedin.com/, inspect my feed, and summarize the top relevant posts.
If the page is not logged in, stop and tell me what login step is required.

For an agent that should routinely browse sites, add browser-computer to its skills or mention Browser Computer in the system prompt:

When a task requires an authenticated website, JavaScript app, screenshot, or click workflow, use the browser-computer skill and the teamday-browser-computer MCP tools. Reuse named profiles instead of creating throwaway sessions.

Profiles

A profile is the durable browser identity. Use stable names like:

  • linkedin-main
  • salesforce-admin
  • analytics-prod
  • qa-checkout

Do not mix unrelated accounts in one profile. If an agent has to use multiple identities, give each identity its own profile name.

Authentication

Browser Computer can keep cookies once a browser profile is authenticated. If a site requires an interactive login, passkey, CAPTCHA, or 2FA challenge, the agent should stop and ask the user for the missing step.

The current runner capability provides the persistent browser and automation tools. A polished live user handoff UI, where a human directly controls the hosted browser to complete login, is a separate product surface.

Example Agent Flow

An agent will typically:

  1. Call browser_status for the named profile.
  2. Call browser_open with the URL and profile.
  3. Call browser_snapshot to inspect the page.
  4. Use browser_click, browser_type, or browser_eval when interaction is needed.
  5. Call browser_screenshot when visual proof is useful.
  6. Leave the profile running only when follow-up work needs the same page state.

Security Notes

  • Browser profiles can contain authenticated cookies. Treat profile names as access boundaries.
  • Use separate profiles for different users, customers, and environments.
  • Do not ask agents to bypass CAPTCHAs, MFA, paywalls, or site rules.
  • Prefer OAuth/API MCPs when a site has a proper API integration; use Browser Computer for workflows that genuinely require the website UI.