unbrowseIn Part I, I argued that the way past the login screen is the one client sites already trust as you: your own browser. As of 12 October 2026, that reach-back is built and in testing but not yet switched on in production. This part is about the next problem, and it is further out. As of the same date, browser memory as described below is not built. It is the plan, written down so you can hold us to it.
Imagine the agent gets in. Now give it a harder job.
"Find last month's invoice from our supplier and pay the balance."
It gets in. Then it stops.
Which supplier portal? Which page? Which of the forty tabs you had open that Tuesday?
You'd know. You saw it.
Getting in was half the problem
Remembering is the other half.
Your browser has seen everything you've done on the web. And it remembers almost none of it.
History keeps a list of URLs. The cache keeps some pixels. The calls that actually built each page vanish the moment you close the tab.
Your browser already did the work
Every time you check an order, approve an expense, or track a shipment, your browser calls the site's own API.
Those calls are the map. Which endpoint lists your orders. Which one returns the invoice. Which ID from one call opens the next.
That's exactly the map an agent needs.
Today it has to rebuild that map from scratch. Unbrowse learns a site by doing the task in its own cloud browser, watching the site's first-party requests and compiling them into a route it can replay. That works, and it's live. But it means the first visit happens from a browser the site has never met, and on some sites that visit gets stopped at a bot check before anything is learned.
The plan: your browser remembers
Here is what we want to build.
You browse the way you always do. Unbrowse keeps the map.
Not the pages. The shape underneath them. This site has an orders endpoint. It takes a date range. It returns invoices. The invoice ID opens the payment page.
Site by site, a graph of the APIs you actually use.
With that graph, the agent's learning step mostly disappears for the sites you already use. You taught it by using the web. The agent starts from a map instead of a blank page, and only goes back to a browser when the map is missing or stale.
The other half of memory is context
The map tells an agent what a site can do. Context tells it what you were doing.
The tabs you had open. The pages you read. The form you were halfway through when the meeting started.
The plan is to record that too, so you can ask:
"What was I doing on the supplier portal on Tuesday?"
and the agent can answer from what your browser saw, as you, instead of guessing.
Pointers, not copies
The design choice we care most about is what the memory actually holds.
Unbrowse's MCP connection already carries a memory graph built on pointers: a node for a site, a learned API or a request, plus the notes you or your agent attach to it. Browser memory is meant to extend that shape rather than invent a new store. The graph would hold pointers and your annotations; the content behind a pointer would live in a sealed store or in your own browser, and resolve only for you.
That shape has a useful property. Forgetting becomes real. If the record behind a pointer is deleted or expires, the pointer stops resolving, while your own note on it can stay. And a graph of pointers is much easier to show you, page by page, than a pile of copied traffic.
It should travel with you
Close your laptop, and the agent should keep working. Open a new laptop, and your last month should already be there.
The plan is to sync your sessions, history and recent work to your Unbrowse workspace, as something you turn on, with memory kept for 30 days. That's a different trust deal from Part I, where a request never leaves your browser, and we'll say exactly what the copy contains before anyone turns it on.
It also won't do everything. Some sessions are tied to the device that signed in. Google and some banks, including the one I use, bind a login to the machine; a copy of the profile on another machine isn't expected to work there. For those sites, the agent goes through your own browser or not at all.
The rules we've set before writing the code
We've written the acceptance tests before the feature, so the controls can't be bolted on later. Nothing below exists yet; these are the conditions it has to pass before it ships:
- You choose site by site what it remembers. Banks, email and health sites start off.
- Passwords and card numbers you type never land in a recording.
- You can pause it, see the whole timeline, and forget a site, a day, or everything.
- Memory older than 30 days is gone.
- A company can keep memory off for its whole domain until an admin turns it on.
- You can export what it holds about you.
If any of those fail, it doesn't ship. That's the deal.
Why build it at all
Because the bottleneck moves. Once agents can get in, the next thing that stops them is not knowing where anything is. Today the answer is to send the agent exploring, slowly, from a server the site doesn't trust. The better answer is the browser that was already there, which saw the requests, in the order you made them, signed in as you.
The live part of Unbrowse today is the learn-once, replay-forever loop: one MCP server at unbrowse.ai/mcp that learns a site's own requests, verifies them, and shares read-only routes that carry no secrets. The background is in our April 2026 paper, and the docs show how to connect.
Imagine ASI. Again.
It can get in. Then it knows where everything is, and what you were in the middle of.
Not because it guessed. Because your browser was there.
That's the next part we're building.