The 7 Levels of Hermes Agent: From Basic Chatbot to Self-Managing Backend

Give the agent its own home before you give it any work

I am Madhuranjan Kumar, and the staged path described in this playbook compresses what takes most people months of disorganized experimentation into seven deliberate steps. The underlying principle is simple: each level assumes the one below it is stable. Skip a level and you build on a foundation you have not tested. Hermes Agent becomes genuinely useful only when the levels stack correctly, which means starting at the bottom and not moving to the next level until the current one has proven reliable.

Level one is giving the agent its own computer. This sounds straightforward but the decision carries real implications for everything that follows. Running Hermes on your personal machine means the agent competes with your daily work for resources, and more importantly it means the agent has access to everything your personal machine has access to. Running it on a dedicated VPS, a small cloud server that costs between four and twelve dollars per month at standard providers, gives it an isolated environment and frees your own machine from carrying the overhead. The agent lives on the VPS, runs around the clock whether your laptop is open or not, and can only reach what the VPS has access to rather than inheriting the full scope of your personal working environment.

The setup for level one is not complex. Choose a VPS provider, spin up an Ubuntu instance with at least 4GB of memory and preferably 8GB for a comfortable working environment, connect through the browser terminal, and follow the Hermes installation steps. The agent installs its own dependencies and runs through a brief onboarding wizard. By the end of thirty minutes, you have a Hermes installation on a machine that does not sleep and does not share resources with anything else you do.

Connect it to a channel your team already uses

Level two turns the agent from a service you connect to by logging into a server into something that feels like a teammate. The connection is through the messaging tool your team already uses: Discord, Slack, Telegram, or WhatsApp. You create a bot in that platform, grant it the necessary permissions, invite it to the relevant channel, and paste the resulting token into Hermes. After that, sending a message to the channel sends a task to the agent.

The practical difference is significant. Connecting to the agent through a browser terminal requires opening a laptop, navigating to a server session, and typing at a command line. Sending a message in Discord takes five seconds from any device. The friction of the terminal interface is what keeps most server-hosted agents from being used consistently. Messaging integration removes that friction entirely. You can send a task from the floor, from a phone, from another meeting, from anywhere that has a messaging app installed.

The channel setup also creates a natural log of every task delegated and every result returned. The conversation thread in the messaging channel is a searchable record of what the agent has done and what it returned. For a team where multiple people need to see what the agent handled during the day, the channel is the shared view that makes that visibility possible without any additional tooling.

Test level two before going further by sending five real tasks from the messaging channel and confirming that the agent handles each one correctly. The test tasks should include one that requires a simple response, one that requires a file operation, and one that requires the agent to access the internet for information. If all three types work reliably, level two is solid.

Prune what you do not use before the system grows stale

Level three addresses a problem that every growing agent system faces if it is not actively managed: accumulation of skills that are no longer used. Hermes can create new skills, which are reusable capabilities it installs and can call on for future tasks. Over weeks of use, skills accumulate for jobs that were relevant once and have not been needed since. Each unused skill occupies context space, adds cost to every call that touches memory, and makes the system slightly harder to understand when something goes wrong.

Hermes Curator, which is what level three activates, manages this automatically. It marks skills stale after thirty days of non-use and deletes them after ninety days of non-use. Skills that are used regularly stay active. Skills that were created for one task and never called again are cleaned up on a schedule without requiring manual review of every skill in the library.

The practical effect of enabling Curator before the system grows large is that the skill library stays clean and current. The skills that exist are the ones the business actually uses. The skills that have accumulated from one-off experiments do not add overhead to every session. Context stays lean, costs stay predictable, and the system is easier to debug when a skill behaves unexpectedly because the skill library is not buried under dozens of obsolete entries.

Enable Curator at level three, not at level five when the library is already full. Pruning a clean library is trivial. Pruning a library that has accumulated months of clutter is a significant task and one that produces unexpected gaps when skills you thought were still active turn out to have been marked stale. The habit of good skill hygiene starts with enabling automation to enforce it from the beginning.

Automate the backup before anything else breaks

Level four is the one that everyone should do immediately and almost no one does first: automated daily backup of the entire Hermes directory to a private Git repository. The Hermes directory contains the agent's configuration, its memory, its skill library, its custom instructions, and the context accumulated through weeks of use. If the VPS is wiped, crashes, or needs to be rebuilt, everything in that directory is lost. Rebuilding it from memory is slow and produces something that is almost but not quite the same as what was there before.

The setup is a cron job, a scheduled task that runs at a fixed time each day, that compresses the Hermes directory and pushes it to a private repository. Level four means building that cron job and confirming it runs successfully before any other configuration happens. The cron job itself can be set up by asking Hermes to do it: describe what you want in the messaging channel, and the agent will write the backup script, test it, and configure the scheduled job.

