Web browser automation that reads your own browser before it drives anyone else's

An identity layer. Before the agent drives a single tab, Fazm runs a local Swift extractor (ai-browser-profile-swift-light, v0.1.0, declared at Desktop/Package.swift line 18) that reads your Chrome's autofill, saved logins, history, and bookmarks out of the browser's SQLite files, builds a structured profile of you, and writes it to ~/ai-browser-profile/memories.db. That profile is then addressable at runtime via a tool called query_browser_profile. When the agent hits a signup form, a checkout, or a support request, it pulls your real email, real phone, real address, real card, and real saved accounts from that database instead of hallucinating placeholders. Selenium has no concept of you. Playwright has no concept of you. Both drive a fresh browser with a blank profile, and you are the one who has to hand-feed them every value.

On your Mac, at ~/ai-browser-profile/memories.db. It is a local SQLite file. The extraction takes 1 to 2 seconds and is re-run automatically whenever the agent's query hits a profile that is missing, stale (older than 24 hours), or incomplete. The schema has nine tag filters that the agent can narrow by: identity, contact_info, account, tool, address, payment, contact, work, and knowledge. You can list the raw tags in the MCP tool registry at acp-bridge/src/fazm-tools-stdio.ts line 369. Nothing in that database ever leaves the machine. There is no cloud sync. There is no telemetry for the contents.

Because most real automations involve typing information the agent does not start with. 'Sign me up for this newsletter' needs your email. 'Book the meeting room' needs your calendar identity. 'Request a refund' needs your order ID and your address. 'Apply to this job posting' needs your phone, resume URL, and work history. A driving-only tool either has to ask you for each one (destroying the whole value proposition), or it has to invent plausible-looking fake values and send them (destroying trust). Fazm does neither; it pulls the value you have already saved into Chrome and uses that.

Partially. If Chrome has zero autofill records, zero saved logins, and an empty history, query_browser_profile returns nothing meaningful and the agent will have to ask you. The realistic case is different: anyone who has used Chrome as their primary browser for a few months has a rich autofill set by accident, because Chrome's Payment Autofill, Address Autofill, and Password Manager are on by default. The extractor reads what is already there. There is no 'fill in this wizard' step. If you want to override or remove a specific entry after the fact, the agent can call edit_browser_profile (fazm-tools-stdio.ts line 350) with action: delete or action: update.

Two things. First, the extractor runs entirely locally. It links into your Fazm.app process as a Swift package dependency (ai-browser-profile-swift-light on GitHub at m13v/ai-browser-profile-swift-light, pulled from your Package.swift); there is no server involved. Second, it reads what the OS will give it using standard Chrome storage locations. Encrypted login credentials that require Chrome's own key to decrypt are not decrypted; only the metadata and the fields Chrome stores in the clear (autofill entries, history, bookmarks, non-password credentials) are surfaced. The profile database never contains a password. You can confirm this by opening ~/ai-browser-profile/memories.db in any SQLite browser and grepping for 'password'.

The local agent, automatically, whenever the task requires personal context. The bundled skill file at Desktop/Sources/BundledSkills/ai-browser-profile.skill.md tells the model exactly which phrases trigger a query: 'what's my email', 'what accounts do I have', 'what tools do I use', 'find contact X', 'what's my home address', 'what card do I use'. The model is also free to call it unprompted when it notices the page it has just snapshotted contains a form with a 'Phone number' field, an 'Email' field, or a 'Shipping address' block. The first time any query returns empty, the agent silently runs extract_browser_profile to refill the database, then retries.

Chrome stores profile-scale structured data (autofill, history, logins, top sites) in per-profile SQLite files, not LocalStorage. LocalStorage is per-origin key-value, which is useless for 'what is my phone number'. The extractor reads those real SQLite files, joins across them, normalizes the values (so 'mdiakonov@gmail.com' and 'm.diakonov@gmail.com' do not both show up as separate primary emails), scores them by frequency, and writes a consolidated record keyed on semantic role. Addressable by a tag like payment or address, not by 'row 4124 of cookies.db'. That normalization is why query_browser_profile returns a useful answer instead of raw dumps.

Next to it, and it calls it. Fazm's runtime registers both as peer MCP servers in the same Agent Control Protocol bridge. query_browser_profile is one of the fazm_tools MCP tools (acp-bridge/src/fazm-tools-stdio.ts, alongside ten other helper tools). The browser automation leg is Playwright, attached to your real Chrome via a Chrome Web Store extension (ID mmlmfjhmonkocbjadbfplnigmagldckm, see Desktop/Sources/BrowserExtensionSetup.swift line 220). The agent first calls query_browser_profile to get the values it needs, then calls browser_snapshot to see the form, then calls browser_fill_form with the ref of each field and the value from the profile. One agent, two MCP servers, one continuous tool call chain.

The extractor is Chrome-first because Chrome has the most consistent SQLite schema across versions, and because the majority of Fazm users run Chrome. Brave and Edge use a Chromium profile layout that works in practice but has not been formally tested. Arc is a special case because it uses its own profile directory and sidebar UI; the extractor can still find the SQLite, but field coverage is lower. Safari is not currently supported (it uses a different storage engine under a stricter sandbox). If you want to see what was actually extracted, the profile markdown is surfaced inside Fazm's onboarding chat view (Desktop/Sources/OnboardingChatView.swift line 1390 is where extract_browser_profile is wired into the onboarding flow).

The SERP definition is 'a library or service that drives a browser through scripts or an API.' That framing puts the automation author on one side and the browser on the other, with a forever-empty identity slot in the middle that the author has to fill by hand in every test case. Fazm's definition is: the browser is already where you live, most of your identity is already in it, the agent reads that first, then drives it. The web browser becomes a source of truth for 'who the user is,' not just a dumb surface the automation pokes at. That is why reading the profile changes the shape of every subsequent tool call, not just one.