How to Test AI Agents That Rely on Browser Memory, Autofill, and Saved Sessions

AI agents that operate in a browser often depend on more than DOM text and button clicks. They may rely on Chrome or Edge profile state, autofill suggestions, cookies, localStorage, sessionStorage, IndexedDB, and previously authenticated sessions to decide what to do next. That makes them more useful in real workflows, but it also makes them harder to test with the usual clean-room assumptions.

If you want to test AI agents with browser memory, the key question is not only whether the agent can complete a task from a blank profile. The more interesting question is whether the agent behaves correctly when the browser already knows something, when autofill changes the form value, or when a saved session means the next step should be skipped entirely.

This article is a practical guide to those state-dependent flows. It focuses on how to design tests, what state to capture, how to isolate failure modes, and how to keep enough evidence to debug problems later.

Why browser state changes the testing problem

Traditional end-to-end tests often assume that every run begins with a fresh browser context. That works for many application paths, but it misses a category of agent behavior that only appears when the browser has memory.

Common examples include:

• A login form that is bypassed because a session cookie still exists
• A shipping address field that is prefilled by autofill and changes the agent’s branching logic
• A settings page where the agent reads a prior preference from localStorage
• A workflow where a previously accepted permission prompt changes the next page
• A support chat agent that reuses conversation context from sessionStorage

From a testing perspective, these are all forms of hidden input. The page may look the same, but the browser state is part of the system under test.

A stateful browser is not just a UI container, it is part of the input surface.

That matters for agentic systems because the agent may infer intent from persisted state rather than from visible UI alone. If your test only validates the final output, you can miss the fact that the agent took the wrong branch for the wrong reason.

Separate the kinds of browser memory you are testing

Before writing tests, classify the state. Different browser stores fail in different ways and need different setup and teardown strategies.

1. Cookies

Cookies are the most obvious session mechanism. They often carry authentication, CSRF tokens, feature flags, and locale preferences. For testing, cookies are useful because they are easy to inspect and serialize.

Failure modes to watch:

• Expired or rotated session cookies
• Domain and path mismatch
• SameSite restrictions that break cross-site flows
• Secure cookies that disappear in non-HTTPS environments

2. localStorage and sessionStorage

These are common for UI preferences, onboarding state, cached agent decisions, and ephemeral flow data. localStorage survives browser restarts for the same origin, while sessionStorage usually lasts only for the tab session.

Failure modes to watch:

• Stale flags that skip onboarding incorrectly
• Cached assumptions that no longer match server data
• SessionStorage state that is lost when the browser context is recreated

3. IndexedDB and other browser-managed persistence

Some applications cache structured data in IndexedDB, especially if they support offline or heavy client-side workflows. Agents can be affected indirectly if the app reads cached data and renders a different screen.

Failure modes to watch:

• Cache entries that survive longer than expected
• Different behavior in headless versus headed runs due to storage differences
• Slow cleanup, which makes state reuse difficult across parallel tests

4. Autofill and saved form data

Autofill is not just a convenience feature, it is a behavior-changing source of truth. A browser can insert previously saved names, email addresses, payment data, or address fields before the agent takes action.

Failure modes to watch:

• The browser fills values after page load, so assertions run too early
• Autofill suggestions appear only after focus events
• A field appears empty in the DOM but contains a browser-provided value when submitted

5. Saved sessions and profiles

If you reuse a browser profile or persistent context, you are testing state across runs, not just within one flow. That can be realistic, but it also increases coupling between tests.

Failure modes to watch:

• Accidental state leakage between tests
• Profile corruption after a failed run
• State drift because one test mutates data another test assumes is stable

Decide what “correct” means for state-dependent agent behavior

For these tests, the expected result is often not a single page message. You need to define the state contract.

Useful questions:

• Should the agent detect existing authentication and skip login?
• Should it use autofill values, or overwrite them with explicit data?
• Should it preserve an existing saved address, or normalize it?
• Should it treat a stored preference as authoritative, or verify it against server state?
• Should it continue from a restored session, or force re-authentication when the session is too old?

A good test plan distinguishes between three layers:

1. Visible UI behavior
2. Persisted browser state
3. Server-side truth

If those disagree, your agent may still appear to work while being logically wrong.

Build a state matrix instead of a single happy path

A practical way to test these flows is to create a matrix of state conditions. You do not need to cover every combination, but you should cover the combinations that are likely to change the agent’s decision tree.

Example matrix for a checkout-like flow:

This style of matrix is especially useful for agent testing because the agent’s next step may depend on several sources of state at once.

Capture and restore browser state explicitly

The most reliable way to test stateful browser behavior is to treat browser state as test data. Capture it, version it when possible, and restore it deliberately.

With Playwright, you can save and reuse authentication state using a JSON file. That is useful for session state validation, but it is only one piece of the puzzle.

import { chromium, expect } from '@playwright/test';

// Save authenticated state

const browser = await chromium.launch();
const context = await browser.newContext();
const page = await context.newPage();

