A browser-native agent framework for React and Angular, built on
Gemini Nano, WebMCP, and vectorless retrieval.

Wren lets a Chrome tab answer questions and act on your app's own content and tools, entirely on-device. There is no server. Every model call runs against Gemini Nano through the Chrome Prompt API, retrieval is a lexical FTS5 prefilter over a shallow section tree instead of an embeddings pipeline, and the only surface Wren can act through is WebMCP. Nothing ingested, asked, or answered ever leaves the browser tab.

• On-device only. No API keys, no inference bill, no network round trip. Gemini Nano runs locally via the Chrome Prompt API; if it is unavailable, Wren degrades instead of failing.
• Vectorless retrieval. A BM25-style FTS5 prefilter plus a shallow, LLM-navigable section tree replace an embeddings pipeline entirely. No vector database, no chunking heuristics to tune.
• WebMCP as the only tool surface. Wren's dispatcher can act through navigator.modelContext and nothing else, so what your app exposes as a tool is exactly what the model can do.
• Framework-agnostic core. @wren/core has zero UI dependencies. @wren/react and @wren/angular are thin bindings over the same dispatcher, retriever, and storage.
• Small and auditable by design. A hop-capped dispatcher, an ordered token-budget truncation strategy, and a page-scale corpus target keep Wren's behavior easy to reason about end to end.

Every layer below your application code ships in @wren/core and has no knowledge of React or Angular:

pnpm add @wren/core @wren/react   # or @wren/angular

import { WrenProvider, useWren, useTool } from '@wren/react';

function Assistant() {
  const { wren, status } = useWren();

  useTool({
    name: 'get_current_user',
    description: "Returns the signed-in user's display name.",
    inputSchema: { type: 'object', properties: {} },
    execute: async () => ({ content: currentUser.name }),
  });

  const ask = async (question: string) => {
    if (status !== 'ready') return;
    const response = await wren!.query(question);
    console.log(response.answer, response.citations);
  };

  // ...
}

export function App() {
  return (
    <WrenProvider>
      <Assistant />
    </WrenProvider>
  );
}

Run an example locally:

pnpm install
pnpm --filter react-demo dev

In scope

• Client-side only. No server, no network calls at runtime.
• Gemini Nano only as the model.
• WebMCP as the only tool surface.
• Vectorless retrieval: FTS5 plus a shallow section tree, capped at one navigation hop.
• Small, page-scale corpora.

Out of scope

• Any model other than Gemini Nano.
• Embeddings or vector storage of any kind.
• Server components or API routes.
• Multi-hop autonomous planning beyond the capped dispatcher.
• Vue, Svelte, or any binding beyond React and Angular.

• Chrome desktop with the Prompt API and the on-device Nano model available.
• The WebMCP origin trial or flag, for the tool bridge to external agents. Wren's own dispatcher works without it. This bridge (ToolRegistry's mirroring into navigator.modelContext) is unit-tested against a stubbed implementation but has not yet been exercised against a real one: navigator.modelContext has been observed undefined even in Chrome 149 with Nano available, so origin-trial enrollment on top of the Chrome version is apparently still required. Track this as unverified.
• No Cross-Origin-Opener-Policy or Cross-Origin-Embedder-Policy headers are required for storage. WrenStorage uses the OPFS SAHPool VFS, which does not rely on SharedArrayBuffer or Atomics.wait the way the default opfs VFS does. It does need to run in a Worker, since FileSystemFileHandle.createSyncAccessHandle() is only available there, not on the main UI thread.

pnpm install
pnpm build
pnpm test
pnpm lint
pnpm typecheck

Under active, phased development. The public API will change while WebMCP is in origin trial.

Apache-2.0. See LICENSE.

_{Maintained by Mohamed Yasser | Solutions Architect}