Building DCMA a Different Approach to Memory for AI Agents

I've been spending quite a bit of time experimenting with autonomous AI agents. From self-hosting agents with Docker to connecting them with tools, messaging platforms, and different models, I've been interested in seeing how far I could take these systems beyond simple chat interfaces.

One thing I kept coming back to was memory.

Most AI agents I've worked with rely on some combination of conversation history, embeddings, vector databases, and retrieval-augmented generation (RAG) to remember information. It's a practical approach, but I started wondering if there was another way to handle memory.

I wasn't particularly interested in building another vector database or another RAG implementation. I wanted to explore something different.

That's where DCMA started.

So, What Is DCMA?

DCMA stands for Deterministic Cognitive Memory Architecture.

It's a project I've been developing to explore a different approach to how autonomous AI agents represent, retrieve, and manage information.

Instead of treating memory as a collection of documents or text chunks that can be retrieved through semantic similarity, DCMA represents knowledge as an interconnected graph that evolves over time.

The idea is relatively simple to explain, although implementing it is another story.

I wanted memory to have structure. Information should have relationships with other information. Contradictions shouldn't necessarily mean something needs to be overwritten. Recurring patterns should be capable of forming higher-level concepts.

Rather than relying on embeddings to determine what information is relevant, I wanted to experiment with a system where relationships and graph structure play a central role in retrieval.

Why Not Just Use Vector Databases?

There's nothing inherently wrong with vector databases or RAG. They solve real problems, and I still think they're useful.

But while experimenting with agent memory, I became interested in some questions:

• What happens when an agent remembers two conflicting pieces of information?
• How should related memories influence one another?
• Can recurring information eventually become a higher-level concept?
• Can retrieval be explained through explicit relationships rather than similarity scores alone?
• Can memory operations produce reproducible results?

These questions pushed me toward graph-based representations and deterministic state transitions.

I wanted to see whether I could build an architecture where these behaviors were part of the memory system itself.

How I Approached the Architecture

I eventually started organizing DCMA around six fundamental principles:

1. Cognition Is Topology – Relationships and graph structure contribute to how information is represented.
2. Memory Is Dynamic State – Memory isn't just stored information; it evolves through state transitions.
3. Retrieval Is State Reconstruction – Instead of simply searching for similar documents, the system reconstructs relevant cognitive structures.
4. Contradiction Is Native – Conflicting information can coexist within the graph.
5. Abstraction Is Compression – Recurring patterns can be consolidated into higher-level concepts.
6. Attention Is Energy Distribution – Activation propagates through the graph to influence relevance.

These principles eventually became part of DCMA's formal specification.

I also divided the runtime into seven subsystems:

• Symbol Engine
• Topology Engine
• Activation Engine
• Consolidation Engine
• Contradiction Engine
• Retrieval Engine
• Entropy Regulation Engine

Each subsystem handles a different part of the architecture, but they all operate around a shared cognitive graph.

One part I found particularly interesting was contradiction handling. In a conventional memory implementation, conflicting information can easily become a problem of deciding which statement to keep. With DCMA, I wanted to explore representing those conflicts directly instead of immediately discarding one side.

It's one of the parts I'm particularly interested in developing further.

Actually Building It

At some point, I realized that having an interesting architecture on paper wasn't enough. I needed an implementation that I could actually run, test, and experiment with.

I decided to use Rust for the runtime.

I wanted something that gave me control over the underlying data structures and made it easier to reason about state transitions and performance.

The project gradually grew into a Rust workspace with its own runtime components, tests, benchmarks, documentation, and HTTP API.

I also worked on a mathematical formal specification to describe the architecture independently of the implementation.

This was probably one of the more challenging parts of the project. It's one thing to describe how a cognitive system should behave conceptually. It's another to translate those ideas into explicit rules and operations that can be implemented and tested.

I had to think about how graph structures evolve, how activation propagates, how information gets consolidated, and how retrieval should work within the architecture.

There were plenty of things to reconsider along the way.

Making It Public

I eventually decided to make the repository public.

I wanted to share both the implementation and the formal specification rather than keeping the project as a private experiment.

The repository currently includes:

• A Rust-based reference implementation.
• A mathematical formal specification.
• Seven runtime subsystems.
• Automated tests and benchmarks.
• API documentation.
• Usage documentation.
• Known issues and design considerations.

I'm making it available under the MIT License.

You can explore the source code, inspect the architecture, and follow its development here:

github.com/whilmarbitoco/dcma

What's Next?

DCMA is still a work in progress, and there are several things I want to explore before making stronger claims about its capabilities.

Some of my priorities include improving retrieval, evaluating memory consolidation, testing larger graph structures, and comparing its behavior against conventional embedding-based retrieval approaches.

I'm also interested in integrating it with existing autonomous agent frameworks. Ideally, DCMA shouldn't require developers to build an entirely new agent just to experiment with a different memory architecture.

I want to see how it performs when used by actual agents, not just through isolated runtime tests.

A Few Thoughts

I didn't start DCMA with the intention of building a completely new cognitive architecture. It started because I was experimenting with AI agents and became curious about how their memory systems could work differently.

That curiosity eventually turned into a much bigger engineering project involving graph theory, formal specification, Rust, and a lot of experimentation.

I don't consider the architecture finished, and I still have plenty of questions about its practical applications.

For now, I'm happy to have something tangible that started as an idea and eventually became a working implementation.

There's still a lot to explore.