Hermes Runtime
Hermes coordinates a loop: it loads one isolated profile, assembles approved context, asks a replaceable model to reason, follows the relevant skill, invokes only allowed tools, and verifies the result. Sessions preserve conversation continuity; compression preserves important decisions near context limits; checkpoints support rollback after file changes.
Separate configuration, memory, sessions, and skills by role or trust boundary.
Start with identity, privacy, and one task map instead of scanning everything.
Load the skill whose trigger matches the task before choosing commands.
Use the smallest tool surface and explicit target needed for the operation.
Read back the result, report evidence, then route durable knowledge to the correct layer.
Runtime responsibilities
| Layer | Owns | Must not become |
|---|---|---|
| Profile | Configuration and isolation | A shared secret dump |
| Session | Conversation continuity | Canonical project truth |
| Compression | Preserved decisions and constraints | An invented summary |
| Checkpoint | Recoverable file state | Proof the application works |
| Memory | Compact stable facts | Task-progress storage |
What breaks—and how to recover.
Reload canonical maps and cite the selected sources.
Require read-back, runtime smoke, or user-facing evidence.
Keep profile homes isolated and never write across them without explicit approval.
Copyable implementation prompt
Design a Hermes runtime for [WORKFLOW]. Define profile isolation, startup context, model policy, required skill, allowed tools, session handling, compression rules, checkpoints, approvals, evidence, and durable capture. Use placeholders and verify every state-changing step.
Use placeholders for paths, accounts, endpoints, identities, and credentials. Never publish secret values, private records, or a live control surface.
Verification gate
- Profile boundary is explicit
- Context sources are named and minimal
- Tool permissions match the task
- A rollback path exists
- Completion requires direct evidence