I replaced my agents markdown memory with a semantic graph

Why flat files are a dead end for agent memory and what happens when you use a DAG instead

I have been building with AI agents since mid-2025. First with LangChain, then briefly with AutoGen, and for the last couple months with OpenClaw. And the whole time there was something bugging me that I could not quite articulate until I saw it break in production.

The memory problem.

The thing nobody talks about

Every agent framework I have used stores memory the same way: text files. Markdown, YAML, JSON, whatever. It is all the same idea -- dump what the agent "knows" into a flat file and hope for the best.

OpenClaw does this with SOUL.md (the agent personality), HEARTBEAT.md (its task loop), and a bunch of markdown files for conversation history and long-term memory. And honestly? It works fine for personal use. I ran my OpenClaw agent for weeks managing my email and calendar through Telegram. No complaints.

Then I tried to build something for a client.

The client is a small fintech in Spain that needed an agent to handle KYC verification -- basically confirming that a user passed identity checks before letting them do certain transactions. Simple enough, right?

Here is where it fell apart. The agent could say a user passed KYC. It could write "User 4521 passed KYC Level 2" into a markdown file. But when another agent (the compliance agent) needed to verify that claim... it was just reading a text file. There was no way to know if that claim was actually true, if it had been tampered with, or even if the agent that wrote it had the authority to make that assertion.

I was literally building a compliance system on top of text files. I felt like an idiot.

Enter AIngle

I found AIngle because I was googling "semantic memory for agents" at 2am on a Tuesday, which is when all the best technical decisions are made.

AIngle is a protocol -- not a framework, not a library, a protocol -- for storing knowledge as semantic graphs instead of flat text. It comes from a project called Apilium and it is built in Rust (12 crates, which initially scared me, but the latency numbers are wild -- 76 microseconds for local operations).

The core idea is simple once you get past the terminology:
Instead of storing "User 4521 passed KYC Level 2" as a string in a markdown file, you store it as a semantic triple:

Subject:   user:4521
Predicate: kyc:level
Object:    2
Proof:     PoL:hash:a7f3

That last field is what changed everything for me. Every assertion has a cryptographic proof attached. It is called Proof-of-Logic (PoL), and it basically means that when Agent B reads a claim made by Agent A, it can mathematically verify that the claim is consistent with Agent A's history of assertions.

No trust required. No "I read it in a markdown file so it must be true." Math.

How it actually works (with code)

I am not going to pretend this was easy to set up. It was not. The docs are... improving. But here is the gist of what I ended up with.

AIngle has three layers, and it took me a while to understand why you need all three:

Cortex -- this is the part that takes natural language and turns it into SPARQL queries. So when your agent thinks "does this user have KYC level 2?", Cortex translates that into a structured query against the semantic graph. You do not write SPARQL yourself (thank god).

Ami -- the semantic mesh. This is where assertions live, propagate between agents, and get verified via PoL. Think of it as a shared knowledge layer where agents can publish claims and other agents can verify them without trusting each other.

Nexo Genesis -- the storage layer. Each agent (or user, or organization) gets their own "source chain" -- basically a private DAG where their data lives. You own your data. Nobody else sees it unless you explicitly share it, and even then you can use zero-knowledge proofs to share properties without sharing the underlying data.

Here is what the KYC verification looks like with AIngle vs without:

// WITHOUT (OpenClaw style)
// Agent A writes to a file
fs.writeFileSync('memory/kyc.md', 
  '## KYC Status - User 4521: Level 2 (verified 2026-02-15)'
);

// Agent B reads the file and... trusts it?
const kycData = fs.readFileSync('memory/kyc.md', 'utf8');
// hope nobody edited this file lol

// WITH AIngle
// Agent A publishes a verified assertion
const proof = await ami.assert({
  subject: 'user:4521',
  predicate: 'kyc:level',
  object: 2,
  evidence: kycVerificationResult.hash
});

// Agent B queries and verifies cryptographically
const claim = await ami.query({
  subject: 'user:4521',
  predicate: 'kyc:level',
  requireProof: true
});

const isValid = await nexo.verifyPoL(claim.proof);
// isValid is math, not faith

