Engineering service
AI Browser and Extension Development
We build AI features into custom browsers, extensions and desktop apps: assistants that read the current page, summaries, content classification and filtering, and agent features that carry out tasks in the browser. Models run on the device, in the cloud or both, and each feature ships with a test set and cost limits.
- 11+ years of experience
- 300+ projects delivered
- Remote team, clients worldwide
- NDA on request
Overview
What it is and when it fits
We build AI features that live inside browsers, extensions and desktop apps: assistant sidebars, page summaries, content filtering and agents that carry out tasks in the browser. For Kahf Browser, a Chromium browser for families, that meant classifying images as pages load and blurring inappropriate ones in place.
We integrate and evaluate existing models, hosted or on the device, and do the engineering around them: where the model runs, what page data it sees, how output is checked and what it costs. This is not a research service. If there is no browser, extension or desktop product involved, another kind of team will serve you better.
Who this is for
- Teams adding an assistant, summaries or content filtering to a browser extension.
- Companies building AI or agent features into a custom Chromium browser or a desktop app.
- Products with privacy or compliance limits on what data may leave the device.
- Teams with a prototype that now has to work reliably when people use it every day.
How it works
Architecture at a glance
Where AI fits in a browser or desktop app
AI feature
An assistant sidebar, page summaries, content filtering or an agent, as the user sees it.
Orchestration
Prompts, retrieval, caching, evaluation and guardrails.
Model
An on-device model or a hosted API.
Host
- Extension
- Custom browser
- Desktop app
A browser extension, a custom browser or a desktop app.
- Your productWhat your users see
- Our engineeringWhat we build and maintain
- UpstreamThird-party code we build on
- Platforms and releaseBuild, sign and deliver
What we offer
What's included
Page-aware assistants
An assistant sidebar or chat panel that reads the current page's content, through the DOM or an extension's content script, to answer questions about what the user is looking at or search across open tabs.
Content classification and filtering
Images and text classified as the page loads, then blurred or hidden in place instead of blocking the whole page. We built this kind of image filtering for Kahf Browser.
In-browser summaries
Summaries of articles, threads and documents from an extension's toolbar or context menu, using a hosted model, a small on-device model or Chrome's built-in Summarizer API.
On-device model integration
WebGPU or WebAssembly inference in the browser, Chrome's built-in AI APIs, or a native runtime in a desktop app, for features that must work offline or keep data on the device.
Agent features in the browser
Multi-step tasks that a model plans and the browser carries out, such as filling a form. Page content can try to steer the model (prompt injection), so we limit what the agent may do and ask the user to confirm actions that matter.
AI feature audits
A review of an AI feature already in your extension, browser or app, covering latency, cost, prompt reliability, data handling and failure cases.
Deliverables
What you get
- 01
Working AI feature
The feature built into your extension, browser or desktop app, with source code in your repository.
- 02
Model selection with reasoning
A recommendation between hosted and on-device models, based on your task, privacy limits and budget.
- 03
Orchestration layer
Prompt management, retrieval over your content, caching and guardrails, kept separate from the model so it can be swapped.
- 04
Evaluation set and harness
A test set built from your own content, and a script that re-runs it whenever the model or prompts change.
- 05
Cost and usage controls
Caching, limits and fallbacks that keep model usage predictable as adoption grows.
- 06
Handover documentation
Notes on how the feature works, how to update prompts and models, and how to read the evaluation results.
Compare
Where should the model run?
Most products end up somewhere in the middle. These are the trade-offs we discuss with you.
| Aspect | On the device | In the cloud | Hybrid |
|---|---|---|---|
| Privacy | Data stays on the machine | Data is sent to a provider, so terms and retention matter | Sensitive steps run locally, and only what is needed goes to the cloud |
| Model size and quality | Limited to smaller models that fit the hardware | Access to the largest available models | A small model handles routine work, and a larger one handles hard cases |
| Latency and offline use | Works offline, with speed set by the user's hardware | Needs a connection, and adds network round trips | Offline for basic features, connected for advanced ones |
| Cost model | No per-request fee, but larger downloads and device load | Pay per use, so cost grows with usage | Cloud cost is reduced by handling easy requests locally |
| Fit | WebGPU or WASM in browsers, and native runtimes in desktop apps | API calls from an extension backend or your app server | Both, with routing logic between them |
Why it matters
What this gives you
Ships inside the product users already have
The feature lives in the extension, browser or desktop app your users already have installed, not a separate site they have to visit.
Privacy boundaries you set
A clear line between what stays on the device and what is sent to a model provider, decided with you instead of defaulting to sending everything.
A model layer you can swap
Prompts and orchestration sit behind an interface, so moving to a different model or provider later does not mean rebuilding the feature.
Store-ready AI releases
Store reviewers look at how page content reaches a model. We keep permissions narrow and write the data-use disclosures the Chrome Web Store and Firefox Add-ons ask for.
Our approach
How we add an AI feature
Define the task
We agree what the feature should do, what data it sees, and what a good answer looks like.
You get: A task definition and success criteria
Build an evaluation set
We collect examples from your own content and write the checks that judge the output.
You get: A test set you can re-run
Prototype with candidate models
We try hosted and on-device options against the test set, on your target hardware where relevant.
You get: A comparison of quality, latency and cost
Build the feature
We integrate the chosen model into your host, with caching, limits and guardrails around it.
You get: The feature running in your extension or app
Monitor and improve
We track results across prompt and model changes so quality does not drift unnoticed.
You get: Evaluation reports and update notes
When this is not the right fit
- You need standalone model research or data science with no browser or desktop side. That is outside our scope.
- You want to train a foundation model from scratch. We integrate and evaluate existing models instead.
- The feature has no defined task or way to judge output. We would define that before writing any code.
Tech stack
Technologies we use
The engines, APIs and tools we use on this service.
WebAssemblyONNX RuntimeTransformers.jsChrome built-in AI APIsChrome Extension APIs
ChromiumHosted LLM APIsEmbeddings
TypeScriptFAQ
Common questions
We are model-agnostic. We choose between hosted APIs and open models based on the task, your privacy limits and the cost, and we keep the model behind an interface so it can be changed later.
Yes, for suitably small models: WebGPU or WebAssembly inference in the browser, Chrome's built-in AI APIs where your users run Chrome, or a native runtime in a desktop app. On-device models have limits on quality and depend on the user's hardware, so we test on your target machines before promising it.
We build a test set from your own content and score the output against it. The same set is re-run whenever the model or prompts change, so you can see whether a change helped or hurt.
We cache repeated requests, try a smaller model before a larger one, and set usage limits per user or per task. What the final cost is depends on your volume and provider pricing, which change over time.
An extension is faster to ship and works in the browsers people already use, but it is limited by the extension APIs and store policies. A custom browser gives deeper control over the interface and page access, at a higher maintenance cost.
Proof
Related production work
Family-safe and content filtering
Kahf Browser
A Chromium browser for Muslim families that blurs explicit images with AI as pages load. Kahf reports more than 280,000 active installations.
- AI filtering
- Content blurring
- Privacy
Web3 browsers
True Browser
A Chromium browser we built for a private client, aimed at AI and Web3 users, with privacy rules set at the start of the build.
- AI
- Web3
- Privacy
Our services
Related services
Start a project
Adding AI to a browser or extension?
Tell us the product and the feature you have in mind. We will recommend where the model should run and what drives the cost.