await page.goto(‘https://example.com/login’);

await page.fill('#email', 'user@example.com');
await page.fill('#password', 'secret');
await page.click('button[type=submit]');
await expect(page).toHaveURL(/dashboard/);

await context.storageState({ path: ‘state/auth.json’ }); await browser.close();

Restoring it:

import { test, expect } from '@playwright/test';

test.use({ storageState: ‘state/auth.json’ });

test('continues from saved session', async ({ page }) => {
  await page.goto('https://example.com/dashboard');
  await expect(page.getByText('Welcome back')).toBeVisible();
});

That handles cookies and localStorage for the origin under test. It does not automatically cover system autofill, browser profile data, or third-party persistence. Those require a broader harness strategy.

Testing autofill without making the test brittle

Browser autofill is one of the trickier parts of this problem because the browser, not your test code, is inserting the values. That means the timing and visibility of the filled values can vary.

A practical autofill test should validate three things:

1. The browser offers autofill when it should
2. The agent recognizes or safely handles the autofilled value
3. The final submission contains the expected data

Patterns that work

• Focus the field before checking for autofill suggestions
• Wait for the value to appear in the input, not just the DOM attribute
• Verify submitted network payloads when the app sends form data
• Avoid asserting on the exact suggestion text unless it is central to the behavior under test

typescript

await page.goto('https://example.com/checkout');
const address = page.locator('input[name="address"]');

await address.click();

await page.waitForTimeout(250); // small buffer for browser autofill

const value = await address.inputValue(); expect(value).toContain(‘Main Street’);

That small wait is not ideal as a generic pattern, but autofill is one of the cases where browser-driven timing can be less deterministic than app-driven events. A more robust approach is to wait for the field value to change from empty to non-empty, or to watch the network request after submission.

Avoid testing autofill by asserting that a hidden browser popup is present. That is usually too tied to a particular browser implementation.

Verify the browser state, not just the UI

A common failure mode in agent testing is to assert only that the final page looks right. That may miss the real issue, for example, an agent used a stale session cookie and skipped a necessary verification step.

For state-dependent flows, inspect the browser state directly where it matters:

• Cookies, to confirm session and preference state
• localStorage, to confirm saved settings or onboarding flags
• sessionStorage, to confirm tab-local state
• Network requests, to confirm the correct payload
• Server response, to confirm the backend accepted the state transition

Playwright exposes most of this directly.

typescript

const cookies = await context.cookies();
expect(cookies.some(c => c.name === 'session')).toBeTruthy();

const theme = await page.evaluate(() => localStorage.getItem(‘theme’)); expect(theme).toBe(‘dark’);

You should also validate what the browser sends on the wire if the browser state changes a submission.

typescript

const [request] = await Promise.all([
  page.waitForRequest('**/api/profile'),
  page.click('button[type=submit]')
]);

expect(request.postDataJSON()).toMatchObject({ email: ‘user@example.com’ });

This helps separate two questions:

• Did the agent make the right choice?
• Did the application persist the result correctly?

Test stale, missing, and conflicting state on purpose

The highest-value state tests are usually the ones that fail for realistic reasons. Instead of only testing clean success paths, create explicit negative cases.

Stale cookies

A stale cookie can reveal whether the agent correctly falls back to re-authentication.

Expected behavior might be:

• Detect the expired session
• Redirect to login
• Preserve the user’s in-progress action where possible

Missing storage

Delete localStorage or sessionStorage and see if the agent can rebuild state safely.

Expected behavior might be:

• Recreate default preferences
• Prompt the user for required information
• Avoid assuming a previously selected option exists

Conflicting state

Simulate browser state that disagrees with the server.

Example:

• localStorage says the user prefers region A
• Server profile says region B
• The agent should not silently trust the browser if the server is authoritative

Partial autofill

Many forms autofill only some fields. Test whether the agent notices the remaining blanks rather than submitting an incomplete form.

Use logs and artifacts as first-class evidence

When browser state affects behavior, screenshots alone are rarely enough. You want evidence that explains why the agent took a path.

Useful artifacts include:

• Console logs
• Network logs
• Cookie snapshots
• Storage snapshots
• Video or trace files
• Agent reasoning output, if your platform captures it

A trace is especially useful because it can show the browser state at each step. In Playwright, trace viewer data often makes it easier to inspect timing, navigation, and DOM snapshots.

If you use an agentic testing platform, prefer one that preserves evidence around the state transition, not just the final assertion. For example, Endtest, an agentic AI test automation platform,’s AI Assertions can validate conditions in cookies, variables, or logs in addition to the page itself, which is useful when the test outcome depends on browser state rather than only visible text. For teams that want to author stateful flows in a more guided way, its AI Test Creation Agent is designed to generate editable, platform-native steps from natural language.

That kind of evidence model matters because browser-state bugs are often about causality, not just presentation.

A practical test harness pattern

One maintainable pattern is to build a small state factory for your tests. It creates named browser states and makes them easy to reuse.

Examples of state fixtures:

• anonymous-clean
• authenticated-fresh
• authenticated-expired
• autofill-enabled
• autofill-partial
• saved-address-present
• saved-address-conflicts-with-server

Then each test declares which state it wants.

test.describe('session-aware agent flows', () => {
  test('skips login when a valid session exists', async ({ page }) => {
    await page.goto('https://example.com/account');
    await expect(page.getByText('Account settings')).toBeVisible();
  });

test(‘re-authenticates when the saved session is expired’, async ({ page }) => { await page.goto(‘https://example.com/account’); await expect(page.getByRole(‘heading’, { name: /sign in/i })).toBeVisible(); }); });

This is simpler than encoding state setup inside every test body, and it makes failures easier to interpret. When a test fails, the state label tells you what assumptions were in force.

Parallel runs make state bugs easier to create

Browser-state tests are especially sensitive to parallel execution. If two tests share a profile, one can accidentally mutate the other’s state. If a CI worker reuses cached browser data, state leakage can become intermittent.

To reduce this risk:

• Use isolated contexts per test
• Avoid reusing profile directories unless the test explicitly needs persisted browser memory
• Clean up storage between runs
• Keep seeded accounts and test users separate from human accounts
• Make state setup deterministic and repeatable

This is one reason many teams prefer ephemeral browser contexts for most tests, and persistent profiles only for a small subset of flows that truly require them.

What to assert in agentic flows

For AI agents, an assertion should usually cover behavior, not just surface output.

Good assertions include:

• The agent used the correct saved session or detected it was invalid
• The agent accepted autofill when appropriate, or replaced it when policy required it
• The agent did not resubmit stale browser state after navigation
• The agent restored a previous draft when the workflow expected recovery behavior
• The final server-side state matches the user’s intended action

Bad assertions usually focus on brittle text fragments or exact DOM layouts that do not encode the state logic you care about.

If you need assertions that reason over different kinds of evidence, agentic platforms can help when they keep the assertion close to the state. Endtest’s AI Assertions documentation describes natural-language checks over page content, cookies, variables, and logs, which is a reasonable fit for these workflows when you want to avoid building a custom assertion library for every browser state path.

Common failure modes and how to debug them

The agent passed locally but failed in CI

Possible causes:

• No browser profile data in CI
• Different browser autofill behavior
• Headless mode changes timing or storage behavior
• Session cookies expired between runs

Debug by comparing the exact browser context data between environments.

The form submitted the wrong data

Possible causes:

• Autofill injected a value after the agent read the field
• The agent read value too early
• The app stored a default in localStorage and overwrote manual input

Debug by logging field values immediately before submission and by checking network payloads.

The agent skipped a required step

Possible causes:

• Session cookies made the agent think it was already authenticated
• A persistent flag suppressed onboarding
• A browser extension or profile artifact changed the page state

Debug by starting from a fresh context and then reintroducing one state variable at a time.

The test is flaky only on one browser

Possible causes:

• Autofill implementation differs across Chromium, Edge, and Firefox
• Storage quota or sync behavior differs
• Saved profile format is browser-specific

Debug by narrowing the test to the browser that actually supplies the state, and keep cross-browser coverage separate from state-reuse coverage.

A decision rule for teams

If your agent depends on browser memory, ask whether the state is part of the product contract or merely a convenience.

Use persistent browser state in tests when:

• The product intentionally supports returning users
• The agent should continue from saved context
• Autofill materially changes the next step
• Session persistence is a required feature

Prefer a clean browser context when:

• You are testing core navigation and page correctness
• State is not supposed to affect the result
• You want maximum isolation and repeatability
• You are debugging a failure that could be caused by state leakage

The most stable test suite usually includes both. Clean runs prove the baseline, stateful runs prove the browser-memory behavior.

Where agentic testing platforms fit

Custom Playwright or Selenium harnesses are still a good choice when your team needs full control over cookies, storage, profile directories, and low-level debugging. They are explicit and portable, and they let you model unusual browser-state combinations precisely.

Agentic testing platforms become attractive when you want to preserve that stateful evidence without building all the scaffolding yourself. The practical advantage is not magic, it is maintainability: editable steps, state-aware assertions, and a workflow that makes the browser context visible to the team. In state-heavy testing, that can be the difference between a test that is understandable and one that becomes a pile of ad hoc helper code.

Final checklist

Before you ship browser-state-dependent agent tests, confirm that you can answer these questions:

• What state is required for the flow to begin?
• Which state is expected to persist across runs?
• What state should be ignored if it conflicts with the server?
• How do you capture and restore cookies, storage, and session data?
• How do you prove autofill influenced the outcome?
• What evidence do you keep when the test fails?
• Can another engineer reproduce the same state locally?

If you can answer those questions, you are no longer just testing clicks and text. You are testing the actual decision surface of the agent.

That is the right level of rigor for browser-memory workflows, because the next step is often determined by invisible context, not by the page alone.

Further reading

• Software testing
• Test automation
• Continuous integration
• Playwright storage state documentation