hermes - 💡(How to fix) Fix [Feature]: Tiered Memory Storage Architecture — Replace flat memory with 4-layer storage

Problem or Use Case

The current memory tool has a ~2200 character limit. Agents naturally dump everything into it — project configs, position data, workflow details, user preferences, version histories — all mixed together. This leads to:

1. Memory fills up fast (hitting 99% regularly)
2. Hard to update (needs exact string matching for replace)
3. Hard to find (behavior rules mixed with technical configs)
4. Wastes tokens (full memory injected every turn even when most is irrelevant)

When memory is full, agents start forgetting things they were explicitly told. For users running complex workflows (trading systems, multi-project management, CI/CD pipelines), this is a critical limitation.

Proposed Solution

Instead of treating memory as the only persistent storage, adopt a tiered architecture with 4 layers:

Layer 0: Root Index File (~/.hermes/index.json)

A single JSON file that maps all active projects to their storage locations. Agents only need one memory entry: "project index → ~/.hermes/index.json".

Layer 1: Project Files (Data Layer)

• Structured data (positions, configs, output data)
• Scripts and automation
• No character limit, direct read/write via terminal/execute_code

Layer 2: Skills (Logic Layer)

• Reusable workflows and procedures
• Configuration parameters and version histories
• Managed via skill_manage

Layer 3: Memory (Index + Rules Layer)

• Only two types of content: a) Global behavior rules — user preferences, communication style, dos/donts b) One pointer to the root index file
• NOT for: detailed data, workflow steps, version histories

Layer 4: session_search (Fallback)

• Full-text search across past conversation sessions
• Last resort when above layers don't have the answer

Implementation suggestions:

• Add a memory quota warning when usage exceeds 80%
• Document this tiered approach as a best practice in Hermes docs
• Optionally ship a default ~/.hermes/index.json template
• Update the memory tool's system prompt to explicitly recommend project files over memory for large data

Alternatives Considered

1. Expand memory limit — Simpler but doesn't solve the "everything mixed together" problem; still wastes tokens per turn.
2. Use a single universal approach — What agents do today (cram everything into memory). It has already been proven to fail at scale.
3. Database backend (SQLite) — More powerful but more complex to ship and maintain. The tiered approach uses existing infrastructure (file system + skills + memory) without new dependencies.

Feature Type

Performance / reliability

Scope

Small (single file, < 50 lines)

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)