Browser AI From First Principles on AIBussin — AI applications, systems and books

The Browser Stops Being Just a Client

Wed, 02 Sep 2026 12:00:00 +0100

For most of the web’s history, the browser has been the place where computation ends up, not the place where intelligence begins.

It renders documents, executes JavaScript, and stores local state. It turns user actions into requests and server responses into interfaces.

When language models first entered web applications, they fitted that architecture neatly. The page gathered a prompt, sent it to an application server, the server called a model provider, and the answer travelled back through the same chain.

What Does Built-In Actually Mean?

Wed, 02 Sep 2026 12:05:00 +0100

The word built-in suggests permanence.

A built-in function is present when the program starts. A built-in browser feature is expected to work without an installer, account or deployment. If a web developer hears that AI is built into the browser, the obvious mental model is a global function waiting to be called.

const answer = await browserAI.prompt("Explain this page");

That is not the system we actually have.

The API may be absent. The device may be ineligible. The requested language or modality may be unsupported. A model may need to be downloaded. Downloading may require a user action. The bytes can arrive before extraction and loading finish. A session can be created and later exhaust its context. The same interface can be backed by a changed implementation after a browser update.

Build the Smallest Browser AI Observatory

Wed, 02 Sep 2026 12:10:00 +0100

We are ready to make the browser’s AI lifecycle visible.

The first version will be deliberately small. It will not inspect every page, intercept arbitrary prompts, call tools, diagnose quality or persist a history. It will do five things:

create a panel inside Chrome DevTools;
report whether the Prompt API is exposed and available;
create a browser-managed language-model session with visible download progress;
stream a prompt with cancellation;
display an event trace that separates each phase.

That is already more useful than a chat demo.

From Prompt Demo to AI Debugger

Wed, 02 Sep 2026 12:15:00 +0100

Our first DevTools panel can run a prompt and display its lifecycle.

That makes it a useful experiment console.

It does not yet make it a debugger.

A debugger must help explain a failure that occurred in the application under inspection. It needs to connect model activity to application context, preserve events long enough to compare them, and distinguish facts it observed from inferences it derived. It must do this without quietly capturing every prompt, response and page the user visits.

One Runtime, Several Interfaces

Wed, 02 Sep 2026 14:00:00 +0100

The first Browser AI Observatory knew about one global object: LanguageModel.

That was enough to expose the common lifecycle. We could inspect availability, create a session, monitor model acquisition, stream output, cancel a request and record what happened.

Chrome also exposes narrower built-in AI capabilities. Instead of asking a general language-model session to perform an arbitrary task, an application can create a summarizer, writer, rewriter, proofreader, translator or language detector.

Summarization Is a Contract

Wed, 02 Sep 2026 14:05:00 +0100

Summarization looks like the ideal local AI feature.

The input is already in the browser. The desired output is smaller than the input. The task is useful for articles, documentation, conversations, reviews and support content. Sending the entire source to a remote provider can feel disproportionate when a browser-managed model can operate on the device.

So the implementation seems obvious:

const summarizer = await Summarizer.create();
const result = await summarizer.summarize(text);

The code is correct.

The feature is unspecified.

Writing, Rewriting and Proofreading Are Different Operations

Wed, 02 Sep 2026 14:10:00 +0100

Writer, Rewriter and Proofreader all accept text and return text-related results.

That surface similarity makes it tempting to place them behind one function:

const output = await improveText(input);

The name hides the most important property of the operation.

How much is it allowed to change?

A writer may create content that did not exist. A rewriter may change expression while preserving the underlying message. A proofreader should correct a bounded class of errors while leaving correct content alone.

Language Detection Is a Decision, Not an Answer

Wed, 02 Sep 2026 14:15:00 +0100

Translation appears to be a two-step browser-AI pipeline:

text
 ↓
detect language
 ↓
translate to target language

The implementation is short enough to fit inside one event handler.

const candidates = await detector.detect(text);
const sourceLanguage = candidates[0].detectedLanguage;
const translator = await Translator.create({
 sourceLanguage,
 targetLanguage: "en"
});
const output = await translator.translate(text);

The dangerous line is not the model call.

It is the array index.

candidates[0] is the highest-ranked language returned by the detector. That does not make it correct, supported for translation, or confident enough to justify an automatic action.

A Session Is Not a Stateless Function

Wed, 02 Sep 2026 15:00:00 +0100

A remote model API often encourages a simple mental model:

const answer = await complete(prompt);

Input goes in. Output comes back. Any conversation state is reconstructed by the application and sent again.

A browser-managed Prompt API session is a different kind of object. It owns resources, may retain conversational state, reports a finite input budget, supports branching in some implementations, and should be destroyed when its work is finished.

The correct abstraction is not a stateless function.

When the Context Window Fills

Wed, 02 Sep 2026 15:15:00 +0100

