4 ms·

I'm not sure how many HN users frequent other places related to agentic coding like the subreddits of particular providers, but this has got to be the 1000th "u

by gbnwl 10mo ago

I'm not sure how many HN users frequent other places related to agentic coding like the subreddits of particular providers, but this has got to be the 1000th "ultimate memory system"/break-free-of-the-context-limit-tyranny! project I've seen, and like all other similar projects there's never any evidence or even attempt at measuring any metric of performance improved by it. Of course it's hard to measure such a thing, but that's part of exactly why it's hard to build something like this. Here's user #1001 that's been told by Claude "What a fascinating idea! You've identified a real gap in the market for a simple database based memory system to extend agent memory."

austinbaggio 10mo ago
Which of the 1000 is your favorite? There does seem to be a shallow race to optimizing xyz benchmark for some narrow sliver of the context problem, but you're right, context problem space is big, so I don't think we'll hurry to join that narrow race.
- gbnwl 10mo ago
  | Which of the 1000 is your favorite? None, that's what I'm trying to say. My favorite is just storing project context locally in docs that agents can discover on their own or I can point to if needed. This doesn't require me to upload sensitive code or information to anonymous people's side projects and has and equivalent amount of hard evidence for efficacy (zero), but at least has my own anecdotal evidence of helping and doesn't invite additonal security risk. People go way overboard with MCPs and armies of subagents built on wishes and unproven memory systems because no one really knows for sure how to get past the spot we all hit where the agentic project that was progressing perfectly hits a sharp downtrend in progress. Doesn't mean it's time to send our data to strangers.
  - gck1 10mo ago
    > no one really knows for sure how to get past the spot we all hit where the agentic project that was progressing perfectly hits a sharp downtrend in progress. FWIW, I find this eventual degradation point comes much later and with fewer consequences when there are strict guardrails inside and outside of the LLM itself. From what I've seen, most people try to fix only the "inside" part - by tweaking the prompts, installing 500 MCPs (that ironically pollute the context and make problem worse), yell in uppercase in hopes that it will remember etc, and ignore that automated compliance checks existed way before LLMs. Throw the strictest and most masochistic linting rules at it in a language that is masochistic itself (e.g. rust), add tons of integration tests that encode intent, add a stop hook in CC that runs all these checks and you've got a system that is simply not allowed to silently drift and can put itself back on track with feedback it gets from it. Basically, rather than trying to hypnotize an agent to remember everything by writing a 5000 line agents.md, just let the code itself scream at it and feed the context.
- Davidzheng 10mo ago
  Wait.
Forgeties79 10mo ago
Have you tried using it? Not being flippant and annoying. Just curious if you tried it and what the results were
- gbnwl 10mo ago
  Who has time to try this when there's this huge backlog here: https://www.reddit.com/r/ClaudeAI/search/?q=memory https://www.reddit.com/r/ClaudeAI/search/?q=memory
  - deleted 10mo ago
    [deleted]
  - Forgeties79 10mo ago
    Have you tried any of those?
    - gbnwl 10mo ago
      Yes, they haven't helped. Have you found one that works for you?
      - austinbaggio 10mo ago
        What are you both looking for? What is the problem you want solved?
        ggm 10mo ago
        Is a series of postings all in the form of questions an indication somebody hooked "eliza" up as an input device?
        morkalork 10mo ago
        Nah, just another one of those spam bots on all the small-business, finance and tradies sub-reddits: "Hey fellow users, have you ever suffered from <use case>? What is the problem you want solved? Tell me your honest opinions below!"
AndyNemmity 10mo ago
The funny part is, the vast majority of them are barely doing anything at all. All of these systems are for managing context. You can generally tell which ones are actually doing something if they are using skills, with programs in them. Because then, you're actually attaching some sort of feature to the system. Otherwise, you're just feeding in different prompts and steps, which can add some value, but okay, it doesn't take much to do that. Like adding image generation to claude code with google nano banana, a python script that does it. That's actually adding something claude code doesn't have, instead of just saying "You are an expert in blah"
- austinbaggio 10mo ago
  It sounds like you've used quite a few. What programs are you expecting? Assuming you're talking about doing some inference on the data? Or optimizing for some RAG or something?
  - AndyNemmity 10mo ago
    An example of a skill i gave, adding image generation to nano banana. another is one claude code ships with, using rip grep. Those are actual features. It's adding deterministic programs that the llm calls when it needs something.
    - austinbaggio 10mo ago
      Oh got it - tool use
      - AndyNemmity 10mo ago
        Exactly. That adds actual value. Some of the 1000s of projects do this. Those pieces add value, if the tool adds value which also isn’t a given
