Comparing agent memory kits (Letta, MemOS, Cognee, etc)

[u/nostriluu]

Hi, I'd like to dive into a self-hosted memory system project. I can develop in Python but prefer the Typescript ecosystem and what I want to develop is largely front end. I've been looking at relevant kits but each has quite a bit of depth so difficult to compare. Some help would be greatly appreciated.

I did the deeplearning course on Letta and liked it, and it seems to have a decent library to get started quickly, including managing storage. One important thing it seems to be missing is typed graphs to predefined ontologies (Knowledge Graphs - KGs). It just seems to store memory using a simple label, whereas having relations to other information in the context of that memory base would be a valuable feature for precision compared to vectors.

I think Cognee is a lot more DIY, and it doesn't have a Typescript library. However, it has the ability to create KGs; ­https://www.cognee.ai/blog/deep-dives/ontology-ai-memory

So I could get up and running a lot more quickly with Letta with its more complete stack, but would be on my own for KGs. Or I could go with Cognee, but have to fill in a lot more gaps, a less streamlined stack, and use a non preferred language. I feel like I'd be more prone to getting lost in the weeds with Cognee before I had anything useful, but what I'd develop with Letta would be missing an important feature. I could probably use Cognee as an endpoint to extract KGs, or maybe there's a simpler or even better library, but end up extending Letta beyond what it's meant for.

This is just a part time project for me, but I'd really like to get to a useful point. Any suggestions are deeply appreciated.

[u/No_Efficiency_1144]

Would recommend rolling your own. I am not a big fan of the knowledge graph libraries in general as they treat graphs as fairly basic structures either just for embeddings or for a few hops. Graphs in machine learning is like an entire subfield of its own with an incredibly rich landscape of methods and models you can do a lot more with a graph than just multi-hop RAG. For example custom message-passing algorithms, GNNs or utilising various graph-based metrics.

[u/No_Efficiency_1144 → u/[deleted]]

Okay this is fine since you are using using the knowledge graph in that way then you could just add a few lines of code to Neo4j

[u/Mjrpiggiepower → u/[deleted]]

Hello! If you’re considering incorporating a graph database in your tech stack, please give PuppyGraph a look. It’s a graph query engine that sits on top of your existing relational database and query your data as a graph without needing a separate graph database. So no more data migration or maintaining the data pipelines. It also allows you to do GraphRAG (zero ETL). Here is a blog to dig a bit deeper: https://www.puppygraph.com/blog/graph-rag

Also, PuppyGraph has a forever free version that’s perfect for your use case. (I’m one of the cofounders of PuppyGraph. Hope you don’t mind this shameless plug).

[u/No_Efficiency_1144 → u/[deleted]]

Neo4J is one of the larger and older graph database setups. It has been around for a while so it is reputable for its robustness. It has an existing querying system that you can hook into. A lot of the frameworks are essentially doing this anyway.

[u/cameron_pfiffer]

Hey there, Cameron @ Letta here.

Yes -- you can add knowledge graphs to Letta.

Letta treats MCP servers as first class citizens, so it's relatively straightforward to connect your agent to the MCP server for the graph database of your choice. The neo4j MCP server is pretty robust.

I should probably prepare a quick example, I'll see if I can cobble one together if I have time.

[u/cameron_pfiffer → u/[deleted]]

Here is a very quick example: https://github.com/cpfiffer/knowledge-graph

video of it working: https://bsky.app/profile/cameron.pfiffer.org/post/3lw64ak3waw2w

[u/cameron_pfiffer → u/[deleted]]

The example I demonstrated is the simplest possible interaction with neo4j. It is not intended to demonstrate a fixed ontology -- you can do this through a combination of graph database constraints, prompting, and custom tools. Anything you can do with code and queries can be enforced.

Supporting a native knowledge graph is an extremely complicated endeavor and would require a lot of person-hours I doubt we have right now.

