Axiom records you filling the form once. Fazm reads the four SQLite files your browser already has and fills any new form on any site on day one.

If the job you hired Axiom for was 'fill in this form on this site every time a new row lands in a sheet,' then yes, Fazm replaces that workflow without the record-and-replay step. If the job was 'export this table to CSV every morning,' Fazm does that too. Fazm is a Mac desktop agent that drives your real browser and your Mac apps in the same sentence. What makes the comparison interesting is that Fazm starts with a profile of who you are, pulled from the browser you already use, so the agent can type real values into any form, not just forms it has seen before.

Four paths: ~/Library/Application Support/Arc/User Data, ~/Library/Application Support/Google/Chrome, ~/Library/Application Support/BraveSoftware/Brave-Browser, and ~/Library/Application Support/Microsoft Edge. For each path, Fazm iterates every Chromium profile inside, and for each profile opens four files: Web Data (autofill addresses, form field history, credit cards), Login Data (origin_url and username_value; passwords are skipped), History (top-visited hosts), and Bookmarks (JSON). The code is ai-browser-profile-swift-light/Sources/AutofillExtractor/Constants.swift lines 95-104 for the browser paths and AutofillExtractor.swift for the extraction loop.

It copies the file to a temp path before opening. AutofillExtractor.swift line 53-54 shows the pattern: copyToTemp(webDataPath) returns a temporary URL, a defer block deletes the temp directory on return, and only the copy is passed to SQLiteDatabase. This avoids taking a lock on the live Web Data file that your browser is using, which is the common reason other tools hit 'database is locked' errors. It also means you can use Fazm mid-session with no interruption.

No. The extraction is pure local: Swift reads SQLite, writes the result to ~/ai-browser-profile/memories.db on your disk. The extract_browser_profile tool description in acp-bridge/src/fazm-tools-stdio.ts line 342 says it verbatim: 'Extracted locally from browser SQLite files, nothing leaves the machine.' The agent can then query that profile over the MCP interface, still locally. Whatever model you connect to (Anthropic, OpenAI, or a local Ollama) will see only the profile fields the agent chose to include in a given prompt, not the raw database.

Fazm ships the exact decoding table in ai-browser-profile-swift-light/Sources/AutofillExtractor/Constants.swift lines 3-17: 3 is first_name, 5 is last_name, 7 is full_name, 9 is email, 14 is phone, 33 is city, 34 is state, 35 is zip, 36 is country, 60 is company, 77 is street_address, 79 is address_line_2. This is how Chromium itself stores autofill data. Fazm reads the same integers and maps them to human-friendly keys with tags, so the agent can ask 'give me everything tagged identity' or 'give me email' and get a structured answer.

Fazm normalizes via autofillFieldMap in Constants.swift. zip, zipcode, postal, postalcode, postal_code, and postcode all resolve to the same key ('zip'). So do the four ways sites spell first-name (first_name, first-name, firstname, given-name). The agent does not have to care which spelling a given site used. When the site ships a redesign and renames a field, as long as the new name is within the autofillFieldMap aliases, the fill still works. When the name is novel, the agent falls back to reading the snapshot label (human-readable, like 'Postal code'), which usually disambiguates.

The tool description for query_browser_profile says it auto-triggers a new extract if the profile is missing, stale (>24h), or incomplete. So a user who adds a new credit card in Chrome on Monday and uses Fazm on Tuesday gets the fresh entry without any manual step. You can also call extract_browser_profile directly to force a refresh, or use edit_browser_profile to delete or update a specific memory by query string.

The Swift library's headline support list is Arc, Chrome, Brave, and Edge (Chromium), because they all share the same Web Data, Login Data, and History SQLite schema plus the Bookmarks JSON shape. Safari stores data in a different set of files under ~/Library/Safari and Firefox profiles live at ~/Library/Application Support/Firefox/Profiles. The code has the path constants for both (Constants.swift lines 107-112) and dedicated extractors can be added. For most new-Mac users in 2026, the Chromium big-four path hits the autofill they actually filled in.

Two reasons. First, a fresh identity form is friction: users type their own email into the same tool twice. Second, your Chromium autofill is already a living document. It knows your new address before any onboarding form would. Reading it directly means the agent never falls behind on who you are. The alternative, which Axiom does by default, is to hard-code the values into each recording, which is exactly the brittleness Fazm avoids.

In the same agent turn as the browser automation. Playwright MCP returns a text snapshot of the current tab where every input carries a human-readable label and a ref like [ref=e12]. The agent reads the snapshot, for each input finds the best match in the profile via query_browser_profile, then calls browser_type(ref='e12', text='matt@mediar.ai'). One of the things that makes the approach durable is that when a site redesigns and renames a selector, the label in the snapshot almost always stays the same ('Email', 'Phone'), so the profile-to-ref binding still resolves.

Yes. The Swift library is github.com/m13v/ai-browser-profile-swift-light (MIT, zero dependencies, Foundation plus system SQLite only). The Fazm desktop app is github.com/mediar-ai/fazm. The three files relevant to this page are ai-browser-profile-swift-light/Sources/AutofillExtractor/AutofillExtractor.swift, Constants.swift, and acp-bridge/src/fazm-tools-stdio.ts. File paths and behaviors on this page are verified against the repos on 2026-04-19.