Hermes Agent in my lab: architecture, security and real-world usage

Hermes is not the name I gave to a chat window. In my lab it has become a personal operational layer between the channels I use every day and the tools I use to administer systems, produce documentation and publish content.

The distinction is important. A chatbot receives a question and generates text. An operational agent receives an objective, reconstructs the context, chooses authorized tools, performs checks, produces an artifact and verifies that the result actually exists.

The rule I apply is simple: a plausible answer does not equate to a completed job. If I ask for a build, a check or a publication, I want to see the real output of the build, the state of the service and the externally reachable result.

This Technical Note describes my setup and the method I use to operate it. It is not a guide to give indiscriminate access to a language model: it is the opposite. It is a way to make AI operational without giving up perimeter, evidence and rollback.

From chatbot to operational agent

The flow of a traditional chat is linear:

user → question → model → answer

The flow I seek with Hermes is different:

objective → context → tools → verification → result

Hermes adds some distinct components to the language model:

• gateway, to receive and deliver requests through Discord, CLI, API and other channels;
• toolset, i.e., operational capabilities like terminal, SSH, files, browser, search, images and cron;
• memory, for preferences and stable information I don't want to repeat in every session;
• skills, reusable procedures with checklists, commands, risks and verifications;
• scheduler, for recurring tasks and monitoring;
• profiles, to separate configurations, contexts and tools when needed;
• interchangeable providers, so the agent does not depend on a single model or endpoint.

The model proposes and coordinates. The tools observe or act. The verifications establish whether the job was actually successful.

How my setup is built

In my environment Hermes runs on a self-hosted server and is primarily reached via Discord. The gateway maintains the link between channel and session, builds the context and forwards the work to the agent.

The main model currently uses a subscription provider via OAuth authentication. If the provider is unavailable, I can maintain a fallback chain towards models exposed by my Ollama backend, local or cloud. This separation allows me to change the engine without redesigning the entire operational flow.

The tools are not all active by default. They are loaded based on the platform and the task: terminal and files for a system administration task, browser for a visual check, web for a search, cron for a recurring process.

The state of conversations lives in SQLite with WAL journaling. Memory, skills and configuration remain separate and readable files. This choice makes the system inspectable: I can check processes, files, database, logs and service units without relying on an opaque platform.

The complete lifecycle of a request

When I write "check why the service is not responding", the correct job is not to generate a list of hypotheses. The cycle I expect is this:

1. Objective definition — understand what I consider working and what the perimeter is.
2. Context gathering — read configuration, live state, logs and already validated procedures.
3. Controlled execution — use only the necessary tools.
4. Security checkpoint — before high-impact changes, declare scope, backup and rollback.
5. Verification — check output, processes, ports, HTTP, build, diff or data integrity.
6. Delivery — explain what was verified, what changed and what risks remain.

This approach avoids two frequent errors: stopping at the first convincing hypothesis or declaring "done" after merely writing a file.

How I actually use it

End-to-end diagnostics

One of the most frequent uses is troubleshooting. I can start from a very short symptom and ask the agent to traverse all the necessary layers: service, process, port, log, storage, network and public path.

A typical prompt is:

The service is responding slowly. Analyze state, processes, logs and resources.
Do not change anything until you have identified the probable cause.
At the end give me evidence, minimal fix and rollback.

The useful part is not the list of commands I could have executed. It is the correlation between real results and the ability to proceed to a verifiable diagnosis.

Infrastructure and homelab operations

I use Hermes as a support for activities on virtualization, containers, networks, NAS, VPN, monitoring and self-hosted services. In this context I apply a clear distinction:

• reads and inventory can proceed autonomously;
• reversible changes require backup and verification;
• reboots, routing changes, firewall, storage and critical accesses require an explicit perimeter;
• credentials and keys must not end up in memory or prompts.

Example:

Verify the container and its public page.
If a change is needed, prepare backup and rollback first.
Do not reboot host or network without my explicit confirmation.

Site development and publishing

For DanpLab the agent can read the project, update content or components, produce SVG diagrams, run the build and verify the public page.

The expected result is not "I wrote the article". It is:

content → build → deploy → HTTP 200 → visual check → sitemap

This same Technical Note follows that flow: versionable content, original diagrams, real build, publishing and smoke test on the public domain.

Research turned into decision

For products, software, services or technical changes I don't need a collection of links. I ask for an evaluation with explicit criteria: compatibility, real cost, risks, alternatives and recommended decision.

