Giving every object a memory of its own

The direction I want to explore for Potbot and Syn is to give every Syn object a separate memory graph in Potbot. A type, a configured tool, an event and a result would each have a memory of their own.

This is a design proposal from a research review. The separate memory graphs haven’t been implemented or benchmarked.

Remembering what belongs to what

Consider a parser. Its type can describe the contract it should meet. A configured parser can have its own implementation and settings. One attempt to run it is an event, and the result of that attempt is another record.

Keeping those identities separate makes a practical difference. A failed attempt belongs to that attempt’s history. It can teach us something about the configured parser without becoming an inherited fact about every parser of that type.

The graphs could still refer to one another. A question about a tool’s failure could follow a permitted reference to the exact attempt and its result. That reference would need its own access check. Knowing an object exists shouldn’t give an agent access to everything remembered about it.

What the research adds

MAGMA separates several kinds of relationship, including time, entities and inferred causes. Zep’s temporal graph research distinguishes when a fact applied from when the system learnt it. Both ideas would help an object’s memory preserve context as it changes.

MemForest studies how to update hierarchical memory efficiently. Databricks’ MemCurrent research offers another useful comparison: keep the original experience alongside the lessons derived from it.

These approaches address different problems. A summary helps an agent find its way around a long history. A source record lets it check what actually happened. A model’s explanation remains an interpretation, even when it sounds convincing.

A small test before a bigger system

I’d start with a few synthetic objects and give each an empty, separately addressable graph. Then I’d add events, source-linked claims and corrections. One test would use the same object reference in two different source namespaces, to check that their memories stayed separate.

Another would introduce a late correction. The system would need to preserve both what applied at the time and what it knew before the correction arrived. A private result linked from a public object would test whether the boundary held.

Only then would it be useful to compare ordinary search with graph traversal and summaries. The measures would include finding the right evidence, recognising missing information, keeping facts current and the cost of maintaining the memory.

A separate graph for every object needn’t mean a separate database for every object. The storage can be shared while the identities, histories and permissions remain explicit. That is the architecture to test next.

Research checked on 23 October 2026. The linked papers and first-party research reports describe their authors’ methods and results; none establishes that this proposed combination will work well in Potbot. The featured artwork is an original generated concept illustration.