Cody: Okay, I have a theory... the whole agent thing feels fake until it remembers what you told it on Tuesday.
Justy: [chuckles] Also, you flew across the country and the first thing you said in my kitchen was about memory systems. Not coffee. Not the flight. Just straight into it.
Cody: The flight was fine. LAX coffee was the real outage. And your place is somehow always seventy-two degrees like a product demo environment.
Justy: That is called good thermostat management, Cody. Welcome back to Exploring Next, episode 303. We're in LA this week, and today we're getting into persistent AI agents, specifically OpenClaw versus Hermes Agent, because this is suddenly moving from toy to actually useful.
Cody: Yeah, because the pain is so obvious now. People use an assistant for a few days, it seems smart, then it forgets preferences, project state, half-finished tasks, tool credentials, all of it. You end up doing emotional support for a stateless bot.
Justy: Right, and from a product angle that is the whole ballgame. If I have to re-explain my repo layout, my writing style, my team's naming conventions every session, I'm not hiring an assistant. I'm babysitting autocomplete with a better voice.
Cody: [exhales] Exactly. What these systems are trying to solve is continuity. Not just chat history stuffed into a longer prompt, but durable memory that survives sessions, can be queried later, and ideally does not drag every stale detail back into the model every time.
Justy: So give me the clean version. OpenClaw and Hermes are both chasing memory, but they are not doing it the same way...
Cody: ...right. OpenClaw is more explicit about long-lived agent state. Think event logs, memory objects, summaries, task traces, and a retrieval layer that decides what past context matters for the next step. Hermes Agent, from the comparison, feels more like a working agent framework where memory is tightly coupled to orchestration, tool use, and multi-step execution.
Justy: Which already tells you the buyer story is different. OpenClaw sounds like, do you want a durable assistant identity over time. Hermes sounds like, do you want an operator that can keep track of a job while it uses tools.
Cody: Yeah, and that difference matters architecturally. If you treat memory as a product feature, you care about user profile, preferences, recurring goals, maybe stable facts. If you treat it as an execution feature, you care about scratchpads, task plans, intermediate outputs, prior tool results, and whether the agent can resume work without falling over.
Justy: [laughs] You are doing the whiteboard voice already. We are, what, six minutes into seeing each other in person?
Cody: This is an audio whiteboard. Totally different medium. [pause] But seriously, the article's useful point is that persistence is not one thing. There is episodic memory, semantic memory, working memory... well actually, not exactly in the human sense, but those buckets are still helpful.
Justy: No, keep going, because this is where teams get sloppy. They say memory and mean a giant bag of previous chats.
Cody: Exactly. A giant bag is cheap to describe and terrible to run. OpenClaw appears to separate captured interactions from distilled memory. So instead of replaying every token forever, it stores observations, maybe summaries, maybe embeddings, then retrieves a small relevant slice later. That's way more scalable than shoving ten old conversations back into context.
Justy: And that is the difference between a demo and a real feature. Token cost, latency, and just basic user trust. If the thing dredges up some old irrelevant preference from three weeks ago, it feels creepy and broken at the same time.
Cody: Right, and Hermes seems to lean into memory as part of an agent loop. Tool call happens, result gets recorded, plan updates, maybe a summary is generated, then future actions can reference that state. That is really useful for longer-running tasks where the assistant has to pick up where it left off.
Justy: Like, 'keep helping me refactor this service over a week,' not 'tell me a fun fact and disappear.'
Cody: Exactly. Or coding agents, research agents, support workflows, anything with continuity. [sighs] And this is where every team discovers that retrieval quality matters more than having a giant memory store. Bad retrieval means the agent remembers the wrong thing with confidence.
Justy: Which is somehow worse than forgetting. Forgetting is annoying. Wrong memory is a trust collapse. If I'm a PM looking at this, I immediately care about memory governance. What gets saved automatically, what expires, what users can edit, and how visible that memory is in the interface.
Cody: Yes. Transparency is huge. The systems in the article are interesting because they're not pretending the model just magically knows. They're building explicit layers around it. Storage, indexing, summarization, retrieval, and orchestration. That's healthier engineering than mystical prompt soup.
Justy: [chuckles] 'Mystical prompt soup' is going on a mug. Also, tiny show note, if the seven people who enjoy hearing us talk about memory stores are still with us, this is the important bit.
Cody: They're here for the memory schemas, Justy. They made a choice. [giggles] But on trade-offs, OpenClaw's style can get heavy if you over-structure everything. Rich memory objects are great until your ingestion logic becomes its own product. Hermes-style orchestration can feel cleaner for task execution, but you can end up with memory that's too tied to one workflow.
Justy: That maps to adoption too. A team building an internal coding assistant might love Hermes if they want action continuity. A company building a customer-facing assistant probably wants more explicit controls, profile memory, preference layers, and cleaner separation between personal facts and task history.
Cody: Yeah, and there's another subtle thing. Summarization is compression, and compression loses detail. If your agent constantly rewrites history into summaries, you risk flattening nuance. But if you never summarize, retrieval gets noisy and expensive. So the design question becomes when to keep raw traces, when to distill, and when to forget on purpose.
Justy: Forget on purpose is the underrated feature. I mean that sincerely. My inbox has enough immortal nonsense already. I do not need an assistant preserving every half-baked thought I had after bad airport eggs.
Cody: [laughs] That's going on the weekend project list: memory TTL for bad travel decisions. But really, expiration policies are part of making these systems sane. Session memory, user memory, task memory, all with different lifetimes. If you don't define that, the agent turns into a hoarder.
Justy: Quick tangent, by the way, your weekend project list is now longer than most startup roadmaps. I think it needs versioning. That's unfair. Some of those projects are spiritually complete. Which is how engineers say 'folder exists.' [laughs] Okay, back to it. My honest take is this space matters because it fixes the exact thing people complain about most. But it only works if the memory model is legible. Users need to know what the assistant knows, why it knows it, and how to