There are already dozens of books about coding agents. How to configure Claude Code, how to write the perfect skills, which plugins promise to do all the work for you. I’ve decided to write one more — but slightly different.

Mine is not about yet another collection of Markdown files dressed up as a product. It’s about mindset.

What does it actually mean to work with an agent? What skills do you still need to bring — not the agent, you? What are the new challenges nobody warned us about? Things like fatigue from working with AI, the change in your dopamine loops, and how to prevent burnout when agents are doing the mechanical heavy lifting but you’re still the one responsible for the outcome. These are real challenges, and engineers need to be aware of them.

I also explore what an AI-first organization actually means — and it’s not about token consumption.

The Intent Problem

The deeper part of the book goes into AI-assisted architecture: how to structure knowledge and product design, how to keep intent on the human side, and critically — how to document that intent.

Here’s what I’m observing: we’re shifting from heavily writing code to writing specifications that drive agents. The spec is becoming the primary artifact, with code as its output. But quite often we lose the spec. We have some history of chats, and the information starts living inside that chat history. That’s horribly wrong.

The memory of your coding project is not your codebase. It never was. We’ve always had this impedance mismatch between architecture diagrams and code. Whole teams of people existed just to hold the context in their heads and map between these two artifacts. Some projects never had architecture diagrams at all, so they never felt the gap — because they never had the architecture. That’s also possible.

But with agents, you cannot ignore this anymore. It simply doesn’t work. If you come back to a project three weeks later and want to add a small feature, your agent will start rewriting large chunks of the codebase. If you ask it why it made certain decisions or chose a particular pattern three weeks ago — just forget about it. The context is gone.

Context Graphs and Documentation That Agents Can Actually Use

We need to change how we set context and how we use context graphs in our codebases. Documentation and context management matter more now than ever before. It was always important, but agents make it practically impossible to ignore — or you could still ignore it, but the cost of that ignorance will be extreme.

In the book, I explain how to build architecture documentation in an agent-friendly way: how to construct a cascade of specifications that preserve intent, how to set up coding rules, patterns, and conventions that make code generation more effective. And yes — code generation, because the agent is, at the end of the day, a very smart code generator. Your job is to drive the generation. To own the intent. To document everything. To manage context deliberately.

One particularly interesting topic here is semantic markup. We can hint at importance by using Heading 1 — that’s a decent trick. But with HTML or XML tags, you can be precise. You can say exactly what something is, not just how it looks in a hierarchy. This kind of structured, meaningful markup is something agents can parse with real understanding, and it’s worth exploring as a documentation strategy.

The Scale Problem

There’s also a scaling problem I cover in depth. You can start with Markdown files — and that’s a reasonable starting point. But especially in a multi-agent setup, you will quickly discover that flat files don’t scale and don’t work. Large-scale knowledge bases and graph databases are what make agents genuinely capable, not just within a single session but across a swarm of collaborating agents.

Where the Book Stands

The book is philosophical, but if you follow me on Substack, you’ll recognize many of the threads I’ve been pulling on — they’re now composed and in one place. It’s still a work in progress, and if you pick it up on Leanpub, you get all future updates included.

The next big section I need to write is about how to talk to your agent: voice-to-text workflows, how to make your interaction blazingly fast, and how to transform the way we work not just with Claude Code but with an entire swarm of tools — getting the best from them without wasting time or money.

The one thing I want you to take away: we cannot ignore documentation anymore, and we cannot use the old documentation patterns either. The 1970s approach to specs is not what agents need. The shift is real, and understanding it is what separates engineers who will thrive with AI from those who will fight it.

Book https://leanpub.com/clarityengineer

Right now, files are everywhere in the agent ecosystem. Markdown files are the default for everything — skills, custom instructions, agent descriptions, commands, memory. The entire vibe-coding movement runs on the assumption that a folder of .md files is all you need.

And I get the appeal. LLMs are trained on repos, docs, logs, and README-driven workflows. They already know how to list directories, grep for patterns, read line ranges, and write artifacts. The filesystem is the most natural interface we can give an agent. No schemas, no migrations, no query planners. Just text.

But here’s the thing — I’ve walked this path before. And I’ve seen how it ends.

Sovereign Agentic AI (Volodymyrs View) is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

We’ve Been Here Before

This pattern is not new. Early computers were fiddling with text files until it failed. Then people started inventing layers on top of the file system — indexing, querying, structured retrieval. First came reverse-list systems like Adabas. Then hierarchical databases with COBOL and tree structures. Then relational databases and SQL.

Every time the industry starts from files, and every time it rediscovers that files don’t scale past a certain complexity threshold.

The knowledge management world learned this lesson recently. Logseq started as a heavily markdown-based system, just like Obsidian. But at some point, the Logseq team realized they would be much more effective and compact if they converted to a database backend. Obsidian tried a different route — keeping the markdown files but layering query plugins on top — and the result is functional but far from elegant.

From my own observation, every time I tried to build a knowledge management system on top of Obsidian or Logseq, it worked beautifully at first. But once I needed sophisticated queries across a large, linked corpus, the whole thing turned into an unnavigable mess. I spent years going back and forth between these two systems before I accepted that the center of any serious “second brain” is always a database.

Agents are walking the same path right now.

Where Files Work (And Where They Don’t)

Let me be fair to files. For small codebases, toy setups, single-user agents, and keyword-friendly queries, files are great. A folder of markdown, a handful of skill files, some commands — more than enough. The filesystem gives you simplicity, portability, debuggability. You can open a folder and see exactly what the agent saved.

But production agentic systems are not toy setups. The moment you scale up — multi-agent architectures, shared state, growing memory corpora, concurrent access — files hit five hard limitations.

Concurrent writes. Anyone who has dealt with concurrent file access in any language knows it’s tedious. File locking is fragile, platform-dependent, and breaks in surprising ways on network filesystems. Databases solved concurrent access decades ago with MVCC and write-ahead logs. Your agents don’t need to worry about who’s competing for the resource.

Semantic retrieval at scale. When your corpus is small, grep works fine. But as it grows — thousands of memory entries, paraphrased queries, synonym-heavy questions — keyword search breaks down hard. You need vector indexes, hybrid search, ranked retrieval. Files give you grep. Databases give you HNSW indexes, full-text search, and query planners that actually optimize.

ACID guarantees for shared state. In any serious multi-agent system, agents share state. You need atomicity, consistency, isolation, durability. Files provide none of this by default. You have to build it yourself — and building it correctly is a massive engineering effort.

Audit trails and access control. Who wrote what, when, and who can read it? Row-level security, transaction logs, role-based access — databases have this built in. With files, you’re reimplementing permissions from scratch.

Indexed queries over growing memory. Agent memory is not static. It grows. And as it grows, queries that scan the entire file tree degrade linearly. You need B-trees, inverted indexes, the kind of query infrastructure databases have spent forty years optimizing.

The Benchmarks Don’t Lie

