I used to think the hard part of giving an AI memory was storage.
Where do you put things?
How do you index them?
How do you find the right piece of information later?
Those are real problems, and I’ve spent plenty of time thinking about them while building AdamI.
But the further I get, the less I think storage is the interesting part.
A system can save a huge amount of information and still behave almost exactly as if it had no memory at all.
It can pull up yesterday’s conversation.
It can search a vector database.
It can summarize what happened before.
It can even say, very convincingly:
“I remember this.”
What I care about now is something else:
Did that past experience actually change what the system did next?
If it didn’t, then maybe the system stored something.
I’m not sure it really remembered it.
Saving things is only the first step
Most agent systems can already preserve information in one form or another.
Conversation history can go into a database.
Documents can be embedded.
Tool outputs can be logged.
Completed tasks can be summarized and inserted back into future context.
All of that is useful.
Without persistence, every new run starts too close to zero.
AdamI already has some of this infrastructure: persistent memory components, experience recording, task state, and a runtime designed to keep information across tasks and sessions.
But once you can preserve the past, a new problem appears almost immediately:
What is actually worth keeping?
If you save everything, memory turns into noise.
If you save too little, experience barely matters.
And even when retrieval works perfectly, the retrieved information may still have no effect on the decision being made.
At that point, you may have storage.
You may have retrieval.
But I’m not sure you have memory in the sense I’m interested in.
Retrieval is not the same as remembering
A lot of AI memory systems can be reduced to something like this:
Save information
→ retrieve relevant information
→ put it back into context
That works.
But while building AdamI, I’ve started to feel that this is closer to retrieval infrastructure than memory itself.
Imagine an agent makes the same mistake five times.
All five failures are stored perfectly.
On the sixth attempt, the system retrieves all five of them.
It reads them.
It understands them.
And then it makes exactly the same decision again.
Technically, retrieval worked.
Behaviorally, almost nothing happened.
Now imagine a different system.
It fails once.
That failure changes the confidence it assigns to a strategy.
Maybe it chooses a different tool next time.
Maybe it changes the order of operations.
Maybe it becomes more cautious under the same conditions.
Maybe it forms a simple rule:
If this happens again, try B before A.
There may actually be less stored data in the second system.
But the past has started affecting the future.
That feels much closer to memory.
Memory needs consequences
I keep coming back to one sentence:
A memory matters only when the future would be different without it.
That sounds obvious, but it changes the engineering problem quite a bit.
Instead of only asking:
How do I retrieve the right memory?
I also have to ask:
What is this memory allowed to change?
A past experience might affect:
- which action gets chosen next,
- which tool gets used,
- how much confidence the system assigns to a hypothesis,
- which model gets called,
- how risky an operation looks,
- whether human approval is required,
- which strategy should be avoided,
- or which successful pattern should be reused.
Once memory starts doing that, it is no longer just a database sitting next to the agent.
It becomes part of the decision loop.
And that is where things get much harder.
Not every experience should matter equally
One mistake I think would be easy to make is treating every stored experience as equally important.
Consider three cases.
Experience A
A routine API call works exactly as expected.
Experience B
A tool times out once because the network was unstable.
Experience C
The agent repeatedly performs an action that leads to a bad or potentially dangerous result.
If I just store all three and retrieve them by similarity, that is probably not enough.
Experience C should clearly have more influence on future behavior than Experience A.
Experience B may matter for a while, but if the problem never happens again, maybe its influence should fade.
That means a persistent agent probably needs more than retrieval.
It needs some way to evaluate experience.
Questions start showing up:
- Was this event unusual?
- Did it lead to success or failure?
- How serious were the consequences?
- Is this lesson general, or only useful in a very specific context?
- Has the information become outdated?
- Should its influence decay over time?
- If the same thing keeps happening, should the memory become stronger?
- Can newer evidence override older experience?
At this point, it stops feeling like a database problem.
It starts feeling more like:
How does a system use the fact that it has a history?
Remembering and forgetting are probably the same problem
I used to think forgetting was mostly a failure mode.
Now I’m less sure.
A persistent agent that cannot forget may eventually become harder to use.
Old assumptions stay active.
Temporary failures become permanent rules.
Outdated information keeps competing with newer information.
Contradictory experiences pile up.
The system may end up being less experienced and more contaminated by its own history.
So the real problem may not be:
How do I preserve more?
It may be:
What should continue to influence future behavior, and for how long?
I’m starting to think about memory more like a lifecycle:
Experience
→ Evaluate
→ Retain / Forget
→ Retrieve
→ Influence
→ Reinforce / Revise / Decay
The interesting part is not whether a piece of information survives all of those steps.
The interesting part is whether it continues to deserve influence.
AdamI has not solved this yet
I want to be careful here.
AdamI already has persistent memory infrastructure and mechanisms for recording experience.
Some information can survive across tasks and sessions instead of existing only inside the current prompt.
That part is real.
But I would not say AdamI already has a mature system that learns from memory.
It doesn’t.
The harder part is still unresolved:
How should past experience reliably, controllably, and measurably change future behavior?
I don’t want to call that “learning” just because the system can retrieve history.
That would be too close to a mistake I already made in the first version of AdamI: seeing a convincing output and assuming the mechanism underneath was real.
So if I eventually want to say:
AdamI learned something from this experience.
I should be able to test it.
One experiment I want to try
A simple version might look like this.
Give AdamI a task under condition X.
First:
- Record the original decision.
- Let an important experience happen.
- Store that experience.
- Run a similar task again.
- Check whether the decision changes.
Then do one more thing:
- Remove or suppress that memory, and run the task again.
That last step feels important.
If removing a supposed memory makes no difference at all, then I have to ask:
Was it ever participating in the decision in the first place?
This is basically a memory ablation test.
Instead of asking the model:
“Do you remember?”
I can ask a much more useful question:
Does the behavior change when the memory is present versus absent?
That feels like a better test.
Memory should be measurable
If I want to make this more engineering-oriented, I think memory should eventually be evaluated the same way I would evaluate any other mechanism.
Take two nearly identical agents.
Agent A has access to one important past experience.
Agent B does not.
Then give both the same new situation.
If that experience is actually functioning as memory, there should be some measurable difference.
Maybe one agent:
- avoids a repeated failure,
- chooses another tool,
- changes the execution order,
- becomes more cautious,
- finishes faster,
- estimates risk differently,
- or assigns a different confidence level.
Not every memory needs to create a dramatic change.
But over time, the effects of experience should become visible.
If an agent behaves exactly the same whether its history is present or not, then those “memories” may just be an archive.
From persistence to development
This matters to AdamI because persistence was never the final goal.
A program can run forever.
A database can keep records forever.
Neither one necessarily develops.
What I’m interested in is whether continuity can gradually turn into development.
For that to happen, yesterday has to matter to tomorrow.
The system cannot just exist for longer.
Its history needs consequences.
That may be one useful distinction between a long-running AI process and something closer to a persistent artificial entity.
I’m not talking about consciousness.
I’m not claiming biological life.
And I’m definitely not claiming AGI.
I mean something much more concrete:
A system whose future behavior becomes increasingly shaped by the consequences of its own past.
At least that is something I can try to measure.
And that makes it a much more interesting engineering problem.
The question has changed
When I started working on memory, the question in my head was:
How do I make AdamI remember things?
Now I think that question is too shallow.
The questions I care about more are:
What deserves to become memory?
What should be forgotten?
How much influence should a memory have?
When should that influence decay?
What happens when old and new experiences disagree?
And the most important one:
Can I prove that AdamI would have made a different decision without this memory?
If I can answer that, then memory starts becoming more than storage.
It starts becoming part of AdamI’s behavior.
Digital Life Log #005
Building AdamI — a Digital Life in public.
A memory matters only when the future would be different without it.