AedelgardKeep the decision and its source.
Ask the agent to record the choice and why it applies. Conversation records and saved memory are different: not every statement becomes a curated fact. Inspect what was actually stored.
How it works
Saved history.
Useful context.
Your next task.
Aedelgard combines a coding agent with persistent records on your machine. The model does the reasoning; the memory supplies context it can use across sessions.
Follow one project decision.
Suppose you choose SQLite for a prototype because it must run without a database service. You want the next session to retain the reason—not just the code.
This is a synthetic workflow illustration, not a recorded performance demonstration.
Change facts without hiding history.
If requirements change, mark the old choice as superseded and record the new one. Temporal facts carry validity windows. Review the target and the replacement; a model can misunderstand either.
Bring the reason to the next task.
When you return, semantic search can retrieve related records. Project headings guide scoped recall. Retrieval can miss context or find the wrong record: request sources before relying on an important answer.
The mechanisms
Records are not
the same as recall.
The open engine uses a local semantic store and a temporal fact graph. These make history searchable and inspectable; they do not guarantee that the model uses it correctly.
Read the open memory engine →- Semantic memory · ChromaDB
Search saved text by meaning. Retrieval depends on query, filters, embeddings and ranking. Changing the embedding model can require rebuilding the index; changing the reasoning model is a separate operation.
- Temporal facts · SQLite
Structured facts record subjects, relationships and validity windows. Previous states remain inspectable when facts are invalidated rather than deleted. A validity interval alone is not a claim of full bitemporal history.
- Working procedures · skills
Versioned playbooks can retain steps, checks and outcomes. The agent must follow and maintain them. Written instructions are not deterministic execution guards.
- Scheduled reflection
A running body can revisit stored context and propose connections. Reflection uses your chosen model and can incur provider charges. Review its conclusions and the permissions of any enabled autonomous routines.
Change models.
Keep the records.
Supported provider adapters let different models use the stored history. The records remain; reasoning, retrieval choices and tool reliability can change. This is portability, not identical judgement.
Project headings help organize attention. They are not separate encrypted vaults or client security boundaries. Use separate installations and access controls when confidential work must remain isolated.
Moving to another machine
Use the built-in ZIP export to carry portable memory, including the knowledge graph. Provider credentials are excluded. The archive is unencrypted: protect it and verify restoration on a compatible installation before discarding the original.
Optional cloud backup carries encrypted snapshots. It does not make simultaneous edits safe to merge. Keep a separate verified backup of important work.
Review privacy and data handling →Persistent memory in practice
Try it on real work.
See what carries forward.
Save decisions, correct outdated assumptions, and experience how persistent context changes your development loop over time.