Обзор

«Хранить чаты» — это на самом деле три разные задачи по работе с данными с разными паттернами доступа, объёмом и сроком хранения. Слить их в одну таблицу — ошибка: телеметрия раздула бы транзакционное хранилище, а поиск конкурировал бы с записями. Держи их раздельно, каждую за своим slice'ом, чтобы физический бэкенд оставался заменяемым.

Задача	Что это	Где	Slice
Хранилище	чат как источник записи (то, что показывает UI)	Postgres (общий → выделенный инстанс на масштабе)	agent/chat
Короткая память	рабочее окно контекста на этот ход (окно + running summary)	производное от Postgres; сводка персистится на чате	agent/chat + agent/orchestrator
Debug и трейсинг	промпты · вызовы тулов · токены · полный трейс	Langfuse (отдельно; на базе ClickHouse)	инструментировано из api
Память	заметки, которые агент держит между разговорами, плюс поиск по разговору	заметки в Postgres; векторы в infra/vector	agent/memory

Принцип

• Один источник правды (Хранилище) — надёжное, реляционное, с пагинацией для UI.
• Телеметрия — не правда (Debug) — append-only, высокий объём, короткое хранение, своя система.
• Память — производное (Память) — асинхронный индекс, построенный из чатов, а не сами чаты.

«Не в api» — если точнее: доменная логика чата остаётся в slice'е agent/chat (это просто gateway); данные могут жить в отдельной базе. Gateway превращает «сейчас в api, отдельно потом» в изменение конфига, а не в переписывание.

→ Дальше: Хранилище · Короткая память · Debug и трейсинг · Память · Реализация.