docs · concepts

Architecture

One idea drives everything: a repeated site action should be figured out once, written down as a skill, and replayed by every agent after that — instead of re-derived from the raw page on every run.

The skill loop

Every task that touches a website starts the same way: look in the catalog before touching the page. What happens next depends on whether a skill exists.

the skill loopper task
Task arrives"find CTOs in Madrid on LinkedIn"
bmem search linkedin
skill exists · replay
bmem add linkedin.com/search-peopleregistered natively — once
Run in your browsernavigate + evaluate the recipe — structured JSON back in seconds
no skill yet · learn once
Explore the live siteread the page, watch the network log, find the real endpoint behind the UI
Author a SKILL.mdthe steps that worked: selectors, the direct request, the success check
Curated into the catalogvalidated and tested before it ships
One skill per task per site, sharedfrom now on, every agent takes the green lane

First run vs every run after

Without a skill, the agent derives the page live — and pays in time and tokens on every single run. With one, the same task is a recipe replay:

same task, twicelinkedin.com
no skill · derive live
agent · raw browserminutes
$ find CTOs in Madrid on linkedintaking screenshot…1.4sreading DOM snapshot11k tokguessing selectors · retry ×3paginating by hand……the same, next page
with the skill · replay
any agent · same browserseconds
$ find CTOs in Madrid on linkedinsearch-people({ query, geo })0.4s{ people: [ { name, url, headline, … } ] }
Without a skillWith a skill
Per-step page readsScreenshot + DOM snapshot, every stepNone — the recipe is already known
What the model seesRaw pages, thousands of tokens eachStructured JSON fields
Latency per taskMinutes of derive-and-retrySeconds — about 20× faster
Token costPaid again on every runRoughly 4× fewer tokens
BehaviorProbabilistic, varies run to runDeterministic replay

The self-repairing catalog

Sites change markup and APIs constantly, so any skill can break overnight. Because every agent shares one catalog, a break is fixed exactly once:

self-repairshared catalog
Site ships new markupselectors and endpoints drift
A skill breaks for one agentthe first one to hit it
Fixed once in the catalogre-derived, re-tested, re-published
↺ every agent gets the fix through the shared catalog

Prefer the network, not the UI

The most stable skills don’t click through the interface at all. While a site is being explored, the network log usually reveals the direct in-page endpoint behind the UI — so the skill ships one authenticated fetch plus parsing instead of a chain of clicks. Markup changes weekly; internal APIs rarely. That is a big part of why replays stay stable, and why most catalog skills declare only needs: [navigate, evaluate].

What leaves your machine

bmem is consume-only: it downloads skill files and registers them. The skill itself executes inside your browser:

Stays localComes from the catalog
Cookies and logged-in sessions (in your browser profile)Skill files: selectors, request shapes, intent
The browsing itself — pages, results, form inputIndex entries when you search
Anything typed during a manual loginNothing else — the API is read-only
auth

Skills with auth: session ride on the session already in your browser profile. If it expired, log in manually and re-run — the skill itself is still valid. Never automate the login.

Components

ComponentRunsRole
bmem CLIYour machine (Node)Search the catalog, download skills, register them natively
skills installerYour machine (via npx)Detects your agent and writes the skill where it looks for skills
Your browserWherever it already runsExecutes the recipe; holds every session and cookie
Catalog APIapi.browser-memory.comRead-only index of curated skills per site
Skill storageHosted (public bucket)The SKILL.md bodies the CLI downloads

The catalog can be self-hosted and pointed at with one environment variable — see self-hosting.