Compare the options using verifiable sources.
Discard obsolete or incompatible announcements.
Give me a recommended choice, a price threshold and the reasons to avoid others.

Documents and operational notes

Hermes can transform logs, minutes, configurations, and completed tasks into checklists, procedures, and post-mortems. The value lies in starting from the evidence produced during the work, not in generating generic documentation after the fact.

Recurring tasks

I use the scheduler for technical reviews, checks, and reports. The job starts in a fresh session, gathers data, applies criteria, and delivers the result to the intended channel.

A well-designed agentic cron must have:

• self-contained prompt;
• declared sources and criteria;
• limited toolsets;
• consistent model and fallback;
• explicit delivery;
• silent behavior when there is nothing to report;
• inspectable output and final state.

For simple deterministic watchdogs, I still prefer a script: less cost, less ambiguity, and no model involved. The agent is useful when you need to interpret, compare, or synthesize.

Memory and skills: two different things

Memory retains stable facts: language, preferences, conventions, and environment details intended to remain valid. It must be compact. If an information will be obsolete in a week, it probably does not belong in persistent memory.

Skills, on the other hand, retain the method. A skill can describe how to diagnose a SIP problem, how to publish a Next.js site, how to verify a cron, or how to intervene on an infrastructure without losing access.

My rule of thumb is:

memory   → stable facts
skill    → repeatable procedures
session  → temporary details
secrets  → never in the previous three levels

When a procedure proves incomplete, the skill must be updated. A wrong procedure loaded automatically is more dangerous than no procedure at all.

Reliability and self-recovery

An agent connected to systems must be reachable, but duplicating gateways and supervisors does not increase reliability: it creates competition over ports, sessions, and channels.

In my setup, there is only one authoritative service, started at boot and configured with automatic restart. A separate watchdog remains as a last resort, but it only intervenes if the root service is truly broken. A voluntary stop or maintenance must remain as such.

The persistent state is checked with SQLite verifications and consistent backups. For offline work, I use a maintenance lock: it prevents the fallback from reopening the database while it is being copied or repaired.

This part might seem secondary compared to the AI model, but it is not. A brilliant agent on top of an unstable runtime remains an unreliable tool.

My authorization model

I do not treat all actions the same way.

| Level | Examples | Behavior | |---|---|---| | Observation | logs, status, files, metrics, HTTP | proceeds and collects evidence | | Reversible modification | content, configurations with backup, builds | applies within scope and verifies | | High impact | reboot, network, firewall, storage, deletions | scope, backup, rollback, and confirmation | | Public action | publishing, email, messages, external accounts | executes only on explicit request |

Consent applies to the indicated scope. A "go" to publish an article does not authorize lateral changes to DNS, firewall, or other services.

How to formulate a useful request

Long prompts are not needed. Objective, constraints, and success definition are needed.

An effective format is:

Objective: what you want to achieve.
Scope: where it can operate.
Constraints: what it must not touch.
Success: how it should verify the result.
Output: how you want to receive the summary.

Concrete example:

Publish a Technical Note on danplab.com.
Use the existing style and original SVG diagrams.
Do not modify DNS or reverse proxy.
Run build, deploy, mobile check, and public URL verification.
Return URL, checks, and available rollback.

If the default interpretation is obvious, I prefer the agent to start working. The request for clarification is only needed when a decision truly changes tools, risk, or outcome.

What I do not delegate blindly

Hermes does not replace operational judgment. I do not delegate to it without supervision:

• changes that can isolate routers, VPNs, or remote accesses;
• deletions or migrations without verified backup;
• use or storage of credentials received in chat;
• unrequested public communications;
• administrative, legal, or financial decisions presented as certain;
• conclusions based on output not actually observed.

The agent can prepare, compare, verify, and propose. Responsibility for the scope remains human.

Conclusion

Hermes is useful to me because it reduces the continuous switching between chat, terminal, browser, notes, dashboards, and scattered procedures. It does not eliminate the complexity of systems: it organizes it into a more readable cycle.

The value is not in the number of available tools or even in the largest model. It is in the combination of correct context, bounded actions, reusable procedures, and real evidence.

When this discipline is missing, an agent is just a chatbot with dangerous access. When it is present, it can become a personal operational layer: capable of observing, acting, verifying, and documenting without hiding what happened.

Sources and references

• Official Hermes Agent Documentation
• NousResearch/Hermes-Agent Repository
• The parts about my setup describe the configuration and real usage of the DanpLab laboratory at the date of publication.