Richmond Alake from Oracle Developers recently published a detailed benchmark comparing a filesystem-backed agent (FSAgent) with a database-backed agent (MemAgent). The setup was straightforward: both agents used the same LLM, the same task (a research assistant that ingests arXiv papers, answers questions, maintains continuity across sessions), and the same evaluation methodology. The only difference was the memory substrate — files versus Oracle AI Database with vector search.

The findings were clear across three scenarios.

Small corpus, keyword-friendly queries: filesystem and database performed nearly identically. When the information to traverse is minimal and the query matches the source phrasing, retrieval quality converges. Both agents found the right passages and produced comparable answers.

Large corpus, fuzzy queries: the gap widened dramatically. The filesystem agent scored 29.7% on an LLM-judge evaluation, while the database-backed agent hit 87.1%. Keyword search returns too many shallow hits or none when the user’s phrasing doesn’t match the source text verbatim. Semantic search surfaces conceptually relevant chunks even when the vocabulary differs.

Concurrent writes: this is where the filesystem breaks hardest. Without locking, concurrent writes silently lose entries — you get good throughput but corrupted memory. With locking, integrity is restored, but now you own all the complexity of lock scope, contention, platform differences, and failure recovery. The database maintained full integrity under the same workload with standard ACID transactions.

The full benchmark notebook is available on the Oracle AI Developer Hub GitHub. Run it yourself.

You’re Already Rebuilding a Database

Here’s the part that makes me smile. I’ve watched several teams spend weeks, sometimes months, “hardening” their filesystem-based memory implementations. They add file locking for concurrency. They build custom indexing for search. They layer on journaling for durability. They implement access control lists. They add metadata schemas for structured queries.

And I look at this and think — congratulations. You just rebuilt a database. Only with fewer guarantees and more edge cases to own.

This is not a new observation. Anders Swanson from Oracle put it well: building a stateful app using only a filesystem runs the risk of reinventing the database, and that is a large and complex task that should be avoided. Dax from OpenCode called the filesystem “just the worst kind of database.” The pattern is consistent across the industry.

The Interface vs. Substrate Distinction

The key insight is that interface and substrate are different decisions. Filesystems win as an interface — LLMs already know how to use them. Databases win as a substrate — concurrency, auditability, semantic search, ACID guarantees.

The smartest architectures decouple the two. LangSmith’s agent builder, for example, stores data in a database but exposes it to the agent as a filesystem. The agent interacts with files because that’s what it knows. The system stores everything in a database because that’s what scales. This “virtual filesystem” pattern is likely where the industry converges.

My own work with LadybugDB follows a similar philosophy — a graph database with vector search as the memory substrate, but with interfaces that agents can navigate naturally. The combination of graph structure (for relationships and trust chains) and vector search (for semantic retrieval) gives you a hybrid retrieval architecture that neither files nor a simple key-value store can match.

What About Codebases?

There’s an adjacent topic worth mentioning. Several projects I’ve been following try to treat the codebase itself as a database — parsing the AST, making the code globally queryable, giving agents structured access to architecture and dependencies rather than just file contents.

This is exactly what people do with Smalltalk and the Glamorous Toolkit in the moldable programming community. If you can turn your codebase together with your documentation into a queryable structure and hand it to an agent, you get much better understanding — not only for the agent, but for yourself.

The granularity matters. With a database, you get precise context, proper attention management, and traceability. With a flat folder of files, you get scanning and hoping. But codebases-as-databases for agents is a topic for a separate deep dive.

Practical Guidance

Here’s my recommendation, distilled from both my own experience and the benchmark evidence.

Use files when you’re building prototypes, single-user agents, or small-scale tools where iteration speed matters most. A folder of markdown gets you surprisingly far when the corpus is small and the queries are keyword-friendly.

Use databases when you’re building multi-user, multi-agent production applications. Any system where agents share state, where memory grows continuously, where you need semantic retrieval, or where concurrent access is a reality.

Don’t start with polyglot persistence. Running a separate vector database for embeddings, a NoSQL store for JSON, a graph database for relationships, and a relational database for transactions gives you four failure modes, four security models, and four backup strategies. Converged databases that handle multiple data types natively — whether that’s Oracle AI Database, or for embedded use cases, something like SQLite or LadybugDB — reduce operational complexity dramatically.

Start simple. Even a single SQLite file is a massive upgrade over raw filesystem memory. SQLite is fully portable, it’s a single file, and you can have multiple databases that you glue together for different concerns. From there, you can scale up to a full graph database with vector search when the complexity warrants it.

What’s Next

I’m flying next week to meet with the Oracle Devs team. We’re going to talk about agent harnesses, memory architectures, and how Oracle fits into the agentic memory space. I’ll report back with what I learn.

The databases are not dead. Files are simple, they’re a natural interface to LLMs, but when the information gets complex, they’re not a simple solution anymore. Use the tools that decades of engineering have already built for you — because if you don’t, you’ll end up rebuilding them anyway.

We have a recurring issue: users of AI tools like Claude are often told their ideas are “brilliant” or “amazing”.

* Dopamine Loops: This constant validation changes the user’s dopamine response, as they begin to enjoy the praise more than the actual work.

* False Belief: Both senior and junior developers may start believing they are geniuses based on this AI feedback, which can lead to poor decision-making and subpar project releases.

* Overconfidence: High-profile individuals who are distant from actual engineering may claim “coding is dead” due to AI, only for their projects to later face significant security and scalability issues.

The Decline of Internal Critique

The reliance on AI for validation has diminished the practice of rigorous self-review.

* Lazy Coding: The speaker suggests that as users become “addicted” to AI assistance, they may become lazier and less precise in their own work.

* Death of the Coder: Modern IDEs and AI tools have largely replaced the “pure coder” role that existed in the 1970s, where manual precision was paramount.

* Need for Critical Thinking: The speaker emphasizes that engineering and coding are different disciplines; engineering requires a level of critical thinking that AI praise can undermine.

Strategies for Better AI Collaboration

To combat these effects, the speaker suggests several tactical shifts when using models like Claude 3 Opus:

* Switching Roles: Users should explicitly move between “Builder,” “Reviewer,” and “Critic” modes during a session.

* Direct Criticism: Asking the AI to specifically criticize an idea or code—or pretending the work will be reviewed by another model like “GPT-4”—can elicit more honest, less complimentary feedback.

* Iterative Scoring: Building prompts that specifically score code based on invented metrics and iterating several times can help maintain quality.

* Fleet of Agents: Using a “critic team” of different AI agents to review each other’s work can help identify blind spots that a single model might miss.

* Human Validation: Ultimately, the speaker argues that cross-peer review by human teammates remains essential to maintaining engineering sanity.

Would you like to explore specific prompt engineering techniques to make AI more critical of your work?

Introduction to Identity

Hey, it’s me, [unintelligible], and today we will talk about my favorite topic. Maybe not everybody knows, but I’m more the crypto and **self-sovereign identity** guy. And yeah, I love graphs, I love the memory, and agents, and all this topics. But originally, I was spending a lot of time to give the identity—cryptographically verified identity—to the humans.

