#749: design(profile): align Web UI profile management with Hermes runtime model

Summary

Hermes Web UI profile management appears to be treating profile as a lightweight UI switcher, but in Hermes Agent a profile is much heavier: it governs config, env/API keys, sessions, memory, skills, cron jobs, workspace/state, and gateway-scoped runtime state.

That mismatch is now surfacing as a cluster of confusing UX and state-model problems across multiple tabs, not just in the Profiles panel itself.

This issue is intended as a runtime-model / UX-alignment issue, not a request to preempt or replace ongoing sidebar redesign work. The goal is to make sure future design and implementation reflect the actual Hermes profile model clearly.

Confirmed Runtime Model

flowchart TD
    P["Profile (Hermes home)"]
    C["Config / .env / SOUL"]
    S["Sessions"]
    M["Memory"]
    K["Skills"]
    J["Cron jobs"]
    G["Gateway runtime"]
    D["Scheduled execution / messaging delivery"]

    P --> C
    P --> S
    P --> M
    P --> K
    P --> J
    P --> G
    G --> D

Capability Matrix

Area	Profile-scoped	Requires gateway to be running
Config / API keys / env	Yes	No
Sessions	Yes	No
Memory	Yes	No
Skills	Yes	No
Cron configuration	Yes	No
Cron scheduled execution	Yes	Yes
Messaging / proactive delivery	Yes	Yes
Gateway status	Yes	N/A

Why This Is Confusing Today

1. Profile creation UI is misleading

The creation form currently emphasizes fields like Base URL, API key, and Clone config from active profile, which makes profiles look like model/API presets.

But in Hermes Agent, a profile is a full isolated Hermes home, not just a transport/config override.

2. ACTIVE and the green gateway dot are easy to misread as the same state

The current UI can legitimately show:

• profile work as ACTIVE
• the green dot on default

That is technically possible because these represent different things:

• ACTIVE = current Web UI active profile
• green dot = that profile's gateway process is running

But the UI presents them close enough that users naturally read them as contradictory.

3. Switching profiles can make sessions appear to "disappear"

When switching into a fresh profile, the session list can become empty even though the switch was successful. The sidebar may still indicate that sessions exist in other profiles, but the reason is not explained clearly.

4. Cron is configurable even when its full runtime path is not available

The Cron tab currently allows creating, editing, pausing, resuming, and manually running jobs.

However, scheduled execution and some delivery behavior depend on a running gateway. That dependency is not made explicit in the UI, so users can reasonably assume “if I can configure cron here, it should just run.”

5. The profile model affects multiple tabs, but that dependency graph is invisible

This is not only a Profiles-panel issue. The same hidden model shows up in:

• Profiles
• Sessions
• Cron
• any gateway-dependent delivery or messaging behavior

Existing Related Issues / PRs

• #617 — per-job profile selector for scheduled jobs
• #637 — deleting a profile with existing sessions should warn more clearly
• #736 — current PR follow-up on the deletion warning path

This issue is intentionally broader than those narrower fixes.

Discussion Questions

These are the main design questions that need alignment before piecemeal fixes accumulate further complexity:

1. Should gateway state be shown in the primary profile card at all?
2. If shown, should gateway runtime state be demoted to a secondary detail layer instead of the main identity row?
3. Should the profile creation UI be reframed around isolated Hermes state, with model/API fields treated as secondary configuration rather than the primary mental model?
4. Should Cron UI distinguish between:
   • configuration available
   • manual execution available
   • fully enabled scheduled execution depending on gateway/runtime state?
5. Should the Sessions UI explain more explicitly when the active profile changed successfully but has no sessions of its own yet?
6. Should profile management in Web UI be treated as an alignment problem first, and only then as a redesign problem if alignment alone is not enough?

Intent

The intent here is not to prescribe a final visual design up front.

The intent is to establish the correct runtime model and UX constraints so that future profile-related work — including any broader sidebar or settings redesign — addresses the real Hermes semantics instead of layering more local fixes on top of a misleading mental model.