Skip to content

O04 — HP client and Node/browser hosts

Status: design stub. Back to the component map.

Purpose

Expose one HP agent implementation through browser- and Node-usable client APIs. Make its host and tool capabilities clear without creating separate agent semantics for each environment.

Existing foundation

The HP findings, parity pass and work integration describe the shared research core and actual Node/Chrome checks.

Proposed boundary

A subagent is another async agent execution, not inherently an OS subprocess. Browser-owned agents depend on their page/Worker host lifetime. Native files/processes require a Node or remote adapter. The research protocol implements selected Codex shapes plus explicit HP extensions, not full compatibility.

Inputs and outputs: An injected transport/runtime owner and host tool set → threads, turns, child control, jobs and retained observations.

Candidate progression

  • Mock: A browser-session-local facilitation/test agent alongside a Node-hosted agent, with different tool sets and clearly different ownership; no remote administration of the browser agent.
  • First usable slice: Extract only the client/runtime boundary needed by a real session view, and run its public client code in Node and Chrome.
  • Later: Add reusable host services, richer tool discovery and deliberately scoped persistence; keep cross-provider delegation separate from HP-native spawning.

These are discussion candidates, not scheduled work or implemented capabilities.

Recorded review — 19 October 2026

Initially, browser HP agents run inside the overview application to test local facilitation and later reusable AIUI components. They belong to that browser session, use a smaller application-supplied tool set, and are not administered by the remote host coordinator. Do not implicitly share them across tabs or grant native filesystem/process tools.

Node HP remains a host-managed runtime. Browser model/credential connectivity and optional session-log export do not make the browser runtime remotely owned. Local history is the starting recovery direction; reload behaviour and any future same-browser coordination still need discussion before implementation. Do not infer an account-wide or machine-wide browser-agent identity.

Your additions

  • Where should locally hosted browser agents appear in the host/agent overview? For now, as we're moving along this project, the locally hosted browser agents would be things that are running in the Overview application itself. It's a very strange application in a sense. It's mostly for testing for now. What will happen is that locally hosted browser agents shouldn't be actually administered by a remote orchestrator. They're really meant to be only for that specific browser session, not connected to a server, not shared across multiple browser tabs, etc. They're meant for very quick user facilitation, but to test that, what we can have is browser-based agents that run in the host UI that we're creating, just for the purposes of testing that interaction. That makes sense.

I think this is something that would be important to understand: those agents would have much fewer tool calls. They wouldn't be able to hit the file system, etc. They'd be sort of geared towards a static website, but it's useful to have them running in the host application just as a way of testing out the functionality. Eventually, what will happen is that bits and pieces of the host UI will be taken out and made standalone and be easy to integrate into AI UI apps, and there they would run various agents. In the browser

  • What should happen when navigating away, reloading the page or closing the app? In general, we should try to just rely on local history alone and then just do the best thing possible, but it's unclear. What do you do when you have two tabs open on the same website, and how do you distinguish? How do you want that behavior to work?

It's unclear, but the browser-based tabs are meant to be not connected to a central server, except for maybe storing their session logs and so forth. The way I'd say it is, if you think about how WebRTC is meant to work in our infrastructure, it's really meant to be peer-to-peer. Here, the idea is that the agent is very much tied to specific browser tabs, session, or maybe a specific browser, and coordinated across tabs. I'm not sure, but at most, that is not user-based or host-session-based or what have you. Again, we still need to work out the details, though.

Additional requirements, examples and decisions: TBD with you.