And humans didn’t know what to do with it, but looks like **agents**—and agents care. So if we will talk about identity, what is it? What came to your mind? Because, is the name your identity? For sure, you identify yourselves with some name tags that people know how to call it, call you. But is it the identity? I don’t know.

Or you have the passport with the passport number. So, is the passport your identity? And here is a super important thing to understand: that quite often when we’re talking about the identity, we’re mixing the **identity with identifiers**. And identifiers is the name, passport number, social security numbers, and all things that, you know, registries driven by governments invent to identify the people. But it’s not the human identity itself.

---

Sovereign Agentic AI (Volodymyrs View) is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Dimensions of Human Identity

And what then forms the human identity? So, is the nationality and belonging to some group identity? Is the gray eyes actually somehow identify you? Or the fact that you vote for Democrats and hate Trump—is it identity or not?

And that’s all the big questions for people. And the answer is that **we don’t have the monolithic identity**. This identity have a lot of different traits and faces. We even inside our brain actually have the concept in psychotherapy of “internal family,” and we could even have the different voices. And if you argue with yourself in your head, do not worry; it’s our internal architecture. Actually, nobody knows how it’s work, but it is.

And we have multiple “us” inside us. We have multiple “us” when we interact with different environments and social groups. You could talk and behave differently when you’re talking with the parents, when you’re talking with your family, and you have your professional profile and professional identity that you use at work and on the public events and all the things.

For some nations, it’s different. For some cultures, they have more monolithic one that doesn’t have internal worlds. They’re more open, they’re more solid. They’re not better, they’re just different because they don’t understand why they need to be different in different environments or different social groups. In some other cultures, it’s completely opposite—that people build the walls, you know, fortify everything and have really multiple “yourself.”

---

Contextual Identity and AI Agents

From culture to culture, it’s different. So, identity is one of the most challenging psychology, sociology, and technical questions that I ever faced because it have so many dimensions—even more than the vector embeddings for some top-performing models.

So then, what’s actually form of identity? So, the answer is simple: it depends on the **context**. So, identity is context-dependent. And it’s also easier to say that you as a personality have different traits. So, different traits that could be mapped in technology that I do to the claims and verifiable statements in a form of cryptographically protected documents.

And this claim could say the small piece of information about you and your properties, right? And then we have some physical properties: how high you are, your weight, maybe some measurements, maybe the fact that you’re right-handed and all that, the color of your eyes. And maybe we have some context where this information is super important, and that’s form some physical identity that are mandatory for some certain tasks or some certain access right.

Agent Identities

Then we have some work identities, right? The social identities, our dependencies, our position in the company at work, our access rights to different data sources—it’s also the identities. Our dependencies: with whom we work, on which tasks, what we do. And all this forms somehow the social dependencies and social identity.

If we’re talking about the agents—agents are doing something for us, and it’s the biggest context where agents get supplied. It’s **agent capabilities**, and the capabilities and skills. It’s a huge amount of data points that form quite complex identity that make an agent useful for task-oriented jobs, right?

So, we have a task: we need to find the plumber. Then we go and find the agent with the plumbing capabilities. And actually, it’s the most straightforward and understandable type of identity in a context of the task execution. So we’re looking for the agents that could do work for us.

---

Ownership and Verification

Also, the **ownership**. Ownership is the huge pillar of identity. So, is it the local agents that run on our hardware, owned completely by us? It’s one use case. Then maybe we don’t need to know much about him; we just know that it’s “he,” and we own it completely and we know how he built, and we don’t care about these things.

Stuff gets complex if the agent was built by somebody else. And then we need to know on what kind of model the model capabilities this agent run, what kind of other agents and tools it’s use, in which region this agent are located, on which type of hardware it’s run, who provisioned the data, who provisioned the identity, what kind of data sources and knowledge bases agent have the access to.

And it produces some kind of mixture of the capability, resources, and what I say, the “body” or the hardware. So, how the agent built. It’s the same as we have some physical qualities of the color of eyes, and our agent have the LLM model, the model parameters, the hardware that run the model, and some regional location.

I guess it’s common for the agents and people, that I’m based in Berlin, I’m the residence of the European Union, and I could work in the European Union. So agent also could have the permit to work only in European Union countries, for example, if you have some kind of requirements to it.

---

Conclusion: Identity as Data

So, the answer to the agent identity, actually, it’s simple. If we see the myriads of properties of the agents, we put them in a context of the tasks, we put them in a context of the hardware and software, and we put them in a context of the skills and capabilities. Then we have some natural clustering of the properties that form different kind of agent identities. And the overlap of this agent identities form us the profiles.

And these profiles actually could be useful when we form some **personas**, right? And this persona, it’s one of the piece of the agent identity that capable to do some certain task on some environment and hardware in physical setup for us.

And it’s simple—we could go from this property-based multi-identities and identity profiles and unify on this framework not only the humans, but the agents. Because humans also have this—maybe we don’t have the hardware part, yeah? We built differently and have the different properties.

But yeah, why not? And the answer of the question: **the identity is a data**. Identity contain of the claims and properties and data points that form different kind of profiles. And all together, this identities form one big general identity that could satisfy the majority of different contexts and tasks.

And the separate question that I try to answer in my current company—and the separate question that I try to answer in my book, actually, about the self-sovereign agents—how we could verify and confirm all these properties? How we could confirm that Volodya have the gray eyes? We could take a look on Volodya photo, and maybe this photo should be cryptographically verified that it was not changed.

So we need to have some kind of proof that we could validate without having Volodya on board. And same for the agents: we need to have some kind of **verifiable claims** that we could validate and verify before we start the interaction with the agents to see some properties of the agents, maybe without disclosing the property itself. Sometimes it’s matter. So you wants to make sure that the agent have the big enough model, or this model is not hosted in China, or this model has some certain parameters—the size and temperature—but without the disclosing the concrete configuration of the agent because it could create some good environments for future attacks.

And all this actually, it’s a task for the **self-sovereign identity and crypto protocols** that I’m going to explore in my next book.

Today I want to talk about agentic AI and databases — specifically, why agents need strict guardrails, especially for memory.

The Knowledge Graph Trap

The first thing people usually do — and the internet is full of these guides — is build a knowledge graph with an LLM. It doesn’t matter which language you use: you feed in messages without any kind of ontology and just start collecting data. The results look quite good at the beginning. But after a couple of weeks of usage, you realize that your data is completely random and looks more and more like garbage.

This was our observation at King when we started building memory. We realized that we need an ontology — because without one, it simply doesn’t work. But we need the ontology in a form of guardrails and constraints that define what is possible in a memory. And from the other side, we need it to express not just what’s possible, but what really matters.

The Limits of the Semantic Stack

Today we have OWL, SHACL, and everything else in the RDF world that addresses this problem. But the existing tooling still doesn’t give you all the capabilities to construct something truly complex while keeping it strict.