The reason to do this at level four rather than level six is insurance timing. The most likely moment for a setup to go wrong and require recovery is while it is being built, not after it is complete and stable. The levels between four and seven each introduce new complexity and new potential for something to go wrong. Building the backup before those levels means every subsequent change is backed up, and any mistake that requires starting over can start from the last good backup rather than from scratch.

Confirm the backup works by checking the private repository after the first scheduled run. Confirm the backup includes the full directory and not just a subset. Set a recurring calendar reminder to verify the backup completed at least once per week for the first month. After a month of confirmed daily backups, the habit is established and the risk of catastrophic data loss is managed.

Add the Kanban only once the foundation is stable

Level five, the multi-agent Kanban board, is the level that produces the most visible capability increase and the one that fails most dramatically when the foundation under it is not solid. The Kanban board allows multiple agents to run in parallel, each claiming tasks from the board and working independently while you watch progress through a visual interface instead of juggling multiple message threads or terminal sessions.

The reason this level builds on levels three and four specifically is that parallel agents amplify whatever is imprecise in the setup. A single agent with unclear instructions produces one incorrect output. Five agents with the same unclear instructions produce five incorrect outputs simultaneously. A skill that behaves inconsistently in a single-agent setup behaves inconsistently across five agents at once, producing a board full of in-progress tasks that are each going slightly wrong in the same way. The clean skill library from Curator and the safety net from the daily backup make it reasonable to run parallel agents because the system underneath them is organized and recoverable.

The multi-agent research pipeline in the original walkthrough demonstrates the level at its best: two agents gathering current and recent information on a topic in parallel, an analyst identifying the gap in existing coverage, and a writer drafting three concept directions. The human watches the Kanban board and sees each task move from queued to active to complete. The parallelism produces a result in roughly the same time a single sequential run would take for the first task alone. The board makes the work visible and trackable rather than invisible and guessed-at.

Test level five with a single parallel research task before using it for anything business-critical. Run two agents on a real research question your business has, compare their outputs, and evaluate whether the quality and coordination meet your standard. If yes, expand to more complex pipelines. If not, diagnose whether the gap is in the task instructions, the skill library, or the agents' access to relevant sources.

Memory is the feature that changes the agent from a tool to a teammate

Level six is what changes the long-term value of the system. Holographic memory, a local fact store that extracts key facts when a session ends and stores them for retrieval in future sessions, is the feature that makes the agent feel like something that genuinely knows your business rather than something that starts fresh every time you open a new conversation.

The difference is significant in practice. An agent without persistent memory can be very good at handling a task when given full context, but it cannot remember that you told it last month how you prefer vendor communications to be structured, or that a specific supplier has a policy about order minimums that affects how requests should be phrased, or which team member handles each category of request. That context must be re-established every time, which makes every task that depends on accumulated knowledge require re-briefing.

An agent with Holographic memory extracts those facts from sessions automatically and stores them in a local database. When a future task is relevant to a stored fact, the fact is retrieved and included in the agent's context without requiring you to re-explain it. Over weeks of use, the agent's effective knowledge of your business grows through normal use rather than through deliberate training sessions. It learns what it learns by doing the work, the same way a new team member learns the job.

The catch-a-contradiction capability in the memory system is worth noting specifically for businesses where accuracy matters. If two notes about the same subject disagree, the memory system flags the contradiction and asks which is correct before acting on either. An agent that surfaces contradictions before acting is less likely to take the wrong action based on outdated or conflicting information, which is the kind of reliability property that matters for tasks with real business consequences.

Turn Hermes into a backend other agents can call

Level seven is the level that changes Hermes from an agent you interact with directly into infrastructure that other agents can use. By exposing Hermes as a server using the Model Context Protocol, coding tools and other agents can delegate specific tasks to Hermes and receive the results. A coding session in another tool can ask Hermes to check something in your business context, run a workflow against your data, or retrieve information from the memory store that Hermes has accumulated through weeks of use.

The practical use case that makes this concrete is the approval gate. When a coding agent is running a complex refactor that might affect production systems, it can send the potentially risky operations to Hermes before executing them. Hermes pushes an approval request to the messaging channel. The human approves, rejects, or redirects from their phone. The coding agent receives the decision and proceeds accordingly. This pattern applies anywhere an autonomous agent should pause before taking an action that is difficult to reverse.

The phone-based approval gate also makes the full Hermes setup compatible with oversight standards for any business running agents on sensitive operations. The agent works autonomously on the work that can be safely delegated. It pauses for human confirmation on the work that cannot. The confirmation happens through the same messaging channel established in level two, so no additional interface is required. The system that started as a VPS with a chat connection has become a coordinated backend that supports autonomous work within human-defined limits.