Inside One Hermes Turn: From Request to Action
Hermes Agent's defining unit is not the model completion but the turn: an input enters a shared orchestration loop, the loop prepares context and a provider, the model may request tools, and the resulting evidence can drive another model step before anything is persisted. This chapter follows that sequence so the practical meaning of “agent” is clear. It also shows where interruption, approval, fallback, and storage enter, because those boundaries determine whether a tool call is merely suggested or becomes accountable work.
Before the model sees the request
A turn can begin in several places: a person typing in the CLI, a message arriving through the gateway, an IDE using ACP, a batch job, or a program calling Hermes as a library. Those entry points do not each implement their own intelligence. They hand the request to the AIAgent core, while the entry point retains responsibility for presentation, authorization, and platform-specific behavior.
The core first needs a usable context. Hermes assembles a system prompt from ordered layers. Stable identity and tool guidance form the foundation. Project context and caller-supplied instructions describe the environment in which the task is happening. Skills, memory and user-profile snapshots, session information, and runtime hints add the current operating frame. Some information is deliberately kept out of that cached prompt and attached only at API-call time, so a gateway can add turn-specific context without rewriting the durable prefix.
This distinction has a practical consequence. The agent does not treat every new fact as a reason to mutate the whole conversation. A memory write may reach disk while the current prompt remains a frozen snapshot. That preserves the possibility of provider-side prefix caching and keeps the meaning of a turn stable while it is in progress. The cost is that a newly written fact may not influence the same session until a rebuild path or a later session.
The next decision is the runtime provider. Hermes maps a provider and model choice to an endpoint, credentials, and an API mode. OpenAI-compatible chat completions, the Codex Responses path, and native Anthropic Messages calls use different wire formats, but they converge on a common internal message representation. That lets the loop reason in terms of user, assistant, tool-call, and tool-result messages without making every tool understand every provider protocol.
Provider selection is not a cosmetic setting. It determines how tool calls are represented, which context window is available, whether prompt caching applies, and what recovery options exist if a request fails. A configured fallback can replace a failed provider or model, while OpenRouter routing can choose among underlying providers using criteria such as price, latency, throughput, or parameter support. Switching can restore availability, but it can also invalidate a provider-side cache and change the semantics of a request. Portability is therefore a runtime capability with a cost, not proof that all models behave alike.
A model response is a branch in the loop
Once the request and context are prepared, Hermes makes an interruptible model call. The model can return ordinary text, but it can also return one or more tool calls. A tool call is not yet the result of the user's request. It is a proposed transition: a named capability, arguments, and an identifier that will connect the eventual result back to the assistant message that requested it.
The registry decides whether that proposal maps to an available capability. Hermes tools self-register and are grouped into toolsets. Availability checks can remove a tool from the model-facing schema when a credential, dependency, or service is missing. This matters because the model should not be offered a capability that the current session cannot actually execute. It does not make the external service dependable; it only prevents one class of false promise at the interface.
The execution path then applies policy before invoking the handler. Plugin hooks may observe the call. A terminal command is checked for dangerous patterns, and a matching command can require user approval. In an interactive CLI, approval can be requested inline. In a messaging gateway, the request can be sent through the platform and wait for a response. In unattended contexts such as cron or an API session, the default is to deny dangerous actions because no human may be present to answer.
The tool runs only after those gates are resolved. Its result becomes a tool message in the conversation history, paired with the call that produced it. The model sees the evidence and decides whether to call another tool, revise its plan, or answer. That repeated cycle is what separates an agent turn from a single completion.
Multiple tool calls can be executed concurrently when they are independent. Hermes uses a thread pool for that branch, but reinserts results in the original call order. Completion order and conversation order are therefore different things: one slow web request does not require unrelated calls to wait, yet the model still receives a transcript whose tool results correspond to the assistant message that requested them. Interactive tools such as clarification can force sequential behavior because a human decision changes what the other calls should mean.
That ordering rule is more than a performance detail. The model's next decision depends on the relationship between a call and its result. If results were appended solely in completion order, a fast but unrelated tool could appear to answer the wrong request. Hermes gains concurrency without giving up a legible causal history.
Recovery is part of action
An agent that can act must also decide what to do when action is interrupted or fails. Hermes wraps model requests in an interruptible path. If the user sends a new message, issues a stop command, or a signal arrives, the active API thread can be abandoned and its partial response is discarded rather than injected into the conversation as if it were complete. The next input can then be handled without inheriting a half-written assistant turn.
Tool execution has its own failure surface. A missing tool, invalid arguments, an external API error, or a command rejected by policy returns a structured error to the model rather than an unhandled exception. The model can sometimes recover by changing the arguments or choosing another path. It cannot turn a policy denial into a successful execution merely by rephrasing the same request; the approval layer is a boundary around the tool, not another piece of model-generated text.
The loop also has a finite iteration budget. A task that keeps producing tool calls eventually stops and returns a summary of the work completed rather than running indefinitely. This is an important difference between an open-ended agent and an unbounded script. A model may believe more exploration would help, but the runtime still owns the decision that the current turn must terminate.
Provider fallback handles another category of failure. Rate limits, server errors, authentication problems, or an unusable response can activate a configured fallback chain. Hermes resolves the replacement runtime, swaps the provider-specific client and API mode, and continues the conversation when possible. That may preserve the task while changing latency, model behavior, pricing, context limits, or cache status. A fallback is recovery from an availability problem, not evidence that the two providers are interchangeable.
Progress is made visible through callbacks: tool progress, thinking state, reasoning content when a provider exposes it, streaming deltas, clarification requests, and step completion. The CLI can show a spinner and tool output; a gateway can send progress messages; ACP can expose status updates. Observability is therefore part of the interaction contract. A user does not have to infer from silence whether Hermes is waiting on a model, running a tool, or blocked on approval.
What a completed turn leaves behind
When the loop reaches a final response, Hermes persists more than the visible paragraph. The session store can retain the user and assistant messages, tool calls and results, reasoning sidecars where supported, usage information, model configuration, and session metadata. The transcript becomes evidence that can later be searched, compressed, resumed, or used by a bounded review process.
Memory changes are flushed to their configured stores, but this does not mean every completed turn becomes a memory entry. The current turn may remain only in the session transcript. A later review may decide that a user preference belongs in the profile, that an environment fact belongs in agent notes, or that a reusable workflow belongs in a skill. Those are separate state transitions governed by different limits and controls.
Persistence also makes interruption meaningful. If a partial API response is discarded, it is not silently promoted into the canonical conversation. If a tool result is saved, it remains attached to the tool call that produced it. If the session grows too large, compression can later replace the middle with a structured summary while preserving a recoverable record. The runtime is maintaining a history whose structure matters, not dumping strings into a log.
This is why the final response should not be confused with the final state. “The tests pass” is an answer. The tool calls, output, model choice, approvals, and session record explain how that answer was reached and what a later agent can verify. For a learning system, that evidence is the raw material from which future memory or procedure may be selected.
A concrete turn and its boundaries
Imagine a user asks Hermes to fix a failing test in a repository. The entry point supplies the message and the active workspace context. The prompt tells the model which tools are available and includes any relevant standing project guidance. The runtime resolves the selected model and endpoint. The model asks to inspect the test file, so the registry dispatches a read operation and returns the content.
The model now has evidence rather than a guess. It may ask to patch a file and run the test suite. The patch is a state-changing operation, so file-write rules and the tool's own safety checks apply. The terminal command runs in the configured local or remote environment. If the command matches a dangerous pattern, the user must approve it—or the unattended policy denies it. The output returns to the same loop, and the model can revise the patch if the test still fails.
Several boundaries are visible in this small example. The model does not own the filesystem; the terminal backend does. The tool handler does not decide whether a dangerous command is acceptable; the approval policy does. The entry point does not implement the debugging strategy; the shared AIAgent loop coordinates it. And the final prose does not erase the evidence: the session retains the path from request to action to result.
The system can still fail. The model may choose the wrong file, a dependency may be unavailable, the test command may time out, or the external provider may return an error. Hermes's loop supplies recovery and visibility, but it does not guarantee correct judgment. That boundary is essential: orchestration can make a model's actions more structured and governable without making the model infallible.
The turn is therefore the first place to see Hermes's learning thesis in operational form. A request becomes a sequence of controlled state transitions; those transitions produce evidence; and persistence keeps enough structure for later recall or review. The next question is how that evidence is divided among live context, searchable history, compressed continuity, and durable knowledge—because carrying everything forward would defeat the purpose of having an agent that can work over time.