Transcription
Hermes went from zero to 40,000 GitHub stars in 46 days. And to compare, OpenClaw did it in 61. So for Aentic systems, this is the fastest adoption ever seen on GitHub. And when you look at what they do, the memory systems, the identity layers, and the self-learning loops, you can understand why.
But before I installed it, I did something most people don't do. I went and read through the issues. And pretty quickly, I realized something that off-the-shelf systems are fast to begin with. They're fast to start. But you inherit somebody else's architecture, their assumptions, and therefore their problems, too. You can't fix what you don't understand underneath. So, instead of replacing claw code, I rebuilt the parts I actually wanted inside my own setup. And honestly, it turned out ridiculously good. Not because it's better than Hermes, but because I actually understand every single layer now. And I built it in a modular way so I can swap pieces in and out, reuse workflows across projects, and evolve the system as the space changes.
So, in this video, I'm going to show you the exact Hermes features I rebuilt in Cyclc code and the parts I deliberately skipped and why understanding the architecture underneath gives you way more leverage longterm than just installing something like Hermes blindly. So, let's get into it. But before I show you what I built, let me show you the three hidden costs of installing something like Hermes off the shelf to save you some time and pain later.
So, cost number one is that you inherit assumptions that you didn't even know existed in the first place. So, as an example, the infamous self-arning loop on Hermes, the bit that everyone celebrates, has no external guardrails. So, we're effectively telling it to build its own skills automatically, then grade your own homework. So, we've got the self-validation problem. The same model that writes the skill is also the sole judge of its correctness. So, without that external validation step, it basically can't see its own blind spots. It thinks everything is good. And what that means in practice is it can quietly overwrite the changes that you've made to make your skills better with worse versions and has no version control or audit log. So you can say goodbye to your good hard work.
So cost number two is that you can't fix what you don't understand. So OpenClaw is one cycle ahead of Hermes. So the first version came out in November. The first version of Hermes came out in February. But it's the same category of product. But when you look at OpenClaw, we've got over 200 vulnerabilities identified and filed since February. You can see that we've got a ton of critical and high vulnerabilities that exist for OpenClaw. And a security researcher even found 386 malicious packages on the skills marketplace from a single threat actor. So when something breaks at this scale, when something is critical to security, you're left debugging somebody else's code because you don't understand the assumptions underneath or their choices they made when they were building it.
So cost number three then is it doesn't scale across your business. So we've got Paul here who's a nontechnical CEO. He spent over a hundred hours and over $1,000 testing openclaw over 2 months. He wanted to understand if the hype was real, if it could do things that personal AI assistants promised they could do, but basically later found that the bugs and security gaps that he identified disqualified it being from any sort of usable. He's now moved on to Claude and has replicated a bunch of the functionality, 30% of OpenClaw's features in the last couple of months. So, Hermes may be faster to start, but your own setup is actually going to be faster to scale. And the hidden costs of off-the-shelf software like OpenClaw or Hermes only show up once you're already committed and in the process of building with them.
So, let's get into what I actually built and what parts I lifted from Hermes. So, the first thing that Hermes actually nails and the first thing I therefore rebuilt is the identity layer. So the agent needs to know who you are, who your business is, and what you stand for. Otherwise, every AI output is going to sound like an AI output. So in Hermes, this represents itself as a memory MD file and a user.md file. It's a super simple setup and designed for one individual client or a single business. But that's also where its limitations come in because it's assuming that you're one person working on one set of stuff. And there's no concept of switching brand contacts, client contacts, or business contacts inside a single setup. So if you wanted to run Hermes for multiple clients, you'd effectively have to install for each individual client its own Hermes installation with its own memory and user.md files. So if you run an agency or multiple clients or even just two distinct brands of your own, you either bake it into one identity and one system in one install and live with that or you spin up entirely separate Hermes installs. And each one of those has its own memory, its own skills, and its own learning loop. So, I'm sure you can see how that embeds a maintenance problem because the skills aren't shared between the clients, even though some of the procedures might be repeatable. And it's not a direct knock on Hermes. It's just what they built it for, but it's not fit for purpose for a business owner running multiple clients or multiple brands.
So, the way that we've built this is to effectively inject context in the same way. So, we have it for our own identity inside a user.md file. We have memories inside a memory.mmd file, but we also inject shared brand context like voice, how you sound, ICP, the audience that you want to aim your content at, and visual identity or how you want things to look like your colors, your fonts, and visual identity. So each individual client has its own set of shared context, their brand voice, their ICP, their positioning, and their visual identity, but they're still able to actually access and share the procedures or the skills across those client folders. So we've effectively built the folder structure so you can handle multiple clients or multiple brands but still share the relevant shared context so you don't have to maintain it in multiple places. It's just one single install versus Hermes for multiple clients would be individual installs that each have their own memory and learnings.
Now what Hermes actually does is inject the memory MD and user.md into the start of every single conversation which drastically improves the short-term recall of important information. So, let's go on now to talk about memory, which is probably the most important feature after this shared brand context for getting better results. And I've got to give it to Hermes. They've actually really thought through the way you store, inject, and recall information at various points in the life cycle. Now, before we move on to that, if you're enjoying the content so far, then drop down below, hit the subscribe button, hit the like on the video. It's massively helpful to me. So, let's get back into the memory system that Hermes uses that's actually very, very powerful.
So, when you consider memory, we've basically got three levels here. We've got storage of context. Then we've got how does that context actually get injected into every conversation? And then more long-term, how do we recall memories that aren't recent but are still important, the ones that we have to go back and search for it. So simply put, Hermes autosaves and summarizes conversations every single conversation turn. It then injects important memories back into every conversation through the memory MD, the user.md and solder MD files. And that is capped at I think 1,300 tokens, which means we're only loading in a limited snapshot of recent important information for every session. But its biggest limitation is when you go back to actually recall the information that is not been injected into that recent memory. And that's because it's searching by keyword and not meaning. So we might be able to recall exact long-term memories if we remember the words we used when we were talking to Claude. But it's much harder if we can't exactly remember what words we used when we talked to Claude about it, which is pretty likely, right? And kind of rendering long-term recall in this case a bit useless. Who remembers the exact words they used with a client 6 months ago in that conversation they were having with Claude.
And this is where it gets really powerful when you're building a custom setup because we can take the stuff that we like about Hermes or the stuff in green, like the fact we are capping a memory. MD file at 2,500 characters or 1,300 characters and injecting that as a recent memory into the conversation as a memory MD file. And then where there were limitations like in the recall where we only had keyword search, we can take other memory systems like mem search in this example and make recall much more powerful. And that's exactly what we've done with our own agentic operating system. So we're still using some patterns of the recall from Hermes where we effectively check that injected context first. But then when the information is not found in that local memory, we go deeper and actually search by meaning and not by keywords. And that's part of the memarch architecture, not the Hermes architecture. So you can plug and play the bits that you like when you build your own custom system and make it bespoke for your context. Say you needed verbatim recall, you might implement me palace instead of mem search, for example.
Now, here's the bit where Hermes gets controversial, which is that self-learning loop we talked about earlier. So, one of Hermes's biggest selling points is the self-arning loop. So, an agent finishes a task, it's going to write itself effectively a new skill every time and use it the next time, which sounds brilliant in practice. And the first time it happens, it's probably pretty special, but what happens by the 10th skill or the 20th skill when you've made tiny iterations on effectively the same process. So, effectively what we're doing is we are starting on day one. We are telling it to do a specific task and then a couple of weeks later when we come back to do a similar task it's going to create two skills that are fairly similar have a similar description but are kept as separate skills maintained as separate skills because it's not going to capture the nuance in our process and we also have poor visibility of all the skills that we have existing already. So it's just going to continue to create more skills and each one is going to capture that approach at the moment in time with that context for that specific situation. So over time you risk ending up with 15 skills that all do roughly the same thing. Like LinkedIn post V1, V2, LinkedIn post for this client, this client instead. It post writer one and two, all with slightly different contexts and slightly different bits of logic baked in. They've all got similar descriptions, so it doesn't know which one to use any which time. Then when your brand voice shifts or when a client's positioning changes, you've got like 15 places to go and update and maintain it. So yes, it's absolutely faster to build this way initially, but it's a hell of a commitment to actually maintain properly and basically therefore impossible to scale across multiple clients without the whole thing turning into a bit of a mess.
Now, we've created personally in-house in our own Agentic OS a whole logic around how to tackle this and we call this skill systems. So a skill shouldn't be just a one-off task. A skill is a modular component that feeds into a skill system. So each one does one job. It lives in one place. It has a consistent named format and gets updated in one place and all the updates propagate to the rest of the system. So when you want to do something complex like write a LinkedIn post in your brand voice for a specific audience in a specific format, you don't create a write a LinkedIn post skill that bakes in all of these things. You actually have the voice, the ICP, the formatting already maintained as separate skills and then the LinkedIn post system just grabs the correct context, the up-to-ate context from one single file for the voice, for the ICP and the formatting. And then this skill or skill system prompt is effectively chaining those together in the right order. So when your brand voice does shift, you just have one file to update and then every skill system that uses that is going to pull from that single file. So it's infinitely maintainable and scalable. So Hermes is faster to build the first skill, but building your own approach is going to be faster to build the 10th, the hundth skill system that depends on the actual skill and infinitely easier to maintain.
So it begs the question, should you build this for yourself or grab something off the shelf? Well, if you install someone else's stack, you've basically inherited their assumptions about identity, memory, about how their learning loop should work, about whether you'll need multiclient context. And some of those assumptions will work for you, and they might work for you. And Hermes is great as an off-the-shelf comparison to something like OpenC Claw, which was a lot more buggy. But some of those assumptions might not work for you, and then you're left actually trying to maintain or fix the broken parts versus actually just building it more slowly for yourself and understanding the assumptions and making it more scalable. So if you are building it for yourself, you're making those choices on purpose. Yes, you will move slower. You'll get some of it wrong, but every layer is something you can see, you can edit, and actually reuse. You can build it in that modular way. And when something does break, you'll have better knowledge of how to actually find the part that's broken and fix that so it's maintainable in the future. So that's effectively the trade-off. It's going to be faster to start with Hermes, but faster to scale with your own built setup. And neither is going to be the right answer for everyone, right? It's just a personal choice.
Now, I'm definitely not saying my version of the Aentic operating system or every custom version is better than Hermes in every way. Absolutely not. But I understand exactly what assumptions have been made under the hood and I can build on it in a modular way in a slower way that's going to end up being completely custom to my own setup. So if you want my exact Aentic OS, it's inside the Aentic Academy in the description below. And it's basically installed in one line, get it up and running today, and we run through exactly what's inside the OS and all the logic. So you're not just left installing something again without understanding the assumptions. You can plug and play the parts you like and leave out the stuff that doesn't work for you. Now, if you want to see more around what we've got inside our Aentic operating system, watch the next video.