Hermes Agent: The Self-Improving AI That Writes Its Own Skills

An open-source AI agent that reviews its own mistake history, writes new skill files roughly every fifteen tool calls, and rewrites its own prompts from execution traces reached fifteen thousand GitHub stars faster than most developer tools reach one thousand. Hermes Agent from Nous Research is not another chatbot wrapper. It is a self-improving system that gets measurably better the more you correct it, and deploying it well requires a specific sequence.

This playbook covers that sequence from choosing the right first job all the way to the moment you can safely hand the agent a second responsibility.

Choose the right first job: single, narrow, repetitive

The self-improving mechanism in Hermes depends entirely on volume. It writes a skill file when it completes a complex task of five or more tool calls, when it works through a new kind of error successfully, or when you explicitly instruct it to remember something. GEPA, the genetic evolution of prompt architectures layer, reads execution traces and mutates prompts based on patterns across many attempts. Both of those processes need raw material: lots of repetitions of the same category of task.

A first job with the right properties has three characteristics. The task happens multiple times per week, ideally daily. The quality of the output is recognizably good or bad to anyone who understands your business, without requiring lengthy analysis. The rules governing the task are stable and could be written down in a page or less. Customer support triage, order status replies, appointment confirmation messages, recurring report generation, and inventory threshold alerts all qualify. Strategic decisions, original creative work requiring shifting brand voice judgment, and tasks whose definition changes frequently do not qualify.

Before committing to a first job, write a one-page rule document for it. What does a good output include. What are the three most common edge cases and how should each be handled. What should never appear in a reply under any circumstances. If you can write that document clearly in under an hour, the job is ready to hand to the agent. If you keep adding qualifications and exceptions, the job needs more definition before you automate it.

One more practical filter before you proceed: avoid first jobs where a bad output reaches a customer or a financial system without a human review step in between. The agent will make mistakes in the early weeks. That is normal and manageable. What matters is that mistakes stay contained while the system matures and the skill library builds up enough specificity to handle real-world variation reliably.

Provision the VPS: give the agent its own machine

Best practice from the Hermes project documentation is a dedicated VPS, meaning a virtual private server that the agent has entirely to itself. The reasoning is practical: Hermes needs a full operating system to work in, with access to the filesystem, network, installed utilities, and enough compute headroom to run background tasks without competing with other processes. Sharing that environment with other applications creates resource conflicts, permission complications, and debugging complexity that slows iteration in the early weeks when clean feedback is most valuable.

A basic VPS starts at about five dollars per month on any Linux provider. Spin up a fresh Ubuntu instance, run the one-line installer from the Hermes GitHub repository, and the setup script auto-detects the operating system and installs every dependency the agent needs: UV, Python, Node, ripgrep, and FFmpeg. None of those require manual configuration. The installer handles the full dependency chain in a few minutes.

Before running the installer, confirm that SSH access is stable and that the disk has enough space for the SQLite session archive to grow over several months. The archive stores every conversation as a queryable database, which is how the agent can answer questions like "what did I do with return requests in March" accurately from real history rather than inventing a plausible answer. A twenty-gigabyte disk is comfortable for the first year of most small-business workloads. High-volume deployments handling hundreds of conversations daily may need more.

After installation, run a quick smoke test with a simple task to confirm the agent is responding before connecting any live model credentials or real business data. Catching a configuration issue at this point costs five minutes. Catching it after the agent has processed a week of real work costs significantly more.

Connect a model with a spending cap locked in first

The spending cap is not optional and not a precaution for unlikely scenarios. Set it before the agent makes a single API call. An autonomous agent that runs into an unexpected error loop, receives a confusing or ambiguous task, or retries a failing step can make hundreds of API calls in a short window. A hard monthly cap stops that from producing a large surprise bill before anyone notices the problem.

Thirty dollars on OpenRouter is a practical starting cap for a new deployment. It provides enough headroom for active testing and real usage in the first month while being low enough to prevent meaningful damage if something unexpected happens. Once you have a full month of data on actual usage patterns, token consumption per task, and error rates, adjust the cap to something calibrated for your real volume.

Hermes supports a range of model providers including OpenRouter, Nous Portal, GLM, Kimi, MiniMax M2.7, and Claude Opus. For a first deployment, route through OpenRouter with a model that balances quality and cost for your budget. The specific model matters less at this stage than you might expect, because the self-improvement mechanism is model-agnostic. A mid-tier model corrected consistently will outperform an expensive frontier model left to run without feedback, because the skill library and GEPA refinements that drive long-term performance are built from real corrections, not from the base model quality alone.

Configure the messaging integration at this stage as well. Hermes runs as a persistent system service and connects to Telegram, Discord, WhatsApp, Slack, and Signal. Setting up the Telegram integration through BotFather takes about fifteen minutes and gives you the ability to send corrections from a phone the moment you notice something off, rather than batching corrections until you are back at a computer. Immediate corrections are more effective than delayed ones because the context of why something was wrong is still clear, and the correction feeds into the next cycle of GEPA refinement faster.

Spend the first two weeks actively correcting it

This stage determines whether a deployment succeeds or plateaus at mediocrity. The agent learns from real corrections. Without consistent correction input over the first two weeks, the skill library stays thin, GEPA has little high-quality signal to work with, and the agent reaches a level that generates enough frustration to be quietly abandoned before the compounding starts.

Plan ten to fifteen minutes per day for the first fourteen days. Review what the agent produced. When it handled something correctly, leave it alone and let the skill persist. When it got something wrong, correct it plainly and specifically. An example correction that actually works: "When the order was placed more than sixty days ago and the customer asks for a return, say we need to review the case and that someone will follow up within one business day. Do not promise a refund on the initial reply." That level of specificity is enough. You do not need to understand the internals of GEPA or prompt optimization theory to write effective corrections.

