01 / Routing Layer

Work Routing

A request does not just become an answer. It becomes a route. The first decision Hermes makes is not only "what should I say?" but "what kind of work is this?" A short message might stay inside a normal answer. A fuzzy product request might become a deep interview. A bug report might become feedback triage, an investigation plan, and then a coding-agent handoff. A recurring research request might become scheduled ops. That routing behavior is the difference between a chat bot and an agentic operating surface.

The easiest mistake is to reduce this to the terminal command that happens to launch it. Hermes can be entered through a TUI, a CLI, a gateway, or platform adapters. Telegram, Discord, Slack, WhatsApp, Signal, email, Matrix, and webhooks are not separate product stories; they are different doors into the same work loop. The important question is whether Hermes can preserve the thread, user, delivery target, privacy policy, and tool boundary after the message arrives.

Routing is not a separate marketing feature. It is the first architectural pressure point. If Hermes loses the source channel, target thread, permission boundary, or delivery context, the rest of the work becomes ambiguous. A good route keeps the human request tied to the surface it came from and the evidence it can later return.

The anatomy is layered: surface, prompt context, agent loop, memory, skills, extension ports, and evidence boundary. Each layer answers a different question before the agent claims work was done.

02 / Prompt Context

Prompt Builder

The prompt builder is the architecture's throat. It is where a surface message becomes an agent request with identity, files, skills, memory hints, platform context, safety constraints, and tool availability. In OMH, that prompt-builder responsibility is expressed through src/routing/recommend.py, src/routing/chat.py, and src/wrapper/contract.py: they decide which route, visible action, state, and evidence boundary travel with the user's intent.

In practical terms, this means Hermes can answer differently when the same sentence arrives from a local terminal, a Discord thread, a scheduled job, or a repository-connected work session. The message "prepare this for review" is not complete by itself. The useful prompt includes who asked, what thread they are in, which skills are installed, which memories are relevant, which tools are allowed, and whether a wrapper can later record dispatch, execution, verification, review, CI, or delivery.

That makes prompt building less like text templating and more like context compilation. The builder has to decide which instructions are durable, which details belong only to the current turn, which memories are safe to include, and which tools or platform actions the agent is allowed to consider.

03 / Runtime Loop

Agent Loop

The agent loop is the work chamber, but OMH keeps its claims at the wrapper boundary. src/coding_delegation.py, src/wrapper/sessions.py, and src/runtime/artifacts.py prepare executor handoffs, preserve session decisions, and record observed runtime events without pretending OMH is the hidden executor.

That power creates a product responsibility. If Hermes prepares a coding handoff, that is not the same as a coding agent running it. If Hermes prepares an image card prompt, that is not the same as a connected image tool generating and delivering the final image. If Hermes prepares a daily research loop, that is not the same as cron waking, sources being collected, synthesis completing, and a brief being delivered. These distinctions sound small until a team starts depending on them.

This is why Hermes has to separate intention from observation. A plan, a queued action, a tool call, a streamed result, a saved artifact, and a delivered answer are different runtime states. Without that line, an agent stops reporting work and starts narrating a story about work.

04 / Recall Rules

Memory Discipline

docs/MEMORY_CONTEXT.md keeps OMH memory review scoped to OMH-local and wrapper-supplied context. That is a very different mental model from "the agent remembers things." Good memory is selective. It knows what to retrieve, when to retrieve it, and when recalled context should not leak directly into the final answer.

This matters for long-running workflows. A loop that improves a repository over days should remember the goal, the stop condition, previous failures, evidence already collected, and what remains uncertain. A research department workflow should separate raw source inbox, processed notes, briefing output, conflicts, and items still requiring verification. A coding delegation workflow should remember the original interview and plan, not only the last terminal log.

Structured memory is more useful than a pile of prose. A good trace records the original request, route, prompt context, selected skill, tool attempt, observed evidence, result, user feedback, and follow-up candidate. That is the kind of process data Hermes can later inspect or improve from.

05 / Procedural Knowledge

Skills

A skill is not just documentation. It is a repeatable operating pattern that stops Hermes from guessing the same process every time. src/skills/catalog.py, src/skills/render.py, and skills/oh-my-hermes/SKILL.md show the shape: Hermes can be taught when to use a skill, how to keep that skill maintainable, and how to improve skill guidance after observing failures.

This is where GEPA-style thinking matters. Hermes can read traces and improve the way it behaves without retraining a model. But self-improvement only works if the trace is clean. "The agent did something and it seemed okay" is not a learning event. "The user asked for issue-to-PR preparation, the selected skill skipped acceptance criteria, the reviewer found that gap, and this skill patch would prevent recurrence" is a learning event.

