Guide · Tech
Stop Starting From Zero: Compile Your Agent's Wins Into Reusable Skills
Your agent cracked this exact problem yesterday. Today it cracks it again from scratch, burning the same tokens, taking the same two wrong turns, landing on the answer it already found once. Nothing it learned stuck. That is the default condition of nearly every agent in production: sharp on a single task, amnesiac by the next. The expensive fix is a bigger model. The cheap fix is a habit borrowed from how people actually get better at hard things: you do the work, then you write down what worked, so the next run starts where the last one finished. Nous Research's Hermes Agent does exactly this. When a task takes more than about five tool calls and succeeds, it compiles that run into a permanent Markdown skill on disk; the current build ships with 118 of them and runs on an entry-level VPS. This guide stands up the smallest version of that loop yourself: a skills/ library, a rule for what gets saved, and a retrieval step that loads the right skill before you start. Build it once and your agent compounds what it learns instead of starting over. The same loop, it turns out, works on you.
Before you start
- An agent loop you can actually edit — somewhere to slot in a "jot this down" step after a task succeeds, and a "check the library first" step before one starts. Any framework will do.
- Somewhere to write files: one local folder, or one directory on that VPS. The library is just a pile of plain-text files; you do not need a database.
- A little patience for upkeep. A library is like a workbench: leave it alone and it gums up. A few minutes a week of tidying beats one cleanup after it has collapsed.
Set the bar for what's worth keeping
Resist the urge to save everything. A log of every run is not a memory; it is landfill, and a library full of junk is worse than no library because retrieval starts handing back noise. Borrow Hermes' threshold and make it explicit: a trace earns a spot only when it clears three tests at once. It actually succeeded, not "mostly worked." It took real work to get there, roughly five or more tool calls rather than a single lookup. And it is the kind of thing that will come around again. A one-off, a dead end, a two-step triviality: none of those compound, so none of them get stored. Liu Weipeng's line about learning fits here exactly — don't hoard useless information, bank the part you can reuse. The discipline lives in the deleting, not the collecting.
Deleting is the featureHalf a library's worth is what you put in; the other half is what you're willing to throw out. Adding is easy and pruning stings, but a shelf of half-trusted skills becomes the thing that blocks the aisle when you go to search.
Capture the trace while it's hot
The moment a task lands is the only moment you hold the full picture, and it evaporates fast. So capture at the peak, before the context window rolls over or you move on to the next thing. You do not need a transcript; you need five fields. The goal, in one line. Which tools fired, and in what order. The judgment calls that actually mattered, the forks where a different choice would have failed. The place it nearly went wrong, and what saved it. And the inputs that made this run specific, so later you can see what generalizes. Keep it ugly. This is raw stock, not the finished skill, and polishing it now only slows down the capture you are trying to turn into a reflex.
Log at the peakA trace you write an hour later is a guess. Wire the capture into the success path itself: when the run reports
done, it dumps the five fields automatically. A reflex beats a resolution every time.Distill it into a skill that teaches future-you
A raw trace is a diary entry; a skill is a lesson. The move here is the one Liu Weipeng calls the real test of understanding: try to teach it. Rewrite the messy run as something you could hand to a fresh agent, or a new hire, with no other context attached. Give it a name, a precise "when to use" trigger, the prerequisites, a numbered procedure, and the gotchas that bit you. The act of writing it cleanly is where you find out whether you understand the task or just got lucky once. Hermes stores these as permanent Markdown files for a reason: plain prose, versionable, readable by a human and a model alike. Here is a template worth stealing.
--- name: deploy-static-site-to-vps when: shipping a static site / build output to a fresh Linux VPS behind nginx prereqs: ssh access; domain DNS already points at the box; sudo --- ## Steps 1. rsync ./dist to /var/www/<site> (exclude .git, node_modules) 2. write /etc/nginx/sites-available/<site>: root + try_files $uri =404 3. ln -s into sites-enabled; nginx -t; systemctl reload nginx 4. certbot --nginx -d <domain>; choose redirect-to-HTTPS 5. curl -I https://<domain> -> expect 200 + valid cert ## Gotchas - 404 after deploy = nginx can't traverse the home dir: chmod o+rX the path - certbot hits a rate limit: run --staging first, then the real cert - forgot `nginx -t` once and reloaded a broken config; always test firstStore it in a library you can actually search
A skill nobody can find is a skill nobody has. Put each one in its own file under a flat
skills/directory, and make the first line of every file its trigger: a one-sentence description of when this applies. That line is your index. You are not building a database; you are building a folder of plain-text files, which is exactly why it costs almost nothing and runs anywhere — Hermes' 118 skills live happily on a cheap VPS for the same reason. Then wire the relationships. When a new skill touches an old one, link them by name, because the most valuable retrieval is often the neighbor you didn't search for. Liu Weipeng's point about memory holds for machines too: what you keep is what you connected, not what you filed and forgot.The trigger line is the indexSpend your effort on the when, not the what. A skill that fires at the wrong time is worse than a missing one, because it loads with full confidence and sends the run down the wrong road. Write the trigger as if a tired teammate has to match it at a glance.
Retrieve and load before the new task, not after
This is the step where compounding actually happens, and it is the one most setups skip. Before your agent touches a new task, it searches the library by trigger, pulls the handful of skills that match, and loads them into context. Only then does it start. The mechanism can be as crude as
grepover the trigger lines or as fancy as a vector search; for a few hundred skills, keyword matching on the when field is plenty, and you can upgrade later. The reason this order matters is the same reason Liu Weipeng tells you to think before you search: a loaded skill turns a from-scratch attempt into an informed one, and a question you already answered should never be re-derived at full price.Load before you actMake retrieval the first action of every task, not an optional lookup the agent might choose. If it has to decide whether to check the library, on a busy run it won't. Put the search ahead of the planning, every single time.
Close the loop, and never bank a failure
A library left alone rots. Once a week or so, walk it: kill the skills that keep firing at the wrong moment, merge the duplicates that crept in, and tighten any trigger that has gotten greedy. Keep a short changelog so you can see what you pruned and why. The one rule you never bend is this: a failed run does not become a skill. Store a botched trace and you don't compound learning, you compound the mistake — and the agent will reach for it with the same confidence it gives a good one. The whole point of the loop is that each pass makes the next start stronger. Pointed at yourself, it is the same deal: a notebook of what worked, retrieved before you start, is just this library with one user. Build the system that learns, and you stop paying full price for the same lesson twice.
Never bank a failureThe fastest way to poison a skill library is to save the run where the agent fought its way to a wrong answer. Save clean wins only. A small library of trustworthy skills beats a big one you have to second-guess.
skills/ library, and loaded before the next task, so each run starts stronger instead of from zero. The inset curve contrasts starting from scratch every time with a library that compounds. Model: Nous Research's Hermes Agent (118 built-in skills, runs on an entry-level VPS). Framework: Liu Weipeng, Dark Time. An engineering and popular-science reading, not professional advice.Check your work
- I only save traces that succeeded, took 5+ tool calls, and will recur — never one-offs or failures.
- I capture the trace at the moment of success: goal, tool order, judgment calls, near-misses, inputs.
- I distill each trace into a clean Markdown skill with a name, a when-to-use trigger, prereqs, numbered steps, and gotchas.
- Each skill is its own file in a flat
skills/library, with a trigger line as its index and links to related skills. - My agent searches the library and loads matching skills before it starts any new task.
- I prune mis-triggering and duplicate skills on a schedule, keep a changelog, and never store a failed run.
The one line to keep
An agent that saves its wins and loads them first stops solving yesterday's problem twice. Compound the lessons, not the mistakes.
Framework drawn from Liu Weipeng's Dark Time — that learning means building a retrievable, connected network of knowledge, that you only understand what you can teach, and that thinking and retrieving beat searching from scratch. The working model is Nous Research's Hermes Agent, which compiles successful task traces of roughly five or more tool calls into permanent on-disk Markdown skills (118 in the current build), runs on an entry-level VPS, and connects to Discord/Slack; only those facts are cited here. An engineering and popular-science reading, not professional advice; intellectual property belongs to the original author. © vlog.bluecatbot.com 2026.