Supergood vs Playwright: APIs vs Browser Automation for AI Agents

A Playwright alternative for AI agents: why network-layer APIs beat browser automation for high-volume, production access to third-party portals.

Say you're evaluating a Playwright alternative for AI agents that have to log into third-party portals: a property management system, a payer portal, a carrier dashboard. You're really comparing two different layers of the stack. Playwright drives a browser: it renders pages, finds selectors, and clicks. Supergood generates and maintains a REST API (and MCP tools) for the same portal by capturing the network calls the portal already makes. This piece is about when each layer is the right one, and why for production, high-volume agent access the browser is usually the wrong place to be.

TL;DR

Playwright is excellent, best-in-class, for cross-browser end-to-end testing of an application you own and control. It is the wrong tool for running AI agents against third-party portals at volume, because a rendering-layer approach pays a browser tax on every call: seconds of latency, dollars of infrastructure, and a maintenance burden that snaps every time the target site redesigns a page. Supergood works one layer down at the network, so calls are milliseconds instead of seconds, auth and MFA are handled, and a frontend redesign changes nothing.

Comparison at a glance

Latency: why browsers are disqualifying for voice agents

Browsers exist so humans can perform tasks with their eyes. If your automation boots a browser to click a button, you've put a human-shaped suit on a computer and told it to run faster. That suit has weight. Every call pays for a browser process to start, a page to fetch and render, the DOM to settle, and, because an agent is driving, one or more LLM round-trips to decide what to click next.

The research on computer-using agents (CUAs) puts numbers on the cost. In one study, tasks a human finishes in about 2 minutes routinely take agents 20+ minutes, and across 16 top agents even the best used 1.4 to 2.7x more steps than needed; 75 to 94% of total task time is burned on LLM planning and reflection rather than the work itself (arXiv:2506.16042). That is a fine profile for an offline batch job. It is disqualifying for a voice agent, where a caller is on the line and a multi-second gap reads as a dropped call.

A network call has a method, a URL, a body, a status code, and a payload. Supergood works at that layer: no headless browser, no DOM, no selectors, so a portal action is a single request measured in milliseconds. That's the difference between an agent that can hold a phone conversation and one that can't. We wrote up the general case for skipping the browser entirely in The Antibrowser, and the broader shift toward agents that act rather than click in What is agentic AI.

Maintenance burden: who fixes it when the portal changes

A button has pixels, and pixels look the same whether the click did the right thing or did nothing. That is the maintenance trap with browser automation against sites you don't own: your selectors encode assumptions about someone else's markup, and that markup changes on their schedule, not yours. When the portal ships a redesign, your agent breaks, and you find out from a failed run, or worse, from a wrong result.

The failure mode is subtle enough to be dangerous. The most rigorous public CUA benchmark reports agent success of 67 to 85% on simple UI interactions but only 9 to 19% on complex multi-step workflows, and documents "trajectory degradation": the agent looks productive while quietly dropping constraints and confirmation steps, and eventually submits the wrong record at step 14, the worst failure mode because the system reports success (arXiv:2511.17131). A screen-clicking agent can be confidently, silently wrong.

Supergood started as an observability company monitoring third-party APIs, and the founding observation carries the whole argument: network calls are deterministically observable and maintainable; buttons on a screen are not. Because the generated tools work at the network layer, frontend redesigns don't break anything: the tools never touched the frontend. When a portal changes its backend API, production telemetry catches it and a maintenance agent ships a fix, usually before the customer notices. For the general pattern of giving agents a stable interface to software that never exposed one, see MCP for software without a public API and What is an unofficial API.

Cost at scale: the browser tax compounds

Latency and maintenance both show up on the invoice, but raw infrastructure is the cleanest line to draw. A hosted browser session costs roughly $0.12 to $0.24 at the cheapest. A real multi-step workflow (login, navigate, clear MFA, fill a form, plus the LLM round-trips to drive it) lands closer to $1.00 to $1.50 per completed call. A network call to the same backend skips all of that overhead. At production scale, those per-call differences stop being rounding error and start being budget.

Cost math worked example

Assumptions: cheapest hosted browser session $0.15; realistic multi-step completed workflow $1.00/call.

Annualized at 1M/month: browser floor ≈ $1.8M/yr; realistic ≈ $12M/yr. The floor figure assumes a perfect one-session-per-call world with no retries and no LLM tokens, which is not the world anyone actually operates in; the realistic column is the number to plan with. Note these are infrastructure costs only and exclude the engineering time to build and maintain the automation, which is where the browser approach hurts most.

Code side by side

Here's a realistic Playwright login-and-submit flow against a portal. It's clean Playwright, nothing wrong with the code, but note everything it has to own: the browser lifecycle, the selectors, the waits, the MFA loop, and (not shown) the retry and observability scaffolding around it.

const { chromium } = require('playwright');

