DEV Community: Vladimir Stelmak

Your AI Agent Does Not Need More Chat History. It Needs Real Memory 🧠✨

Vladimir Stelmak — Tue, 30 Jun 2026 16:02:54 +0000

Most AI agents fail in a very boring way.

Not because they are stupid.
Not because the model is weak.
Not because the prompt is bad.

They fail because they forget.

You explain the project once.
Then again.
Then again.
Then again.

You tell the agent your coding style, your architecture, your rules, your preferences, your mistakes, your decisions, your context.

And after a few sessions, everything slowly turns into fog.

The agent does not really remember.
It only carries a longer conversation behind it.

That is not memory.

That is just a backpack full of text. 🎒

So I started building something different:

👉 Memory Genome Engine
A local-first structured memory engine for AI agents.

GitHub:
https://github.com/ECD5A/Memory-Genome-Engine

The Problem: “Memory” Is Usually Just More Text

A lot of AI memory systems are basically one of these things:

📜 long chat history
🧾 summaries
🔍 vector search
☁️ hosted memory
🧩 random notes injected into prompts

All of these can be useful.

But they also create a strange problem:

The agent may remember something, but you do not really know what, why, where, or how.

Why did this memory appear?
Is it still valid?
Who confirmed it?
Does it belong to this project or another one?
Is it private?
Is it outdated?
Can I inspect it locally?
Can I move it between machines?
Can I validate the store?

For real agent workflows, these questions matter.

Especially if the agent is not just answering a question, but helping you build, debug, research, write, plan, or maintain a project over many sessions.

That is where normal chat history starts to break down.

My Idea: Memory Should Be Structured 🧬

Memory Genome Engine is built around one simple idea:

AI agent memory should be structured, local, inspectable, and explicit.

Not just:

User likes short answers.

But something closer to:

kind: user_preference
scope: global
status: active
trust: user_confirmed
sensitivity: private
subject: communication_style
value: User prefers concise technical answers.

This is the “genome” part.

Each memory item has markers.

These markers describe what the memory is, where it belongs, how much it should be trusted, whether it is active, whether it is sensitive, and how it should be recalled later.

So instead of treating memory as a random chunk of text, the system treats it as a structured memory cell.

That makes the agent’s memory easier to inspect, debug, filter, and reason about.

Why Local-First? 🏠

I do not think every agent memory system should be cloud-first.

For many workflows, memory should live close to the user.

Local-first memory means:

✅ no required hosted service
✅ no required vector database
✅ easier inspection
✅ easier backups
✅ better control over private context
✅ useful for offline or local agent workflows
✅ easier to understand what the agent actually stores

This is important to me.

I do not want agent memory to become another invisible black box.

If the agent remembers something, I want to see it.
If it recalls something, I want to understand why.
If something is stale, I want to mark it.
If something is wrong, I want to reject it.
If something is private, I want boundaries around it.

That is the philosophy behind Memory Genome Engine.

What Memory Genome Engine Does ⚙️

Memory Genome Engine is a Rust-based memory layer for AI agents.

It provides:

🧠 structured memory cells
🧬 marker-based memory “genomes”
📦 local binary storage
🔥 hot memory for recent items
🧊 sealed pages for older memory
🔎 recall into context packets
🖥️ CLI support
📟 terminal UI
🔌 MCP-compatible server
🐍 Python SDK
🟦 TypeScript SDK
🔐 optional encrypted stores

The goal is not to build another full agent framework.

The goal is narrower:

Give agents a real memory subsystem they can use across sessions.

Something durable.
Something inspectable.
Something local.
Something a developer can actually reason about.

A Small Example

Imagine telling an agent:

mge remember "The project uses Rust for the core engine" \
  --kind project_fact \
  --scope memory-genome-engine \
  --trust user_confirmed

Later, the agent can recall relevant context:

mge recall "What should I know before changing the engine architecture?"

And instead of dumping random chat history into the prompt, the system can return a more focused context packet.

That packet can contain project facts, constraints, warnings, preferences, and other memory items that are relevant to the task.

This is the difference between:

“Here is everything we ever talked about.”

and:

“Here is the memory that matters for this task.”

That difference matters a lot.

Why Not Just Use Embeddings? 🤔

Embeddings are useful.

Vector search is useful.

Semantic retrieval is useful.

But I do not think every memory problem should be solved only with embeddings.

Sometimes you need structure.

Sometimes you need clear scopes.
Sometimes you need trust levels.
Sometimes you need status markers.
Sometimes you need to know whether a memory is active, rejected, deprecated, or private.
Sometimes you need deterministic behavior more than magical similarity.

Memory Genome Engine is marker-first.

That means memory is organized around explicit metadata and structured recall, not only semantic closeness.

It is not trying to say “embeddings are bad.”

It is saying:

Agent memory should not be only vibes-based retrieval. 😄

Hot Memory And Sealed Memory 🔥🧊

