Add Overview: introduction, products, concepts, why KERNEL

[andrewleesteele]

Summary

Top layer of the guides IA restructure (stack: #671 → #672 → #673 → #674). Adds the Overview section and completes the new sidebar.

• Introduction: rewritten around what KERNEL provides, why each browser runs in its own VM (with a diagram), and the open source projects behind it, ending with cards for See all products, Quickstart, and Cookbooks.
• See all products (new): one grid of products in order of relevance.
• Important concepts (new): the agent framework (model, system prompt, tools, skills, browser automation framework), browser infrastructure, and the internet, with a diagram, a "which piece to change" table, and what KERNEL provides for each piece.
• Why KERNEL? (new): performance and framework pairing first, then what sets KERNEL apart, why not run Chrome yourself, and when KERNEL isn't the answer.

After this layer, the old sidebar groups are gone and the Guides sidebar is Overview, Start building, How it works, Partnering with KERNEL.

Testing

• mint validate and mint broken-links pass on this branch.
• The diagrams were rendered and checked in a local build.

🤖 Generated with Claude Code

---

Note

Low Risk
Documentation and Mintlify navigation only; no application or API behavior changes.

Overview
Restructures the Guides sidebar by adding an Overview group (products, concepts, why-kernel) and dropping the old Info entries for info/concepts and info/unikernels from navigation.

The home Introduction (index.mdx) is rewritten around KERNEL as an “internet runtime,” unikernel-per-browser rationale (new diagram), open-source project cards, and get started links to products, quickstart, and cookbooks—replacing the prior feature cards, copy-prompt block, and prod-setup content.

Three new overview pages add a product grid, an agent-stack mental model (diagram + troubleshooting tables), and a “why KERNEL” narrative with self-host vs KERNEL comparison. Integrations overview now points readers at Important concepts for how sections map to the stack. Four new SVG assets support those pages.

^{Reviewed by Cursor Bugbot for commit 6ca26eb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 4 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 6ca26eb. Configure here.}

[cursor]

Payments card overclaims card isolation

Medium Severity

The Payments card names Link on first mention instead of link by stripe, and says agents can check out without exposing card data. fill keeps numbers out of app and model context, not out of the browser, so this reads as a blanket PCI-out-of-scope claim.

 

^{Triggered by learned rule: Payments: link by stripe / link; no blanket PCI-out-of-scope}

^{Reviewed by Cursor Bugbot for commit 6ca26eb. Configure here.}

[cursor]

Auth card overclaims session persistence

Medium Severity

The Authentication card says managed auth will handle MFA and keep the session alive. Automatic recovery is only attempted for eligible flows, and MFA is limited: TOTP may be generated when a secret is available, while email, SMS, and other user steps still need the user.

 

^{Triggered by learned rule: Automatic reauth is a narrow promise — don't over-claim or over-narrow}

^{Reviewed by Cursor Bugbot for commit 6ca26eb. Configure here.}

[cursor]

Cloud-hypervisor GitHub link is private

Medium Severity

The intro open-source grid links github.com/kernel/cloud-hypervisor as "our fork" of Cloud Hypervisor. That repo does not appear to be publicly reachable, so the featured card 404s for readers outside the org. mint broken-links will not catch this.

 

^{Triggered by learned rule: Don't link public docs to private or internal GitHub repos}

^{Reviewed by Cursor Bugbot for commit 6ca26eb. Configure here.}

[cursor]

Why-KERNEL headings are conversational

Low Severity

New headings Why KERNEL?, What sets KERNEL apart, Why not just run Chrome yourself?, and When KERNEL isn't the answer are marketing or conversational. Docs headings are supposed to stay formal and descriptive, in the style of Why use X over Y.

Additional Locations (2)

• overview/why-kernel.mdx#L9-L10
• overview/why-kernel.mdx#L17-L18

 

^{Triggered by learned rule: Use formal, neutral tone in documentation headings}

^{Reviewed by Cursor Bugbot for commit 6ca26eb. Configure here.}

[dprevoznik]

Left a few update suggestions, but overall, LGTM - i may have some final points at the end about highlighting browser repl more, but i want to read the other PRs and get them approved first potentially.

[dprevoznik]

Though this is often a fine distinction, i don't think it's always correct that if a site has an API / MCP, the actual work that needs to be done can be accomplished with it (e.g. facebook CLI not having like count per post).

Instead, i think the distinction should be if the problem can be solved with an API or MCP lean on it, otherwise if it can't then use the browser primitive.

[dprevoznik]

Also KERNEL is useful for non-logged in websites too.

[AnnaXWang]

just my personal opinion, I don't immediately understand what this diagram is trying to explain to me

[AnnaXWang]

To me, these are "features" not "products"! Could we rename?

[AnnaXWang]

Suggested change

KERNEL is the internet runtime for agents. we provide crazy fast, open source browser infra for your agents to access and act on the internet. each chromium browser is pre-configured with anti-detection defaults, runs in its own vm with isolated resources, and can be driven with browser automation frameworks, computer controls, or cdp and webdriver bidi directly. beyond browsers, KERNEL provides a platform of capabilities so your agents have what they need on real websites: stealth and proxies, authentication, payments, live view, replays, and more.

KERNEL is the internet runtime for agents. we provide crazy fast, open source browser infra for your agents to access and act on the internet. each chromium browser is pre-configured with anti-detection defaults, runs in its own vm with isolated resources, and can be driven with browser automation frameworks, computer controls, or cdp and webdriver bidi directly. beyond browsers, KERNEL provides a platform of infrastructure primitives so your agents have what they need on real websites: stealth and proxies, authentication, payments, live view, replays, and more.

[AnnaXWang]

"infra primitives" has done well

[AnnaXWang]

i ran these pages through Gauge's GEO / clarity checker!

[AnnaXWang]

"infra primitives" has done well

[AnnaXWang]

We have the opportunity to use these docs to improve GEO as well. Kernel appears in just 1.48% of answers in Framework/SDK fit over the last 30 complete days.

Highest-impact edits

• Make the title and opening answer a specific question. “Important Concepts” gives search and answer systems little indication of what the page explains. Use a title such as “How Kernel sits between agent framework and the internet”. Open with a two-sentence definition of each layer, then explain where Kernel fits. The current description is clear but could name both terms. The clearest, most citable claim is simpler: the agent framework decides what to do; Kernel provides the browser infrastructure that executes those actions.
• Narrow “How KERNEL optimizes each piece.” Kernel integrates with models and frameworks; it does not optimize the model, system prompt, or internet itself. Rename the section “Where Kernel fits in the agent stack” and group its links under browser execution, access and authentication, observability, and scale. That would make the page easier to quote without overstating the product.
• Tighten the troubleshooting boundaries. A failed page action can come from a selector, site behavior, or browser state, not only infrastructure. Likewise, browser infrastructure helps an agent reach and interact with sites; it does not guarantee that an action “lands.” The “Which piece to change” table is the page’s best extractable asset, so precision there matters most.

[AnnaXWang]

this page is particularly excellent

Fix before publishing

• Correct the standby claim. The table says charges stop five seconds after “the last activity.” Kernel’s billing rule is five seconds after the last client disconnects. A connected client can remain billable while an agent thinks. The opening sentence should also avoid implying standby starts whenever a browser is idle.
• Qualify the benchmark and self-hosting comparisons. “Fastest browser infrastructure” exceeds the narrower claim that Kernel led the providers tested on a particular benchmark. Likewise, self-hosted Chrome does not inherently require a cold container pull, share a kernel, or leave credentials in an agent’s context. Frame those as problems a team may need to solve, not unavoidable outcomes.
• Move the clearest answer to the top. Lead with the framework distinction, then speed evidence: “Kernel provides isolated cloud browsers for AI agents. It works underneath the agent framework you already use, with managed authentication, anti-detection, and tools for running browsers at scale.” Follow with the measured latency and a linked benchmark whose test scope is explicit.
• The “Why not just run Chrome yourself?” table is the best GEO asset. Once its rows make fair, specific comparisons, it can answer several distinct evaluation questions. The final “When KERNEL isn’t the answer” section strengthens that credibility; keep it.

[AnnaXWang]

Highest-impact edits

• Add a short answer above the cards. Define Kernel as browser infrastructure for AI agents, then explain that the products cover browser execution, access to websites, authentication, and operating sessions at scale. This gives the page a self-contained answer rather than relying on card labels.
• Group the cards by the job they solve. For example, put Browsers, Pools, and Code Execution together; Stealth, Proxies, and Config Registry together; and Vaults, Authentication, and Payments together. A reader can then tell which product to investigate without scanning all 12 cards.
• Check a few precise claims. “Without your agent ever reading them,” “keep the session alive,” and “skips … the browser create rate limit” describe specific guarantees. Link each to documentation that supports the exact behavior, or narrow the wording.
• Keep the cards as navigation. Add a brief text introduction and descriptive group headings for extractability; a second full product table would mostly duplicate the directory.