feat: One gateway for multiple agent profiles. - #24914
Conversation
teknium1
left a comment
There was a problem hiding this comment.
Thanks for the substantial multi-profile gateway prototype. Current main now has an opt-in one-process multiplexer, but it deliberately uses per-profile adapters and credentials (website/docs/user-guide/multi-profile-gateways.md:59-104, :158-165), so this PR's same-token chat-routing goal remains distinct rather than redundant.
Problems
- The new
agent_home_scopeonly redirectsget_hermes_home()(gateway/run.py, PR executor-scope hunk). It does not install a profile secret scope. Current multiplexing couples the home override withset_secret_scope(build_profile_secret_scope(...))ingateway/run.py:1413-1444; without equivalent coverage, a routed profile can resolve host-process credentials. gateway.show_agent_nameis introduced as a user-facing setting but is not added to the normal defaults documented inhermes_cli/config.py:2843-2875.- The branch predates current profile attribution and multiplexing seams:
gateway/session.py:850-883now owns profile session namespaces, whilegateway/run.py:16825-16869scopes a routed source's whole agent turn. This needs a design-level rework rather than a mechanical salvage.
Suggested changes
- Rebuild the same-token route against the current profile-runtime and credential-scope seams, and retain the default
agent:maincompatibility contract. - Add the response-label setting through
DEFAULT_CONFIGand docs if retained.
Automated hermes-sweeper review.
| # copied context — setting it in the async frame here would | ||
| # leak past _run_agent's return, since the awaiting coroutine | ||
| # and the executor share the same logical context until the | ||
| # next copy_context() boundary. |
There was a problem hiding this comment.
agent_home_scope changes only path resolution. It does not scope profile credentials; current multiplexing pairs the home override with set_secret_scope(build_profile_secret_scope(...)) in gateway/run.py:1413-1444. Please make the routed-turn scope cover secrets too, otherwise a selected profile can resolve host-process credentials.
What does this PR do?
Lets a single gateway process serve multiple Hermes profiles as switchable agents — instead of needing one gateway per profile bound to a separate platform credential.
User-facing surface
/profile/profile ls/profile codercoderprofile (persisted)/profile default@coder fix bugcoder; binding intact[<agent>], toggleable viagateway.show_agent_nameIsolation guarantees
~/.hermes/profiles/<name>/layout)(chat, agent)pair has its ownsession_id— switching back to a previously-used agent resumes its own conversation, no leakage from other agentsMechanism
HERMES_HOMEbecomes aContextVar;get_hermes_home()consults it first → per-turn agent swap with no env-var rebind_run_agentwraps the executor inagent_home_scope(<agent.home>)so AIAgent construction + run-conversation see the right pathsbuild_session_keytakesagent_name→(chat, agent)pairs get distinct session_keys → distinct transcripts; chat bindings persist tosessions/chat_bindings.jsondefaultagent keeps the legacyagent:main:...prefix → zero migration for existingstate.db/sessions.jsonDetails see #24913
Related Issue
Fixes #24913
Type of Change
Changes Made
How to Test
Checklist
Code
fix(scope):,feat(scope):, etc.)pytest tests/ -qand all tests passDocumentation & Housekeeping
docs/, docstrings) — or N/Acli-config.yaml.exampleif I added/changed config keys — or N/ACONTRIBUTING.mdorAGENTS.mdif I changed architecture or workflows — or N/AFor New Skills
hermes --toolsets skills -q "Use the X skill to do Y"Screenshots / Logs