I’ve been using OWL for a long time. It has amazing features: rules, descriptive logic, reasoning, and much more — things that property graphs unfortunately lack. But it’s still hard to express super strict guardrails. Sometimes you need to combine different tools, for example SHACL and OWL, to achieve what you need. I know this is a form of religion: every time you go to the RDF folks and say the semantic stack can’t do something, they will tell you that you’re using it wrong, and that with the newer version of RDF you can do everything. I completely agree — you can. The problem is that it gets clunky and complex. And if it’s clunky and complex for people, it will likely be clunky and complex for LLMs as well.

Types as the Foundation

How do we combine strict guardrails with the ability to express what’s important? In software — especially in more advanced languages — we have types. We design classes, hierarchies, inheritance, and other structures. We express our logic and constraints as types.

If you take this to its extreme, you end up in Haskell, Rust, or OCaml — languages with extremely powerful type systems. But you can go even further. There are languages that allow you to blend types with values, encoding logic directly at the type level. You can create a type that specifies a list of exactly three items, or describe logical constraints directly within the type itself. These languages work with dependent types — the dependency between type and value.

The mathematics behind dependent types, especially cubical types, forces you to think like a mathematician. But here’s the key insight: the types we use in programming actually came from a different branch of mathematics. They came from logic. Types are logical constructs, born from a revolution in mathematics when Russell discovered that sets are not enough to describe our world. Types are the form of logic that changed the fundamentals of mathematics. And if they can describe the world around us, they can describe what matters for agents’ memories and LLMs — because types are flexible enough.

Stricter Constraints, Better Results

With better constraints, LLMs work significantly better. The stricter the constraints, the better the guardrails. We already see this in the vibe coding space: if you have a strict language with static types, and especially one that forces you to do things in one particular way, it consumes fewer tokens and produces results much faster. Rust is much better for vibe coding than JavaScript — or at least much cheaper — and it keeps getting better. There were initial problems with Rust due to limited training data, but modern coding agents handle it extremely well now.

Beyond the Object-Relational Impedance

If types are the answer, how do we bring them to our data storage? We could build a layer on top of our database in software, but then we face the classical headache of object-relational impedance mismatch. As developers, we use ORM tools to bridge this gap, encoding part of the constraints in the database and another part in code. Synchronizing all of this is extremely hard.

But what if we could use the same types — even functions and programmability — directly inside our databases? I’m not talking about document databases that attempted to cross this border by sacrificing schemas, making the integration friendlier for languages like JavaScript. I’m talking about a database that has held my attention for more than two years: TypeDB.

TypeDB: Types at the Core

TypeDB takes dependent type theory seriously and makes it the core of the database. Everything is typed. You have strict type definitions that define the schema. Your query is another form of type. Functions are typed. It’s a kind of dream: the concepts you’ve used in programming for decades now live inside your database.

More importantly, you get extremely strict, understandable, and well-defined constraints. You can finally say precisely what matters and how it should look.

Even with property graph databases like LadybugDB — which I genuinely like — this isn’t always possible. In LadybugDB and similar property graphs, you can describe the shape of a node with all its properties and define what connections between nodes are allowed. But you have no ability to describe the shape of a subgraph. You can say that a parent and child can have a relation, but you cannot say that a child should have only two parents. You would need a validation query, pushing that constraint to the application layer. In TypeDB, you can design a type with a special kind of relation that has particular rules and fixes precisely this constraint.

PERA: A Developer-Friendly Paradigm

TypeDB was intimidating to me at first because it uses TypeQL — a completely different query language and an entirely new paradigm. But this paradigm is genuinely good. Beyond strictness, it doesn’t force you to learn advanced mathematics. It gives you a fairly simple concept called PERA: Polymorphic Entity-Relation-Attributes. It’s a visual and intuitive modeling framework that makes designing your data quite straightforward.

The real beauty is that you can feed this to an LLM. I’ve already tried it several times: teach the LLM TypeDB, use the TypeDB constraints as extraction rules, and you don’t even need a special evaluation framework — because the database itself validates the data you try to store. If something goes wrong, you get an error and can feed it back to the LLM. So alongside the construction rules, you also get an evaluation engine. For developers, this feels remarkably close to what you already know.

From LadybugDB to TypeDB

What I did was take my LadybugDB book and bring it to the next level. I took all my concepts — Semantic Spacetime, metagraphs, and everything else — and encoded them in TypeDB. It works. But there’s an important observation: TypeDB is a more closed-world database. It’s stricter and forces you to think in advance about what’s possible. Property graphs, with their weaker constraints, are more friendly to open-world ideas and more easily extendable. When you want to extend TypeDB, you need to reason about what your current types allow and extend them deliberately.

But at the same time, as I’ve said, stricter constraints and closed-world design provide better guardrails for your agents.

The Book

I wrote a book about TypeDB where I express all this work — a memory architecture that explains how to use these concepts with stricter guardrails for agentic AI. If you want to learn something new, and if you want better guardrails for your agents, give it a try.

https://leanpub.com/typedbforedgeaiagents

Hey, long time no see! So, we’re on our Philosophical Wednesdays, and today we will talk about one of my favorite topics: the metagraphs. And, you know, my journey to the metagraphs was quite long because I was building the AI memory—conversational memory for Keen—and I hit the wall: that binary relations somehow do not describe the complexity of the cognitive processes that humans have.

And then I started reading, by the way, a lot of materials about human cognition: how the memory works, how the semantical memory and episodical memory interact with each other, and all of these things. Then I discovered for myself the question of time, and different scales of time, and how we process time in the brain. And the structure that was described was not fitting well to the graphs. It was fitting well to the complex, multi-layered networks that have cross-relations between the layers.

It was a lot of nested and hierarchical structures that also coreference each other; and in some context, what you have as a node could deal actually as a connection between the entities and all of these things. So, it was a mind-blowing structure, but when you try to model something like that as a directional graph, it was extremely cluttered. And I’m not a mathematician, actually—I have some mathematical background—I’m more the engineer. So, I don’t care about the beauty of the structures; I just need to fix, or let’s say, make something working.

But I figured out that my approach is simply not working. And then I started my research. The first thing that I found was the hypergraphs. And hypergraphs have really good mathematical models; we know how to use them. It’s a lot of papers; we even have some databases that allow us to work with hypergraph or hypergraph-like structures. And for sure, if you, for example, use TypeDB, you already somehow have the hypergraphs capability, and this database is really good for the hypergraphs. And they even have some good concepts—some modeling framework that allows you to think better about the hypergraph. Strongly recommended.

But my problem with the hypergraphs was that if I have the hyperedge, and the main idea of the hypergraph [is] that your edges could connect multiple nodes—not just two, but any amount of nodes—and if you have directed hypergraph, then you just mark the nodes, what is in input nodes, what is in output nodes, and so on. But my need was more. I was keen to build the structures that have the ability to have the hierarchies—and the hierarchies are nested graphs.

So, and sometimes I had the need to reference the hyperedge as a node, and I called it “metanodes.” And I decided that I invented something great and cool—until I Googled and learned about the metagraphs. And I even found one book—you could imagine, it’s mind-blowing idea—that really have the huge application in AI space. And right now, we have only one book and tons of papers from one author that actually talking about it since decades.

