ontogr

OntoGr Agent Memory: open source memory for agents where every fact keeps its quote, source, and time I've been working on RAG and agent memory, and the recurring problem is trust. An agent saves something it learned, and later nobody can say where it came from, whether it is still true, or what it believed at an earlier date. We're building an open source Python library for this. - Grounded ingestion and extraction: Messages, documents, tool outputs, events, and record rows become episodes. Entities and facts are extracted in two separate passes, and every fact carries a verbatim quote from its episode. - Per-tenant ontology: Each tenant defines the entity and relation types it allows. A model can propose additions, but a person approves every change. - Reversible entity resolution: It uses the cheapest evidence first and asks a model only about ambiguous pairs. Every merge can be undone. - Two time axes: Valid time and system time let a read ask what was true on a date, or what the system believed on that date. A new value closes the old version instead of overwriting it. - Contradiction rulings: Rules, an optional model judge, and a person's decision settle conflicts, and the person's decision overrides both. A failed judge call is never stored as "no conflict". - Traceable and auditable: Every fact traces back to a quote and an episode, and every temporal write goes into a hash-chained ledger. Per-tenant grants, an audit log, previewed and resumable forget and erase, and deterministic export are built in. - Four-lane retrieval: Vector, keyword, entity, and graph lanes are fused with reciprocal rank fusion. The result is a token-budgeted context block that reports which lanes failed. - Fits your stack: It runs on FalkorDB or Neo4j, with pgvector or Postgres if you want them. A background consolidation job deduplicates, summarizes, scores, and archives. You bring your own LLM and embedder. Repo: ontogr/ontogr-agent-memory I'd like feedback on the time model and on which benchmarks you'd want to see first.

Agentic GraphRAG: an open source library connecting document knowledge and agent memory using a 3D graph We're building Agentic GraphRAG (ontogr/agentic-graphrag), an open source library for connecting the documents an agent reads with its task history and decisions. I've worked on RAG systems and LLM training for the past three and a half years. Lately, I've been following how agents retain work across sessions, especially coding agents. Our project explores how that memory can stay connected to the knowledge an agent used, so a later session can recover both a conclusion and its evidence. The implementation uses Neo4j for three connected graph layers: 1. Knowledge holds documents, source passages, and extracted entities and relationships. Passages retain their document version and location, including page positions for PDFs. 2. Working memory records tasks, progress, messages, and tool activity. The built-in agent uses DeepAgents/LangGraph and saves task events so work can continue across sessions. 3. Decision memory stores conclusions, assumptions, and open questions. Decisions link to source passages, recorded events, or earlier decisions, and keep their history when reviewed or replaced. For example, an agent can record a contract recommendation with the policy passage it relied on. If that policy changes, the recommendation and its explicit dependent decisions are flagged for review. The change doesn't automatically make the recommendation wrong, but it tells a later session that the decision needs another look. The document pipeline uses Docling for ingestion and Chonkie for chunking, preserving sections, tables, and passage hierarchy. You define a schema for your domain's entities, properties, and relationships. The schema guides extraction, validation, and entity search. GLiNER supports local extraction, with BAML handling structured LLM extraction for selected chunks. Retrieval combines Neo4j's native full-text and vector rankings with reciprocal rank fusion. Agents can search original passages even when extraction misses a fact, navigate surrounding sections and table rows with headers, and follow entity relationships back to supporting text. The built-in agent checks that cited passages were read during the run, belong to the allowed documents, and match the cited versions. It doesn't verify that the evidence supports the conclusion. You can also connect other agents through MCP. We're working on a more modular pipeline, additional storage backends, and domain-specific benchmarks. TL;DR Agentic GraphRAG is an open source library that stores document knowledge, agent work, and decisions in one connected graph. Agents can resume tasks and trace saved decisions to their original evidence, while source changes flag affected decisions for review. Are there other open source projects you'd recommend for combining RAG and agent memory? I'd also like to hear what you think of our approach.

Agentic GraphRAG an open source framework that connects your documents, agent activity, and decisions in one graph. Your agents can find evidence, continue work across sessions, and revisit decisions when their sources change. ontogr/agentic-graphrag t.co

