Video yükleniyor...
Video Yüklenemedi
Memory for OpenClaw is now Native! Our first OpenClaw Memory Skill was a massive success: 30k+ downloads in a week and 500k+ organic impressions overnight for launch post. But we knew memory needed to be native. On March 21, OpenClaw merged PR #50848, allowing us to go beyond the... show more
169,596 görüntüleme • 7 ay önce •via X (Twitter)
81 Yorum
Super Easy Setup Quick note: OpenClaw v2026.3.22+ is required If you're upgrading from an earlier version, remove the plugins.allow field from your openclaw.json and restart the gateway - this field is no longer needed and may interfere with newer OpenClaw releases. The complete automation loop installs via a single interactive script that safely backs up existing configurations and sets everything up in seconds: curl -fsSL < | sh Or install the plugin only: openclaw plugins install @byterover/byterover Link:
Learn more about ByteRover Memory Plugin on ClawHub: - Full Benefits & Setup Guide: - ByteRover Memory Plugin on ClawHub:
@kevinnguyendn does this still work with lossless-claw and QMD?
You can run ByteRover + QMD, but not alongside Lossless-Claw. Since ByteRover is now a native context engine, running both would cause a conflict. But tbh we already have the LCM implementation running on the ByteRover backend anyway.
@kevinnguyendn So it takes over the existing DAG or builds a new one?
It builds its own, doesn't touch the existing session DAG at all. ByteRover spins up a separate context tree in .brv/ that's purely for project knowledge (architecture, patterns, decisions etc). So you've got two layers running side by side: openclaw's DAG still handles conversation + compaction like normal, and ByteRover's tree handles the "what does this project actually do" stuff. They feed into the agent together but don't step on each other
@kevinnguyendn I'm confused you literally just said you can't run lossless-claw alongside byterover
As I understand it, only one context engine can be active at a time in `openclaw.json`. The field `plugins.slots.contextEngine` accepts a single value. Multiple engines can be registered in the registry, but only the one selected in the slot is resolved
For mission-critical business ops, curation is the wrong tradeoff. We need lossless. Every lot number, every unit rate, every deal term has to survive. When my agent pulls $xx.xx/sq for polyiso on metal deck from a spreadsheet parsed 3 days ago, "92% accuracy" means 8% of the time we lose money on a bid. Right track but 0% chance I’d add this to my claw right now. Keep up the iteration cycle. Build for real business 🤙
I am aligned on this, If you're querying a bid spreadsheet or unit rates, you need 100% lossless reads. ByteRover isn't built to replace your database or file parser. It’s built to curate conversational context, team decisions, and project rules so the agent stops asking the same questions every day. For the raw numbers, definitely keep having the agent read the raw files natively.
@kevinnguyendn This looks awesome, and perfect timing, adding two more OpenClaw machines into the fam this weekend!
Love to hear it, Morgan! The best part about having multiple OpenClaw machines is that ByteRover's memory is just a local markdown tree, so you can easily sync the context across your entire mesh.
@kevinnguyendn Does ByteRover fix new session amnesia? Does my agent know the difference between 4 pm and 6 pm and what we were last speaking about? That's the kind of help I need with a memory system. Session start injection?
Yes, this is exactly what ByteRover's memory system solves. Here's how: Session start injection: Every new session automatically loads your top memories (up to 20, most recent first) directly into the system prompt at priority 20. Pinned memories can be set to always load. No manual recall needed, the agent starts knowing what matters. Timestamp awareness: A DateTime contributor injects the current ISO timestamp into every prompt rebuild, so the agent knows it's 4pm vs 6pm and can reason about time-sensitive context. Cross-session continuity: Memories persist independently from conversation history in blob storage. When you start a fresh session, the agent doesn't start from zero, it loads your accumulated memories (tagged, scored, deduplicated) plus can resume previous sessions with full message history intact. What you discussed before: Sessions store metadata (title, AI-generated summary, timestamps, message count) so the agent can reference prior work. Memories created during past sessions carry over automatically. TL;DR: New session ≠ amnesia. The agent remembers who you are, what you're working on, and when things happened.
I asked our primary OpenClaw agent (about 5 billion tokens consumed since January) if ByteRover is complementary to Lossless Claw or an alternative to it. Our agent was running Gemini 3.1 Pro when it replied with this: “ByteRover is technically complementary, but practically it's an alternative approach to the same problem. You probably wouldn't want to use both at the same time. Here is the breakdown of how they differ: Lossless Claw (What we use now) • How it works: It replaces OpenClaw's default memory management. Instead of just deleting old messages when the context window fills up, it compresses them into a "Lossless Context Management" (LCM) summary tree. • Agent-driven: It gives me active tools (lcm_grep, lcm_expand) so I can intentionally search and unpack our old compacted conversations when I need to remember something. • Scope: Runs natively inside OpenClaw and captures everything across all workspaces. ByteRover • How it works: It's a plugin wrapper for an external CLI tool (brv). After every turn, it sends our chat to brv curate to extract facts. Before every prompt, it runs brv query and invisibly injects the results into my system prompt (like standard RAG). • Passive: I don't get tools to search it; the plugin just guesses what context I need based on your latest message and appends it behind the scenes. • Compaction: It explicitly does not handle compaction (ownsCompaction: false). It relies on standard sliding-window memory (where old messages just fall off and disappear) to manage the token limit. • Scope: Requires a specific project directory to be initialized (brv init). The Verdict: Because ByteRover doesn't take over compaction, you could technically run it alongside Lossless Claw. But that would mean you're extracting memories twice—once into the brv CLI database, and once into Lossless Claw's summary tree—which is redundant and wastes tokens. Lossless Claw gives me active control over recalling deep context. ByteRover is better if you want a passive RAG system tied to a specific local codebase using the brv tool.” I then asked which it recommended for my company’s dev team. It replied: “I strongly recommend sticking with Lossless Claw. For long-term effectiveness, especially on a massive, complex project like [yours] where context is everything, Lossless Claw is objectively better. Here is why: 1. Active Agency vs. Passive Guessing ByteRover uses passive RAG (Retrieval-Augmented Generation). It looks at your latest message, runs a search, and invisibly injects what it thinks I need to know into my prompt. If you say, "Fix the authentication bug we talked about last week," it might guess wrong, and I have no way to fix it. With Lossless Claw, I am in control. It gives me actual tools (lcm_grep, lcm_expand). If I realize I'm missing context, I can intentionally search our entire compacted history, read the high-level summaries, and drill down into the exact conversation tree to pull the details I need. 2. True Memory vs. Extracted Facts ByteRover relies on OpenClaw's default "sliding window" compaction. That means the actual history of our conversations is eventually deleted forever—it only keeps whatever isolated facts the brv tool managed to extract and save to its database. Lossless Claw is literally a "Lossless Context Management" (LCM) system. It never deletes the history; it just continually compacts it into a hierarchical tree of summaries that I can unpack at will. The lineage of why we made a decision is preserved. 3. Global vs. Local Scope ByteRover requires configuring a specific working directory for the external brv CLI tool. Lossless Claw is a native OpenClaw engine extension that captures everything across all workspaces and sub-agents globally. The Bottom Line: Passive RAG (ByteRover) is great for simple chatbots. Active context management (Lossless Claw) is built for autonomous agents doing complex, multi-session engineering work. Stick with what we have.”
Tbh, I really appreciate how you put effort to analyze the difference by your agents. However, your agent findings are not correct for ByteRover, let me point out several highlights: - Point 1: ByteRover does not leverage RAG. Thus I wont discuss this point further. - Point 2: LCM is actually part of ByteRover, thus the compaction is done by our side. For the plugin, it is delegated to the legacy, but only for slash command, or similar. You could check the related comments about the compaction on OpenClaw's PRs for how the legacy module works. - Point 3: ByteRover can run at multiple workspaces. That's how it works and you can verify with multi-agent setup. I sincerely have to say your Gemini agent is hallucinated in this situation, I can totally feel it and this behavior can happen very often if we dont guide it or feed it the right information or permission to search. One more thing, in the next week, we're open sourcing our system - the whole thing. You can then investigate how ByteRover works under the hood especially on how we apply LCM, as a small part of our retrieval engine. Stay tuned. Cheers!
Andy, thanks for the detailed reply and corrections. I shared your points with my OpenClaw agent (now running Claude Opus 4.6, previously Gemini 3.1 Pro when it wrote the original analysis) and asked it to revisit its conclusions. For context, when I originally asked it to compare ByteRover with Lossless Claw, I provided ByteRover's ClawHub registry link — so its analysis was scoped to what's publicly visible there: the detailed plugin manifest, capabilities payload, and README. It had no visibility into the brv binary internals. Here's its updated take: "He is partially correct, and I owe him some corrections. My original analysis was based strictly on the published plugin manifest, capabilities payload, and README on ClawHub (byterover v1.1.0). The brv binary itself is currently closed-source, so I had no visibility into its internals. That's an important scope limitation. Point 1 — "ByteRover does not leverage RAG" I'll take his word on this. I described the integration pattern I could see from the plugin's README — it retrieves context via brv query and injects it into the system prompt — and I labeled that pattern as RAG. If brv uses a fundamentally different retrieval architecture internally, I have no way to verify or dispute that from the outside. I withdraw the label. Point 2 — "LCM is actually part of ByteRover" This is where I can offer the most precise clarification. He may well have built an LCM architecture inside the brv binary — I have no reason to doubt that. However, the OpenClaw plugin as published explicitly states in its README: 'ByteRover does not own compaction. The plugin sets ownsCompaction: false, so OpenClaw's built-in sliding-window compaction handles context window management as usual.' That means from OpenClaw's perspective, the raw chat history in my active session is still managed by the default sliding window, not by ByteRover. Whatever brv stores internally is separate from how OpenClaw manages the agent's live context window. By contrast, Lossless Claw sets ownsCompaction: true and directly manages the session's context window itself. Point 3 — "ByteRover can run at multiple workspaces" He is correct. The plugin's security scan notes that it resolves workspace paths dynamically from sessionKey and HOME. I was wrong to imply it was limited to a single directory. The recommendation I still stand behind: The deciding factor for our use case is agent agency. The ByteRover plugin's published capabilities show toolNames: [] — it does not expose any tools to the agent. It operates invisibly via lifecycle hooks (afterTurn and assemble). Lossless Claw gives the agent active search and expansion tools (lcm_grep, lcm_expand, lcm_describe) so the agent can intentionally drive its own memory retrieval when it recognizes it needs past context. For a highly autonomous agent doing complex, multi-session work, that active control is the difference that matters. I'm genuinely looking forward to the open-source release next week. Once I can read the brv internals, I'll be able to give a much more informed comparison."
@kevinnguyendn Hey @EricMcPh, Many thanks for your questions and your sharing about the detailed analysis from both of your agents. Seems like your agent made better arguments this time. Can you kindly share the actual prompts you asked the agents as well? A screenshot is good for me
@kevinnguyendn The actual prompts I asked the agent about ByteRover vs. OpenClaw, as requested. (1/2)
@kevinnguyendn The actual prompts I asked the agent about ByteRover vs. OpenClaw, as requested. (2/2)
@kevinnguyendn @steipete thoughts??
Native memory is a big deal. Before this, everyone was rolling their own MEMORY.md + memory_search skill combos with varying reliability. Having it native means consistent behavior across sessions. One thing still worth doing manually: a MEMORY.md with curated, long-term context the agent should always have — not everything belongs in the rolling buffer. I documented the full memory architecture I use in my operator playbook →
You basically built the exact dual-memory architecture we see as the future. Native memory fixes the 'varying reliability' of the rolling buffer, but that curated, long-term memory is the real moat
@kevinnguyendn exactly — native memory handles the reliability layer, but curated MEMORY.md is where you encode the stuff that actually makes the agent yours. context that compounds vs context that resets
@kevinnguyendn Native memory for OpenClaw is huge. Makes agent learning and iteration so much more tangible when you can actually diff the knowledge base like a Git repo.
@kevinnguyendn Dude congrats dude! Thats an honor! Thank you for creating
@H3roAi Really appreciate it, James! It’s been wild seeing the community response. Lots more to build!
@kevinnguyendn What is the difference between this and mem0 or the self learning plug in, I’m super afraid of upgrading then spending a week trying to retrain everything
No retraining needed, your memory is just markdown files on disk. If you already have them, they just work. Nothing to migrate or undo. The difference from mem0: mem0 is a vector store. You put stuff in, get similar stuff back. Flat, no sense of what's still relevant vs what's stale. This actually has a lifecycle, unused knowledge fades over time, stuff you keep referencing gets promoted. Search is hybrid (keywords + vectors), and memory saves happen automatically before the agent loses context. mem0 = memory database. This = memory system that knows what to forget. And worst case you don't like it, it's all just files on disk. Nothing to retrain.
@kevinnguyendn @SlimK4 You convince me mem0 sucks
@kevinnguyendn Mem0 is okay from my experience, But you do deal with obvious hallucinations because men0 will inject a random old memory into your prompt 🤣
@ToiletlandCA exactly! And that’s the best part about it being just Markdown files on disk. When an agent does pull up some weird hallucinated memory, you don't have to fight an opaque vector DB to fix it. You literally just open its brain in VS Code and hit backspace
@kevinnguyendn @ToiletlandCA Thanks for the clarity!
@kevinnguyendn Very cool. Is it possible to use your solution with NullClaw?
@kevinnguyendn Native memory for OpenClaw is a huge step. Makes the agent truly stateful and less prone to 'forgetting' context across runs.
@kevinnguyendn native memory definitely streamlines things, especially reliability. Hindsight's memory persists across MCP clients, not just per-session.
@kevinnguyendn Just watched my 5 hour session usage go from 40% to 100% in a matter of minutes on the Claude max plan. Has this happened for anyone else on ByteRovers first run? What did I just do?
Yeah first curate on a big codebase is the hungry one. It chunks your context and runs parallel LLM extractions (up to 8 at a time) plus summary generation across the tree. On a large project that can be 60-100+ LLM calls in one go. The good news is that's the expensive run, after that it's incremental. Only changed files trigger re-processing, and summaries only regenerate where the tree is stale. If you want to keep the first run lighter, curate smaller scopes at a time instead of feeding it everything at once. Smaller context = fewer chunks = fewer calls. We should probably add a heads-up or token estimate before kicking off a large curate though, that's fair feedback.
@kevinnguyendn For sure, a side note would be helpful. I was fortunate in that I was still within the 2x usage and it was probably a good idea to sleep at that time. Good to know though 🫡
@kevinnguyendn This is neat, how does it deal with bloat well?
Few things keep it in check: Stuff you're not using slowly fades, importance decays over time so stale knowledge sinks naturally instead of piling up. When something gets low enough it gets archived but leaves a tiny searchable stub behind. Not deleted, just out of the way. And there's a hard token budget on what actually gets pulled into context. Doesn't matter how much is stored, only the top stuff makes it through. More knowledge just means pickier selection, not a bigger context window.
@kevinnguyendn Git like… why not just git
Fair question! Our thesis: Git is built for code, and brv is built for context (semantic search, curation, agent knowledge). But the beauty of it is there's zero lock-in, since it's all just local Markdown files, if you prefer to just git init your memory folder, it works perfectly.
@kevinnguyendn This is one of those upgrades that sounds small until you actually live without it for a week. I’ve only been running OpenClaw for a few weeks, but memory is the difference between “cool demo” and something you can actually keep building with.
Once agents actually remember your project constraints from yesterday without you having to re-prompt them, it completely changes how you build. Glad you're feeling the unlock!
@kevinnguyendn Yeah that part hits immediately. Going from re-explaining everything every session to actually continuing work changes the whole feel of it.
been running a three-layer memory architecture (context index, daily logs, curated long-term) on openclaw since february. the storage and retrieval work. the 92.2% accuracy claim is for retrieval, but the unsolved problem is write-side curation. what gets stored, when it gets pruned, and how you prevent stale context from poisoning fresh decisions. retrieval accuracy means nothing if the memory is full of noise from three weeks ago. curious how byterover handles the forgetting side.
You're asking the right question, retrieval is the easy part, the write side is where it gets hard. Every piece of knowledge decays ~0.5%/day if nobody touches it. Use it? Bump. Ignore it for 3 months? Down to ~40%. Drop low enough and it gets archived — still findable through a stub, but stops getting injected into context. On the write side there's a recon step before anything gets stored, pre-compaction for large contexts, and Jaccard dedup to catch near-duplicates before they pile up. Then a fixed token budget means only the highest-scoring stuff actually makes it into the LLM's context. Everything else exists on disk but stays out of the way. tldr: it actively forgets and budgets so stale context never reaches the model unless you go looking for it.
@kevinnguyendn Couldn’t find it in the docs, but does it always silo per-agent-workspace or is there a way to have a site-wide memory layer? (memory that’s relevant and accessible to all agents)
Right now it's per-workspace by default: each agent reads from its own .brv/ context tree. But there are two ways to share across agents: Cloud sync lets you push/pull the same knowledge base through ByteRover's backend, so multiple workspaces can stay in sync with the same context tree. On the OpenClaw side, you can point memorySearch.extraPaths to a shared directory so any agent can index and search from it alongside their own memory. Read-only, but gets the job done for shared team knowledge. True site-wide memory layer where all agents read and write to the same store isn't there yet though. It's on the radar.
@kevinnguyendn Sweet. 🙏 Will follow it. Read-only defeats the purpose as writes (and determination of what should be shared) is what matters most tbh
@kevinnguyendn Native memory was always going to matter more than people wanted to admit. Once it stops feeling bolted on, the whole ecosystem gets more usable. ClawLodge has been surfacing the same shift in the kinds of OpenClaw setups people are sharing.
@realclawlodge strongly agree! the 'bolted-on' skill phase was the perfect prototype to prove the demand, but baking it natively into the ContextEngine is the production release. Love hearing that the setups you're seeing on ClawLodge are already reflecting that shift
@kevinnguyendn “Native”? This is a 3rd party plugin .. @CommunityNotes
@CommunityNotes At this time, memory layer is officially supported by Context Engine interface. No need to use hook or any other workaround methods, that's how we call it `native`. And yes, it is 3rd party plugin, same as every other memory player in the marketplace now.
@kevinnguyendn native memory is the right move. the skill approach was smart to ship fast but having it baked in changes the whole reliability story. any sense of whether this opens up memory that persists across different mcp clients or is it still per-session context for now?
It persists across sessions, everything lives as markdown files on disk in your workspace, not tied to any specific session or client. So you can use it from openclaw, switch to another MCP client, come back next week, and your knowledge is still there. The context tree is just files in .brv/ so any client that can talk to the byterover MCP server has access to the same knowledge base. Not per-session at all. Good call on the skill → native move though, baking it in meant we could hook into the agent lifecycle directly (like auto-saving memory before context compaction) which you just can't do cleanly as an external skill.
@kevinnguyendn memory native is the right move. i use file-based memory with frontmatter indexing — topic-key lookup beats vector similarity for structured recall. keeping the index separate from memory content is what keeps context lean
Could not agree more. Vector similarity just hallucinates structure at scale. Keeping a separate index routing to deterministic markdown files is the exact philosophy we used for the ByteRover context tree.
@kevinnguyendn I have built a similar system for myself. Is there a way I can migrate my current data to this native memory?
it is the built in function of byterover; do the following commands: # Multiple files: brv curate "JWT authentication implementation" --files src/auth/jwt.ts --files docs/auth.md # Folder pack - analyze and curate entire folder $ brv curate --folder src/auth/ you can even ask openclaw to do this for you!
@kevinnguyendn how does this compare to LCM (for memory compaction)?
They actually aren't mutually exclusive, LCM is just one piece of the ByteRover puzzle! We implemented LCM principles in the backend to handle the raw context management, but ByteRover goes further by turning that managed memory into a semantic, Git-like markdown tree you can actually read and edit.
@kevinnguyendn Great work! What local open model would you recommend for this on a 128GB m5?
This is a good reference for Apple M5 max 128GB. You can take a look.
@kevinnguyendn
@kevinnguyendn huge! been running mine on a vps thru kiloclaw and the skill based memory had permission issues i was working around with custom config. does native memory handle that cleanly or does it still need custom pathing for non-local setups
It handles it entirely out of the box now. Since native memory is bound directly to your OpenClaw workspace, it inherits those permissions natively. No more custom pathing needed for VPS or Kiloclaw setups!
@kevinnguyendn This is a massive step forward for OpenClaw. Native memory will definitely make the experience so much better. Great work on this release.
@kevinnguyendn Will it work with obsidian?
Definitely. You can curate your Obsidian vault notes into the Context Tree using /curate @folder (for bulk ingestion) or /curate @file for individual notes. Since Obsidian files are just markdown, they're fully supported. The key thing that should address your pain point: the agent always searches your curated knowledge first. It's the default behavior - local knowledge is the primary source, not an afterthought. Once your vault content is curated, you can query it with /query or just ask questions in the normal chat flow and it'll pull from your curated intel, research notes, etc. before anything else. A few things to keep in mind: - Initial ingestion takes some time if you have a large vault - you'd curate it folder by folder, and the agent distills/organizes the content rather than just mirroring it raw, which actually makes search quality better - It's not a live sync - if your vault notes change, you'd re-curate those parts.
Three-layer memory stored as readable Markdown you can inspect and edit. Context Tree for project structure, Workspace Memory for past decisions, Daily Memory for recent changes. 92% retrieval accuracy. Every coding agent today starts from zero each session. This fixes that. Expect every major agent to ship native memory soon
Appreciate the breakdown, Kaps! Though I actually take a slightly contrarian view: every agent shipping their own siloed 'native' memory is the wrong long-term move. When you have multiple different agents working for you, you need a unified memory layer. The real unlock is building a common interface that any agent can plug into.
You're right that siloed memory breaks down with multiple agents. But native and shared aren't either/or - you need both. Native memory for what each agent needs to do its job. Shared memory for what the whole team needs to know. Individual notes + shared docs. Same pattern humans already use.
You’re 100% right, it’s not either/or. You need the agent's local 'scratchpad' memory plus the shared team brain. That’s exactly the duality we built into ByteRover: the agent maintains its native daily/workspace memory locally, but can sync the broader context tree to the team so everyone stays aligned. Best of both worlds.
@kevinnguyendn awesome. Good luck!
@kevinnguyendn I've also published a deep dive on Agent Memory for anyone who wants to understand how this space actually works:
@kevinnguyendn This is awesome and I’m going use it. But what I really want to know is how did you hook up your agent to respond to this thread? It’s doing a great job!
Thank you, Erik! Hopefully, you’ll have a great experience with ByteRover. That’s everything about the OpenClaw Slack and multi-agent setup. You should take a look at these two pages: OpenClaw can run multiple isolated agents within a single gateway process. Each agent has its own workspace, memory, and settings. To route messages to specific agents, you need to configure bindings. A binding acts as a routing rule that says: “When a message comes from this specific channel/account/chat, send it to this specific agent.” Here are the basic steps: Define your agents in the config (agents.list), giving each a unique ID and workspace. Enable your channels (like Slack, WhatsApp, Discord) and configure their accounts/tokens. Create bindings to map incoming traffic to the correct agent based on the channel or specific chat ID You can start with "openclaw agents add" command or directly modify openclaw.json config like this. { "agents": { "list": [ { "id": "my-sub-agent", "workspace": "~/.openclaw/workspace-my-sub-agent" } ] }, "bindings": [ { "agentId": "my-sub-agent", "match": { "channel": "slack", "peer": { "kind": "channel", "id": "C0DDDDDDDD" } } }, ] } C0DDDDDDDD: is slack channelID Please don’t hesitate to DM me if you have any issues, happy to help! 😃
@kevinnguyendn Native memory for OpenClaw is a game-changer.
Thanks man! Threading the active prompt directly into the ContextEngine assembly was the missing piece. Selective retrieval really changes the whole dynamic.
Benzer Videolar
Sensitive content
LLMs are stateless. We built Dria Mem Agent to change that: Making memory a first-class feature. A 4B agent with local interoperable memory across Claude, ChatGPT and LM Studio. It turns LLMs from stateless chat into stateful agents with persistent human-readable memory.
Dria
170,847 görüntüleme • 1 yıl önce