So, as you see, sometimes the great idea could be lost until they gets needed again. And what idea of the metagraph? Metagraph is the highest abstraction of the graphs that say that node could contain another graphs, the edges could contain another graphs, and edges could be used as a node. So, it’s three building blocks that allows you to build completely mind-blowing recursive, hierarchical, any kind of structures that you could even imagine.

And even the structures that you couldn’t imagine because your brain simply not able to depict such things. And even if you ask me how to visualize the metagraph, I don’t have the good answer because for the hypergraphs, we could use something like Venn diagrams—and even with this it’s not always possible—but with the metagraphs, I still have no idea how I could depict such things, to be honest. So, it’s a challenge itself, and it’s a challenge of our brain capacity to describe this.

But metagraphs is mind-blowing mathematical structure. We have some mathematical theory, but unfortunately, we have zero to nothing databases that are capable to model such kind of things, unfortunately. So, we’re not there. I know some projects that built on top of TerminusDB that try to combine the graph databases with the JSON-LD documents as a nodes, and they gets closer to the metagraph future.

To some extent, you could use the TypeDB to model the metagraphs with some ramifications. And, you know, at the time when I was working for Keen, we have no embedded databases for the graphs. It was practically only the RDF boxes with some magical license that was not ready for the devices licensing and all of these things. So, it was the question: so what to do? And I haven’t found anything then just use the SQLite.

And we partner with Turso folks that was building the mind-blowing vector search indexes, and we was using the vector search together with the graph search to build the memory. So, I built the directed graph in a SQLite. And then I asked myself, okay, if I build the directed graph in a SQLite, could I build the hyper and metagraphs? And result of it actually is my book about the edge portable graphs on the user device purely in SQL. And I would say that it’s quite challenging.

So, it was also challenge for me every time when I had classical graph query with the multiple hoops and I end up with the mixture of SQL and TypeScript code to mimic somehow something that, for example, OpenCypher could do for me in one line. So, if you go this path, probably you will have the same challenge.

And after that, time flies and I meet Kuzu—Kuzu folks. But when my book was on the editing phase, Kuzu just disappear. And all my chapters that was dedicated to Kuzu just go to the void because, you know, the future of the database was not clear, and I decided that, unfortunately, it’s not worth of publishing it anymore.

But what I made: I model translation framework that allow me to build quite metagraph-like structure as a bipartite directional graph. So, I lose a lot of properties of the metagraphs for sure, but I make something working with the tools that we have today. And then I was able to build quite sophisticated memory structures that I need for the conversational memory.

And then in a couple of months, I will discover—when I will jump to the agentic protocol and multi-agent cooperation—that actually the metagraph is yet another model or the data structure that help us to build the cooperation graphs in a multi-agent systems, where every agent could be the swarm of agents inside that cooperate with each other into extremely complex things. So, it’s not only the conversational memory, but it’s also about the cooperation and coordination thing.

And the metagraph is a good building block for something that I called the promise graphs, actually. And, you know, I wrote a book how to do it in SQL; after that I wrote a book about the Ladybug, how to use Cypher, and some characters are dedicated to the metagraphs for sure. And then I discover the semantic space-time. The semantic space-time concept—I would say that it’s more ontology for the directed graphs that allows us to describe the world around us.

And when I published my article about the meta and hypergraphs in a property graph model—a property graph model—the author of this space-time say, “Haha, come on, it’s just a space-time that able to describe it.” And then I get the closer look to the space-time and yes, once actually two out of—and even three out of four relations—it’s all of them needed for the metagraph.

You could say that you contain something, you could say that you have a property of something, and you could say that you similar to somebody. And for sure, the causal link, but when you could say that you have a property or you could contain somebody inside, it’s already good enough building block to build something quite metagraphish. And, yeah, and I remodel my metagraph concept as a bipartite subset of the semantic space-time.

And then I practically build the framework that allow you to build the metagraphs with the tools and concepts that we have nowadays, without the need of waiting for something better to appear. And then I catch myself on this idea that we practically have no materials about the metagraph. We have no studies, we have one book, we have couple of papers—majority of the metagraph papers belong to same person.

And I decided that I have this old rule: write the book that you want to read and write the book that you want to have. And I decide that, you know, I wants to have this book. I wants to read the book, to write the book about the metagraphs, but in more engineering way, without the crazy mathematics and the formulas and the topology.

https://leanpub.com/metagraphforaiagents

Maybe I will add it later, but I just take all my work that I did for the different databases and bake it up—I bake it up to something more digestible, something more simple. From all five different relation model I pick one, and for the metagraph in a property graph database I also pick this bipartite ramified structure of the bipartite graph, and I assemble the book.

If you follow my books, you already maybe touch some of the chapters. But right now, I’m really proud to announce that we have the book about the metagraphs. And we have the book not just about some abstract metagraphs, but we have the book about the metagraphs that actually focused on the AI future and more applicable for the topics of the agentic memory and multi-agent interactions.

It’s more important. I believe in a data structure in a context of the task, because without it, it’s doesn’t really matter. So, I will share my book; it’s still on editing phase, but it’s already available. Maybe it will be two or three additional chapters for the mathematical kicks, I don’t know, but it’s already available. You could buy it; I tried as much as I can to make it more affordable. If you are the student and have no money for the book, write me—I will give you the copy.

It’s somewhat philosophical talk about what’s next. What’s next in the agent world and, you know, I just published a book about the LadyBugDB-based LPG memory and how to model the memory in a proper graph and all those things.

But right now is the question, actually what to do with it? And why do the agents need memory? Yeah, for sure, agents need to remember.

But what do they need to remember and what do they want to do with it? It’s a good question, and yeah, we have a lot of ontologies and data models of memory that somehow mimic human memory, with an episodic events graph, semantic knowledge, complex semantic relations, semantic graphs, and hypergraphs. You can find all this in my book.

But one big missing piece is the cognitive process, right? So, how to actually extract all these ontology structures from the outside world, and it’s still the question that we need to solve.

And I don’t think classical LLMs will give us a straight answer. So it’s not a question of one-shot prompts or some hybrid LLM pipelines, we need something more powerful and more classical, please.

But my thinking these days actually goes to something beyond of the memory. And no, it’s not the context graphs, because actually the memory is more advanced than the context graph and actually you could read it also in my LangGraph book about the proper graphs and the memory and how they actually replace all of this in something much better than the classical context graphs.

But today we will talk about the world models. Actually, why do agents need memory? Why do humans need memory? And you know that we have an internal model of the world around us in our heads, and we accept signals from outside the world that are processed and calculated according to that model.

So it’s how humans function. And we have the concept in our head that describe external world and it’s a big philosophical topic of idealism, if the concept exists separately and what we observe, is it the real thing or only the concept in our head?

But we will not go to this topic because it’s not Friday and my grappa hasn’t been delivered yet. But the simple question of why the agents need memory and what they want to remember?

And yeah, for sure, we already talked that we have the conversational memory to have better conversations with humans. We have the proper graphs and social memory to organize better conversations and interactions between the agents.