- troupo 10mo ago
  > You can generally tell which ones are actually doing something if they are using skills, with programs in them. > Otherwise, you're just feeding in different prompts and steps "skills" are literally just .md files with different prompts and steps. > That's actually adding something claude code doesn't have, instead of just saying "You are an expert in blah" It's not adding anything but a prompt saying "when asked to do X invoke script Y or do steps Z"
johnnyfived 10mo ago
I imagine HN, despite being full of experts and vet devs, also might have a prevalent attitude of looking down on using tools like MCP servers or agentic AI libraries for coding, which might be why something like this advertised seems novel rather than redundant.
- DrewADesign 10mo ago
  > I imagine HN, despite being full of experts and vet devs, also might have a prevalent attitude of looking down on using tools like MCP servers or agentic AI libraries for coding, which might be why something like this advertised seems novel rather than redundant. I’m not sure where the ‘despite’ comes in. Experts and vets have opinions and this is probably the best online forum to express them. Lots of experts and vets also dislike extremely popular unrelated tools like VB, Windows, “no-code” systems, and Google web search… it’s not a personality flaw. It doesn’t automatically mean they’re right, either, but ‘expert’ and ‘vet’ are earned statuses, and that means something. We’ve seen trends come and go and empires rise and fall, and been repeatedly showered in the related hype/PR/FUD. Not reflexively embracing everything that some critical mass of other people like is totally fine.
  - gbnwl 10mo ago
    I think maybe the point they were trying to make is that despite people on HN being very technically experienced, skepticism and distrust of LLM-assisted coding tools may have prevented many of them from exploring the space too deeply yet. So a project like this may seem novel to many readers here, when the reality for users who've been using and following tools like Claude Code (and similar) closely for a while now is that claims like the one's this project is making come out multiple times per week.
    - johnnyfived 10mo ago
      They pretty much perfectly encapsulated the point in their fired up response haha.
      - 10mo ago
beefsack 10mo ago
I feel like so many of these memory solutions are incredibly over-engineered too. You can work around a lot of the memory issues for large and complex tasks just by making the agent keep work logs. Critical context to keep throughout large pieces of work include decisions, conversations, investigations, plans and implementations - a normal developer should be tracking these and it's sensible to have the agent track them too in a way that survives compaction.
- ramoz 10mo ago
  Great advise. For large plans I tell the agent to write to an “implementation_log.md” and make note of it during compaction. Additionally the agent can also just reference the original session logs.
  - hasperdi 10mo ago
    The problem with this approach, is that the model may forget to update the log... It usually happens when the context window >50% filled
    - ilvez 10mo ago
      .. and not only those, but the baseline as well aka CLAUDE.md.. I've countless of times told it basics, in the same session without compacting etc etc
    - ramoz 10mo ago
      I found this happen less often if the task is a part of the plan. It typically gets in a cycle habit of editing code and updating the doc
      - hasperdi 10mo ago
        thanks, I'll keep that in mind
- SkyPuncher 10mo ago
  Yep. I just have my agents write out key details to a markdown file. Doesn’t have to be perfect. Just enough to reorient itself to a problem.
