The final piece of the puzzle

Once you understand the loop, tools, memory, skills, subagents, and cron, there is still one system question left:

how do all of these capabilities actually meet users?

That answer lives in the surfaces:

• CLI
• TUI
• gateway adapters
• ACP integrations

Why this matters architecturally

Many agent projects are trapped inside one shell:

• they are only a CLI
• or only a chat bot
• or only an editor integration

Hermes is trying to avoid that trap by keeping the runtime reusable while letting surfaces specialize for user context.

Surface-specific logic should stay surface-specific

A mature architecture keeps these concerns separate:

• rendering and interaction models in the surface
• session, tools, and execution in the runtime
• durable state in the lower layers

If you let UI needs directly mutate the loop, every surface becomes a fork of the agent system.

Hermes is not perfect, but its intent is clear: one runtime, many shells.

The broader design lesson

This is the final reason Hermes is worth studying:

it is not only a codebase about model calls.
It is a codebase about turning an agent runtime into a reusable product substrate.

That requires:

• separation of product shell and execution engine
• stable contracts between layers
• durable state beneath temporary surfaces

A final mental summary

If you had to summarize Hermes after reading this site, a good answer would be:

Hermes is a layered agent platform that treats execution, capabilities, memory, procedure, delegation, and autonomy as distinct runtime concerns, then exposes them through multiple user-facing surfaces.

That sentence captures the architecture better than any single function body.