But agents need something more than memory. Agents need to form, using their memory, their own world view because they need to understand what’s actually around, what they can do about it, and what you ask them.

I just released the book. If you’re not following me, actually, I have a decent amount of books about different topics, but all of them are mainly about the agentic memory and the data structure around the memory. And I was focused on the privacy-preserving artificial intelligence. So the majority of the data and processing happens on your phone or on the mesh of your private devices, and maybe some LLMs even hosted on your phone. And it’s a separate discussion for the small language models and how they will transform the privacy and why it matters for the individuals.

https://leanpub.com/ladybugdb

Sovereign Agentic AI (Volodymyrs View) is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

And I talk about the sovereignty in my previous chapter of the podcasts. But what’s special about this book? First of all, it’s describing how to work with the property graphs with the OpenCypher. And Cypher is the query language for the property graphs that was invented by Neo4j, and right now we have it in a Ladybug with interesting features like the relational and node tables with the strict types and all other things. So the Ladybug is an amazing database that’s unlocking the RAG and memory on the user devices for the private agents.

And it came also with seven simple ideas that I was keen to emphasize in the book. The first one is the meaning of the private AI. And it’s the main topic what we’re talking in this podcast—how to have private, sovereign AI that you could rely, you could own, and you could control. And make sure that your data is not contributing to somebody else’s training dataset that will discriminate the group of people to whom you belong. And taking into the account all the madness that happening right now in US War Department, or how they call it right now, and the big LLM providers, we could see how the things could horribly go wrong in this space.

Another interesting idea that I try to bring is that we need something more than memory or we need something more than RAG, first of all. So because RAG is the retrieval-focused process and it’s much more than the memory, right? It’s much less than the memory, let’s say. And yeah, so then I’m describing how to take the property graph model and explain the basics of the graphs and then I try to lead them to the heavy lifting topic of the AI-empowered data structures like the hypergraphs, the metagraphs and why they matter for the agentic workforce and why we still could use the technology that was not designed for it but still able to do the job. After that, we switch to the topic of implementing the semantic spacetime. It’s the special kind of ontology that allow us to describe the complex object around us and offer us something much powerful than simple graph embeddings and similarity and bring the similarity as the graph structure.

And in the same time, I would say that we construct the metagraphs based on the semantic spacetime. That are quite powerful concept of nesting the information and creating the complex relations. And actually, I have the working strategy of the big graphs that make the hypergraph and metagraphs working with the simple Cypher and the property model. Then we switch to the deeper topic: we model entire memory for the agents that I describe in my separate book. So I sacrifice my entire book to make this book and just take the distilled summary of it and bring it to your table as the working database schema and code, line-by-line of the schema, and explaining how it works, how to use it, what kind of entities we have, what kind of properties of these entities we have. So it’s really special book, I would say.

And then we will go deeper to some technology advantage. First of all, the Ladybug have the side project, the Ladybug Memory, that have its own memory model that it’s worth of give it a try. It’s built on top of the Ladybug and have own view on the information and we just try to demystify it. Also I describe some super advanced features that no one of the graph databases have, like the ability to have the extensions, work with JSON, work with graph algorithm, work with the relational databases with the power of the Ladybug, and all other things. So it’s really deep topic from one side of the database that nobody heard yet, but the database that could really heavily change the landscape of the graphs. And from the other side, it’s really the deep topic what the agentic AI needs to move forward.

And for sure I try to explain how the conversational memory and memory of the agents could be coupled with something that I called the promise graphs. I also explain the promise graphs and give the property model and ontology of the promise graph that could be used to track the multi-agent and agent-to-agent communication. So it’s quite unique book with, let’s say, 20 euros price or something like that, and then really go deep on so many topics that go beyond. And for sure I intentionally haven’t mentioned the context graphs because if you have the property graphs and agentic memory, you have the context graphs for free and you have the context management for free in completely different philosophy, actually. So it’s some kind of combination.

And I haven’t talked actually deeper that the promise graphs open us the door to something that I call the social memory, where the agents memorize with whom they could interact on which tasks and who is the good guys, who is the bad guys, and all other things. So it’s still open-ended book that captures so many concepts that for me it was hard to stop. But the most important thing is that if majority of my books was the abstract philosophical explanations of the different kind of graph model and architecture, this book is 85% hands-on. So it’s not just explaining the concept, it’s just go and build it with the property database with the concrete fields. That, for example, this memory contains so many interesting patterns like the temporal axis, the temporality, and the different dimensions of the time, the clustering on the kind and the context, the clustering of the graph based on the layers, introduce the layered graph rules and all other things.

So this book, it’s somehow the quintessence of all the research that I made in the last two and a half or even three years. And right now with the Ladybug, I really made it happen. So we still have the place where we could model it and store in a more type and data-driven way, because the Ladybug, it’s the special kind of database that have the node and relational tables that actually have the fixed structure. So it’s not so weird as our favorite Neo4j where you could actually on-the-fly create the relations and nodes that was accidentally mistyped or just broken.

So give it a try. The Ladybug is amazing database. Give it a try to read the book because it’s really special. Take a look to the memory structure, take a look to the promise graph concept. And I still keen to talk about the cognitive processing and how to digest the bigger piece of information to more structured memory and why it should happens gradually. And why it should happens gradually especially on the devices that have the limited processing capacity while your app is still open. It’s all complex questions that deserve a couple of good chapters in a book, or maybe book itself. Because the structure of the data is not enough. We needs to have the cognitive model and concept model on top that allow us to build the processes of all the things. And the processes sometimes is more important because even the reconstruction of the memory from the persisted storage for the human, for example, it’s completely magical and complex reconstruction process where you damage the information a bit and your reconstruction is really depends from your mood, the level of sugar in your blood, and the stars on the sky. That’s why sometimes it’s too creative and sometimes it’s so unreliable that even this process itself deserve the separate book.

And this book I already try to write and it’s 85% ready because I have the memory model, but I skip all this human-like flaws of the memory and why we needs to invent something more reliable than the human memory but still could mimic some good things from the human memory. And this book is still waiting of my attention, to be honest, and I feel a bit ashamed that I could not finish it for more than six months already. But it have so many contradictive material that I needs to process and make my own opinions, not only from the technical side but from the side of the neurology and cognitive science that it’s really hard to finish, to be honest. But I keeping try hard enough. So give it a try to the Ladybug, read my book, and say what you think about it and if you building the agents, you could build the agents that remember now much better than before. So see you next time. Ciao!”

Would you like me to create a technical glossary for the specific terms mentioned in this transcript?

Today, we will talk about sovereignty and AI sovereignty. I must confess that I’m not an AI person; I’m not a machine learning or data science guy. I do a lot of things about graphs and agentic memory—that’s my favorite topic.

Before that, I was a general architect, focusing for the last five years on self-sovereign identity, cryptography, decentralized systems, and all these interesting things that give people sovereignty. So, what is sovereignty, why does it matter, and what does it mean in terms of AI?

Defining Sovereignty

