Test both sides of your customer journey before trusting automation

On October 31, 2026, Microsoft released version 0.0.84 of Playwright MCP, a server that lets an AI assistant drive a web browser through the Model Context Protocol. The new option: when the browser_tabs tool opens a tab, it can give it a named isolatedContext. Tabs with the same name share cookies and storage. Tabs with different names stay separate. Leaving the name out, or using “default”, keeps the default context. Playwright MCP v0.0.84 release notes (opens in a new tab)

Playwright MCP mainly works from structured accessibility snapshots, a text description of the page’s elements, rather than relying on screenshots. It is developer tooling: someone has to add it to an MCP-compatible client’s configuration before any of this is usable. Playwright MCP documentation (opens in a new tab)

Most journeys have two sides

An organizer publishes an event and an attendee registers. An admin changes a setting and a customer sees the result. Testing one side at a time hides the problems that appear where the two meet. Separate named sessions make it practical to keep an “organizer” and an “attendee” signed in side by side, without one login replacing the other.

Useful pairs to test together include organizer and attendee for events, admin and customer for account settings, and manager and team member for approvals. Each pair has a handoff point, and that handoff is where to look hardest.

What separate sessions do not prove

Session separation is about cookies and storage inside the test browser. It is not your app’s authorization, and it is not a security sandbox. If the attendee session cannot open an admin page, that is evidence about your app’s permission checks for that one case, not a feature of the test tool. Your app still has to enforce roles on the server.

A suggested two-sided test plan

These are proposals for a pilot, not proven coverage:

• Use safe test data: dedicated test accounts, clearly marked sample registrations, and an environment where nothing reaches real customers or sends real messages.
• Check the saved outcome: after the attendee registers, confirm the record exists with the right details and that the organizer’s view shows it. A success message alone is not proof.
• Check roles in both directions: the organizer can do organizer tasks, and the attendee cannot. Try an admin address from the customer session and confirm it is refused.
• Check sign-out: sign one user out and confirm the other stays signed in. If you test the same account in two sessions, decide first whether your app is meant to sign that account out everywhere. That is a product decision about server sessions, separate from the browser state the tool keeps apart.
• Check duplicates and retries: submit the same registration twice, or retry after a slow response, and confirm you end up with one record and a clear message.

Write the expected result for each step before the run. Then let the assistant carry out the steps and report what it observed, and have a person review that evidence before anything counts as a pass.

Go deeper

For choosing a workflow, what to measure and how to run a repeatable pilot, see our earlier guide to testing computer-use AI agents.Read: what businesses should test before adopting computer-use agents

If you would like help planning tests like these for your own customer journeys, take a look at Build With AI.Explore Build With AI