The second version is more code, yeah. But it is also the difference between "we think the user passed KYC" and "we can prove the user passed KYC, and here is the cryptographic receipt."

The stuff I did not expect

Once I had the semantic layer running, a few things surprised me.

Memory queries got smarter. With markdown, if I wanted to know "which users completed KYC in the last 30 days and also had a transaction flagged for review", I would have to parse text files and do string matching. With semantic triples, that is just a query. The graph structure makes relational queries trivial.

Agent disagreements became resolvable. I had two agents that disagreed about a user status -- the KYC agent said "verified" and the compliance agent said "under review" because it had newer information. With markdown, this is just two conflicting strings in two files and you pick whichever was written last. With Ami, there is a consensus mechanism. The agents compare the timestamps and provenance of their assertions and resolve the conflict based on which assertion has stronger evidence. No human intervention needed.

The ZK proofs are actually useful. I was skeptical about this. Zero-knowledge proofs sounded like blockchain hype to me. But in practice, being able to prove "this user is over 18" without revealing their birthdate, or "this user has sufficient balance" without revealing the amount -- that solves real GDPR problems. My client legal team was more excited about this than any of the AI features.

What still sucks

I am not going to write a puff piece. There are real problems.

The documentation is sparse. I spent way too many hours reading Rust source code to understand how certain things work. If you are not comfortable reading Rust, you will struggle with the lower-level AIngle stuff.

The onboarding experience needs work. Setting up Nexo Genesis for the first time involves more configuration than I would like. It is not "npm install and go" -- there is infrastructure to think about.

The community is small. When I got stuck, there were no Stack Overflow answers to fall back on. I ended up in a Discord channel with maybe 30 people. They were helpful, but it is not the 117K-member OpenClaw Discord.

And honestly, for simple personal agents -- managing your email, setting reminders, basic automation -- you do not need any of this. Markdown memory is fine for that. AIngle is overkill for "remind me to buy groceries."

But if you are building agents that need to make verifiable claims, handle sensitive data, or work in regulated industries... flat files are not going to cut it. I learned that the hard way.

What is next

I have been doing all of this integration manually -- wiring AIngle into my agent setup, writing the adapters, configuring Nexo Genesis by hand. It has been educational but it has also been a lot of plumbing work that I would rather not repeat.

A few days ago I came across a project called MAYROS that has AIngle baked in from the start. It is an OpenClaw fork, so the channel integrations (WhatsApp, Telegram, Slack) and classic skills carry over, but the memory layer is completely replaced with semantic graphs and PoL verification out of the box. Basically what I have been building by hand for weeks, but already wired into the agent runtime.

I have started setting it up for my fintech client staging environment and so far the migration CLI is surprisingly clean -- it reads the old OpenClaw markdown memory and converts it to semantic triples. The classic skills work without touching anything, which was my main worry. Still early days for me with it but the architecture looks solid.

I am going to write a proper follow-up post once I have spent more time with it -- the full migration process from OpenClaw, how the multi-agent PoL verification works in practice with real compliance flows, and honest benchmarks. The stuff I wish someone had written when I was getting started with AIngle by hand. Follow me if you do not want to miss that.

The MAYROS repo is at github.com/ApiliumCode if you want to poke around the code in the meantime. And if anyone has already tried it, hit me up in the comments -- I would love to compare notes.

tl;dr

• Agent memory stored in flat files (markdown, JSON) works for personal use
• It breaks badly when you need agents to verify each other claims
• AIngle stores knowledge as semantic graphs with cryptographic proofs
• The learning curve is real but the capabilities are worth it for anything touching compliance or sensitive data
• If you are building toy agents, keep using markdown. If you are building agents that matter, look at semantic memory
• I am testing MAYROS (an OpenClaw fork with AIngle built in) -- full writeup coming soon

I am happy to answer questions in the comments. I have been heads-down in this stuff for weeks and I genuinely think semantic agent memory is going to be the standard approach in a year or two. Or I am wrong and we will all be parsing markdown files forever. Either way, it has been a fun ride.

If you are working on something similar or have thoughts on agent memory architectures, I would love to hear about it. I am especially curious if anyone has tried other approaches to inter-agent verification that do not involve semantic graphs.