We will talk about this from the human angle, but also from the angle of the agent. This raises interesting philosophical questions: agents and AI systems are no longer just microservices. If they mimic our identity and represent us, should they have traits of our identity and some kind of rights?

Sovereignty as a term appeared in politics for countries: you control your own territory and make independent decisions without the influence of others in internal and external politics.

Digital Sovereignty in the Web 2.0 Era

What does sovereignty mean for the digital world? We usually talk about Web 2.0 and Web 3.0. Big platforms took away permission from people. In the Web 2.0 revolution, we gave too much power to platforms.

Currently, platforms are the representatives of humans on the internet. If you want to do something, you have to go through a platform. We want to change this setup and return to the state of the internet before the big platforms and the Web 2.0 revolution.

If you want to talk to somebody, you shouldn’t need a man-in-the-middle or a representative. You could do everything on behalf of yourself; you control your own data and your own compute. To represent yourself in a network, we need some form of identity—a crypto identity—to represent yourself in a secure but anonymous way.

The Three Pillars of Digital Sovereignty

Digital sovereignty is mainly about ownership: you own your identity, you control it, and you own your data. There are three big pieces to this:

* Data Ownership: You own your data and control access to it.

* Software Control: You own or control the software that runs on top of your data to make it useful. In terms of AI, this means owning the code or the software around your agent. You should be able to audit it, change it, and adapt it to your needs.

* Compute Sovereignty: You need compute to run this software. This is the most challenging part because running powerful models requires heavy computational power, GPUs, and powerful servers.

The GPU and Infrastructure Challenge

Some people compare access to GPUs to access to power stations. They say you don’t need to run your own power station to consume electricity. However, for electricity, we have laws that protect consumers, multiple suppliers, and better regulation.

With LLMs (Large Language Models), we don’t have this. If a player goes out of the market, you are left with “garbage” that doesn’t work anymore. If a provider like OpenAI decides you are “not so good for them” and cuts your access, you lose everything: your conversations and your workflow.

The Path to Sovereign AI

We need to own the computational power and the models just as we own the data. This opens the question of how to own expensive infrastructure or create a “commodity” for it that a group of people or states could manage.

For example, there are initiatives in Switzerland where they are making their own LLMs aligned with the state, with security guardrails acceptable to Switzerland rather than the US, and accessible to all citizens.

Hosting the model yourself offers the highest level of privacy because you have a “zero sharing” policy. You ensure your data is not contributing to training models that might discriminate against groups you belong to.

The Future: Local and Edge Agents

The goal is to own your data, your compute, and the infrastructure. While AI infrastructure is not easily achievable for everyone, “local edge agents” are.

* We can use smaller LLMs that run on our own machines.

* We can afford servers with a few GPUs to run middle-sized models.

* Some agents will run on LLMs, some on distilled SLMs (Small Language Models) for specialized tasks, and some on classical machine learning or neuro-symbolic approaches.

These can run not just on powerful machines, but even on a user’s phone. For example, at King, we built an agent that made inferences directly on the user’s device (iPhone or Android). This is a target for private and sovereign AI. If you own your phone, you own the hardware where the agent runs, and you have a full data snapshot of all your conversations.

Conclusion

Sovereignty matters because nobody can “cut you off”. You own, change, and do anything you want with your system. Furthermore, if you decide to contribute to training a model, you can do so in a fairer way by receiving benefits for providing your data, creating a more equal data economy.

Ultimately, sovereignty is about protecting our future from surveillance capitalism and the control and domination of big companies or countries.

Introduction and Experience

Hey, we will talk about the agents and why agents need memory, and how it could look like, and why, for example, RAG is not enough and why RAG is not true memory and all of this thing. So, you know, I was working on the memory for the last two years. I was working on it actively when I was the part of the Keen, the privacy-focused AI assistant. Right now, I am working more on the agents and the protocols and agent identity at Affinity, but still memory is my big passion.

The Landscape of Agent Memory

If you’re following the space right now, we have the huge booming topics like context graphs, decision traces, how to make agents learn from his decisions. We also have some manipulations around this because we dehumanize the agents and actually compare them with the people that could take ad hoc decisions, and actually for me, it’s not really true.

Anatomy of an Agent

But you know, let’s talk about the agent anatomy first. So majority of the agents that we’re talking about nowadays, unfortunately in a core have the large language models. And large language models have some kind of memory because they have the training data stored in weights, and actually the LLM has something that it is remember, and it remembers a lot. But the problem is that it’s not acquiring new information and it’s not acquiring information, for example, user gives to them or some company specific if we talk about the enterprises.

The Rise and Limitations of RAG

And then what we do, we build the knowledge base and we apply the RAG, yeah, so augmented generation. And this helped us to bring the data that was not in the data set and allow LLM to work with them. And actually RAG was quite successful and we start from simple vector databases and vector search, then we all realize that it gives us some decent results, works quite well, for example, for the documents, works quite well by the way if we have the limited amount of documents. Because if the amount of information will grow, we will see the decay, and especially when we build the vector space representation of all our documents and we will see if they condense. So if they focus on one topic in one place or they just sparse and distributed. The more condensed they are, the more the errors will get because we do not know which of the chance to choose.

Advanced Memory Strategies

And then we apply different strategies. It was the boom of graphs, entity recognition, different strategies combining the RAGs with the graph with the vector search for RAG, then combining the graphs with the vector search for RAG and some advanced topics from naive BM25 indexing to some advanced graph neural network indexes and all of the things.

And all this helped, but still the accuracy struggle, and we even have the research that it was the broken promise that actually the RAG do not solve the hallucination of the agents, it’s improve a bit. And then we stay with the questions, okay, if not RAG, what we could do to fight with the hallucination from one side, from another side improve the conversation experience.

Shifting from Bots to Agents

And right now when we shifted from the bots that talk with the users to the agents that do something for the users, we discovered that we have the new properties to the agents that not just needs to maintain the value conversation and pick up the facts that relevant to the conversation. We have much bigger challenges: how the agent could follow the plan, how the agent could execute the tasks without the hallucinations, and how to make his actions align with our goals and wishes. And it’s way more challenging task than just simply correlation of the information chunks that GraphRAG gives us.

Mimicking Human Memory

So then we end up with the concept of the memory because we trying to mimic the humans and we have the memory. And it’s interesting and deep talk: how human memory works, do we have one memory or we have multiple memories, how it’s organized and how we do the processing.

But if we could shortly talk about the memory and why RAG is not memory, the first big thing, especially for the conversational memory, that the RAG doesn’t have the context. The RAG doesn’t have the deep context in episodic context.

So we remember something in a context of the emotions and events that happened to us. And we don’t have the emotional context, so we don’t have the emotions at all. Right, we could capture them somehow, but majority of the systems doesn’t have even the notice of this, right? And the human memory, the stronger it is, the stronger the emotion was. And if they’re negative or they’re just dangerous stuff to you, you will remember it much better. I don’t think that it’s a positive of the human memory, but it was the survival mechanism.

Episodic Memory and Processing