willtemperley 10mo ago
Replace "Automation" with "Agentic coding" here: https://xkcd.com/1319/ https://xkcd.com/1319/
stingraycharles 10mo ago
imho, if it’s not based on a RAG, it’s not a real memory system. the agent often doesn’t know what it doesn’t know, and as such relevant memories must be pushed into the context window by embedding distance, not actively looked up.
xnx 10mo ago
Some with a coding background love prompt engineering, contrived supporting systems, json prompting and any other superstition that makes it feel like they're really doing something. They refuse to believe that it's possible to instruct these tools in terse plain English and get useful results.
christinetyip 10mo ago
This is fair, many memory projects out there boil down to better summaries or prompt glue without any clear way to measure impact. One thing I’d clarify about what we’re building is that it’s not meant to be “the best memory for a single agent.” The core idea is portability and sharing, not just persistence. Concretely: - you can give Codex access to memory created while working in Claude - Claude Code can retrieve context from work done in other tools - multiple agents can read/write the same memory instead of each carrying their own partial copy - specific parts of context can be shared with teammates or collaborators That’s the part that’s hard (or impossible) to do with markdown files or tool-local memory, and it’s also why we don’t frame this as “breaking the context limit.” Measuring impact here is tricky, but the problem we’re solving shows up as fragmentation rather than forgetting: duplicated explanations, divergent state between agents, and lost context when switching tools or models. If someone only uses a single agent in a single tool and already are using their customized CLAUDE.md, they probably don’t need this. The value shows up once you treat agents as interchangeable workers rather than a single long-running conversation.
- gbnwl 10mo ago
  > That’s the part that’s hard (or impossible) to do with markdown files or tool-local memory. I'm confused because every single thing in that list is trivial? Why would Codex have trouble reading a markdown file Claude wrote or vice versa? Why would multiple agents need their own copy of the markdown file instead of just referring to it as needed? Why would it be hard to share specific files with teammates or collaborators? Edit - I realize I could be more helpful if I actually shared how I manage project context: CLAUDE.md or Agents.md is not the only place to store context for agents in a project, you can just store docs at any layer of granularity you want. What's worked best for me is to: 1. Have a standards doc(s) (you can point the agents to the same standards doc in their respective claude.md/agents.md) 2. Before coding, have the agent create implementation plans that get stored in to tickets (markdown files) for each chunk of work that would take about a context window length (estimated). 3. Work through the tickets and update them as completed. Easy to refer back to when needed. 4. If you want you can ask the agent to contribute to an overall dev log as well, but this gets long fast. Is useful for agents to refer to the last 50 lines or so to immediately get up to speed on "what just happened?", but so could git history. 5. Ultimately the code is going to be the real "memory" of the true state, so try to organize it in a way that's easy for agents to comb through (no 5000 lines files that agents have trouble trying to carefully jump around in to find what they need without eating up their entire context window immediately).

by gbnwl 10mo ago

austinbaggio 10mo ago

Which of the 1000 is your favorite? There does seem to be a shallow race to optimizing xyz benchmark for some narrow sliver of the context problem, but you're right, context problem space is big, so I don't think we'll hurry to join that narrow race.

gbnwl 10mo ago
| Which of the 1000 is your favorite? None, that's what I'm trying to say. My favorite is just storing project context locally in docs that agents can discover on their own or I can point to if needed. This doesn't require me to upload sensitive code or information to anonymous people's side projects and has and equivalent amount of hard evidence for efficacy (zero), but at least has my own anecdotal evidence of helping and doesn't invite additonal security risk. People go way overboard with MCPs and armies of subagents built on wishes and unproven memory systems because no one really knows for sure how to get past the spot we all hit where the agentic project that was progressing perfectly hits a sharp downtrend in progress. Doesn't mean it's time to send our data to strangers.
- gck1 10mo ago
  > no one really knows for sure how to get past the spot we all hit where the agentic project that was progressing perfectly hits a sharp downtrend in progress. FWIW, I find this eventual degradation point comes much later and with fewer consequences when there are strict guardrails inside and outside of the LLM itself. From what I've seen, most people try to fix only the "inside" part - by tweaking the prompts, installing 500 MCPs (that ironically pollute the context and make problem worse), yell in uppercase in hopes that it will remember etc, and ignore that automated compliance checks existed way before LLMs. Throw the strictest and most masochistic linting rules at it in a language that is masochistic itself (e.g. rust), add tons of integration tests that encode intent, add a stop hook in CC that runs all these checks and you've got a system that is simply not allowed to silently drift and can put itself back on track with feedback it gets from it. Basically, rather than trying to hypnotize an agent to remember everything by writing a 5000 line agents.md, just let the code itself scream at it and feed the context.
