Google’s Disco points to a different kind of AI browser

Google is testing Disco, a Labs experiment that uses Gemini 3 to turn your open browser tabs into lightweight generated web apps called GenTabs. It’s invite-only, macOS-only for now, and clearly early. Still, the idea has more substance than the usual AI sidebar.

The pitch is straightforward. Instead of summarizing the page in front of you, Disco looks across a group of tabs, infers the task, and builds a temporary interface for it. A trip planner from flight pages, hotel listings, and restaurant bookmarks. A study dashboard from articles, lecture notes, and docs. A meal planner from recipe tabs.

That makes immediate sense. Browsing sessions already contain a rough picture of intent. Most AI browser tools treat the browser as a place to answer questions. Google is treating it as input for generating software.

Better than another assistant pane

Most browser AI features fall into a familiar set of jobs: summarize a page, answer questions about it, automate a few clicks. Useful enough. Also pretty constrained. They still inherit the shape and limits of the original site.

Disco goes after a broader problem. It tries to build a new interface from multiple sources. That matters because plenty of web tasks already span sites. Researching a product. Comparing docs. Planning travel. Building a shortlist, then cutting it down.

The web handles documents well. It handles cross-document workflows poorly.

If GenTabs works, it fills that gap without asking people to change how they browse or move to a fully AI-native browser. That’s a product choice, but it’s also strategy. Perplexity’s Comet and OpenAI’s Atlas-style browser efforts lean toward rebuilding browsing around the agent. Google’s approach is more conservative, and probably more practical in the near term: keep the browser, add an agent layer, and have it assemble temporary apps from the tabs people already opened.

That’s easier to ship. It’s also less of a behavior change.

How Disco probably works

Google hasn’t published a technical spec, so some of this is inference. Still, the likely architecture is easy enough to sketch.

First, Disco needs session context. That means tab titles, URLs, visible page content, and probably some sense of order and grouping. A system app plus browser hooks could collect a lot of that. Plain DOM extraction covers many sites. For messier cases like cross-origin iframes, protected content, or highly dynamic apps, it may have to fall back to metadata, accessibility tree access where allowed, or explicit user selection.

Then comes preprocessing:

• chunk the text
• strip noise
• generate embeddings
• preserve timestamps and tab relationships
• infer which tabs belong to the same task

That last part matters. A decent system has to separate “I’m planning a trip” from “I have 27 tabs open because I’m a person with a browser.”

From there, Gemini 3 likely acts as a planner. It gets summaries, embeddings, recent Gemini chat history, and maybe other user signals. Then it maps the session to a task pattern. Budget travel. Product comparison. Weekly meal prep. Exam review.

Google probably isn’t asking the model to freehand an app from scratch. That would be messy and risky. The saner design is a schema-driven UI generator backed by a constrained component library: tables, charts, forms, maps, filters, calendars, cards. Structured tool calls, not arbitrary JavaScript with fingers crossed.

That fits Google’s examples. A GenTab would be assembled from known components tied to extracted data. Charts could use something like Vega-Lite. Layout could sit on Web Components or a controlled React surface. Updates would come from natural-language prompts translated into diffs against the app schema, instead of regenerating the whole interface every time.

That’s important for responsiveness. If a user says “group these hotels by neighborhood” or “remove recipes with peanuts,” the system should patch the current state, not start over.

The constraint model is the smart part

Generated software always tempts companies to hand the model a sandbox and hope for the best. That produces flashy demos and brittle products.

A constrained runtime is a better idea.

If Disco sticks to a fixed component set, isolated storage, strict Content Security Policy, and no third-party scripts inside generated tabs, Google gets a few benefits at once:

• lower prompt injection risk
• less XSS exposure
• more predictable output
• better performance
• easier attribution

Attribution matters here because Google says GenTabs link generated elements back to source pages. That helps with publisher relations, sure. It also helps users debug the output. If a chart or list item looks wrong, people need to know where it came from.

Without lineage, these interfaces get opaque fast. With lineage, they’re still fallible, but at least you can inspect them.

There’s a broader lesson in that design. Good AI products often come from tighter systems around the model, not just a bigger model dropped into the same old workflow.

Where it gets messy

Disco depends on context quality, and browser context is messy by default.

People open duplicates. They skim. They leave stale tabs hanging around for days. They mix work research with personal junk in the same window. The model has to infer intent from noisy evidence, and that’s a harder problem than summarizing a single page.

There’s also a trust problem. Generated interfaces look cleaner than the source pages they came from, which can make them feel more authoritative than they deserve. If a GenTab merges conflicting information from several sources into one tidy dashboard, users may assume the data is consistent when it isn’t.

That’s a real product risk. Clean UI can hide uncertain reasoning.

The privacy issue is obvious too. A system that reads across tabs and chat history has enormous contextual reach. It also has a lot of room to overreach. Google will need very clear consent boundaries, enterprise controls, and domain-level restrictions if this gets anywhere near workplace use. Plenty of teams will want it blocked on internal tools, financial systems, HR portals, and anything with customer data.

For enterprise buyers, the checklist is dull but decisive: admin policies, domain allowlists and blocklists, local processing where possible, auditability, and a clear answer to a basic question: what leaves the device?

Without that, Disco stays a consumer curiosity.

What developers should watch

Even if Disco never escapes the lab, the pattern matters. Browsers are turning into agent runtimes that can compose interfaces from whatever they can parse and retrieve.

That changes what “web-ready” means.

If your content is semantically structured, machine-readable, and broken into stable sections, these systems have a better shot at ingesting and citing it correctly. If your site is a pile of client-rendered div soup with text buried in images and thin metadata, expect bad summaries or no summary at all.

A few practical implications:

Treat semantics as infrastructure

Use real headings, tables, lists, labels, and landmarks. Publish JSON-LD where it fits. Keep canonical URLs stable. Give important sections anchors. Agent systems work better when the source has structure.

Offer clean data surfaces

If your product exposes information people may want inside a generated interface, an API matters. So do sane CORS settings, caching headers, and deterministic response formats. Agents are bad at scraping their way around fragile frontend code when a reliable endpoint exists.

Expect prompt injection to move up the stack

If an AI system reads your pages and then acts on that context, user-generated content becomes part of the attack surface. Prompt injection stops being just a chatbot issue and starts looking like a web issue. Sanitizing content, labeling untrusted text, tightening CSP, and reducing arbitrary script behavior all matter more.

Design for composability

Your app may sometimes be the destination and sometimes a source for somebody else’s generated workspace. Lightweight widgets, read-only embeds, stable query parameters, and predictable contracts help.

That’s becoming part of how software gets assembled in front of users.

Google’s timing makes sense

Google didn’t need to be first. It needed a credible answer to the AI browser shift without breaking Chrome’s basic model.

Disco looks like that answer. It extends the browser people already use, keeps Gemini in the middle, and turns multi-tab research into something closer to a temporary app. If the execution is solid, that’s useful. If it’s sloppy, it turns into another demo that falls apart as soon as users leave the happy path.

The bigger point is the direction. The browser is starting to assemble interfaces from context instead of waiting for websites to provide them.

Developers should pay attention. Publishers, product teams, and security engineers probably should too.