Profile Inheritance — Base/Profile Layering for Hermes Agent

Date: 2026-05-09 Status: Feature Proposal

1. Problem

When a user creates a second profile with hermes profile create, the new profile starts as an independent blank copy. It does not inherit:

• The user's SOUL.md operating contract (communication rules, autonomy boundaries)
• Custom skills built in the original profile
• Toolchain configuration (model routing preferences, shell init files, command compression)
• Efficiency settings (routing, compression layers)

Every capability built in one profile must be manually replicated to others. This breaks the moment a single user runs more than one profile.

Root cause: The profile system treats profiles as fully independent instances. But a single user's profiles are not independent — they share tooling, rules, and operational preferences that should only be configured once.

2. The Three-Layer Model

A user's Hermes environment naturally divides into three layers:

Layer 1: Base — Shared by All Profiles

Universal infrastructure. Configured once, inherited everywhere:

Layer 2: Hybrid — Mechanism Shared, Instance Per Profile

The engine is shared; what runs on it differs:

Layer 3: Profile — Domain-Specific

Bound to what that profile does. Sales profile has client configs and PPT templates. Fitness profile has training data and workout plans. These should never leak between profiles.

The decision rule: "Whose problem does this solve?" → Not bound to any profile → Base → Bound to a specific profile → Profile → Unclear → The capability isn't thought through yet

3. What This Looks Like in Practice

We validated this model by manually wiring base-layer inheritance between two profiles. Here's what worked:

SOUL.md via symlink:

~/.hermes/profiles/<name>/SOUL.md → ~/.hermes/SOUL.md

One file. Modify once. All profiles see changes instantly.

Shell init inherited: The base profile's BASH_ENV (pointing to command compression wrappers) added to each new profile's launchd/systemd config automatically.

Base skills copied on creation: Infrastructure skills (troubleshooting, orchestration) copied to new profiles at creation time.

Facility registry: A classification file (facts/facility-classification.yaml) tracks which layer each capability belongs to, consulted before any new capability is built.

4. Proposed Implementation

Minimum Viable

1. hermes profile create inherits from base, not blank template. New profiles automatically get:

   • Symlink to base SOUL.md
   • Base BASH_ENV / shell init
   • Base skills (configurable which subset)
   • Base config defaults (efficiency routing on, etc.)

2. Base facility directory — ~/.hermes/base/ containing:

   • SOUL.md (single source of truth)
   • Shell init scripts
   • Base skills subset
   • Facility classification registry

3. Profile creation gate — hermes profile create asks for a domain description before proceeding. No description, no profile.

Future

• Skill layering: hermes skill create --base vs --profile to mark layer
• Profile lineage: Track which profile spawned from which, enabling merge-back of improvements
• Cron templates: Base cron job templates that profiles instantiate with their own delivery targets

5. Why This Matters

The current "isolated copies" model has a linear maintenance cost: N profiles = N × (fixes + updates). The base/profile model makes profile count irrelevant. Fix once, propagate everywhere. The user focuses on domain work, not infrastructure synchronization.

Profiles are not independent agents. They are views into the same operator's toolkit, specialized by domain.