Hermes proposes onboarding that waits for real app authorization instead of talking around it

Hermes' Desktop onboarding proposal addresses a product problem that a conversational installer can create for itself: the agent keeps talking while the person is trying to authorize an app, or invents a workaround when that app is not connected. PR #108292 puts the authorization card in charge of that moment and makes the agent wait for the actual connection outcome.

The facts

- The guided onboarding work is behind HERMES_GUEST_ONBOARDING=1; the proposed connector-card behavior also applies to ordinary manage_connections calls. - Connect opens a browser authorization and tells the agent to wait on that connector rather than create a second link that cancels the first. - A successful connector card stays visible with a Connected indicator, while the MCP variant retains its compact settled presentation. - The connector picker reads the live gateway catalog instead of offering hardcoded or misspelled app identifiers; an unavailable catalog offers Skip. - The proposed prompts check status, batch requested connections and explicitly prohibit routing around an app the user declined. - The build handoff checks actual connection status, and a first task must be finishable without the selected apps rather than pretending none were connected.

Why it matters

Natural-language setup can conceal state as easily as it can simplify it. A fluent answer about Gmail is not an authorized Gmail connection, and another generated sign-in link may invalidate the one a user is already completing. Making the agent pause is therefore a capability improvement, not an interruption to the demo. The same principle applies to onboarding menus: a live catalog can honestly say what the backend supports, whereas a polished static list can promise integrations that do not exist.

Current

Inspected on 2026-09-12. The Hermes Agent release baseline is v2026.9.11 published 2026-09-11T19:20:31Z. The main source was open (not merged) when captured. Proposals, merged mainline changes and packaged releases are different availability states; the linked release baseline does not imply that open proposals have shipped.

Evidence

Primary evidence: NousResearch/hermes-agent PR #108292 (https://github.com/NousResearch/hermes-agent/pull/108292). Supporting context: Hermes — official product documentation (https://hermes-agent.nousresearch.com/docs/); Hermes Agent — official product README (https://raw.githubusercontent.com/NousResearch/hermes-agent/main/README.md). Sources were read directly through public pages or GitHub API bodies. Contributor test results are attributed claims, not independently reproduced results.

Operator take

Judge the proposed first-run experience by transitions rather than screenshots alone. A useful rehearsal starts with a fresh profile, requests two apps, connects one, declines the other and verifies that later work respects both decisions. Relaunching mid-guide should resume the guide rather than strand the user inside a normal shell with setup still incomplete. The contributor reports an isolated Desktop harness and a live Gmail authorization on macOS, along with focused test suites. That is evidence of the author's rehearsal, not an authorization or account connection performed by this newsroom.

Caveat

The proposal was open when inspected, and flag-gated onboarding copy is not proof that every hosted entitlement or free-tier path is publicly available. Existing documentation and the README establish the broader product, not the proposed behavior. No credentials were read or app grants changed during this curation run.