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.

If 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 — the honest answer is that you're 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 — genuinely 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/MFA/CAPTCHA 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) is blunt about 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–2.7x more steps than needed; 75–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 at 2 a.m.

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–85% on simple UI interactions but only 9–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 precisely 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. The margin math is simple: an integration you maintain by hand is a headcount line item; one that's maintained for you isn't. 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–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–1.50 per completed call. A network call to the same backend skips all of that overhead. For a typical customer running ~1M calls/month, 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 honest planning number. 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, MFA, and CAPTCHAs are handled server-side; there is no browser, no selector, and nothing to maintain.

# 1. Authenticate once — Supergood handles login, MFA, and CAPTCHAs
curl -X POST https://api.supergood.ai/v1/yardi/auth \
  -H "Authorization: Bearer $SUPERGOOD_KEY" \
  -d '{"account": "acme-co"}'
# → { "session": "sg_sess_9f2..." }
# 2. Call the backend action directly (milliseconds, no browser)
curl -X POST https://api.supergood.ai/v1/yardi/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 shape (Yardi, in this example) is documented at the Yardi API.

When Playwright is the right choice

Playwright is free, open source, and genuinely 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 precisely the case where 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–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–0.24 per hosted session at the floor, and closer to $1–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–$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, MFA (a real service-account email and phone per agent), and CAPTCHAs 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.