Two things to watch carefully during this period. The first is whether the same type of error repeats three or more times in a row after you have already corrected it once. If it does, the correction is not being absorbed and needs to be rewritten with different phrasing, more explicit constraints, or a concrete example of the correct output. The second is the skill files themselves. They are readable markdown files stored on the VPS that you can open and inspect directly at any time. Reading them tells you what the agent believes it has learned from your usage. If a skill file accurately reflects a rule you tried to teach, the learning worked and that skill will transfer to similar future tasks. If the skill file captures a confused or partial version of your intent, correct that specifically in plain language. Treating the skill files as visible, inspectable artifacts rather than black-box internals is one of the practices that separates deployments that stay on track from ones that drift.

By the end of week two, with consistent daily correction, the agent will have a meaningful library of skills specific to your business domain, and GEPA will have had several full cycles to refine the underlying prompt architecture based on real execution traces.

Let GEPA refine the prompts and read the skill files it creates

After the intensive two-week correction phase, shift from daily checking to periodic review. GEPA runs continuously in the background during normal agent operation. It reads execution traces across completed tasks, applies an evolutionary process to identify patterns in what succeeded and what failed, and mutates the prompt architecture to close the gaps it finds. You do not trigger this manually. Your job at this stage is to observe whether first-attempt quality is improving week over week without requiring the same correction volume as the early weeks.

One useful practice at this stage: deliberately test one edge case per week. Send the agent a scenario that previously caused problems and observe the response. If it handles it correctly, the skill from the earlier correction has generalized and is now working across new instances of the same problem type. If it still stumbles, you have something specific to correct in a fresh context, which produces another GEPA input cycle. Deliberate probes like this guide the improvement curve more precisely than waiting for organic edge cases to surface on their own.

Use the SQLite query capability as a diagnostic tool as well. Ask the agent to summarize how it handled a category of task over the past month. The queryable session archive produces a factual record of actual behavior rather than a rough impression, which is more useful for deciding where to focus correction attention next. This capability also makes the agent useful as its own auditor: you can ask it questions about its own performance history and get structured, database-backed answers rather than model-generated summaries of a vague impression.

By the end of the first month, with a narrowly scoped first job and consistent early correction, a typical deployment reaches sixty to seventy percent of the target task handled without review, roughly thirty percent needing a quick check before the output is used, and under ten percent requiring direct owner attention.

Expand scope only after the first job runs without guidance

The correct trigger for expanding to a second job is behavioral, not a calendar date. The first job should run for at least four consecutive weeks without requiring daily correction, with a first-attempt quality rate you would describe as reliable. Not flawless. Reliable: you check in a few times per week and find the work completed cleanly without anything that needed intervention.

When that threshold is met, add a second job using the identical sequence: narrow scope, two weeks of active daily correction, a shift to periodic review, and a deliberate wait before adding a third. One well-trained job running at eighty percent first-attempt accuracy produces more business value than five partially trained jobs each running at forty percent, because the combined supervision overhead on five partial deployments can exceed the full time cost of handling all five tasks manually.

Scope expansion is also the moment to consider whether the second job can leverage the first job's skill library. An agent that already handles customer support triage can extend naturally into drafting follow-up emails for resolved tickets, because the customer context, product vocabulary, and tone guidelines it has already learned transfer directly. Starting the second job in an adjacent domain means it reaches reliability faster than it would from a cold start on something entirely different.

Worked example: e-commerce support recovered in eight weeks

An online store shipping physical products handles forty support contacts per week. The mix is consistent across months: shipping time questions, return requests, size exchange inquiries, and a set of product-specific questions that recur every week with slightly different wording. At four minutes per contact on average, including reading, composing, and sending the reply, that is one hundred sixty minutes of weekly support work, roughly two and a half hours every week.

The first job assigned to the agent is triaging and drafting replies to this support queue. Infrastructure cost: a five-dollar-per-month VPS plus a thirty-dollar spending cap on OpenRouter. Total monthly infrastructure: thirty-five dollars.

Weeks one and two are the active correction phase. First-attempt quality starts around sixty percent. The owner corrects ten to twelve responses per day, spending about two minutes per correction. Skills accumulate quickly because the task domain is narrow and the rules are stable. The agent learns the return policy specifics for international orders, the exact language the store uses for shipments delayed more than five business days, the size exchange cutoff for seasonal products, and the product-specific FAQ answers it gets wrong in the first few days. By the end of week two the skill library reflects the actual complexity of the support queue.

By week four, the agent handles roughly sixty-five percent of contacts without any review needed. Twenty-five percent need a quick owner check before sending. Ten percent get flagged for direct owner handling.

By week eight, after several GEPA refinement cycles have run on the accumulated execution traces, the agent handles approximately eighty percent of contacts without owner involvement. The remaining twenty percent consists of quick approvals taking under a minute each and genuine exceptions requiring personal attention. The two and a half weekly hours of support work has become thirty minutes of oversight focused on the most complex edge cases.

Monthly infrastructure cost: thirty-five dollars. Monthly time recovered: roughly eight hours. At a conservative personal valuation of twenty-five dollars per hour, that is two hundred dollars in recovered capacity per month against a thirty-five-dollar cost. The ratio improves every month that follows because the skill library keeps growing and the oversight requirement keeps falling without any additional work from the owner.

The important lesson from this example is not the technology. It is the sequence. Narrow first job. Dedicated machine. Capped model connection with a hard limit set before the first run. Two weeks of disciplined daily correction without skipping days. GEPA running continuously in the background. A deliberate hold before adding any second responsibility. Each step sets up the next correctly, and the compounding that follows starts in week three without any additional effort from the owner beyond the daily ten-minute correction habit.