Your AI Keeps Forgetting! (Do This Instead)

[00:00:00]So, if you've built any kind of AI application or autonomous agent, this is a wall that people run into. Large language models suffer from complete amnesia. So, the second the API connection loses, and the every everything your agent has learned, every decision it made, every tool trace it generated, it's completely wiped off, right? So, if you want your agent to remember anything, you have to pack its entire conversation history back into the context window for the next call that you're going to make. And that completely destroys your latency, racks up massive unsustainable token bills, and you end up paying, you know, a lot of money.

[00:00:41]And to solve this, we turn to traditional rag, right?

[00:00:46]Vector rags. So, the idea, if you don't know, is we split our files into text chunks, we turn those chunks into vector embeddings, and we throw them in a vector database, and that's cool. That's done.

[00:00:58]But, traditional vector rag is architecturally limited. Vector databases treat your files like isolated bag of embeddings, if you will, and there's no real structure, okay? There's no awareness of like relationships, and you know, it works really fine for like demo purposes, simple search task, if you will.

[00:01:21]Let's say you're trying to find a single paragraph inside a user manual. But, if you ask your agent for like something more complex, let's say there's a there's a multi-hop query, the vector rag will not work as well as you expect it to. So, you think about like an enterprise workspace. Your product requirements are, you know, and everything is you're you're tracking everything in Jira, and your long-form like technical guides you are having on like GitHub or something or Google Docs or whatever, and your developers, they're chatting, uh, you know, um, in Slack. And you if you ask like a standard uh, rack system like, "Hey, how does the Salesforce agreement that we signed uh, last week affect the open Jira ticket uh, that we would discuss on Slack?"

[00:02:08]It won't be able to answer as accurately because it's going to retrieve isolated chunks about Salesforce, other chunks about Jira, few Slack messages. It can't structure, you know, structurally trace the connections between these these platforms.

[00:02:23]So, it leaves the LLM to like hallucinate, if you will. So, it's it's not like you can just stuff more data into a massive context window to solve this. That's not how it works either because you get hit with token latency and the model inevitably misses the key details placed right inside uh, the middle of your prompt. So, if we want agents that can actually learn and operate inside of inside a complex uh, domain, we need to have persistent structured memory layer that understands relationships, not just uh, semantic similarity.

[00:03:02]Now, this is where Cogni comes in. So, Cogni is an open source AI memory platform designed to give agents a self-improving long-term memory engine.

[00:03:10]It bridges this gap we spoke about earlier between raw unstructured data and LLM reasoning by combining graph databases with vector storage. So, unlike uh, standalone vector stores, Cogni operates on a three uh, layer unified uh, database architecture.

[00:03:26]The relational store, which basically handles uh, document level metadata and provenance, basically means that it can track exactly where each uh, you know, piece of data came from and how it links to the source. Then there's the vector store, which basically holds embeddings for semantic similarity searches. And the graph store, which basically represents entities and relationships as interconnected nodes and edges. And because these systems are unified under a single engine, every node in your graph stays linked to its corresponding vector embedding. So, this basically means that your retrieval can move seamlessly between semantic similarity and structural graph traversal without losing context or coherence. I'll give you a demo in a bit. And um uh also Cogni, you know, does not just construct a static knowledge graph. It constructs a context graph. So, basically a traditional knowledge graph uh stores uh rigid static facts. And a context uh graph is dynamic and temporal. So, basically it tracks how facts change over time. And um it preserves provenance back to the source documents. And it adapts based on user feedback and actual usage traces.

[00:04:35]So, Cogni splits this memory into like two logical layers. So, there's the session memory that acts as a high-speed uh transis- transient uh cache, if you will, for active agent runs. So, basically loading relevant embeddings and graph fragments into run-time context for fast reasoning. And then there's the permanent memory stores, uh which is going to store the long-term memory um knowledge, including historical interaction traces, derived relationships, and domain-specific ontologies, um steadily organizing them so that, you know, these can evolve over time. Uh Cogni's uh 1.0 API condenses this entire life cycle into just four uh core operations. Uh the functions are remember, recall, improve, and forget.

