Looking for Guidance: Improving Playwright MCP Runbook Replay Reliability

Hi everyone,

We are building an AI-powered browser automation agent using Playwright MCP, and we have implemented a runbook/replay mechanism to reduce repeated reasoning and improve navigation performance.

Current Architecture

Our setup currently looks like this:

• AI Agent (Client) – Hosted on Azure Container Apps
• Playwright MCP Server – Hosted on Azure Container Apps
• Chrome Extension – Running in the user's browser

The Chrome Extension maintains a webhook connection with the Playwright MCP relay/server.

The MCP server generates Chrome DevTools Protocol (CDP) commands, which are executed by the Chrome Extension in the user's browser.

Runbook Functionality

When the agent needs to navigate to a particular page, it normally performs multiple browser actions such as:

• browser_navigate
• browser_snapshot
• browser_click
• browser_type
• Other Playwright MCP tools

During the first successful execution, we record the tool calls and their parameters used by the agent to reach the desired page. We store these actions as a runbook.

For subsequent requests requiring navigation to the same destination, instead of asking the AI agent to reason through the navigation steps again, we directly replay the stored runbook.

First execution

User Request ↓ Agent Reasoning ↓ MCP Tools ↓ Browser ↓ Desired Page

Example recorded sequence:

browser_navigate → browser_snapshot → browser_click → browser_snapshot → browser_type ...

Subsequent execution

User Request ↓ Runbook Replay ↓ MCP Tools ↓ Browser ↓ Desired Page

This significantly reduces latency, token usage, and unnecessary LLM reasoning.

Example Runbook Step

{ "tool": "browser_click", "args": { "target": "e140", "element": "Earn credentials link" }, "a11y": { "role": "link", "name": "Earn credentials", "index": 0, "text": "Earn credentials", "textIndex": 0, "path": "generic/list/listitem/article/generic/generic", "url": "https://learn.microsoft.com/en-us/" }, "pageUrl": "https://learn.microsoft.com/en-us/", "timestamp": "2026-07-30T10:24:04.374Z" }

For each recorded action, we persist information such as:

• MCP tool name
• Tool parameters
• Snapshot reference
• Accessibility role
• Accessibility name
• Element text
• Element index
• Text index
• Accessibility-tree path
• Page URL
• Other relevant metadata

The Problem

The main challenge is runbook replay reliability.

A runbook contains references obtained from a previous browser_snapshot. During replay, the page may have:

• Slightly different DOM structure
• Timing differences
• Dynamic content
• Accessibility-tree changes

As a result, a previously recorded snapshot reference may no longer match the current page.

For example, a recorded action may effectively be:

browser_click(ref="some_snapshot_ref")

During replay, that reference may no longer exist or may resolve to a different element because the current snapshot has changed.

This causes intermittent failures in operations such as:

• browser_click
• browser_type
• Other element interactions

Current Status

We have improved the replay mechanism and currently achieve approximately 90% replay success.

The remaining ~10% failures are difficult because they are often nondeterministic. The same runbook can succeed or fail depending on the current browser or page state.

Questions

We would appreciate advice from anyone with experience using Playwright MCP or building production browser automation systems.

1. What is the recommended way to make Playwright MCP tool calls more resilient to changes in snapshot or accessibility-tree references?
2. Is relying on snapshot ref values fundamentally unreliable for replay? Should we instead store a different representation of the target element?
3. If so, what additional information would you recommend storing for each interaction?
4. What is the best strategy for re-resolving an element when the original snapshot reference is no longer valid instead of failing the entire runbook?
5. Are there Playwright MCP capabilities or recommended patterns that specifically address dynamic pages and changing accessibility trees?
6. For a production-grade browser automation agent, what architecture or strategy would you recommend to achieve >99% replay reliability?

Our goal is not to eliminate dynamic behavior from websites, but to make the runbook intelligent enough to recover when previously recorded element references become invalid.

Any architectural recommendations, implementation patterns, or examples from production systems would be greatly appreciated.

Thank you!