Коротка пам'ять

Робочий контекст для цієї розмови на цьому кроці — повідомлення, які LLM реально бачить, утримані в межах токен-бюджету моделі. Це не те саме, що дві інші «пам'яті»:

• Коротка пам'ять (ця сторінка) — живе вікно розмови + running summary. Обмежена, на кожен крок.
• Memory — семантичний пошук по всіх минулих чатах (довготривала, pgvector).
• Тривкі факти — те, що агент сам вирішив запам'ятати (agent/memory, у стилі MEMORY).

Обмеження: ефемерний мозок

Наш мозок — це запуск api на кожен крок — stateless, скейлиться під трафік. Тому коротка пам'ять не може жити в процесі між кроками. Два наслідки:

1. Робочий контекст регідратується з Postgres на кожному кроці (з чату-першоджерела).
2. Результат компакції має бути збережений — running summary, що зберігається на чаті — щоб наступний ефемерний крок не перераховував його заново.

(У межах одного довгого кроку — наприклад, годину керуючи worker'ом — вікно росте в процесі, поки цей інстанс мозку живий; воно зберігається в кінці кроку.)

Збирання контексту (на крок)

Context engine оркестратора будує промпт наново на кожному кроці:

[ system prompt ]          ← snapshot на чаті → тримає prefix cache моделі теплим
[ running summary ]        ← rolling структурований підсумок старіших кроків, у fence "reference-only"
[ tail window ]            ← найсвіжіші повідомлення VERBATIM, у межах tail-токен-бюджету
[ retrieved long-memory ]  ← pgvector-збіги, у fence <memory-context> (вичищені з виводу)
[ new user message ]
+ tools = MCP-тулсет (brain-MCP · worker-MCP · connector-MCP) — не в історії

Пайплайн компакції

Бюджет = контекстне вікно моделі − резерв під відповідь. Коли вікно виходить за бюджет:

1. Дешевий pre-pass (без LLM): стискаємо старі tool result'и до однорядкових підсумків, дедуплікуємо однакові, відкидаємо застарілі скриншоти/зображення. Часто лише цього вже досить.
2. Захищаємо head & tail: тримаємо system prompt + перший крок і свіжий tail (за токен-бюджетом, а не за кількістю повідомлень) verbatim.
3. Memory-flush хук: перед підсумовуванням витягуємо тривкі факти в agent/memory, щоб компакція ніколи мовчки їх не втратила.
4. Підсумовуємо середину дешевою допоміжною моделлю (через system/llm) у структурований підсумок — resolved · pending · active task — і зливаємо його в попередній summary.
5. Anti-thrash: пропускаємо компакцію, якщо свіжі проходи дали мало; потім зберігаємо новий summary.

Де насправді живе зведення

Не в колонках у треда, а рядком у самому треді, виду kind = summary. Вікно ріжеться за найсвіжішим таким рядком, тому модель читає переказ і все, що після нього, а рядки до нього лишаються там, куди людина може прокрутити.

Зберігання рядком, а не полем, дає дві речі, яких колонка дати не могла:

• Межа видима. Стиснута розмова і підмінена розрізняються лінією, яку читач бачить, а «почати заново» — це та сама лінія, поставлена свідомо.
• Це ідемпотентно. Id рядка виводиться з повідомлення, за яким він іде, тому повтор — або дві вкладки разом — пишуть один рядок, а не два.

Де це живе

Аспект	Слайс
повідомлення + рядок-зведення (джерело вікна)	agent/chat
context engine + цикл кроку	agent/orchestrator
дешева допоміжна модель для підсумків	system/llm
довготривала + тривка пам'ять	agent/memory

Коротка пам'ять — це не нове сховище, а похідне збирання поверх agent/chat плюс маленьке поле summary. Саме це й робить її придатною для ефемерного мозку: кожен крок api регідратує вікно з Postgres, компактить за потреби, зберігає summary і знову стає stateless.

Дивіться також

• Storage — чат-першоджерело, з якого будується вікно.
• Memory — довготривалий пошук (коротка пам'ять ≠ довга пам'ять).
• Runtime model — де сидить цикл кроку.
• Implementation — побудова context engine.