Context Composition Comparison — Reference Projects vs. Us (organized by the three layers)#

This document compares the context components that reference projects feed to the LLM against our L0/L1/L2 design, laid out layer by layer. It is a comparison; the design itself lives in composition.md.

Hermes is also three-layered, partitioned by stability — the same organizing principle as our L0/L1/L2. It calls the layers stable / context / volatile:

• stable = identity + tool guidance + skills + model/platform/environment hints → our L0
• context = caller system_message + context files (AGENTS.md, etc.) → our L1 project layer
• volatile= memory snapshot + USER.md + external memory → our L1 project memory / L2

The other projects (opencode / claude-code / openclaw / pi-mono) each carry fewer context components than Hermes, on par with us or fewer.

Legend: ✓=present, -=absent, △=present but scattered, not assigned to a layer.

Within a layer, components are also ordered by stability: more stable goes first, more frequently changing goes last, because cache-prefix matching makes intra-layer order matter too. The # column in each table below is the wire order from front to back within that layer. Per-turn-appended content such as history goes at the end of its layer. The ordering follows Hermes's stable_parts append order plus our caching principle.

L0 System level (configured once, never changes)#

Intra-layer order: identity (most stable) → guidance blocks → tools/skills → environment info (relatively more variable, goes later).

Ordering rationale: identity/guidance/tools are configured once and never touched, so they go first; environment info (OS/backend/date), although also stable across a whole session, is closer to changing than identity — it changes when you switch machines or when the day rolls over — so it goes at the end of L0.

L1 Session/project level (follows the project/session, variable)#

Intra-layer order: fixed project info (changes only when you switch projects, most stable) → session bindings → security detection → history (appended per turn, last).

Ordering rationale: fixed project info (AGENTS.md / project memory / USER.md / cwd / bindings) changes only when you switch projects, so it goes first; history is appended every turn, is the least stable, and goes at the end of L1. Injection detection and the truncation policy sit right next to the project files they guard, so 2 and 3 follow 1.

L2 Task level (used once then discarded, this turn)#

Intra-layer order: this turn's situation/environment (relatively stable) → this turn's input → this turn's output spec → timestamp (very last).

Ordering rationale: situation/environment/todo are this-turn but relatively settled, so they go first; user input and output spec are in the middle; the timestamp changes every time, so it goes very last.

Components we do not carry#

These components exist in a reference project but have no counterpart here, because we have no corresponding feature: computer-use guidance, Nous subscription guidance, Kanban multi-agent coordination, the Hermes profile mechanism, and the external memory provider. The registration model in composition.md leaves a slot for each — building the feature means registering one ContextComponent, with no framework change.

Also absent: the token budget hint, which no reference project carries either.