[00:05:19]So, let's talk about remember. That's the first one. This is your main ingestion entry point. So, it has two distinct uh modes depending on whether you want to provide a session ID. Without a session ID, it operates in uh permanent memory mode, running the full heavier pipeline to chunk, uh extract entities, and build graph nodes. And it creates the embeddings. If you pass it a session ID, it runs in uh session memory mode, acting as a high-speed uh short-term cache that returns quickly. So, if you leave uh uh self-improvement uh enabled, it you know, triggers automatically an asynchronous background bridge to sync that session data into the permanent graph. Second, we have recall. This is basically how you query your memory. So, Cogni comes equipped with uh 14 distinct uh search types ranging from simple semantic chunk search to highly advanced inter- inter- interactive uh reasoning.

[00:06:12]So, for example, you can use like graph completion uh CoT to run an iterative uh step-by-step chain of thought uh traversal over the graph to validate multi-hop answers. Third, we have uh improve. Uh critical issue with the typical agent memory is that it uh remains static. Improve basically runs the enrichment process under the hood to refine and enrich your graph over time.

[00:06:34]So, basically, when you pass it session IDs, it bridges the temporary session memory directly into your permanent uh long-term graph. And it also applies feedback-based weighting. So, if a user gives a thumbs up to an agent's uh response, the engine uh strengthens the weights on the graph edges that were retrieved to generate that answer, making them more influential when you make uh queries in the future.

[00:06:59]So, here you can see I had only these nine files. And now I'm adding one more uh demo prep call file. This is the file.

[00:07:06]Process is complete. Now, if I go to the knowledge graph, earlier, knowledge graph did not have uh this file, right?

[00:07:12]It did not exist. So, if you see here, this has been updated.

[00:07:16]It has been mapped by Cogni itself. And if I go here, here I can see the types, and everything is available.

[00:07:23]This is going to also help in recall.

[00:07:25]So, if I go ahead and search some query regarding Maya, so, you can see I'm getting information about it. Finally, we have forget. Uh this basically allows you to safely prune the data at the item level, data set level, or wipe everything to keep your database clean.

[00:07:39]So, how do you build this uh graph without turning it into a complete mess?

[00:07:43]If you let an AI build a knowledge graph completely on its own, it can become a disaster. For example, if the AI reads one document and makes a folder called, let's say, Stripe Gateway, and then it reads a different document and makes a folder called a payment flow, it won't actually realize that they are actually the exact same thing.

[00:08:00]And you end up with a fragmented, uh, disconnected database where the dots never get connected. So, Cogni solves this by giving you a set of blueprints called data points. These data points are written in, uh, standard Python uh, using a popular tool called, uh, Pydantic. You can think of this as, a, strict template, and you get to define exactly what your entities are, and what information they can hold, and how they are allowed to link to each other. And if you're worried about, uh, the Python code breaking when you try to link the two, uh, different templates together, Cogni has a neat little trick called, uh, skip validation. It's basically a single line of code that prevents, uh, Python from throwing a tantrum when, uh, templates reference each other. So, you know, now, to keep this entire, uh, database perfectly clean, Cogni uses the highly clever, uh, deduplication system, because usually, uh, databases assign like a random ID to every single thing that you upload, and that is how you get duplicates. So, Cogni allows you to flag unique identity fields instead, like a specific product serial number, a unique email address, or, uh, file path. It takes those uh, specific fields and generates a locked unique ID for that item. This basically means that if you upload three different documents that mention the exact same product serial number, Cogni won't create three duplicate nodes. It's automatically going to find the existing node. Um, it merges the new information, and it simply, you know, links any new connections directly to it. So, your graph stays clean, organized, and lightweight. Lastly, Cogni makes these, uh, connections incredibly easy to search.

[00:09:29]So, there is a simple setting you can turn on called embed triplets.