async function submitCharge(account, tenantId, amount) {
  const browser = await chromium.launch({ headless: true });
  const page = await browser.newPage();

  // Login
  await page.goto('https://portal.example-yardi.com/login');
  await page.fill('#username', process.env.PORTAL_USER);
  await page.fill('#password', process.env.PORTAL_PASS);
  await page.click('button[type="submit"]');

  // MFA: wait for OTP / TOTP. You own retrieving and entering the code
  await page.waitForSelector('#mfa-code', { timeout: 30000 });
  const code = await getOtpFromInbox();          // your integration
  await page.fill('#mfa-code', code);
  await page.click('#mfa-submit');

  // Navigate to the charges screen (selectors break on redesign)
  await page.waitForSelector('nav >> text=Charges');
  await page.click('nav >> text=Charges');
  await page.waitForSelector('#new-charge');
  await page.click('#new-charge');

  // Fill and submit the form
  await page.fill('#tenant-id', tenantId);
  await page.fill('#amount', String(amount));
  await page.click('#submit-charge');

  // Confirm. But "success" pixels look the same as "did nothing"
  await page.waitForSelector('.toast-success', { timeout: 15000 });

  await browser.close();
}

The same action through Supergood is a REST call. Auth and MFA are handled server-side; there is no browser, no selector, and nothing to maintain.

# 1. Authenticate once: Supergood handles login and MFA
curl -X POST https://api.supergood.ai/v1/{portal}/auth \
  -H "Authorization: Bearer $SUPERGOOD_KEY" \
  -d '{"account": "example-pm-portal"}'
# → { "session": "sg_sess_9f2..." }
# 2. Call the backend action directly (milliseconds, no browser)
curl -X POST https://api.supergood.ai/v1/{portal}/charges \
  -H "Authorization: Bearer $SUPERGOOD_KEY" \
  -d '{"session": "sg_sess_9f2...", "tenant_id": "t_123", "amount": 2150.00}'

For agent frameworks, the same portal ships as an MCP server (npx supergood-mcp init) and works with Claude, OpenAI, LangChain, n8n, Zapier, or any REST client. Endpoints come with auto-generated OpenAPI specs; the full reference is in the docs, and the per-portal docs show what a generated endpoint could look like; see the Yardi API page for an example.

When Playwright is the right choice

Playwright is free, open source, and excellent. Pick it without hesitation when:

• You're end-to-end testing an app you own. The whole point of E2E testing is to exercise the real rendered UI, including the frontend. That's Playwright's home turf.
• You need cross-browser QA. Chromium, Firefox, and WebKit from one API is exactly what Playwright is for.
• It's a one-off script or a prototype. If you're running something a handful of times, the browser tax doesn't matter and you shouldn't pay a vendor to avoid it.
• You're doing low-volume scraping. At small volumes, per-call cost and maintenance are noise.

Supergood is a different trade. It's a paid vendor, and standing up a new portal means a one-time walkthrough of the workflow so it can capture the underlying calls. That overhead only pays off when you're running production integrations at volume, which is exactly when Playwright's per-call cost and per-redesign maintenance stop being acceptable. Use the right layer for the job.

FAQ

Is Playwright fast enough for voice agents?

Generally no. Each portal action pays for a browser to boot, a page to render, and the DOM to settle, and an agent-driven flow adds LLM planning round-trips on top; research found 75 to 94% of total task time goes to planning and reflection (arXiv:2506.16042). For a live phone call, multi-second gaps read as a dropped connection. A network-layer call returns in milliseconds, which is what voice needs.

Does Playwright break when the site changes?

When the target site redesigns its frontend, yes: your selectors encode assumptions about markup you don't control, and new markup means new selectors and a broken run. That's inherent to automating at the rendering layer. Supergood works at the network layer, so frontend redesigns don't break anything; only a backend API change matters, and a maintenance agent handles those.

How much does Playwright cost at scale?

Playwright the library is free. The cost is running browsers: roughly $0.12 to $0.24 per hosted session at the floor, and closer to $1.00 to $1.50 for a realistic multi-step completed workflow once you count MFA, navigation, and LLM round-trips. At 1M calls/month that’s ~$150K to $1M/month in infrastructure alone, before the engineering time to maintain it. A direct network call to the same backend avoids that infrastructure entirely.

Can Playwright handle MFA and CAPTCHAs?

It can, but you build it. MFA means scripting an OTP/TOTP wait loop and wiring up code retrieval; CAPTCHAs typically mean integrating a third-party solving service. Both are yours to maintain. Supergood handles auth and MFA (a real service-account email and phone per agent) automatically.

Is Supergood a drop-in replacement for Playwright?

Only for the third-party-portal use case. If you're testing your own app's UI or doing cross-browser QA, keep Playwright: Supergood doesn't render pages and isn't trying to. If your goal is production agent access to a portal that has no public API, Supergood replaces the browser automation with a maintained REST/MCP interface.

Related reading

• Supergood vs Browser Automation: the broader API-vs-browser-automation case.
• Handling MFA in Playwright: Playwright MFA workarounds vs a durable fix.
• The True Cost of Browser Automation Past 10,000 Calls a Month: what running browsers actually costs at scale.
• Why Browser Automation Is Too Slow for Voice Agents: where Playwright's latency breaks down.

Try it

If you're running agents against portals at volume and the browser tax is showing up in your latency or your invoice, look at the network layer instead. Start with the docs, or read The Antibrowser for the argument in full. See it at supergood.ai.