That is why automatic mutation should not be the default product story. The safer loop is trace, evaluate, propose, review, patch, and replay. Hermes can draft the improvement, but a human or trusted review gate should decide when a workflow or skill actually changes.

06 / Extension Ports

Tool And Plugin Ports

Tools are where Hermes stops being only conversational and starts touching the outside world. src/mcp_bridge.py, src/plugin_bundle/omh/tools/chat_tool.py, and src/plugin_bundle/omh/tools/recommend_tool.py sit at that edge: they describe what can be called, how arguments move across the boundary, which tool paths are protected, and how results return to the loop.

A good tool port is explicit about authority. Reading a file, opening a browser connector, writing to a repository, posting to a channel, and registering a plugin are different powers. Hermes should preserve that difference in the prompt context and in the user-visible status so a convenient automation does not quietly become a hidden production action.

Plugin and MCP-style extensions also need provenance. The runtime should be able to tell whether a claim came from Hermes itself, a wrapper contract, a plugin-authored metadata record, or observed backend output. That distinction is what lets the same agent feel flexible without turning every extension into an unverifiable black box.

07 / Gateway Surface

Hermes Gateway

Gateway intent policy in src/routing/recommend.py, src/skills/catalog.py, and src/wrapper/contract.py is what lets Hermes treat Discord, Slack, Telegram, email, webhooks, and other message surfaces as different entrances to one agent loop. The gateway is not merely a transport adapter. It carries origin, user, thread, delivery target, attachment policy, silence policy, and status-update expectations into the runtime.

That gateway context changes the answer Hermes should produce. A local terminal response can be verbose. A Slack thread may need a short status update and no file attachment. A Discord handoff may need to preserve the channel, mention policy, and follow-up thread. A webhook may need a machine-readable result without chatty explanation. The same user intent can therefore render differently without changing the underlying workflow.

The boundary is delivery. Preparing a gateway intent card is not proof that a platform message was sent. A healthy gateway path can say which channel it is preparing for, which delivery constraints it will respect, and which evidence would prove that the reply, attachment, or status update actually reached the destination.

08 / Scheduled Work

Cron And Scheduled Work

Scheduled work in src/hermes_ops.py and src/commands/ops.py is what makes Hermes feel operational when nobody is watching the terminal. A useful agent can receive work from a platform, preserve session context, respect platform delivery policy, prepare scheduled checks, name protected tool requirements, hold locks, scan for prompt injection, and return results through the right channel.

That does not mean every workflow should become unattended automation. Verification is still on the operator. A loop that runs unattended can also make unattended mistakes. The healthier product design is layered verification: cheap inner-loop checks such as schema validation, compile logs, focused tests, or smoke commands run often; slower outer-loop checks such as adversarial review, integration testing, release gates, or human approval run at important boundaries.

Hermes should make that cost dial visible. A healthy runtime can say: here is the next step, here is the cheap verification, here is the expensive verification, here is what failed, here is why we loop back, and here is what still needs human judgment.

09 / Boundary Model

Evidence Boundary

The most important product boundary inside Hermes is not "can the agent say the right sentence?" It is "what can the agent truthfully claim happened?" Prepared work, queued work, dispatched work, completed work, verified work, reviewed work, and delivered work should not collapse into one vague success state.

This matters for every extension point. A tool schema can exist without a tool call happening. A plugin can be installed without being loaded in the active session. A scheduled job can be declared without waking. A gateway can receive a message without successfully delivering the answer. The runtime needs different states for those facts.

That boundary is what keeps an agent useful under real operations. It lets Hermes speak naturally to a user while still preserving the machine-readable difference between intent, action, evidence, verification, delivery, and follow-up.

10 / Summary

Takeaway

Hermes Agent is strongest when it is understood as a full work runtime: surfaces, prompt builder, agent loop, memory, skills, tools, plugins, cron, gateway, and delivery. The boundary is simple: Hermes can plan, call tools, persist context, and return results, but every operational claim should map to an observed runtime fact.

This page is based on local repository inspection rather than marketing copy alone. The important source surfaces include README.md, docs/DIRECTION.md, docs/MEMORY_CONTEXT.md, src/routing/recommend.py, src/routing/chat.py, src/wrapper/contract.py, src/wrapper/sessions.py, src/coding_delegation.py, src/runtime/artifacts.py, src/runtime/records.py, src/mcp_bridge.py, src/plugin_bundle/omh/tools/chat_tool.py, src/plugin_bundle/omh/tools/recommend_tool.py, src/hermes_ops.py, src/commands/ops.py, src/skills/catalog.py, src/skills/render.py, and skills/oh-my-hermes/SKILL.md.