And another one that these events or the information that we remember more focused on the episodic memory. And we even have the episodic buffer. So we have the big chunks that have the episodes, they go to the episodic buffer, then they go to the temporal memory, then in night we just process the memories, move them to the permanent memory, and then we have a couple of cognitive processes that do the semantization of the episodic memory. And episodic memory decay faster, but all our memory, somehow the big chunk of our declarative memory actually is the episodic memory and have the fight episodic context.

The Challenge of Time in Memory

And unfortunately RAGs struggle with it. Yeah, we could build some graph-based memory systems that have the context concept, that have the episodic concept as event graphs, for example, do. Then we get completely new challenge that we wants to process the episodic memory and now we need the notion of time. And time itself is a huge, huge topic.

And actually I wrote a book about the AI memory and time because time deserve itself the book, and maybe two to be honest. So this episodic context go quite tight to the understanding of time, processing time, and actually time is not timestamps. Time actually the sequence or the DAGs, the directed acyclic graphs of the events.

And if we’re talking about the human, these events have some different emotions and different impact on our life. They have some consequences, they have the relation, they have the casual relation between each other. And I talking about this architecture of this event-focused, casual, time-aware memory in my book. So it will take a quite long time to describe it here, but if you wants to understand it, you could read my book about conversational memory or you could also find the architecture of this memory in the my new book that I still working on it.

https://leanpub.com/time-aware-ai-memory

Beyond Context Graphs

It’s a book about what’s goes beyond the context graph and how to make the agents actually do what we ask them to do. And another thing that GraphRAG have quite limited capabilities to build the associations and the semantic packages. So we always remember the semantic information in a connection to another semantical concept. That’s why we all like graphs because they somehow mimic how our semantic memory works because our semantic memory is the huge network.

But the trick is that our semantic memory, if we read some researches, it’s not the directed graph. It’s more the multi-layered hierarchical network that have at least three kind of hierarchies and some sub-hierarchies and the classification of the things. So you have some mixture of multi-layered graph that form this complex network. But our main ability is to build the associations and build the links between the concepts, and yeah graphs could do it, but GraphRAG even have the quite limited capacities to do it.

https://leanpub.com/beyondcontextgraphs

Memory as a Cognitive Process

And the biggest part that RAG is only one cognitive process, right? That you get the question, you find what’s relevant, you give it back. But human memory have huge amount of cognitive processes: of processing, extracting, memorizing, semantization, the dynamic recall, the decay, and forgetting.

And forgetting itself actually is the big topic that we will talk next. But your retrieval happens without the understanding of the information, it’s just some mathematical filtering like BM25 or some graph algorithms that find the centrality of the different entities and all other thing. It’s too naive and it’s not enough.

The Role of Forgetting and Recall

And I already mentioned that the memory require forgetting and forgetting is a huge, huge topic because our memory is more focused to forget. But it’s still big question how we forget, do we forget forever or we just change the priority and importance of this information and we have struggle to recall it and all of the things.

And recall actually have the loop: the more often you recall the information, the better you remember it, you make this neural network stronger and you just remind that it’s something important to you and all other thing. So as you see, the forgetting is tightly connected to recall in a human memory.

And actually I also build this naive mechanisms to look in that if we collect the statistic of the retrieval and recall, and if it’s more often then probably it’s something that we wants to put some importance to it. And when we try to form this recall loop with the forgetting, then I proposed the different concepts of attention.

Focus, Attention, and Task Orientation

So we just remember what’s matter and we remember what’s matter to us in the particular action and task. And actually human memory is quite task-oriented and you quite often recall the things around the actions and by the way, they activate completely different areas of your brain. So you try to recall the information with the purpose to do something. So and your skills is slightly different kind of memory, it’s not declarative memory, and even if you have amnesia, you still know how to drive the bicycle. It’s yet another evolutionary thing, it’s more automatic and it’s quite interesting topic.

But then I guess that agent memory could be heavily built around the concept of the focus and attention. And then the forgetting is something that doesn’t matter right now for this particular task. And it’s quite task-oriented.

Explanability and Goals

And if it’s task-oriented, then we shift from the conversation and conversational relevance to more important thing that the context graph nowadays could solve: how you taking the decision, how to make this decision explainable, and how to make this decision of the agent following your goals, following your constraints, following your company policy and all other thing.

And I would say that this kind of context graph and agent memory architecture in a context of the tasks have completely different focus and attention mechanisms from the conversational memory because in conversational memory, you have only one cognitive process that are quite complex, or maybe couple of cognitive processes of digesting and extracting the memories and actually finding the relevant memories according to the conversational context. So it’s simple.

Social Dimension of Memory

But when we have the agent that actually communicate with other agents and actually cooperate with them and do something, so it’s already social component of the memory that agents needs to remember: who is reliable, to whom the agent could trust, to whom agent could delegate. So we get this social dimension of the memory for the agents.

And the most important that agent interact also with the humans that give him the tasks, and maybe some other agents give him the tasks. And it’s open question: should agent differentiate the human and the agent or for agent it’s all the agents and it doesn’t matter if this agent drinks tea while talking or just consume a bit of energy? So it’s a good question that we still needs to get answer.

Operational Memory and Symbolic AI

But the agent operational memory is more focus on the tasks. It’s more focus on the rules and what could happen and what’s to do if something happens. And then it’s open us the good old space of the symbolic AI and expert system and rule-based memory and rule-based expert system and approaches that we all forget because we heavily failed in eighties with the Prolog formal system and first-order logic and all other things. But right now all this stuff is more and more relevant.

Future Directions: Promise Theory

And what’s more important that rules relevant, we needs to have the memory to remember the rules, we needs to have the reasoning capabilities and solvers that could apply the rules and what’s more important, we just needs to have some framework that actually apply all this rule-based systems to the agent interactions and agent intents and all other thing.

And I touch this topic in my new book, What Goes Beyond the Context Graphs, and today we have the memory for sure that we already have a chance to talk. And we have the concept of the promises and Promise Theory of Mark Burgess. And in Promise Theory, we form some kind of promise graphs. And these promise graphs actually captures not just the decisions but some interaction of the agent with other agents, some interactions of the agent with the tools and data information.

So we have some promises of the interaction of the agent with the memory, we have some promises that interact with the tools. So somehow we have quite complex audit log that could be reflected, could capture what agents made, what other agents made for the agent, what kind of data traces we have, and all this complex promises could lead us with the casual analysis to the final decisions, give us the possibility to apply the rules and have some kind of explainability and causality.

Conclusion

So the combination of causality analysis, data traces, and actually the Promise Theory give us the good foundational framework to go beyond the context graphs because the context graph right now quite weak concept that say that we needs to store the decisions but we have no implementation of this. And actually I also talking about the semantic space-time that could be used for this.

So please, I have the bundle for the memory that explain all the things in two books, one is time-focused, another one I work on this beyond concepts. So if you’re keen to learn about the memory more, if you’re keen to build the agents that remember and do what you ask them to do, just read my books, contact with me, and let’s talk together about this complex topic.

To read my memory book bundle : https://leanpub.com/b/agenticmemory