A placement for Hermes Browser Extension inside the Core & Edges plan — grounded in the draft map's own rules, and in code that is already on origin/main.
The map's own core test decides it. Run in order, the first yes wins — and it wins three different ways, because Hermes Browser Extension is three different things.
The map's Surfaces layer is "how people reach the agent": CLI, Ink TUI, Desktop app, Dashboard, API server, webhook, Bot Mode. Hermes Browser Extension is exactly that — a full client for the agent, living where the user already works. Surfaces are core by the map's own ledger. The extension never enters the Python tree, so it costs the core zero lines.
Under it, two small edges. The controller lane — the part that lets the agent drive the user's real tabs — is the browser half of a ruling Teknium already made on 27 Sep: browser, local and on by default. The companion plugin is the opposite shape: optional, fail-soft, and it should leave core entirely.
Why not vendor: rule ii says the vendor owns the vendor's integration — and the vendor here is Nous. There is no other company whose product this is. Why not community: a community entry has no corporate owner and no support commitment. A surface people reach the agent through cannot be adopt-a-plugin.
Every third-party integration in the tree, placed by the draft map's own proposal — category by sector, proposed home by ring. Solid dots are still wired into core; hollow ones are already plugins. The gold star is where Hermes Browser Extension's controller lane lands: the browser sector, happy-path ring, beside the Browser Use CLI and Chromium — both already ruled core.
Hover any dot. Data transcribed from the draft map, re-scanned against origin/main ac9a850 on 27 Sep 2026. The star is the only mark this proposal adds.
The map draws five homes. Hermes Browser Extension touches three of them — and the split is the whole argument.
Loop, prompt, tools, state, config, security, plugin host. Never a plugin. Surfaces live here too: CLI, TUI, Desktop, Dashboard.
What most users hit in session one, on by default. Nous Portal, the big model routes, the big chat apps, a keyless web and voice path.
Own repo, one click from setup. For what is strategic but not for everyone: hyperscalers, open protocols, power-user modes.
When a company ships the product, it maintains the plugin in its own org. Nous keeps official plugins only where no vendor will.
No corporate owner; catalog plus adopt-a-plugin. Fine for niche engines and one-off skills. Not for a way people reach the agent.
The placement asks for nothing the architecture doesn't already do. The controller lane is on origin/main today, written against the map's own rules.
Authored by abundantbeing and landed via PR #91535. Routes the existing browser_* tools — no new tool schema, no new names in the core tool list. That is rule v, one source of truth, already satisfied.
This is the one ask that touches core, and it is a security improvement on an open port rather than a feature. Everything else in this proposal lives outside the Python tree.
Repo figures from the GitHub API and extension repo (v0.3.4), Oct 2026. Tests cover the extension repo only; the seven controller-lane modules live in the hermes-agent repo.
The map's section 05 keeps the Browser Use CLI as the default driver and moves agent-browser out to an optional browser-classic plugin. Hermes Browser Extension doesn't disturb that. It joins the router as a second lane — the user's own browser, with their sessions, behind one approval.
A full client, not a toolbar. Side panel over the page you're on, Bot Mode group chats across the agent roster, Hermes Assist drafting beside text fields, file attachments, voice, 21 locales. It speaks the gateway's existing API — sessions, runs, models, skills — so it inherits whatever the core becomes.
No silent capture. Page context is opt-in per connection, and remote or chat-only sessions never capture it. No credential handling — the vault work stays in core where the map put it. No second tool schema. When the extension isn't connected, every path reports unavailable and the agent carries on.
The map's rule iii: a category may only shed members after its seam exists and the built-ins go through it. Hermes Browser Extension was built against the seams that exist, and it needs exactly one that doesn't.
| Seam | State | What Hermes Browser Extension does with it |
|---|---|---|
Cloud browsersregister_browser_provider | Extend · P2 | The map's own pluggability audit says this seam covers cloud browsers only, and lists extending it to local engines as the fix. The extension lane is that local engine. The router already behaves like the seam; registering it makes the seam honest. |
Toolsctx.register_tool | Exists | The companion registers seven tools here. All fail-soft. None are kernel tools, so none belong in _HERMES_CORE_TOOLS — which is the map's stated end state for that list. |
Hookspre_llm_call | Exists | The companion lifts browser context out of the prompt here. Context stays untrusted data, never instruction. |
Skillsregister_skill | Exists | The hermes-browser skill ships inside the companion and teaches the agent when the tools are worth calling. |
| Desktop UI plugin contributions | Exists | 84 desktop catalog entries already. Browser control status and pairing approval render as contributions, not as forks of the Desktop app. |
| Credential vault local Fernet store | Stays core | Untouched. The map keeps the local vault in core and moves 1Password and Bitwarden out to an official plugin. The extension never holds a credential. |
| Setup / tools UX generic setup contract | Missing · P0 | The map flags this as the blocker for every extraction: once plugins declare their own config, hermes setup, hermes tools and the Desktop pickers must render it with first-party polish. The extension's connect flow is the first real client of that contract — so it funds the enabler instead of routing around it. |
Seam states and priorities transcribed from the draft map's pluggability audit. P0 = the map's own "fund before anything else leaves" tier.
The map sequences six waves, memory first, each with an exit you can check in the tree. Hermes Browser Extension doesn't insert a wave. It attaches to four that exist — and it can fund the one the map says to fund before anything else leaves.
Generic left-core migrator, plugin-declared config rendered with first-party polish, one source of truth for providers. The map says fund this before anything else leaves core.
Vendor tools left behind in core move into the plugins that already own them. Exit: deleting a plugin directory deletes the integration everywhere.
Browser Use CLI becomes the driver, Chromium ships through the package manager, agent-browser retires to browser-classic. Three PRs, each with a testable exit.
Kanban, MoA, pets, the local runtime and research tooling move to official repos. The companion plugin is the same shape and ships in the same wave.
Chrome Web Store and Firefox AMO listings, owned by Nous, versioned with the agent. The extension repo stays standalone — store review cycles don't gate agent releases.
No bundled Chromium of our own. No second browser tool schema. No credential storage. No default-on page capture. No fork of the Desktop app.
Providers move to their creators' repos, catalog-listed, auto-migrated. The companion follows the same shape: maintainer-owned, catalog-listed, gone without a trace.
Browser Use CLI is the preferred driver. Chromium ships through the package manager. The extension is the other local browser — the user's own — behind the same router.
cua-driver is the only OS path to computer use, and it stays core. The extension never touches that path. Tab control is not desktop control, and the line should stay sharp.
Adopt the three-ring placement: surface beside Desktop, controller lane on the happy path, companion as an official plugin. Say it in the map so the next pass counts it.
Review PR #88203. It's the only core change, it's loopback-only, and it removes a reason to share the raw API key.
Transfer the repo to the Nous org, or keep the current maintainer under a written agreement. Maintenance continues either way — the catalog needs an owner of record.
One catalog entry, one setup line, store listings under the Nous name. Rule iv: no UX regression. Connecting should feel like the Desktop app, not a sideload.
Bundling and packaging less things with the core agent, more plugins, leaner core. Not that we're not trying to be a personal assistant agent.
Hermes Browser Extension is that sentence in product form. The core stays lean because the surface lives in its own repo, the plugin stays optional because it fails soft, and the agent becomes more of a personal assistant because it can finally see the page its user is looking at — with permission, and only then.
Key architectural decisions to settle during the technical review to align the browser surface with the core roadmap and upcoming unified gateway.
Context: Determines whether Desktop's proven model (core surface app + cataloged plugins) serves as the standard template for client surfaces.
Context: Evaluates day-one setup friction versus explicit user consent. The existing router supports either behavior without modification.
Context: Clarifies preference between formal organization repository ownership versus an official catalog listing with a dedicated maintainer.
Context: Ensures alignment with upcoming unified gateway API authentication plans so the scoped pairing handshake converges seamlessly.
Context: Addresses official publisher credentials and whether extension signing should gate on core agent releases or follow an independent cadence.
Context: Determines whether the browser extension's connection flow can serve as the first production implementation of the generic setup contract.
Every figure in this deck is verified against the draft map's data, the hermes-agent tree at origin/main, and the extension repository. Controller lane verified on origin/main as of October 2026: broker, router, seven test modules, extension_control defaulting off. Pairing verified as PR #88203 (open, unmerged). Stars, forks, and contributor counts verified via the GitHub API for Hermes Browser Extension v0.3.4. Designed to adapt cleanly to the unified gateway specifications.