A stateful session eventually encounters a physical limit.

Prompts, initial instructions, examples, conversation history and model outputs all compete for a finite context budget. Once the budget is exhausted, the application cannot solve the problem by pretending the next message is independent.

The difficult question is not how to delete text.

It is how to preserve the right state.

1. The context window is a budget

When a session exposes usage and quota, context pressure becomes observable:

Cold Starts, Warm Runs and Real Latency

Wed, 02 Sep 2026 15:30:00 +0100

“Local AI is faster” is not a measurement.

It compresses several different waiting periods into one adjective. A browser-native feature can avoid network round trips and still make a user wait for model acquisition, process startup, session creation, context ingestion or slow generation.

To understand latency, we have to take the lifecycle apart.

1. One duration hides several clocks

For one interaction, useful timestamps include:

Phase	Starts	Ends	User-visible?
Capability inspection	`availability()` call	state returned	Usually not
Acquisition	session request requires assets	assets ready	Yes, if it blocks
Session creation	`create()` called	session returned	Often
Prompt startup	prompt called	first chunk	Yes
Generation	first chunk	final chunk	Yes
Validation	output complete	feature accepted/rejected	Sometimes

The perceived wait for a streaming feature is often dominated by time to first output:

The Browser Manages the Model

Wed, 02 Sep 2026 15:45:00 +0100

The central promise of built-in AI is an abstraction boundary:

application
 ↓
browser AI API
 ↓
browser-managed runtime
 ↓
current model and execution strategy

The application asks for a capability. The browser chooses how to provide it.

That separation is powerful, but it does not make the lower layers irrelevant. Changes beneath the API can alter availability, accepted options, performance and behavior.

We encountered that fact before completing our first prompt experiment.

A Resolved Promise Is Not a Correct Answer

Wed, 02 Sep 2026 16:00:00 +0100

The following code has only one definition of success:

try {
 const output = await session.prompt(input);
 show(output);
} catch (error) {
 showFailure(error);
}

If the promise resolves, the interface displays the result.

That is sufficient for a deterministic lookup whose return value is authoritative. It is not sufficient for a probabilistic system that can return fluent, well-formed and incorrect text.

A resolved promise proves that an operation completed according to the runtime contract. It does not prove that the feature did its job.

Evaluate the Feature, Not the Demo

Wed, 02 Sep 2026 16:15:00 +0100

A demo asks whether one carefully chosen example can work.

A feature evaluation asks how often the product contract holds across the inputs, states and failures users will actually encounter.

Both have value. Confusing them is the problem.

1. The unit of evaluation is the feature

“Evaluate Gemma 4” is too broad for our application. “Evaluate this prompt” is too narrow.

The useful unit is something a user attempts:

summarize selected documentation
rewrite permission copy without changing authority
detect language and decide whether to translate
produce structured arguments for a read-only tool

Each feature includes input preparation, capability selection, model output, validation, fallback and UI behavior.

When Local Is Not Available

Wed, 02 Sep 2026 16:30:00 +0100

A browser-native AI feature cannot assume that its preferred local capability exists everywhere.

The API may be absent. Hardware may be ineligible. A language pair may be unsupported. Model assets may need acquisition. Session options may be rejected. Storage pressure or a browser update may change a state that worked yesterday.

Reliability begins by treating local availability as a runtime condition, not an installation promise.

1. Unavailable is not one state

A useful feature distinguishes:

Structured Output Is Still Model Output

Wed, 02 Sep 2026 16:45:00 +0100

JSON feels safer than prose because software can parse it.

That is a real advantage. It is not a guarantee that the values are correct, permitted or useful.

A model can produce perfectly valid JSON containing a nonexistent file, an unsupported operation, a reversed date range or an action the user never authorized.

Structured output is still model output.

1. Structure removes one class of ambiguity

Suppose we ask a model to choose a fixture and repetition count. Prose might return:

From Buttons to Capabilities

Wed, 02 Sep 2026 17:00:00 +0100

Chapter 16 ended with a rule: a model may propose a structured action, but only deterministic policy and appropriate authority may admit it for execution.

That rule assumed the action already existed. A JSON object naming send_email does nothing until some operation is bound to that name. This chapter is about the binding.

A browser agent can already operate software without one. It looks at a page, guesses which control matters and simulates a click. That is sometimes the only route available. It should not be the preferred contract between two pieces of software.

Expose the First WebMCP Tool

Wed, 02 Sep 2026 17:15:00 +0100

Chapter 17 built the contract. This chapter registers it with the browser.

Our first WebMCP tool should not send a message, edit a document or buy anything. It should read from the book we control. We will expose search_book: a bounded operation that returns relevant chapters and passages.

