Live data from Hacker News

Show HN: Core – open source memory graph for LLMs – shareable, user owned

github.com

21–30 of 43 posts

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#21

I don't see the advantage over a simple text file accessible by MCP. Could you elaborate?

Hey - agreed that for basic fact recall, a simple text file + MCP works fine.

We designed CORE for complex, evolving memory where text files break down.

Example: Health conversations across ChatGPT, Claude, etc. where your parameters change over time.

A text file can't give you: "What medications have I tried, why did I stop each one, and when?" or "Show me how my symptoms evolved over 6 months."

For timeline and relational memory, CORE wins. For static facts, text files are enough i guess.

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#22
post #10

I love how we have come full circle. Anybody remembers the "semantic web" (RDF-based knowledge graph)? It didn't take off because building and maintaining such a graph requires extensive knowledge engineering work and tools. Fast forward a couple of decades and we have LLMs, which is basically auto-complete on steroids based on general knowledge, with the downside that it doesn't "remember" any facts unless you spoon…

Hey - well put!

I guess "semantic web" folks were right about the destination, just few years early :P

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#23

I've been building a memory system myself, so I have some thoughts... Why use a knowledge graph/triples? I have not been able to come up with any use for the predicate or reason to make these associations. Simple flat statements seem entirely sufficient and more accurate to the source material. ... OK, looking a little more, I'm guessing it is a way to see when a memory should be updated; you can match on the first t…

Hey, another co-founder of CORE. Great question about triples vs. fact statements! Your house example actually highlights why we went with a reified graph:

With fact statements, you'd need to decide upfront: is this one "about my house" memory or separate facts? Our approach lets you do both:

Representation flexibility: For your house example, we can model (house, needs repair, attic bath) AND connect it to (attic bathroom, has fixture, bath). The LLM extraction helps maintain consistency, but the graph structure allows both high-level and detailed representations simultaneously.

Updating and deduplication: - We identify potential duplicates/updates by matching subject-predicate patterns - When new information contradicts old (e.g., repair completed), we don't delete - we mark the old statement invalid at timestamp X and create a new valid statement - This maintains a complete history while still showing the current state - The structured format makes conflicts explicit rather than buried in text

The schema isn't rigid - we have predefined types (Person, Place, etc.), but relationships form dynamically. This gives structure where helpful, but flexibility where needed.

In practice, we've found this approach more deterministic for tracking knowledge evolution while still preserving the context and nuance of natural language through provenance links.

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#24

how would you say you compare to graphiti from zep?

Hi, There are 3 major differences between Zep and CORE 1. Market: Zep is B2B focused, CORE indvidual users 2. Portablity: Zep is locked to their platform , CORE works across claude, cursor, windsurf 3. Architecture: Zep is Temporal based vs CORE is Reified + Temporal based graph What this means: Zep remembers what happened when CORE remembers what happened when + why we should believe it + how facts relate Example: Y…

Graphiti is free and open source. It's MCP server works with any MCP client, from Cursor to Claude, too...

Graphiti MCP has tens of thousands of users. They deploy it to their desktops, servers, you name it. And for many different use cases: B2B, B2C, and personal use.

More here: https://github.com/getzep/graphiti

Source: me, one of the authors of Graphiti :-)

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#25
post #8

So, this is cool and a per-user memory is obviously relevant for effective LLM use. And major props for the temporal focus. However, keeping a tight, constrained context turns out to actually be pretty important for correct LLM results ( https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-ho... ). Do you have a take on how we reconcile the tension between these objectives? How to make sure the model has access…

hey, thanks for the article reference. i read it.

that's the exact problem we've been solving! Context bloat vs. memory depth is the core challenge.

our approach tackles this by being selective, not comprehensive. We don't dump everything into context - instead, we:

- use graph structure to identify truly relevant facts (not just keyword matches) - leverage temporal tracking to prioritize current information and filter out outdated beliefs - structure memories as discrete statements that can be included/excluded individually the big advantage? Instead of retrieving entire conversations or documents, we can pull just the specific facts and relevant episodes needed for a given query.

it's like having a good assistant who knows when to remind you about something relevant without overwhelming you with every tangentially related memory.

the graph structure also gives users more transparency - they can see exactly which memories are influencing responses and why, rather than a black-box retrieval system.

ps: one of the authors of CORE

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#26
post #10

