hermes - 💡(How to fix) Fix Proposal: Move Hermes toward a more progressive-loading architecture (minimal startup context, upgrade-on-demand toolsets) [1 participants]

Hi team — first, Hermes is already one of the most capable general-purpose agents I’ve used. Its breadth is a real strength: rich toolsets, multi-platform gateway support, skills, memory, delegation, cron, browser, etc.

That said, I think Hermes could benefit from moving a bit further toward a progressive-loading / sparse-default architecture.

This is not a suggestion to reduce Hermes’s capabilities or turn it into a minimal-only agent. Rather, the goal would be:

Keep the full capability surface, but reduce how much of it is exposed / injected by default at the start of a session.

Why this may be worth exploring

As Hermes grows, there are two costs that seem increasingly important:

1. Default prompt/tooling cost

   • even small tasks inherit a fairly large capability surface
   • tool schemas, skill metadata, context files, memory, and routing instructions all contribute to startup overhead

2. Tool-selection ambiguity

   • when many tools are visible, the model has more opportunities to choose a suboptimal one
   • for simple tasks, a narrower initial action space may improve consistency

I think Hermes already has many of the building blocks needed to address this:

• toolsets
• skills with explicit loading
• memory + session search
• context compression
• delegation
• cron
• browser/file/terminal separation

So this feels less like a new subsystem and more like a refinement of default loading strategy.

Proposal

1) Session-scoped minimal toolset bootstrapping

At session start, expose only the smallest toolset likely needed for the task domain.

For example:

• coding / repo inspection
  • file + terminal
• web research
  • web
• browser automation
  • browser
• long-running automation
  • cronjob
• planning / multi-step execution
  • todo (+ maybe delegate_task only when warranted)

The important part is: do not remove tools globally — only minimize what is exposed initially.

2) Upgrade-on-demand toolset expansion

Minimal startup only works if the agent can expand capabilities when needed.

Example flow:

• session starts with file + terminal
• task evolves and requires browser interaction
• Hermes expands to include browser
• later the task needs scheduled follow-up
• Hermes expands to include cronjob

This would avoid the failure mode of “minimalism by deprivation.”

A progressive capability model seems safer than either:

• always exposing everything, or
• aggressively hard-limiting the session forever

3) Make skills/memory even more index-first

Hermes already supports on-demand skill loading, which is great.

A possible next step:

• keep an ultra-light always-on routing index
• only load detailed skill text when relevant
• optionally narrow visible skill metadata to the current task domain

In other words:

• index always on
• details only on demand

This same principle could apply to memory and project context as well.

4) Split prompt/context into layers

A possible architecture:

Layer A: always-on core

Only the essentials:

• safety rules
• tool-use discipline
• platform context
• high-value user preferences

Layer B: routing layer

Small task-relevant hints:

• likely task domain
• relevant skill index entries
• compact project/context summary

Layer C: load-on-demand detail

Only loaded when required:

• full skill bodies
• long project docs
• large context files
• historical transcripts
• deep environment notes

This could preserve Hermes’s richness while making the default active context much sparser.

5) Add prompt/context cost diagnostics

It would be very useful to expose approximate attribution such as:

• tool schema cost
• skills metadata cost
• memory/user-profile cost
• context-file cost
• total always-on vs on-demand budget

Without visibility, it’s hard to know where Hermes is actually “heavy.”

A diagnostics view could help both users and maintainers answer:

• why is this session expensive?
• what is always loaded?
• what should be moved behind on-demand loading?

What I am not suggesting

To be clear, this is not a request to:

• reduce Hermes to ~9 tools
• remove rich platform/tool support
• replace Hermes’s architecture with another agent’s architecture wholesale
• discard skills/memory/session search in favor of a minimal-only design

Hermes’s breadth is valuable. The suggestion is only to make the default active surface smaller and more progressively expandable.

Why this seems aligned with Hermes specifically

Hermes is already unusually close to supporting this well because it already has:

• explicit toolsets
• strong separation between tool domains
• explicit skill loading primitives
• memory/session retrieval mechanisms
• compression infrastructure
• delegation

So the main opportunity seems architectural, not capability-related:

shift from “broad by default” toward “broad in reserve, sparse in the active context.”

Possible implementation path

A gradual rollout could look like:

Phase 1

• add context/prompt attribution diagnostics
• add task-domain recommendation for initial toolsets

Phase 2

• reduce always-on skill/memory metadata
• introduce a lighter routing index layer

Phase 3

• support upgrade-on-demand toolset expansion during a session
• move toward truly progressive context assembly

This would make the idea testable in stages without destabilizing the current UX.

Expected benefits

If done well, this could improve:

• lower startup prompt cost
• lower tool-selection ambiguity
• better small/medium task efficiency
• better scalability as more tools/skills/context sources are added
• clearer mental model of what Hermes is actively loading vs merely capable of loading

Thanks again for building Hermes — this suggestion comes from liking the current system a lot and thinking it may be able to get the best of both worlds: rich capability surface + sparse default runtime footprint.