Why We Stopped Writing Selectors: The Playwright-to-Agent Handoff

The Cost of Brittle Scripts

I used to think I could outsmart frontend refactors with clever XPath selectors. I was wrong. Every time a vendor updated their CSS class names, our scraper broke. We weren’t building a tool; we were accumulating technical debt. The industry has moved past brittle scripts not because of hype, but because the maintenance cost became unsustainable.

In our benchmarks, Playwright outperformed raw LLM calls for deterministic tasks, but it hit a wall when the DOM structure became unpredictable. We needed a stack that could handle exploratory reasoning without requiring us to maintain a fragile map of selectors.

This is why we split the architecture: Playwright handles the deterministic, selector-based execution, while AI agents handle the exploratory, goal-based tasks where the path is unknown. This split exists because frameworks like browser-use and LangGraph have stabilized the “tool-use loop,” allowing agents to reason about the DOM rather than just clicking elements.

Why Playwright is Still the Foundation

Despite the noise around vision-based models, Playwright remains the default foundation for our AI agents. This isn’t nostalgia; it’s engineering pragmatism. Playwright offers a unified API across Chromium, Firefox, and WebKit, providing superior stealth and detection evasion capabilities compared to Selenium or Puppeteer. For AI workloads, where reliability and speed are paramount, this consistency is non-negotiable.

Agents “see” the web differently than humans do. They rely on accessibility trees and DOM snapshots rather than visual pixels. This DOM-driven approach is significantly more cost-effective and faster than processing images. When an agent needs to fill a form or click a button, reading the underlying HTML structure is more reliable than interpreting a screenshot.

For teams integrating Playwright into AI workflows, there are three distinct integration paths to consider:

1. MCP Server: Best for prototyping. It allows agents to interact with the browser via the Model Context Protocol, making it easy to test capabilities without deep integration.
2. CLI: Best for token-efficient production. By offloading execution to a command-line interface, you reduce the context window burden on the LLM, lowering costs and latency.
3. Test Agents: Best for CI/CD maintenance. These agents can autonomously repair broken tests, keeping your regression suite healthy.

The technical advantages of Playwright are clear, but raw Playwright is verbose. This is where the agent layer begins.

Where Playwright Ends: The Agent Layer

The architecture of a modern AI agent is a separation of concerns: the LLM acts as the reasoning engine, while Playwright serves as the execution layer. The LLM decides what to do; Playwright executes how to do it.

Tools like browser-use and Stagehand abstract the complexity of selector maintenance. They remove the need for developers to write explicit selectors for exploratory tasks. Instead, the agent interprets natural language goals into multi-step browser interactions.

When should you use Stagehand? Stagehand, by Browserbase, reduces boilerplate by 60-70% compared to raw Playwright + LLM glue. It removes the need for explicit wait conditions and selector maintenance, which are the primary sources of flakiness in custom scripts. It is the preferred choice for teams wanting agent ergonomics without building custom integration layers. For TypeScript developers, Stagehand provides a clean abstraction that feels native to the ecosystem.

Conversely, when should you use raw Playwright + LLM? If you have maximum control and lowest cost as your primary drivers, and you own your infrastructure, raw Playwright is superior. It allows for fine-grained control over the browser context, which is critical for complex, multi-step workflows where you need to ensure specific state transitions. We recommend starting with CLI because MCP latency kills prototyping velocity.

The trade-off is clear: Stagehand offers speed of development and reduced boilerplate, while raw Playwright offers maximum control and cost efficiency.

Choosing the Right Stack for Your Workload

The market bifurcates into DOM-driven stacks and vision-driven stacks. Your choice depends entirely on the nature of your workload.

DOM-driven stacks, including Playwright and Stagehand, are best for 80% of workloads. They offer high reliability and cost efficiency because they interact with the underlying structure of the web. If your target application has a standard HTML DOM, use a DOM-driven stack.

Vision-driven stacks, such as Anthropic Computer Use and OpenAI CUA, are necessary only when DOM access is blocked or for canvas-based UIs. These stacks process visual pixels, allowing them to interact with applications where the DOM is obfuscated or non-existent. However, they are significantly more expensive and slower than DOM-driven approaches. Use them only when you have no other choice.

Runtime decisions are also critical. For low-volume workloads, self-hosted browsers are sufficient. However, for high-volume workloads, managed runtimes like Browserbase are recommended above 100 browser-hours per month. Managed runtimes handle infrastructure scaling, stealth management, and session persistence, allowing you to focus on the agent logic rather than browser maintenance.

The AI browser market is projected to grow from $4.5 billion in 2024 to $76.8 billion by 2034, driven by this shift toward intelligent automation. But growth doesn’t mean every tool is right for every job.

Practical Implementation Patterns

Starting with MCP for prototyping is the most efficient path. It allows you to validate the agent’s reasoning capabilities before committing to a production architecture. Once validated, move to CLI for production to manage token costs. The CLI approach minimizes the context window required for each action, keeping your LLM bills predictable.

Handling anti-bot detection is a persistent challenge. Agents must be designed to mimic human behavior, including mouse movements and typing delays. Session persistence is equally important; agents should maintain cookies and local storage across sessions to avoid re-authentication loops.

Deploying agents in Docker for scalable, headless execution is the standard for production. Docker containers provide isolation, ensuring that one agent’s failure does not impact another. They also allow for easy scaling across multiple instances to handle concurrent workloads.

For teams looking to understand the architectural shift from hardcoded selectors to tool-use loops, the research from MachineLearningMastery provides a clear breakdown of how frameworks like browser-use and LangGraph enable this transition. Similarly, ByteTunnels outlines the three official integration paths for Playwright in AI workflows, emphasizing the importance of choosing the right path for your stage of development.

Recommendation

For early-stage startups, stick to Stagehand. The speed of development outweighs the marginal cost savings of raw Playwright. For teams with complex, state-heavy workflows, stick to raw Playwright + LLM. Only move to vision-driven agents when DOM access is impossible.

Sources and further reading

• Playwright for Browser Automation in AI Agents: From Accessibility Trees to Agent Loops | ByteTunnels
• Browser Automation AI Agents: Playwright vs Stagehand | Digital Applied
• Building Browser-Using AI Agents in Python | MachineLearningMastery
• 11 Best AI Browser Agents in 2026 | Firecrawl
• AI Building Intelligent Automation with Browser Use and Playwright | Tutorials Dojo