Connecting agent memory to knowledge, and decisions with DeepAgents and Neo4j Over the past three and a half years, I've worked on RAG systems and LLM training. Recently, I've been following how people are building memory and retrieval into their agents: 1. Agent memory keeps a record of previous work and decisions for later tasks. I've been seeing a lot of experimentation here with coding agents. 2. The context layer gives agents access to knowledge through hybrid RAG and GraphRAG pipelines. What interests me is how we connect the two, so an agent's past work stays connected to the knowledge behind it. That's what we're working on with our open source project, Agentic GraphRAG (ontogr/agentic-graphrag). We use Neo4j to connect document knowledge, agent activity, and decisions, with a built-in agent based on DeepAgents/LangGraph. The graph has three connected layers. The knowledge layer provides context, and the working and decision memory layers record what the agent did and concluded. 1. Knowledge: contains the documents, their passages, and extracted entities and relationships. Docling handles ingestion and Chonkie handles chunking. We preserve the document's sections, tables, and passage hierarchy, along with each passage's source version and location, including page positions for PDFs. 2. Working memory: records tasks and their progress, including messages and tool results. The built-in agent saves its messages and tool activity as task events, so another session can pick up the task with its previous progress available. 3. Decision memory: records conclusions, assumptions, and open questions. Each decision can link to source passages, task events, or earlier decisions. Reviewing a decision can reaffirm it or replace it while keeping the earlier version in its history. Schema Grounded: You define a schema for the entities, properties, and relationships relevant to your domain. We use it to guide extraction, validate the results, and determine the entity labels used in search. GLiNER supports local extraction, while BAML handles structured LLM extraction for selected chunks. Graph Retrieval: works over the original passages as well as the extracted graph. We combine Neo4j's full-text and vector rankings with reciprocal rank fusion, so passage search remains available when extraction misses a fact. An agent can also follow entity relationships to supporting passages or read beyond a search hit into nearby sections and table rows with their headers. Decisions and supported relationships link back to source passages. Before returning an answer, the built-in agent checks that cited evidence was read during the run, is within the allowed documents, and matches the cited version. The checks don't establish whether the evidence supports the conclusion. Updates to a cited document flag the affected decisions and their explicit dependents for review, and existing citations still point to the text originally cited. Alongside the built-in agent, we provide an MCP server for connecting other agents. Our next work includes a more modular pipeline, additional storage backends, and domain-specific benchmarks. TL;DR The main difference is how we connect an agent's knowledge, work, and decisions. For someone considering the library, that means: - 3D graph: Documents, agent activity, and decisions form three connected layers. Agents can resume work and trace decisions to their source documents. - Retrieval: Agents can search original passages even when extraction misses a fact, follow entity relationships, and navigate surrounding sections and table rows with headers. - Schema: Your schema guides extraction, validation, and entity search. - Citation through the graph: Decisions and supported relationships link to source passages. The agent checks that evidence was read, is within scope, and matches the cited version. What are you using for retrieval and long-term memory with LangChain or LangGraph? I'd like to hear how your stack is working for your domain and what you think of our approach.

Agentic GraphRAG: an open source project combining the context layer and agent memory I have been working in the AI space for the past three and a half years, across RAG systems, LLM training, and retrieval. I was also one of the co-authors of the MMTEB paper. Lately, I have been seeing people experiment with two types of systems with Agents: 1. Context Layer: People are building hybrid RAG and GraphRAG pipelines and connecting them to agents. 2. Memory Layer: Agents store past work and decisions to use in later tasks. The coding agents are at the forefront here. I feel there is still a lot of work to do in combining these two systems well. Our project, Agentic GraphRAG (ontogr/agentic-graphrag), is trying to address this by connecting agent memory to the context layer in a unified graph. Here is the problem it targets: an agent records a decision based on a policy document, the document later changes, and nothing tells the agent the decision is stale. We store the data in a graph with three connected layers. Knowledge is the context layer; working memory and decision memory make up the memory layer. 1. Knowledge stores documents, source passages, entities, and their relationships. We use Docling for ingestion and Chonkie for chunking, preserving the document's sections, tables, and passage hierarchy in the graph. Passages retain their source version and location, including page positions for PDFs. 2. Working memory stores tasks, progress, messages, and tool results. The built-in agent uses DeepAgents/LangGraph and records messages and tool activity as task events, so later sessions can recover the task's progress rather than start from scratch. 3. Decision memory stores conclusions, assumptions, and open questions, linked to exact source evidence, recorded events, or earlier decisions. Decisions can be reaffirmed or replaced without losing their history. The knowledge pipeline is built around a schema you define, covering entity types, properties, and relationships. The schema guides extraction and validation, and supplies the entity labels used in graph search. Extraction can run locally with GLiNER, with BAML handling structured LLM extraction for selected chunks. Direct passage search remains available even when extraction misses a fact. These connections let an agent: - Find passages through Neo4j's native full-text and vector indexes, combining keyword and semantic rankings with reciprocal rank fusion. - Read beyond a search hit by navigating to its surrounding section, neighboring passages, or table rows with their headers. Entity relationships also lead back to supporting passages where evidence is recorded. - Cite exact source versions. The built-in agent checks that each cited passage was fetched during the run and belongs to the documents it's allowed to read. - Search earlier decisions in the same project. When a cited document changes, affected decisions and their explicit dependents are flagged for review. Our roadmap includes: - Making the pipeline more modular so its components can run on different hardware. - Extending retrieval support to additional graph databases and storage backends. - Running extensive benchmarks on domain-specific datasets, to be released soon. What's your current stack for RAG and agent memory, and how is it working for your domain? I'd also like to hear what you think of our approach.

