Manoj58 (u/Manoj58) - Readit News

Manoj58 commented on Show HN: Core – open source memory graph for LLMs – shareable, user owned github.com/RedPlanetHQ/co... · Posted by u/Manik_agg

hanszarkov · 2 months ago

Does this work with Claude?

Manoj58 · 2 months ago

We support MCP server which you can use to connect to claude

https://github.com/RedPlanetHQ/core/blob/main/README.md You can check in our readme on how to use mcp server

Manoj58 commented on Show HN: Core – open source memory graph for LLMs – shareable, user owned github.com/RedPlanetHQ/co... · Posted by u/Manik_agg

cpard · 2 months ago

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?

Manoj58 · 2 months ago

This is something we brainstorm a lot on. While LLMs can infer semantics at runtime, we got biased to explicit triples for these reasons:

Efficient, precise retrieval through graph traversal patterns that flat text simply can't match ("find all X related to Y through relationship Z")

Algorithmic contradiction detection by matching subject-predicate pairs across time, which LLMs struggle with across distant contexts

Our goal is also to make assistant more proactive, where triplets make pattern recognition more easy and effective

what do you think about these?

Manoj58 commented on Show HN: Core – open source memory graph for LLMs – shareable, user owned github.com/RedPlanetHQ/co... · Posted by u/Manik_agg

MarkMarine · 2 months ago

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

Manoj58 · 2 months ago

You've identified a fundamental gap - that meta-cognitive "I could retrieve this" intuition that humans have but LLMs lack.

Our graph approach addresses this: - Structure knowledge with visible relationship patterns before loading details

- Retrieval system "senses" related information without fetching everything

- Temporal tracking prioritizes recent/relevant information

- Planning recall frequency tracking for higher weightage on accessed facts

In SOL(personal assistant), we guide LLMs to use memory more effectively by providing structured knowledge boundaries. This creates that "I could know this if I looked" capability.

Manoj58 commented on Show HN: Core – open source memory graph for LLMs – shareable, user owned github.com/RedPlanetHQ/co... · Posted by u/Manik_agg

lukev · 2 months ago

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 to relevant info, while explicitly excluding irrelevant or confounding factors from the context?

Manoj58 · 2 months ago

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

Manoj58 commented on Show HN: Core – open source memory graph for LLMs – shareable, user owned github.com/RedPlanetHQ/co... · Posted by u/Manik_agg

ianbicking · 2 months ago

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 two items of the predicate. In a sense you are normalizing the input and hoping that shows an update or duplicate memory.

I would be curious how well this works in practice. I've spent a fair amount of effort trying to merge and deduplicate memories in a more ad hoc way, generally using the LLM for this process (giving it a new memory and a list of old memories). It would feel much more deterministic and understandable to do this in a structured way. On the other hand I'm not sure how stable these triples would be. Would they all end up attached to the user? And will the predicate be helpful to establish meaningful relationships, or could the memories simply be attached to an entity?

For instance I could list a bunch of facts related to my house: the address, which room I sleep in, upcoming and past repairs, observations on the yard, etc. Many (but not all) of these could be best represented as one "about my house" memory, with all the details embedded in one string of natural language text. It would be great to structure repairs... but how will that work? (my house, needs repair, attic bath)? Or (my house, has room, attic bathroom) and (attic bathroom, needs repair, bath)? Will the system pick one somewhat arbitrarily then, being able to see that past memory, replicate its structure?

Another representation that occurs to for detecting duplicates and updates is simply "is related to entities". This creates a flatter database where there's less ambiguity in how memories are represented.

Anyway, that's one area that stuck out to me. It wasn't clear to me where the schema for memories is in the codebase, I think that would be very useful to understanding the system.

Manoj58 · 2 months ago

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.

Manoj58 commented on · Posted by u/harshithmul

_boffin_ · a year ago

One of the things I’m doing at work is working on an agent that checks the documentation against the ticket and attempts to confirm the spec in the ticket is correct. Another flow is to also check the ticket and check if a “rational” software engineer had enough information to make an informed decision to complete the task. If not, provide suggestions as a comment on how to improve the ticket.

Manoj58 · a year ago

I'm more curious about how you've implemented this.

Manoj58 commented on Ask HN: How are you handling SaaS integrations for LLM's? · Posted by u/Manoj58

victorsup · 2 years ago

You have to be more specific. Do you mean feeding mailing and documents a LLM to train your new model?

Manoj58 · 2 years ago

I mean how do you get data from mailing and documents data to feed LLM's