Davidzheng 10mo ago
Wait.

Forgeties79 10mo ago

Have you tried using it? Not being flippant and annoying. Just curious if you tried it and what the results were

gbnwl 10mo ago
Who has time to try this when there's this huge backlog here: https://www.reddit.com/r/ClaudeAI/search/?q=memory https://www.reddit.com/r/ClaudeAI/search/?q=memory
- deleted 10mo ago
  [deleted]
- Forgeties79 10mo ago
  Have you tried any of those?
  - gbnwl 10mo ago
    Yes, they haven't helped. Have you found one that works for you?
    - austinbaggio 10mo ago
      What are you both looking for? What is the problem you want solved?
      - ggm 10mo ago
        Is a series of postings all in the form of questions an indication somebody hooked "eliza" up as an input device?
        morkalork 10mo ago
        Nah, just another one of those spam bots on all the small-business, finance and tradies sub-reddits: "Hey fellow users, have you ever suffered from <use case>? What is the problem you want solved? Tell me your honest opinions below!"

AndyNemmity 10mo ago

The funny part is, the vast majority of them are barely doing anything at all. All of these systems are for managing context. You can generally tell which ones are actually doing something if they are using skills, with programs in them. Because then, you're actually attaching some sort of feature to the system. Otherwise, you're just feeding in different prompts and steps, which can add some value, but okay, it doesn't take much to do that. Like adding image generation to claude code with google nano banana, a python script that does it. That's actually adding something claude code doesn't have, instead of just saying "You are an expert in blah"

austinbaggio 10mo ago
It sounds like you've used quite a few. What programs are you expecting? Assuming you're talking about doing some inference on the data? Or optimizing for some RAG or something?
- AndyNemmity 10mo ago
  An example of a skill i gave, adding image generation to nano banana. another is one claude code ships with, using rip grep. Those are actual features. It's adding deterministic programs that the llm calls when it needs something.
  - austinbaggio 10mo ago
    Oh got it - tool use
    - AndyNemmity 10mo ago
      Exactly. That adds actual value. Some of the 1000s of projects do this. Those pieces add value, if the tool adds value which also isn’t a given
troupo 10mo ago
> You can generally tell which ones are actually doing something if they are using skills, with programs in them. > Otherwise, you're just feeding in different prompts and steps "skills" are literally just .md files with different prompts and steps. > That's actually adding something claude code doesn't have, instead of just saying "You are an expert in blah" It's not adding anything but a prompt saying "when asked to do X invoke script Y or do steps Z"

johnnyfived 10mo ago

I imagine HN, despite being full of experts and vet devs, also might have a prevalent attitude of looking down on using tools like MCP servers or agentic AI libraries for coding, which might be why something like this advertised seems novel rather than redundant.

DrewADesign 10mo ago
> I imagine HN, despite being full of experts and vet devs, also might have a prevalent attitude of looking down on using tools like MCP servers or agentic AI libraries for coding, which might be why something like this advertised seems novel rather than redundant. I’m not sure where the ‘despite’ comes in. Experts and vets have opinions and this is probably the best online forum to express them. Lots of experts and vets also dislike extremely popular unrelated tools like VB, Windows, “no-code” systems, and Google web search… it’s not a personality flaw. It doesn’t automatically mean they’re right, either, but ‘expert’ and ‘vet’ are earned statuses, and that means something. We’ve seen trends come and go and empires rise and fall, and been repeatedly showered in the related hype/PR/FUD. Not reflexively embracing everything that some critical mass of other people like is totally fine.
- gbnwl 10mo ago
  I think maybe the point they were trying to make is that despite people on HN being very technically experienced, skepticism and distrust of LLM-assisted coding tools may have prevented many of them from exploring the space too deeply yet. So a project like this may seem novel to many readers here, when the reality for users who've been using and following tools like Claude Code (and similar) closely for a while now is that claims like the one's this project is making come out multiple times per week.
  - johnnyfived 10mo ago
    They pretty much perfectly encapsulated the point in their fired up response haha.
    - 10mo ago