RAG context and agent memory belong together. Here's what we're building. I have been working in the AI space for the past three and a half years, across RAG systems, LLM training, and retrieval. I was also one of the co-authors of the MMTEB paper. Lately, I have been seeing people experiment with two types of systems with Agents: 1. Context Layer: People are building hybrid RAG and GraphRAG pipelines and connecting them to agents. 2. Memory Layer: Agents store past work and decisions to use in later tasks. The coding agents are at the forefront here. I feel there is still a lot of work to do in combining these two systems well. Our project, Agentic GraphRAG, is trying to address this by connecting agent memory to the context layer in a unified graph. Here is the problem it targets: an agent records a decision based on a policy document, the document later changes, and nothing tells the agent the decision is stale. We store the data in a graph with three connected layers. Knowledge is the context layer; working memory and decision memory make up the memory layer. 1. Knowledge stores documents, source passages, entities, and their relationships. We use Docling for ingestion and Chonkie for chunking, preserving the document's sections, tables, and passage hierarchy in the graph. Passages retain their source version and location, including page positions for PDFs. 2. Working memory stores tasks, progress, messages, and tool results. The built-in agent uses DeepAgents/LangGraph and records messages and tool activity as task events, so later sessions can recover the task's progress rather than start from scratch. 3. Decision memory stores conclusions, assumptions, and open questions, linked to exact source evidence, recorded events, or earlier decisions. Decisions can be reaffirmed or replaced without losing their history. The knowledge pipeline is built around a schema you define, covering entity types, properties, and relationships. The schema guides extraction and validation, and supplies the entity labels used in graph search. Extraction can run locally with GLiNER, with BAML handling structured LLM extraction for selected chunks. Direct passage search remains available even when extraction misses a fact. These connections let an agent: - Find passages through Neo4j's native full-text and vector indexes, combining keyword and semantic rankings with reciprocal rank fusion. - Read beyond a search hit by navigating to its surrounding section, neighboring passages, or table rows with their headers. Entity relationships also lead back to supporting passages where evidence is recorded. - Cite exact source versions. The built-in agent checks that each cited passage was fetched during the run and belongs to the documents it's allowed to read. - Search earlier decisions in the same project. When a cited document changes, affected decisions and their explicit dependents are flagged for review. Our roadmap includes: - Making the pipeline more modular so its components can run on different hardware. - Extending retrieval support to additional graph databases and storage backends. - Running extensive benchmarks on domain-specific datasets, to be released soon. Which tools are you using for RAG and memory in your agents?

@JustinGorya I am building a graph-based memory system for AI agents with three connected layers: document knowledge, task progress, and decisions linked to evidence. It brings GraphRAG + agent memory together, helping agents resume tasks as evidence changes. ontogr/agentic-graphrag

@trikcode I am building a graph-based memory system for AI agents with three connected layers: document knowledge, task progress, and decisions linked to evidence. It brings GraphRAG + agent memory together, helping agents resume tasks as evidence changes. ontogr/agentic-graphrag

@Da7_Tech Building a AI based Fraud Detection platform that is built on graphs. (ontogr.com) Also building an open-source Agentic GraphRAG framework that is schema-driven, so the agent answers questions grounded in the graph effectively. (ontogr/agentic%E2%80%A6)

@khushbooverma_ Building a AI based Fraud Detection platform that is built on graphs. (ontogr.com) Also building an open-source Agentic GraphRAG framework that is schema-driven, so the agent answers questions grounded in the graph effectively. (ontogr/agentic%E2%80%A6)