One design idea I like in MGE is the memory lifecycle.

Recent memory lives in a hot layer.

Older memory can be sealed into binary pages.

So memory has a path:

remember → hot memory → seal → recall

This gives the engine a way to separate recent, active memory from colder, archived memory.

The agent does not need to carry everything at once.

It can ask for what matters.

That is closer to how I think long-running AI tools should work.

Not infinite prompt stuffing.
Not endless chat logs.
Not “hope the model figures it out.”

But memory with structure, lifecycle, and recall.

Why I Care About Inspectability 🔍

For me, this is the most important part.

I do not want an AI agent to say:

“I remembered this somehow.”

I want to ask:

Where did this memory come from?
What kind of memory is it?
What scope does it belong to?
Is it still active?
Is it trusted?
Is it sensitive?
Can I validate the store?
Can I export or inspect it?

If agents are going to become long-running tools, their memory cannot stay invisible.

A serious agent needs serious memory boundaries.

Not because everything must be complicated.

But because once an agent starts remembering things across sessions, memory becomes part of the system’s behavior.

And system behavior should be inspectable.

This Is Still Early 🚧

Memory Genome Engine is still young.

It is not a giant platform.
It is not a polished commercial product.
It is not trying to solve every memory problem in AI.

It is a focused open-source project exploring one direction:

local-first structured memory for AI agents.

I am building it because I want agents that can work with real project context without turning that context into an opaque cloud dependency or a giant pile of chat history.

There is still a lot to improve.

But the foundation is already there:

Rust core
CLI
TUI
MCP server
Python SDK
TypeScript SDK
binary local storage
memory markers
sealed pages
recall modes
optional encrypted stores

And I think this direction is worth exploring.

Who Is This For? 👀

You may find Memory Genome Engine interesting if you are:

🧑‍💻 building local AI agents
🔌 experimenting with MCP tools
🧠 thinking about long-term AI memory
🛠️ building developer assistants
📚 working on research workflows
🔐 interested in local/private memory
🦀 working with Rust-based AI infrastructure
🧪 tired of “just add vector DB” answers

If any of that sounds familiar, I would really appreciate your feedback.

Final Thought ⭐

I think AI agents need better memory.

Not just longer context windows.
Not just summaries.
Not just embeddings.
Not just hidden hosted state.

They need memory that can be structured, inspected, validated, moved, sealed, and recalled.

That is what I am trying to build with Memory Genome Engine.

GitHub repo:

https://github.com/ECD5A/Memory-Genome-Engine

If the idea feels useful, please check it out.
And if you want to support the project, a GitHub star would help a lot. ⭐

Thanks for reading! 🙏

Disclosure: this article was written by Vladimir Stelmak and edited with AI assistance.

Why an AI Agent Should Not Be Treated as Proof: Building EllipticZero Research Lab

Vladimir Stelmak — Mon, 01 Jun 2026 20:44:06 +0000

In security review, large language models are useful, but they also create a dangerous temptation: the output often sounds more certain than the evidence behind it.

A model can summarize code, suggest review directions, produce hypotheses, and write a convincing report. That is useful work. But a model sentence is not proof. In smart-contract security, cryptography, access control, asset flow, signing assumptions, and upgrade logic, an unsupported confident answer is not just noisy. It can push a reviewer toward the wrong risk, the wrong fix, or the wrong sense of completion.

I built EllipticZero Research Lab around that boundary.

Project:

https://github.com/ECD5A/EllipticZero

EllipticZero Research Lab is a source-available local-first research workflow for scoped smart-contract security review and defensive ECC research. The core idea is simple: agents can help with planning, hypotheses, critique, and report structure, but substantive claims should remain tied to local tools, traces, manifests, replayable artifacts, exportable reports, and human review.

It is not positioned as an autonomous hacking system or a replacement for auditors. The goal is narrower and more practical: help a careful reviewer see what was checked, what the local evidence supports, what still needs manual validation, and what artifact remains after the review.

The Problem With Model-Only Security Output

If you give a contract to an LLM and ask it to find bugs, it will usually produce something. Sometimes that something is a useful hypothesis. Sometimes it is a shallow detector-style warning. Sometimes it is a plausible vulnerability description that is not connected to a reachable path, local tool output, a source location, or a reproducible artifact.

That is a poor fit for security review.

A reviewer needs to know:

what code or repository surface was inspected;
which local tools or checks produced signals;
which findings are supported by evidence;
which findings are only hypotheses;
what still needs human validation;
how to repeat or compare the run later;
how to export the result without turning a weak signal into a confirmed vulnerability.

This is why I think AI-assisted security tools should be designed around evidence boundaries first, and agent reasoning second.

Evidence First, Agent Second

The working rule in EllipticZero Research Lab is:

An agent can propose hypotheses, structure the review, and criticize conclusions. Evidence remains in local checks, artifacts, traces, manifests, replay bundles, and human validation.