The modesty is deliberate. Starting with a bounded read-only tool removes state-changing consequences while we test registration, discovery, schema handling, execution and tracing. It does not remove disclosure risk — a read tool can still leak — so the corpus and the result still need explicit bounds, which is most of what section 6 is about.

Tool Choice Is a Behavioral Problem

Wed, 02 Sep 2026 17:30:00 +0100

Chapter 18 built a tool that is correct by construction: its contract is tested, its results are bounded, its lifecycle is traced. None of that determines whether an agent uses it well.

Once a model can see several capabilities, the outcome depends on a behavioral pipeline:

discovery → selection → argument construction → admission → execution → result use

A single “task passed” score cannot tell you which stage failed. Chapter 13 made this argument for model output: a resolved promise is not a correct answer. The same layering applies to tool use, with more stages and higher stakes.

Untrusted Text Meets Executable Authority

Wed, 02 Sep 2026 17:45:00 +0100

Before tools, malicious page text could corrupt a model’s answer. That is a quality problem.

After tools, the same text sits in the same reasoning context as send_email, export_traces and publish_note. Now it is a security problem.

Prompt injection becomes an authority problem when untrusted language shares a reasoning context with executable capabilities. The defense is not a better classifier for hostile text. It is an architecture in which the model’s influence over language does not translate into influence over authority.

Put a Human at the Authority Boundary

Wed, 02 Sep 2026 18:00:00 +0100

“Ask the user before doing anything dangerous” sounds like a safety design.

It is only a slogan until we define what the user sees, when approval occurs and exactly what the approval authorizes.

A useful authority boundary turns a model’s proposal into a concrete, validated effect. The user approves that effect—not a vague intention and not the model in general.

1. Classify effects before requesting permission

Not every tool call deserves the same interruption. Begin with effect classes:

The Browser as a Personal Policy Engine

Wed, 02 Sep 2026 18:15:00 +0100

So far, the browser has supplied models, sessions, context and tools. We used them to inspect applications and constrain agent actions.

There is another direction the same architecture can travel.

Instead of asking only, “What can an agent do to a website?”, ask:

What should the website be allowed to do to the user’s attention?

A personal policy engine observes the page, evaluates content under rules chosen by the user and changes presentation locally. It is not the site’s moderation system. It is the user’s mediation layer.

Build an AI-Origin Content Filter

Wed, 02 Sep 2026 18:30:00 +0100

Suppose a user says:

Exclude AI-generated content from my browser experience.

The request is clear. The underlying fact often is not.

Once text has been copied, edited, translated, mixed with human work or stripped of metadata, its origin may be impossible to establish from the content alone. A serious filter must therefore manage evidence and uncertainty rather than pretend to possess an infallible detector.

1. Define the claim precisely

“AI-generated” can mean several things:

Build Browser AI Lens: The User-Owned Intelligent Browser

Wed, 02 Sep 2026 18:45:00 +0100

A platform decides what enters a feed, how it is ranked, which controls are prominent and which forms of automation are available.

The user may select among the settings the platform offers. That is not the same as controlling the interface.

The preceding chapters built the machinery for another layer: software acting locally, under rules the user can inspect, across sites and independently of one model provider. This chapter assembles that machinery into one product, Browser AI Lens, and states precisely what has been demonstrated and what has not.

Appendix A — Browser AI Field Guide: Setup, APIs, States, Diagnostics and Configuration

Tue, 08 Sep 2026 00:00:00 +0100

This appendix consolidates the contracts, states, and procedures distributed through the argument into one working reference. Prose explains; this section is for the keyboard.

Publication snapshot: September 2026. Browser flags, origin trials, API availability, and experimental configuration change. Flag values and external documentation details below reproduce the tested builds of this edition. Anything the book’s own laboratories did not observe is marked as such.

A.1 Development setup

Surface	Setting / location	Value / action	Purpose	Stability
Chrome flags	`chrome://flags/#optimization-guide-on-device-model`	Enabled (lab profile)	On-device model support for local development	Experimental, recheck per build
Chrome flags	`chrome://flags/#prompt-api-for-gemini-nano`	Enabled where applicable	Foundation-model API access for local testing	Experimental, recheck per build
WebMCP	`chrome://flags/#enable-webmcp-testing`	Enabled	Local WebMCP development without relying on the origin trial	Experimental, recheck per build
Extensions	`chrome://extensions`	Developer mode, load unpacked	Load the Browser AI Observatory	Durable workflow
Diagnostics	`chrome://on-device-internals`	Open model status	Inspect on-device model state and errors	Browser diagnostic surface
JavaScript	`LanguageModel.availability(options)` in DevTools	Run with intended options	Operational preflight before creation	API contract
Observatory	AI Observatory panel, capability inspection	Run inspection	Capture the full lifecycle instead of guessing	Book tooling

Flag values follow the laboratory run-book convention of this edition, not a permanent browser contract.