Browser AI on Programmer.ie: Modern AI programming

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.

It executes JavaScript.

It 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

A browser agent can operate software by looking at a page, guessing which control matters and simulating a click.

That is sometimes necessary. It should not be the preferred contract between two pieces of software.

The alternative is a capability: an operation the application exposes deliberately, with a name, description, input schema, result and authority boundary.

1. A button is evidence, not an interface contract

The text “Book” may represent a purchase, reservation, navigation link or decorative heading. Position and colour help a human infer meaning, but none provides a stable machine contract.

Expose the First WebMCP Tool

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

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 finds relevant chapters and passages.

1. Start with a narrow contract

Conceptually, the page registers:

navigator.modelContext.registerTool({
  name: "search_book",
  description: "Search this book for passages related to a query.",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string", minLength: 2, maxLength: 300 },
      limit: { type: "integer", minimum: 1, maximum: 10 }
    },
    required: ["query"],
    additionalProperties: false
  },
  execute: ({ query, limit = 5 }) => searchIndex(query, limit)
});

WebMCP is evolving, so the exact registration surface must be checked against the browser version used for an experiment. The durable architecture is name, description, schema and implementation.

Tool Choice Is a Behavioral Problem

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

A tool can be perfectly implemented and never used correctly.

Once an agent sees several capabilities, success depends on a behavioral pipeline:

discover → select → construct arguments → invoke → interpret result

A single “task passed” score cannot tell us which stage failed.

1. Discovery precedes choice

If the tool never enters the agent’s effective context, it cannot be selected. Record which registrations were available, filtered, truncated or rejected.

Untrusted Text Meets Executable Authority

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

Before tools, malicious page text could mislead a model’s answer.

After tools, the same text may influence an action.

Prompt injection becomes an authority problem when untrusted content shares a reasoning context with executable capabilities.

1. Identify the trust domains

A browser agent may combine:

user instructions;
developer policy;
page content;
tool descriptions;
tool results;
prior session state.

They are all text to the model. They are not equally authoritative.

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:

The User, Not the Platform, Controls the Interface

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.

Browser AI creates the possibility of another layer: software acting locally, under rules the user can inspect, across sites and independently of one model provider.

This chapter assembles the system we have built and defines the limits of that claim.