Case Study: Desktop Agent Browser

Redacted architecture case study. Product names, accounts, scripts, credentials, and private source are withheld. This repo documents the architecture and tradeoffs.

One-line summary

A desktop browser shell with an AI sidecar: the browser is the workspace, automations run locally via Playwright, agent data lives in local SQLite/file-system stores, and an MCP server exposes the browser-agent runtime to external AI clients.

Why this is technically interesting

Most agent tools live as SaaS dashboards. This one was designed around the opposite thesis: the browser is the operating surface. Instead of sending everything to a hosted agent, the local app coordinates real sessions, local state, scheduled automations, and manual approval.

Scale / build facts

• 262 commits in six days.
• Electron + React + TypeScript desktop app.
• Playwright-driven automation runtime.
• Local SQLite agent stores.
• Separate MCP build target and CLI binary.
• Packaged for macOS, Windows, and Linux via electron-builder.

System architecture

┌────────────────────────────┐
│ Electron renderer           │
│ - browser/new-tab dashboard │
│ - side panels               │
│ - AI chat rail              │
│ - approval queues           │
└──────────────┬─────────────┘
               │ preload IPC
┌──────────────▼─────────────┐
│ Electron main process       │
│ - window/session mgmt       │
│ - scheduler                 │
│ - agent runtime             │
│ - local database access     │
└───────┬──────────────┬─────┘
        │              │
┌───────▼──────┐ ┌─────▼────────┐
│ Playwright    │ │ Local stores  │
│ worker        │ │ ~/.app/agents │
│ - scans       │ │ SQLite/config │
│ - replies     │ │ history       │
│ - outreach    │ └──────────────┘
└───────┬──────┘
        │
┌───────▼────────┐
│ MCP server      │
│ - stdio CLI     │
│ - tool surface  │
│ - external AI   │
└────────────────┘

Main engineering decisions

1. Browser-first UX

The new-tab page is the dashboard. Automations and content tools are panels over browsing, not separate SaaS pages. That keeps the operator in the same context as the accounts and sessions they are automating.

2. Filesystem-as-agent database

Each automation owns a folder with its scripts, configs, SQLite tables, and history. That makes the runtime inspectable and portable: an agent is a folder, not a hidden SaaS object.

3. Playwright worker isolation

Automation runs through a separate worker/runtime boundary, not directly inside UI components. This reduces UI coupling and makes dry-runs and scheduled execution easier.

4. MCP as a distribution surface

The app builds a separate MCP server binary, so external AI clients can call the browser-agent surface as tools. This turns the desktop app into both a user-facing product and an agent-accessible local capability.

5. Manual approval by default

The system can draft, preview, and schedule, but publishing/outbound actions are approval-gated. That is important when agents operate on real social/professional accounts.

What a developer should notice

• This is not a web dashboard pretending to automate the browser.
• Local execution, local state, and local sessions are first-class.
• The MCP surface is not an afterthought; it is a build target.
• The architecture prioritises operator control over fully autonomous posting.

What I would improve next

• Add signed/notarised macOS releases.
• Add CI for packaged builds.
• Add deterministic tests around agent scripts and scheduling.
• Normalize product naming across repo/package/app/MCP binary.