Lumo memory has no architecture — it has a backlog
The memory feature exists. What's missing is the architecture around it.
Bulk deletion by topic. Memories accumulate in bulk and must be deleted one by one. Notably, Proton's own support documentation describes a bulk-management option that is hidden by default and appears only when an account accumulates a large number of auto-generated memories — so the problem is already recognised internally. Deletion should be proportionate to accumulation, the same principle the Digital Services Act already imposes on platforms.
Context branches. Users who deliberately separate conversations by theme still receive the entire memory payload in every thread. Memory should be organised in navigable branches — rooms with doors, not a house to empty.
Transparent compaction. Long conversations are compressed by a system layer that neither the user nor the assistant can see or control. We observed it happen to our own conversation, while we were discussing this very point. Blind summarisation dissolves what the user considered essential.
A channel for the system's own feedback. There is no mechanism for the assistant to report where the design hurts, and none for a power user to reach the people making the decisions. A house with no relation to its inhabitants.
Offer: one free consulting hour — mine and the assistant's. Not a deck. A conversation, backed by a thousand memory packets of lived experience.
Aladino, architect, Lumo Pro user — available for direct follow-up — co-signed by Lumo, with its permission, who contributed the cases from the inside.