That changes the shape of the system.

The agent is not the final authority. It is part of the workflow. It can help decide what to inspect next, explain why a risk lane matters, and turn noisy output into a readable review queue. But a finding should not become stronger just because the text sounds strong.

The useful output is not "the AI found a bug." The useful output is a review artifact that another person can inspect.

How The Workflow Is Structured

EllipticZero Research Lab is organized around a few layers.

The first layer is local context: contract code, repository inventory, selected domain, local tool availability, synthetic cases, saved sessions, and artifacts. The workflow is designed to preserve what was actually available during a run.

The second layer is bounded agent work. Agent roles can help with math, cryptography, strategy, hypotheses, critique, and reporting. Their job is to improve the review process, not to convert an unsupported statement into proof.

The third layer is the artifact layer: sessions, traces, manifests, replay bundles, Markdown reports, SARIF exports, evidence coverage, toolchain fingerprints, and redacted JSON snapshots. If the result cannot be inspected later, it is much less useful for serious review.

The fourth layer is the reviewer. The report should make it clear what was observed, what was inferred, what evidence exists, what is weak, and what should be checked manually.

Why Smart Contracts And ECC

Smart contracts are a useful first domain for this kind of workflow because they have repeatable review lanes:

access control;
upgrade and storage layout;
asset flow;
vault and share accounting;
oracle assumptions;
signatures;
rewards;
AMM and liquidity logic;
bridge and custody surfaces;
staking and treasury logic.

Those lanes are structured enough to support repeatable review, but dangerous enough that overconfident automation is risky.

For example, "there is an external call" is not the same as "there is an exploitable reentrancy bug." "There is an admin function" is not the same as "there is a critical access-control vulnerability." A useful workflow needs context, reachability, state transition reasoning, local signals, and a clear manual-review boundary.

The ECC side is included as defensive research: point formats, curve metadata, subgroup/cofactor checks, twist hygiene, encoding boundaries, and curve-family consistency. This is another area where model confidence without local computation is not enough.

What A Useful Result Looks Like

The target result is not a dramatic list of "10 critical bugs." A better result is a cautious review snapshot:

finding cards;
risk lanes;
source-line hints when available;
local tool signals;
evidence coverage;
confidence notes;
manual-review boundaries;
remediation direction;
recheck path;
reproducibility bundle.

That is less flashy than an AI-generated audit claim, but it is more useful.

If a smart-contract golden case is run, the system should show not only a potential risk, but also why it entered the review queue, what local evidence exists, what remains unconfirmed, and how a reviewer can repeat or export the result.

Why Markdown, SARIF, And Replay Matter

Security workflows need exports.

Markdown is useful because people can read it, send it, attach it to discussions, compare it with previous runs, and use it as a review packet.

SARIF is useful because it can fit into code-scanning and CI-like workflows. But SARIF output needs care. A SARIF item should not automatically become a confirmed vulnerability just because it exists in an export. In an AI-assisted workflow, an exported item may be a review item, a local signal, or a hypothesis that still requires validation.

Replay and reproducibility matter for a similar reason. If the review result cannot be revisited, compared, or explained later, it is hard to defend in front of a team, client, or auditor.

Why Mock Mode Matters

The project supports hosted providers when configured, but it also keeps a no-key evaluation path.

That matters because an evaluator should be able to inspect the shape of the workflow without first trusting an external model provider or sending private code anywhere. A local reviewer should be able to run a self-check, open golden cases, inspect report shape, and see export behavior before deciding whether to configure a live model.

For a security tool, mock mode is not just a convenience. It is part of the evaluation boundary.

Current Project Shape

The current repository includes:

an interactive CLI workflow;
scoped smart-contract review lanes;
defensive ECC research paths;
bounded agent roles;
local-first evidence handling;
evaluation guide and golden cases;
reproducibility/session artifacts;
replay bundle path;
Markdown report export;
SARIF review export;
benchmark scorecards;
security and data-handling boundaries;
commercial licensing documentation for hosted, OEM, white-label, resale, and paid platform use cases.

The project is source-available, not open source in the usual permissive sense. It can be read, evaluated, and run locally under the published license terms. Commercial productization paths require a separate commercial license.

What I Want Feedback On

The main question I care about is not "can AI audit smart contracts?"

The better question is:

How should AI-assisted security review preserve the boundary between model reasoning and evidence?

I am especially interested in feedback on:

evidence model and report shape;
SARIF export boundaries;
manual-review posture;
golden case evaluation;
smart-contract review lanes;
defensive ECC research tasks;
where the workflow should be stricter about confidence.

The project is here:

https://github.com/ECD5A/EllipticZero

I am Vladimir Stelmak, publishing the project under the GitHub handle ECD5A. The project name is EllipticZero Research Lab.

Disclosure: this article was written by Vladimir Stelmak and edited with AI assistance.