5 ms·

Yes, that is actually the next thing we are shipping! We have heard from a ton of OpenClaw users that the biggest barrier to them getting everything they want

Yes, that is actually the next thing we are shipping! We have heard from a ton of OpenClaw users that the biggest barrier to them getting everything they want out of their agents is that memory is not a solved problem. LCM could be a great solution to that. Stay tuned -- will ship it ASAP.

vessenes 7mo ago
Love it. Yes, compaction is a huge pain point in openclaw, and it EATS tokens.
vessenes 7mo ago
Riffing on this a little, there’s a few things that would be useful: 1 - global namespace - for the gateway agent/coordinator - would make inspecting results of subagent tasks much more safe and efficient, and all the benefits of precision across compaction boundaries for the main chat thread. I could see giving the subagents access to it, or just prompting them fresh and storing results in the global memory - probably the second is better. 2 - permissioned memory spaces - stuff that a given subagent should know without giving them global memory access. Then a gateway could mark some stuff ‘available’ as part of prompting. This would be a super useful set of primitives - from reading the paper, I think you could do this relatively cheaply, maybe a tagging system for branches/nodes in the DAG. openclaw keeps some sort of track of what subagents should have access to already in the form of skills, but I haven’t looked into the actual permissions architecture.
- ClintEhrlich 7mo ago
  Just passed this on to my co-author who is working on the plug-in. Really appreciate the suggestions! We will probably ship a fairly basic version to start, but I think there are a lot of cool things that can be added.
  - vessenes 7mo ago
    Awesome! Looking forward to it
- belisarius222 7mo ago
  Did somebody say 'global namespace'? I spent years working on one of those as part of Urbit... In general, I think you're right. Each conversation is an append-only log at the lowest layer, and I see no reason not to expose that fact as a global namespace, as long as permissions are handled gracefully. Of course getting permissions to work well might be easier said than done, but I like this direction.

vessenes 7mo ago

Love it. Yes, compaction is a huge pain point in openclaw, and it EATS tokens.

vessenes 7mo ago

Riffing on this a little, there’s a few things that would be useful: 1 - global namespace - for the gateway agent/coordinator - would make inspecting results of subagent tasks much more safe and efficient, and all the benefits of precision across compaction boundaries for the main chat thread. I could see giving the subagents access to it, or just prompting them fresh and storing results in the global memory - probably the second is better. 2 - permissioned memory spaces - stuff that a given subagent should know without giving them global memory access. Then a gateway could mark some stuff ‘available’ as part of prompting. This would be a super useful set of primitives - from reading the paper, I think you could do this relatively cheaply, maybe a tagging system for branches/nodes in the DAG. openclaw keeps some sort of track of what subagents should have access to already in the form of skills, but I haven’t looked into the actual permissions architecture.

ClintEhrlich 7mo ago
Just passed this on to my co-author who is working on the plug-in. Really appreciate the suggestions! We will probably ship a fairly basic version to start, but I think there are a lot of cool things that can be added.
- vessenes 7mo ago
  Awesome! Looking forward to it
belisarius222 7mo ago
Did somebody say 'global namespace'? I spent years working on one of those as part of Urbit... In general, I think you're right. Each conversation is an append-only log at the lowest layer, and I see no reason not to expose that fact as a global namespace, as long as permissions are handled gracefully. Of course getting permissions to work well might be easier said than done, but I like this direction.