[00:09:32]Basically, when this is active, the engine, uh, takes the connections into uh, your graph and saves them as a small searchable sentences. So, instead of your own um you know, your AI only searching for isolated words, it can actually search for relationship patterns like product X is built by company Y, right? So, this is what makes the memory incredibly sharp and highly queryable. Now, this is not just a conceptual theory. Developers and enterprise platforms are actively running this in production. Um first we have a No Unity, a massive uh European student platform.

[00:10:07]They tried understanding user proximity and relationships using standard sparse vector embeddings and relational SQL databases. But, the SQL queries quickly became unmanageably complex, and using Cogni they built and deployed a production-grade proof of concept mapping the relationships of 40,000 students in just 2 days.

[00:10:25]Next, we have a SlideSpeak, which basically integrates memory into document generation. So, instead of forcing users to generate uh presentations from scratch um in isolated uh disconnected uh sessions, they integrated uh Cogni's long-term memory layer so that the application retains uh shared user context and uh dynamically improves the presentation outputs over time. And then, there is a code-based parsing. So, if you're building a custom coding agent, standard vector rag is incredibly weak because it cannot understand file dependencies that spread across a code base. With Cogni, you can parse an entire repository using libraries like parso and Jedi and load the files uh as uh custom uh code file objects, and the engine builds a structured queryable dependency graph of your code structure, allowing your coding assistant to traverse class inheritances and see exactly how modifying a file in one folder will affect modules across your entire repository.

[00:11:21]And finally, we have a first-party agent integrations. So, if you're using tools like, you know, uh Cloud Code, Cursor, uh MCP clients, Cogni connects to them uh So, for cloud code, you can just install a local plugin. It automatically hooks into cloud's life cycle. So, you know, capturing prompt histories, tool traces, and code diffs into session memory, and automatically running an improvement pass to commit uh that knowledge to your long-term graph the moment you exit your session.

[00:11:51]So, how do you actually deploy this? If you want to run everything uh locally, you get to have a completely offline uh zero infrastructure setup. Your vector graph and metadata databases run embedded uh did uh directly on your uh machine for free. You can even launch the entire interactive uh visual um dashboard on your local host using a single function call, Cogney start UI.

[00:12:14]This fires up the local front end on port 3000 and the back end API on port 8000, keeping all your data safely on your machine without sending a single byte to an external service.

[00:12:24]But, if you're building an enterprise application that needs to scale, you can transition to Cogney Cloud. Cogney Cloud gives you a fully manageable auto-scaling back end. So, under the hood, it orchestrates pipelines as a serverless uh container jobs running on model uh utilizing uh hosted Kuzu graph uh databases, uh LanceDB tables, uh Postgres uh SQL uh databases, and S3 for completely isolated multi-tenant workspace uh namespaces. So, the transition is virtually seamless because the cloud Python SDK uh uses the exact same API and package structure as the open-source library. So, you simply initialize your cloud URL and um API key with await uh cogney.server uh call, and all of your local uh remember and uh recall operations are automatically rotated and processed in the cloud. Now, let's be objective here. Who is this actually for?

[00:13:16]If your application only needs simple keyword lookups, or if you're just doing some basic document search like standard vector rag is, you know, perfectly fine for that. Um uh uh has lower latency. You don't need to introduce like a complexity of graph database schemas if you do not have relational data.

[00:13:32]But if you're building autonomous agents that need to retain memory across different conversations, or if you're dealing with like a multi-source enterprise, um, you know, silos where the answers require connecting the dots between uh, various files, static vector databases, you know, simply will not cut it. You need a persistent structured context graph. So, the open-source core is uh, completely free and uh, it's Apache 2.0 licensed, I believe. So, you can build with it, um, on your own hardware without worrying about licensing limitations.

[00:14:01]Um, give it a look. Try running it on the local UI. Uh, let me know in the comments how you are handling long-term memory for your AI systems. Let me know if you have any questions in the comment sections below as well. And you can find all the links to the description in the description below as well for Cogni.

[00:14:16]It's open-source, so you can, you know, uh, contribute to the project as well and join their community to ask more questions directly to the maintainers.

[00:14:25]And yeah, thanks for watching. I'll see you in the next one. Bye.

[00:14:29]>> [music]