beefsack 10mo ago

I feel like so many of these memory solutions are incredibly over-engineered too. You can work around a lot of the memory issues for large and complex tasks just by making the agent keep work logs. Critical context to keep throughout large pieces of work include decisions, conversations, investigations, plans and implementations - a normal developer should be tracking these and it's sensible to have the agent track them too in a way that survives compaction.

ramoz 10mo ago
Great advise. For large plans I tell the agent to write to an “implementation_log.md” and make note of it during compaction. Additionally the agent can also just reference the original session logs.
- hasperdi 10mo ago
  The problem with this approach, is that the model may forget to update the log... It usually happens when the context window >50% filled
  - ilvez 10mo ago
    .. and not only those, but the baseline as well aka CLAUDE.md.. I've countless of times told it basics, in the same session without compacting etc etc
  - ramoz 10mo ago
    I found this happen less often if the task is a part of the plan. It typically gets in a cycle habit of editing code and updating the doc
    - hasperdi 10mo ago
      thanks, I'll keep that in mind
SkyPuncher 10mo ago
Yep. I just have my agents write out key details to a markdown file. Doesn’t have to be perfect. Just enough to reorient itself to a problem.

willtemperley 10mo ago

Replace "Automation" with "Agentic coding" here: https://xkcd.com/1319/ https://xkcd.com/1319/

stingraycharles 10mo ago

imho, if it’s not based on a RAG, it’s not a real memory system. the agent often doesn’t know what it doesn’t know, and as such relevant memories must be pushed into the context window by embedding distance, not actively looked up.

xnx 10mo ago

Some with a coding background love prompt engineering, contrived supporting systems, json prompting and any other superstition that makes it feel like they're really doing something. They refuse to believe that it's possible to instruct these tools in terse plain English and get useful results.

christinetyip 10mo ago

This is fair, many memory projects out there boil down to better summaries or prompt glue without any clear way to measure impact. One thing I’d clarify about what we’re building is that it’s not meant to be “the best memory for a single agent.” The core idea is portability and sharing, not just persistence. Concretely: - you can give Codex access to memory created while working in Claude - Claude Code can retrieve context from work done in other tools - multiple agents can read/write the same memory instead of each carrying their own partial copy - specific parts of context can be shared with teammates or collaborators That’s the part that’s hard (or impossible) to do with markdown files or tool-local memory, and it’s also why we don’t frame this as “breaking the context limit.” Measuring impact here is tricky, but the problem we’re solving shows up as fragmentation rather than forgetting: duplicated explanations, divergent state between agents, and lost context when switching tools or models. If someone only uses a single agent in a single tool and already are using their customized CLAUDE.md, they probably don’t need this. The value shows up once you treat agents as interchangeable workers rather than a single long-running conversation.

gbnwl 10mo ago
> That’s the part that’s hard (or impossible) to do with markdown files or tool-local memory. I'm confused because every single thing in that list is trivial? Why would Codex have trouble reading a markdown file Claude wrote or vice versa? Why would multiple agents need their own copy of the markdown file instead of just referring to it as needed? Why would it be hard to share specific files with teammates or collaborators? Edit - I realize I could be more helpful if I actually shared how I manage project context: CLAUDE.md or Agents.md is not the only place to store context for agents in a project, you can just store docs at any layer of granularity you want. What's worked best for me is to: 1. Have a standards doc(s) (you can point the agents to the same standards doc in their respective claude.md/agents.md) 2. Before coding, have the agent create implementation plans that get stored in to tickets (markdown files) for each chunk of work that would take about a context window length (estimated). 3. Work through the tickets and update them as completed. Easy to refer back to when needed. 4. If you want you can ask the agent to contribute to an overall dev log as well, but this gets long fast. Is useful for agents to refer to the last 50 lines or so to immediately get up to speed on "what just happened?", but so could git history. 5. Ultimately the code is going to be the real "memory" of the true state, so try to organize it in a way that's easy for agents to comb through (no 5000 lines files that agents have trouble trying to carefully jump around in to find what they need without eating up their entire context window immediately).