Retriever AI is an AI web-agent platform that can understand, navigate, extract from, and take action inside a user's live browser.
Unlike browser agents that repeatedly ask a model what to click next, Retriever represents webpages as structured text and DOM data. Its code-as-plan architecture has the agent write a JavaScript program for the user's specific request and execute that program in a sandbox.
The generated code can parse page content, extract hundreds of rows, normalize identifiers, call APIs, batch requests, join records, remove duplicates, write to Google Sheets, and complete actions in the browser. Repetitive data operations are handled by deterministic code rather than by additional model calls.
The challenge: the most valuable lists are inside the user's browser
Many high-value business lists do not exist at a public URL or behind a convenient API. They live on pages the user is already authorized to see:
- Event guest and attendee lists
- Logged-in professional searches
- Member and partner directories
- Customer or vendor portals
- Subscription databases
- Private marketplace and property listings
- Internal dashboards and CRM views
Server-side enrichment platforms cannot see which records the user is currently looking at. So users export a CSV, clean it, upload it into another product, map its columns, configure an enrichment waterfall, and import the results back into the system they started in.
A browser agent can see the page, but without a structured data layer it has a different limitation: it has to open and research every record individually. A list of 500 people turns into hundreds of tabs, page loads, model turns, retries, and verification steps.
Retriever needed a way to combine the context available inside the user's browser with fast, structured public-web data.
The solution: the browser provides context, Bright Data provides enrichment
Retriever uses the browser as the context, intent, and action layer, and Bright Data as the public-web data layer.
When a user opens an authorized page and asks Retriever to enrich it, the agent generates a JavaScript plan that:
- Parses the records visible in the browser.
- Extracts and normalizes names, profile URLs, company domains, listing URLs, or other identifiers.
- Selects the appropriate Bright Data dataset and fields.
- Performs bulk lookups against pre-collected datasets where available.
- Uses live collection for exact URLs that need fresh data.
- Runs targeted web searches to discover missing information and candidate sources.
- Joins and deduplicates the results.
- Scores or classifies the enriched records according to the request.
- Opens only the most relevant pages when browser-level verification is needed.
- Writes the results to a sheet or completes the requested actions in the live browser.
Retriever exposes Bright Data-backed enrichment across people, business, social, commerce, real-estate, employment, and local-business datasets — LinkedIn people, LinkedIn contact-enriched profiles, and LinkedIn companies for instant lookup, plus live collection for Crunchbase, Instagram, Amazon, Zillow, Indeed, and Google Maps. The full list, filter syntax, and pricing are in the enrichment docs.
Bright Data's Dataset API supports low-latency searches over pre-collected marketplace data, while the Web Scraper API returns fresh structured records for supported URLs and sites.
Code-as-plan turns enrichment into a generated program
Retriever does not ask the model to research each row. It asks the model to write the enrichment pipeline once.
The resulting program handles key extraction and normalization, batching, parallel requests, retries, dataset-field selection, record joins, deduplication, cost calculation, result projection, sheet writes, scoring, and filtering.
That means a different enrichment workflow for every request. An event attendee list might need people and company data followed by ICP scoring. A property directory might need Zillow data, neighborhood research, and price comparisons. A product list might need Amazon data, availability checks, and competitor discovery.
Instead of forcing each user into a fixed waterfall template, Retriever generates the waterfall for the particular page, dataset, and requested outcome. Users can inspect the generated code, edit it, save it, and replay it against a future list.
// Build lookup keys from the rows on the page — the LinkedIn slug, not the URL.
const ids = rows
.map(r => r.linkedinUrl?.split('/in/')[1]?.split(/[/?#]/)[0].toLowerCase())
.filter(Boolean);
// Estimate cost and get explicit approval before any paid call.
const estCredits = Math.ceil(ids.length * 0.25);
const { answers } = await rtrvr.askUser({
questions: [{
key: 'enrichApproval',
query: `Enrich ${ids.length} LinkedIn profiles for ~${estCredits} credits?`,
choices: ['Yes', 'No'],
}],
});
if (answers.enrichApproval !== 'Yes') return { summary: 'Enrichment declined.' };
// One instant lookup — batching against the Dataset API happens server-side.
const { records } = await rtrvr.enrich({
dataset: rtrvr.datasets.linkedinPeople,
filter: { name: 'id', operator: 'in', value: ids },
fields: ['name', 'position', 'current_company', 'city'],
});Everything around the paid lookup is deterministic code, not model turns. A for-loop should not cost tokens, and here it doesn't.
Web search as a force multiplier for browser agents
Bright Data-powered web search expands how much research a browser agent can do before it needs to navigate anywhere.
A conventional browser agent discovers information by opening a search engine, typing a query, reading the result page, clicking a result, loading the page, and repeating. Discovery itself becomes a long browser workflow.
Retriever reverses this. Its generated code fans out targeted searches across industries, people, companies, locations, products, or research topics. It receives structured titles, URLs, snippets, and local results, then deduplicates and ranks them before opening any pages.
The agent only opens the highest-value sources — for detailed extraction, fact verification, authenticated information, form completion, outreach, and other browser-native actions.
Search performs discovery. The browser performs verification and action.
Example: turning an event guest list into qualified pipeline
In Retriever's launch demonstration, the user opened a 500-person event guest list available through their authenticated browser session and gave the agent one instruction:
Enrich these guests with professional profiles and work emails, score them against my ICP, and reach out to the top 10.
Retriever generated and executed a program that:
- Extracted all 500 attendees from the open page
- Normalized the available profile and identity information
- Matched the records against people, company, and contact datasets
- Used web search and live pages for what was still missing
- Scored the attendees against the user's ideal customer profile
- Streamed the enriched records into a Google Sheet as they landed
- Selected the 10 strongest matches
- Sent personalized connection requests and emails
The whole process started from the page the user was already viewing. No export and re-import loop, no manual column mapping, and no requirement to configure a reusable enrichment template before the task could begin.
At Retriever's current pricing, the Bright Data-backed instant lookup costs 0.25 Retriever credits per matched record — $2.50 per 1,000. A fully matched 500-person lookup is therefore about $1.25. Unmatched lookups are not charged, and every paid dataset operation is estimated and shown to the user for approval before it runs.
User control and architectural separation
An important part of the architecture is the separation between authenticated browser context and public-web enrichment.
Retriever does not need Bright Data to sign in to the user's account or reach the authenticated source page. The page the user has opened is processed by Retriever as a user-authorized context and selection layer.
The generated plan then sends the relevant public identifiers or source URLs into Bright Data's data products. Results come back to Retriever, are joined with the original browser records, and are presented or acted on inside the user's workflow.
Paid enrichment calls are approval-gated, and the generated program can be inspected before or after it runs. Entity extraction happens before the cost estimate, and the paid lookup runs only after the user approves it.
Looking forward
Retriever plans to expand this model across sales research, recruiting, event follow-up, real estate, e-commerce, local-business discovery, job research, and any workflow where a user has a valuable list open in their browser.
The larger opportunity is to make public-web data a native building block for web agents. Instead of asking users to leave their workflow and operate a separate data platform, Retriever lets an agent select the right Bright Data product, write the integration code, get approval, and use the resulting data as part of a complete task.
Bright Data provides the public-web data plane. Retriever provides the live context, orchestration, and action layer.