Decision Framework: When to Use What (July 2026)

Updated Aug 2026

Quick Decision Tree

Do you need browser automation?
├── No → Use standard tools (curl, API clients)
└── Yes
    ├── Is an AI agent driving it?
    │   ├── No → Use Playwright or Selenium directly
    │   └── Yes
    │       ├── Does the agent have filesystem access?
    │       │   ├── Yes → Playwright CLI + skill (default: ~4x cheaper than MCP)
    │       │   └── No (sandboxed) → Playwright MCP
    │       ├── Building agent features into a product (TypeScript)?
    │       │   └── Stagehand (intent API, hosted browsers)
    │       ├── Python-first team or research work?
    │       │   └── browser-use
    │       └── Want the full plan → generate → heal workflow?
    │           └── Playwright Test Agents (npx playwright init-agents)
    └── What type of testing?
        ├── Functional → Playwright CLI skill + test agents
        ├── Accessibility → Playwright MCP or CLI snapshots (a11y summaries)
        ├── Visual regression → screenshots on disk + comparison tooling
        ├── Exploratory → planner agent, or MCP for interactive sessions
        ├── Performance → Traditional tools (k6, Lighthouse)
        └── API → No browser needed (curl, httpie)

Scenario-Based Recommendations

Scenario 1: New Startup, Building From Scratch

Context: Small team, modern SPA, CI/CD via GitHub Actions, a coding agent (Claude Code, Cursor) already in the workflow.

Recommendation: Playwright CLI + skills, with Test Agents for generation

Why:

• One install (playwright-cli install --skills), zero framework code to start
• The same agent that writes your application code drives your tests — shared context, and the CLI path keeps that context affordable
• init-agents scaffolds planner/generator/healer for your agent runtime
• Grows naturally into a reviewed specs/ + tests/ structure

Scenario 2: Enterprise with Existing Selenium Suite

Context: Large team, legacy application, 2000+ existing Selenium tests, migrating to AI-assisted QA.

Recommendation: Selenium 4.x (existing) + Playwright CLI skill (new tests)

Why:

• Don't rewrite 2000 tests — maintain the existing Selenium suite
• New tests go agent-driven on the Playwright stack
• Both worlds converge on WebDriver BiDi over time (low-level in Selenium 4 today, high-level in the eventual Selenium 5)
• Gradual migration as old tests naturally need updates

Scenario 3: Accessibility-First Product

Context: Government or healthcare app with WCAG compliance requirements.

Recommendation: Playwright (CLI or MCP — both expose accessibility structure) + dedicated a11y tooling

Why:

• The YAML snapshots are accessibility-tree summaries — roles and accessible names are the primary addressing scheme, so a11y problems surface constantly during normal test runs
• For deep WCAG audits, the agent analyzes ARIA roles, labels, and structure semantically; pair with axe-style rule engines for the mechanical checks
• Traces give you the audit evidence trail compliance teams ask for

Scenario 4: Complex B2B Dashboard

Context: Data-heavy application with charts, tables, drag-and-drop, custom components.

Recommendation: Playwright CLI (standard flows) + Stagehand or browser-use (the gnarly parts)

Why:

• Standard flows (login, navigation, CRUD) run cheap on the CLI path
• Custom canvas/chart components may defeat structural snapshots — intent APIs (Stagehand) or vision (browser-use) earn their extra cost exactly here
• Higher per-interaction cost is justified for the 10% of UI that's genuinely hard

Scenario 5: CI-Only Test Runner (No Human Involvement)

Context: Fully automated pipeline, tests run on every push, no human reviews failures in real-time.

Recommendation: Playwright CLI skill, fresh sessions, healer as follow-up job

Why:

• Lowest token cost per run of the agent-driven options
• Failure artifacts (screenshots, snapshots, traces with network capture) collected automatically
• The healer agent triages failures: patch proposals arrive as PRs; "app actually broken" verdicts page a human
• JUnit XML for CI dashboard integration

Cost Reasoning at Scale

Absolute per-test costs depend on your model, provider, and page complexity — any table of dollar figures you read (including in this guide's earlier editions) goes stale in months. The durable reasoning:

• The ratio is what matters: Microsoft benchmarks the CLI path at 4x fewer tokens than MCP for a typical task (27k vs ~114k), trending toward 10x on long sessions. Whatever your per-token price, that ratio compounds across every test, every run, every day.
• Token spend is a first-class metric: track cost per test and per suite alongside pass rate. A cost spike usually means an agent is stuck in a rediscovery loop — it's a quality signal, not just a budget one.
• Vision-based approaches cost per look: tools that screenshot-and-reason on every interaction multiply model calls. Reserve them for UI that structural approaches can't handle.
• The build-vs-buy line: commercial agentic platforms (testRigor, mabl, KaneAI, Applitools, Testim, Functionize) bundle the token costs into their subscription. If your team lacks agent-infrastructure appetite, their pricing can beat DIY — do the math on your actual run volume.

Migration Paths

From Selenium to AI-Assisted

Phase 1: Add Playwright CLI + skill alongside Selenium
Phase 2: New tests go agent-driven (specs/ + generator)
Phase 3: Convert high-maintenance Selenium tests as they break
Phase 4: Decommission old tests as they're replaced

From Playwright (traditional) to AI-Assisted

Phase 1: npx playwright init-agents — scaffold for your agent runtime
Phase 2: Planner drafts specs for existing critical journeys
Phase 3: Generator produces agent-maintained tests; healer handles CI failures
Phase 4: Humans review plans and healer patches, not selectors

From Manual QA to AI-Assisted

Phase 1: QA writes test plans in Markdown (natural language, specs/)
Phase 2: Generator turns plans into executable tests
Phase 3: Planner proposes new scenarios from app exploration
Phase 4: Continuous agent-driven QA with human review gates

Risk Assessment

A January 2026 lesson worth internalizing: Octomind — a credible, recommended tool six months ago — is winding down. In this space, tool-discontinuation risk is not hypothetical; architect so that your test plans (Markdown, portable) outlive any particular execution tool.

The Bottom Line

For your interview, the recommended stack as of July 2026 is:

Primary: Playwright CLI + skill for all agent-driven test execution, Test Agents (planner/generator/healer) for the workflow Secondary: Playwright MCP where sandboxing demands it; Stagehand or browser-use for UI that defeats structural approaches Framework: Markdown plans in specs/ + generated tests + GitHub Actions CI + archived traces

This gives you:

• Cost efficiency for daily CI runs (~4x vs MCP, vendor-benchmarked)
• A reviewed, human-readable source of truth (plans, not selectors)
• Self-healing with honesty (healer can rule "app is broken")
• An audit trail (traces with network capture)
• Portability — plans and skills outlive any single tool