Getting Started with site-memory: Stop Making Browser Agents Learn the Same Website from Scratch

The expensive part of browser agents is often not opening a page. It is making the agent rediscover the same page every time: inspect the layout, guess what a button means, try a filter, open the wrong modal, recover, and then finally perform the task. If the same dashboard, reporting page, checkout flow, or internal admin screen was already explored yesterday, repeating that exploration in a new session is wasteful.

site-memory focuses on that narrow but important gap. It is not a new browser automation framework and it is not a universal long-term memory system. It is a small memory loop for websites: remember how a site is organized, which selectors are stable, where common traps are, and which actions require human confirmation. The next time an agent visits the same site, it can recall a few relevant notes, verify them against the live page, and avoid repeating old mistakes.

This looks modest, but it matters. Browser agents become useful over time only if exploration can turn into an asset. Without that layer, every session is a new employee starting from zero. With it, at least the old paths do not need to be rediscovered every day.

What site-memory actually solves

site-memory solves repeated website exploration cost. It does not try to remember everything.

The working loop is straightforward:

before a task starts, generate a memory query from the current goal and site;
retrieve a small number of relevant notes from previous visits;
let the browser agent use those notes while still checking the live page;
after the task ends, write back reusable findings from the session.

This is different from ordinary chat memory. General memory might store user preferences, project background, or long-term facts. site-memory is closer to a field notebook for browser agents. It stores practical observations such as “the export button is under Reports → More,” “the date picker only applies after clicking Apply,” “the second Search button belongs to the advanced filter,” or “never click Delete without asking for confirmation.”

The project’s own positioning is direct: browser automation agents repeatedly explore the structure of the same websites, and site-memory helps them remember visited sites so they can move toward the goal faster next time. The README reports WebVoyager benchmark results with 70% to 90% cost reduction, more than 4x speed improvement, and no accuracy loss. Those numbers should not be treated as a universal promise for every workflow, but the direction is the important part. Page structure, navigation paths, and failure notes should become reusable assets instead of being re-inferred from scratch.

Where it is useful

site-memory is most useful when the website is relatively stable and the task repeats.

exporting a weekly report from the same SaaS dashboard;
filtering and extracting data from the same recruiting, real-estate, course, or ecommerce sites;
checking orders, invoices, tickets, or account state in an internal admin system;
running repeated UI acceptance paths in a staging environment;
keeping a browser agent on long-term duty so it becomes more familiar with the tools it uses.

It is not a good fit for every case:

one-off pages you are unlikely to revisit;
sites where routes, labels, and controls change constantly;
workflows that require storing cookies, tokens, personal data, or customer secrets in memory notes;
attempts to bypass CAPTCHAs, fraud controls, paywalls, or required human review.

In short, site-memory stores the route map, not the keys. A route map can help an agent avoid wrong turns. Credentials, sessions, and authority still need to be handled through proper security boundaries.

Check three things before installing

The project is lightweight, but it depends on the surrounding agent runtime. Before relying on it, confirm three things.

First, check Node.js. The project requires Node.js 22 or newer. Using the expected runtime avoids subtle installation and execution issues.

Second, make sure your agent environment can load skills. The README mentions tools such as Claude Code, Codex, OpenClaw, and Gemini CLI. Depending on the runtime, an agent may be able to install the skill itself, or you may need to copy skills/site-memory/ into the appropriate skills directory manually.

Third, confirm that you already have a browser control layer. site-memory does not click pages by itself. It provides the memory cycle. Actual browser work can be handled by its Chrome DevTools Protocol skill or by another browser automation stack that your agent can use.

A sensible first workflow

Do not begin with a sensitive production admin panel. Start with a harmless site or an internal staging page where repeated navigation is useful and mistakes are cheap.

Choose a repeatable task, such as opening a report page and applying a filter.
Run the browser agent without existing notes and let it complete the task.
At the end of the session, save only reusable observations: stable navigation, selectors, gotchas, and confirmation rules.
Run the same task again in a fresh session.
Compare the number of steps, tool calls, corrections, and wrong turns.

The improvement should feel practical rather than magical. The agent should not claim it already knows the page forever. It should recall a small set of likely-useful notes, verify the current DOM, and adjust if the site changed.

What good website memories look like

Good site memories are short, specific, and safe. They should describe navigation behavior, not store private data.

TEXT

On example-dashboard.test, the CSV export is under Reports → Usage → Export.
The date range control does not apply until the blue Apply button is clicked.
The table uses server-side pagination; changing filters resets to page 1.
Do not click the red Archive button without explicit user confirmation.

Bad memories are vague or dangerous. “This site is confusing” is not actionable. “User token is...” is a security problem. “Always click confirm” is unsafe. The memory should help the agent navigate, not bypass judgment.

Security and privacy boundaries

Because browser automation often touches authenticated sites, memory hygiene is essential. Keep credentials out of notes. Keep customer data out of notes. Avoid saving personal information, private URLs, session identifiers, or one-time states. If the agent learns something that is only true for the current account or current day, either do not store it or label it carefully.

Human confirmation should be remembered as a rule, not removed as an obstacle. Destructive actions, purchases, account changes, messages, and submissions should still require explicit approval. A memory that says “the delete button is in the row actions menu” is useful. A memory that says “go ahead and delete rows automatically” is not.

How to judge whether it is working

The value of site-memory should show up in operations, not vibes. Track a few simple signals:

fewer repeated page-inspection steps on the same site;
fewer wrong clicks and modal recoveries;
lower token and tool-call usage for repeated tasks;
faster completion while maintaining the same accuracy;
memory notes that remain readable and easy to delete or correct.

If the notes become long, stale, or full of sensitive details, the system is drifting. The best site memories are small enough for an agent to read quickly and precise enough to verify against the live page.

The larger lesson

site-memory is a small tool with a larger message: agent learning does not always require a giant personal memory database. Sometimes the right memory is narrow, local, and task-shaped. For browser agents, remembering the shape of a website can be enough to turn repeated work from exploratory wandering into a familiar route.

That is the difference between an agent that is merely capable of using a browser and one that gradually becomes competent on the sites you actually use. It still needs supervision, live verification, and safe permissions. But it no longer has to learn the same doorway twice.