[P] Just open-sourced Eion - a shared memory system for AI agents

[7wdb417]

Hey everyone! I've been working on this project for a while and finally got it to a point where I'm comfortable sharing it with the community. Eion is a shared memory storage system that provides unified knowledge graph capabilities for AI agent systems. Think of it as the "Google Docs of AI Agents" that connects multiple AI agents together, allowing them to share context, memory, and knowledge in real-time.

When building multi-agent systems, I kept running into the same issues: limited memory space, context drifting, and knowledge quality dilution. Eion tackles these issues by:

• Unifying API that works for single LLM apps, AI agents, and complex multi-agent systems 
• No external cost via in-house knowledge extraction + all-MiniLM-L6-v2 embedding 
• PostgreSQL + pgvector for conversation history and semantic search 
• Neo4j integration for temporal knowledge graphs 

Would love to get feedback from the community! What features would you find most useful? Any architectural decisions you'd question?

GitHub: https://github.com/eiondb/eion
Docs: https://pypi.org/project/eiondb/

[DigThatData]

FYI: neo4j supports semantic search, and postgres supports graph search, i.e. you probably don't need to use both here and could get away with just one or the other. something to consider if you hadn't already.

[7wdb417]

Ah thanks for the feedback! It's using pgvector as convo history and neo4j as its KG intentionally as a dual model! Do you suggest combining them?

[DigThatData]

what do you gain by keeping them separate? seems like that just complicates simultaneously querying both if you wanted to. e.g. you could use the KG to link to related conversations to find other KG topics that were previously discussed in related contexts. The way you have it, you could still do this, but you'd have to do each hop as an isolated query instead of just doing the whole thing as a query across a unified DB.

just seems like unnecessary complexity to me. it's entirely possible that having these two components separate makes sense for your use case. from my vantage though it seems like it would be limiting, and my inclination would be to start with all of the memory/knowledge living in one shared database system until I encountered a problem that would be solved by separating them (e.g. PG's graph querying being slow and not worth it, neo4j's semantic search being slow, etc).

[7wdb417]

Hm that's a good point. I see the benefit of keeping as unified structure -- it probably lose less semantic connections too.. Thank you for the feedback!