What happened
Sergei Petrukovich’s Habr article describes an assistant that runs through three messaging services. Telegram, MAX, and VK act as transport adapters feeding a shared ingress; agents, LLM routing, and memory run once on a server. The article says that the same person currently has separate user IDs across Telegram and MAX because the services do not provide a shared identifier. Linking identities is being implemented, but reconciling information already accumulated in two profiles is harder.
The first memory layer appends each answer in full to a per-user, per-agent memory.md file. New entries are compared with the ten most recent entries; near-duplicates above a 0.7 overlap threshold receive a refinement marker. When a file exceeds its cap, older entries move intact to an archive. The article reports 11,674 archived records across 134 subjects. Its design choice is to constrain reading, not writing: an item excluded from one prompt is still retained for later retrieval.
The second, primary layer stores message-and-answer rounds in PostgreSQL with embeddings and generated full-text search vectors. It contains 16,333 rounds for 657 users. A separate CPU container runs text-embeddings-inference with deepvk/USER2-small; the application itself does not load a model, and a request continues without vectors if the embedding service is unavailable. Semantic similarity is combined with lexical ranking using a formula in which lexical weight is 0.02. Snowball stemming and BM25 support word search. Each turn retrieves at most four rounds and 3,000 characters. The selected rounds enter the prompt with dates and are framed as conversation records, not instructions.
A cheaper model acts as a judge to select rounds that may be useful later, preferring to omit uncertain candidates. When personal conversations go quiet, the system creates dated summaries; the original rounds remain the source of truth, and each segment is summarized once. A separate access policy controls which agents can read other agents’ histories: sensitive agents such as medical, nutrition, and legal assistants are not sources for other agents, while each agent can read its own history.
The fifth layer contains canonical facts and skills in SQLite with FTS5. The article says canonical facts exist for only three subjects, with 1,486 records. User corrections can remove similar facts; 221 have been removed this way. Skills have a retention strength that rises with use and is designed to decay after 14 days without use, but the author says a scheduled production run could not be confirmed. A separate library’s semantic vector path is disabled in production (MEM_SEMANTIC=0); BM25 remains active there. The article also reports hash-linked history for 893 of 894 entries and SHA-256 checks for important agent files. It says Rospatent decided to grant Lisa Studio a utility model patent, application 2026120741, with priority dated 2 July 2026; the claimed formula is broader than the system currently enabled in production.
What the archive adds
New Runtime’s earlier coverage on 6 September 2026 described memory moving beyond transcript retention toward preferences, procedures, reusable skills, and agent self-improvement. This case adds implementation detail: a production system preserves full rounds, derives summaries, applies cross-agent access controls, and distinguishes enabled features from dormant library code. A related New Runtime note on the memory tax raises a useful counterpoint: dedicated memory mechanisms need to earn their complexity against simpler retrieval.
Trend signal
This case supports the idea that company memory needs write and correction loops, but only in a bounded sense: the described system retains original rounds, derives summaries, and removes facts when users correct the assistant. That is more than retrieval over a static document pile, though the article does not establish that every loop runs reliably in production. See Company memory needs write loops.
Why now
The article’s central distinction is timely for teams moving memory features from prototypes into deployed assistants: a library can contain more than the production system actually uses. Its account explicitly separates enabled retrieval paths from disabled semantic search and planned-but-unverified skill decay, making deployment status part of the design discussion rather than an afterthought.
Why it matters
For builders, this is a useful reminder that memory quality depends on the whole retrieval and governance path, not just on embeddings or a larger context window. Keeping original rounds while limiting prompt-time retrieval gives a system the option to revisit information without paying to include all of it on every turn. The reported cap of four rounds and 3,000 characters is a concrete starting point to test, not a universal optimum.
The access policy is equally operational: a memory system spanning distinct agents needs rules about which histories can cross boundaries. Framing recalled conversations as records rather than instructions is another direct defense against a system being manipulated through its own stored content. Finally, the article’s distinction between deployed behavior and library capability is a strong practice for teams: test the active path, observe its schedules, and label unverified mechanisms as such. These decisions are more reusable than adopting any single database or embedding model.
Limits and uncertainty
The figures describe one assistant, not a controlled evaluation or a representative sample of production systems. The article reports stored records and users, but does not measure recall quality, response accuracy, latency, or memory-related cost. It also says the regularity of skill decay could not be confirmed, despite reduced weights appearing in the data. Cross-messenger identity merging is still in progress. The patent decision is reported by the author; the article does not independently establish the scope or practical effect of the patent, or show that every element in its formula is deployed.
Reader takeaway
Treat memory as a set of explicit production mechanisms: preserve source interactions, decide what enters each prompt, derive summaries without replacing their source, and govern which agents can read what. Then verify which mechanisms actually run. This case is valuable less as a blueprint to copy than as a concrete example of separating retained data, retrieval, policy, and implementation status.
Open question
How does the team measure whether the judge and retrieval limits surface the right memories without raising latency or degrading answers?