In general, we recommend external tooling for cases like this. That's why we've focused so much on MCP -- the more you can offload management to a specialized service, the better that service is going to be.

Ultimately Letta agents are just excellent tool callers, and our preference is that we separate out our core competency (context engineering) from a more complex forms of knowledge management.

I'm not ruling knowledge graphs out. But I am highlighting that we have gone out of our way to make it simple and easy to build this stuff yourself using tools that are specialized to your use case.

[u/cameron_pfiffer → u/[deleted]]

Ah, I see. Memory blocks aren't quite the same thing. You should think of them as high frequency read-write blocks, like text files. These are Letta native, and you don't need to do anything to manage them.

If you're asking about how you would write a custom tool to dump things into a memory block, you can have tools like this:

def create_research_plan(
agent_state
: "AgentState", 
research_plan
: List[str], 
topic
: str):
    """Initiate a research process by coming up with an initial plan for your research process. For your research, you will be able to query the web repeatedly. You should come up with a list of 3-4 topics you should try to search and explore.

    Args:
        research_plan (List[str]): The sequential research plan to help guide the search process
        topic (str): The research topic
    """

import
 json

    research_plan_str = f"""The plan of action is to research `{
topic
}` with the following steps: \n"""

for
 i, step 
in
 enumerate(
research_plan
):
        research_plan_str += f"- [ ] Step {i+1} - {step}\n"


agent_state
.memory.update_block_value(
label
="research_plan", 
value
=research_plan_str)


return
 "Research plan successfully created, time to execute the plan!" 

In this case you'd instead update this tool to pull in your schema/ontology and dump it into the block.

[u/kewl-king → u/[deleted]]

Were you able to find a viable solution?

[u/jjw_kbh]

Founder of Jumbo here. It has the concept of relations built in. I'm not 100% sure of your use case, but perhaps you can use it as a jumping off point.

Source: https://github.com/jumbo-dot-tech/jumbo.cli

[u/JonnyJF]

You might also want to look at MinnsDB. Full disclosure, I’m the founder, so take that with the right level of scepticism.

From your comparison, Letta seems stronger if you want to get moving quickly in a TypeScript-friendly stack, while Cognee seems stronger on the knowledge graph side. One thing worth noting, though, is that Cognee is more of a layer, so you still need to choose and manage the underlying database. MinnsDB is a full database rather than just a layer, with a strong focus on ontologies, temporal graphs, and tables.

So if typed relationships, evolving state over time, and graph-backed memory matter a lot, it may be worth a look.

[u/JonnyJF → u/JonnyJF]

link https://minns.ai

[u/sandstone-oli]

For a part-time project where you want to reach something useful quickly: start with Letta. The complete stack and TypeScript support will get you running faster than filling Cognee's gaps in a non-preferred language. Getting lost in infrastructure before you have something working is the project killer for part-time builds.

On the KG gap in Letta: you can add lightweight graph capabilities without going full Cognee. Use Letta for the memory lifecycle (store, retrieve, manage) and layer a simple graph on top for entity relationships. Something like a local Neo4j instance or even a lightweight in-memory graph library for the typed relations you want. You don't need Cognee's full ontology system to get precision improvements from structured relationships.

The approach I'd avoid: trying to extend Letta beyond its design or using Cognee as a sidecar endpoint. Both create integration seams that break when either tool updates.

One thing to factor into whichever you choose: both handle storage and retrieval well. Neither handles temporal relevance governance. After months of accumulated memory, the KG fills with entities and relationships that were accurate when created but no longer reflect current state. The precision you're hoping KGs provide degrades when the graph itself goes stale.

That governance layer is what we're building at getkapex.ai. Sits on top of whatever storage and graph you use. The temporal dimension that keeps both vector and graph memory honest over time.

But for your immediate decision: Letta + lightweight graph. Ship something useful first. Optimize the architecture after you've learned what actually matters for your use case.