---
id: "lib-2026-11-08-five-memory-layers-of-an-ai-assistant-what"
type: "library"
title: "Five memory layers of an AI assistant: what actually runs in production and what stayed in the library (Пять слоёв памяти ИИ-ассистента: что реально работает в проде, а что осталось в библиотеке)"
lang: "RU"
org: "Habr-Author"
source_type: "Practitioner post"
date: "2026-11-08"
week: "2026-W45"
url: "https://nosov.ai/library/lib-2026-11-08-five-memory-layers-of-an-ai-assistant-what/"
original_url: "https://habr.com/ru/articles/1105098/"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "A developer at the small studio behind a multi-messenger assistant documents its production memory design with real store sizes and parameters, and separates what runs from what stayed in the library, but reports no measure of recall quality."
summary_basis: "full-text"
original_minutes: "4"
tags: ["ai technology", "agent memory", "rag", "privacy between agents", "production vs design gap"]
---

# Five memory layers of an AI assistant: what actually runs in production and what stayed in the library (Пять слоёв памяти ИИ-ассистента: что реально работает в проде, а что осталось в библиотеке)

Tier B (Useful, limited): A developer at the small studio behind a multi-messenger assistant documents its production memory design with real store sizes and parameters, and separates what runs from what stayed in the library, but reports no measure of recall quality.

Summary based on the full text.

## In short

A 8 November 2026 Habr post (author mrPetrukovich) on the memory system of an AI assistant with about 1,200 people using it through Telegram, MAX and VK. Memory is five layers: a per-agent file, stored message-reply rounds with hybrid search, a cheap judge model that selects what to keep, dated summaries of quiet conversations, and canonical facts and skills. The author is candid that part of the original memory library, including the vector path, is switched off in production.

## Key numbers

- about 1,200: people using the assistant across Telegram, MAX and VK
- 16,333 for 657: message-reply rounds stored in PostgreSQL with pgvector, and the people they belong to
- 11,674: archived memory.md entries across 134 subjects
- 4 rounds, 3,000 characters: cap on recalled memory per turn
- 187 of 362: agent skills whose retention weight has already decayed

## What it reports

- Messengers are thin adapters into one core; the same person on Telegram and MAX is still two user IDs.
- Layer 1: every reply is appended in full to the agent's memory.md; near-duplicates (overlap 0.7 against the last ten) are marked as refinements; old entries move to an archive (11,674 entries, 134 subjects). Truncation happens on read, never on write.
- Layer 2: 16,333 rounds for 657 people, embedded on CPU with deepvk/USER2-small; if the embedding server is down the turn proceeds without vectors. Score = similarity + 0.02 x normalised lexical (BM25, Snowball stems); RRF was dropped.
- Recall is capped at 4 rounds and 3,000 characters, placed at the end of the prompt as a dated conversation record, not as instructions, to limit injection through memory.
- Layer 3: a cheap model marks rounds worth remembering and keeps doubtful ones. Layer 4: 899 dated summaries, each segment summarised once; rounds remain the source of truth.
- Read policy: sensitive agents (doctor, dietitian, lawyer, tarot reader) and user-created agents never serve as memory sources for other agents.
- Layer 5: canonical facts exist for only 3 subjects (1,486 records); corrections soft-delete facts above cosine 0.60 (221 so far). Skills decay by 0.85 after 14 idle days, floor 0.05. A hash chain covers 893 of 894 history rows.
- In production the library's vector path is off (MEM_SEMANTIC=0); the author could not find a scheduled decay job. A utility-model patent was granted to the studio with claims broader than what runs.

## How they got it

First-hand description by the builder, with counts read from production stores and parameter values from the code.

## Limits

- No evaluation of whether recall improves answers or user satisfaction.
- Single small product; scale is modest.
- The author's studio holds a patent on the design, which is a commercial interest.

## Why it matters for companies

The post is a sober checklist for assistant memory: keep raw history and treat summaries as derived, cut on read rather than write, feed memory into prompts as data, and decide early which agents may read which conversations, before a leak forces it. Its last lesson applies widely: check what is actually switched on in production, not what the design document or library promises.

## Key passages in translation

> Обрезать при записи значит потерять навсегда, тогда как обрезать при чтении значит всего лишь не показать сейчас.

Truncating on write means losing it for ever; truncating on read only means not showing it right now.

> обмануть систему можно и её же воспоминаниями.

You can also deceive the system with its own memories.

> Проверять, что реально включено в проде, а не что лежит в библиотеке.

Check what is really switched on in production, not what sits in the library.

Original: https://habr.com/ru/articles/1105098/