I love how we have come full circle. Anybody remembers the "semantic web" (RDF-based knowledge graph)? It didn't take off because building and maintaining such a graph requires extensive knowledge engineering work and tools. Fast forward a couple of decades and we have LLMs, which is basically auto-complete on steroids based on general knowledge, with the downside that it doesn't "remember" any facts unless you spoon…

The problem with semantic web was deeper, people had to agree on the semantics that would be formalized as triples and getting people to agree on an ongoing basis is not an easy task.

My question is, what’s the value of explicitly storing semantics as triples when the LLM can infer the semantics on runtime?

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#27
post #25
post #8

So, this is cool and a per-user memory is obviously relevant for effective LLM use. And major props for the temporal focus. However, keeping a tight, constrained context turns out to actually be pretty important for correct LLM results ( https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-ho... ). Do you have a take on how we reconcile the tension between these objectives? How to make sure the model has access…

hey, thanks for the article reference. i read it. that's the exact problem we've been solving! Context bloat vs. memory depth is the core challenge. our approach tackles this by being selective, not comprehensive. We don't dump everything into context - instead, we: - use graph structure to identify truly relevant facts (not just keyword matches) - leverage temporal tracking to prioritize current information and filt…

One of the challenges I was facing with other memory MCP servers is to get the LLM clients to actually use it to recall relevant information when they need it. Implementing to MCP tools is one thing, getting LLM clients to invoke them at the right time is another.

How do you solve that problem?

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#28
post #25

Earlier quoted context omitted.

hey, thanks for the article reference. i read it. that's the exact problem we've been solving! Context bloat vs. memory depth is the core challenge. our approach tackles this by being selective, not comprehensive. We don't dump everything into context - instead, we: - use graph structure to identify truly relevant facts (not just keyword matches) - leverage temporal tracking to prioritize current information and filt…

One of the challenges I was facing with other memory MCP servers is to get the LLM clients to actually use it to recall relevant information when they need it. Implementing to MCP tools is one thing, getting LLM clients to invoke them at the right time is another. How do you solve that problem?

We faced the same challenge while building SOL (https://github.com/RedPlanetHQ/sol) — a personal assistant that relies heavily on memory for context and continuity.

Getting LLMs to invoke memory tools at the right time is definitely trickier than just wiring up MCP correctly. We're still refining it, but we've made good progress by explicitly guiding the assistant within the system prompt on when and how to use memory.

You can see an example of how we structure this in SOL here: Prompt instructions for memory usage (https://github.com/RedPlanetHQ/sol/blob/964ed23c885910e040bd...)

Using something on similar lines as rules in claude/cursor etc has been working better. It’s not perfect yet, but this combination of prompt engineering and structured tool exposure has been moving us in the right direction.

ps - one of the authors of CORE

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#29
I’ve been thinking about how to do this well, how my memory actually works. I think what is happening is I’ve either got the facts now (that is easy to repro w/ a system like this) or I’ve got an idea that I could have the facts after working on retrieval. It’s like I’ve got a feeling or sense that somewhere in cold storage is the info I need so I kick off a background process to get it. Sometimes it works.

That second system, the “I know this…” system is I think what is missing from these LLMs. They have the first one, they KNOW things they’ve seen during training, but what I think is missing is the ability to build up the working set as they are doing things, then get the “feeling” that they could know this if they did a little retrieval work. I’ve been thinking about how to repro that in a computer where knowledge is 0|1, but could be slow to fetch

Re: Show HN: Core – open source memory graph for LLMs – shareable, user owned

#30
post #26
post #10

I love how we have come full circle. Anybody remembers the "semantic web" (RDF-based knowledge graph)? It didn't take off because building and maintaining such a graph requires extensive knowledge engineering work and tools. Fast forward a couple of decades and we have LLMs, which is basically auto-complete on steroids based on general knowledge, with the downside that it doesn't "remember" any facts unless you spoon…

The problem with semantic web was deeper, people had to agree on the semantics that would be formalized as triples and getting people to agree on an ongoing basis is not an easy task. My question is, what’s the value of explicitly storing semantics as triples when the LLM can infer the semantics on runtime?

Not much tbh. I'm using markdown files as a memory bank[1] for my projects and it works well without the need to structure them in a schema/graph. But I guess one benefit of this particular memory graph implementation is its temporal aspect: searchable facts can evolve over time; i.e. what is true now and how it got here.

[1] https://docs.cline.bot/prompting/cline-memory-bank

Post reply on HN