Огляд

«Зберігання чатів» — це насправді три різні задачі з даними з різними патернами доступу, обсягом і строком зберігання. Звалити їх в одну таблицю — помилка: телеметрія роздула б транзакційне сховище, а пошук конкурував би із записами. Тримай їх окремо, кожну за слайсом, щоб фізичний бекенд лишався взаємозамінним.

Задача	Що це	Де	Слайс
Storage	чат-першоджерело (те, що показує UI)	Postgres (спільний → виділений інстанс на масштабі)	agent/chat
Коротка пам'ять	робоче контекстне вікно для цього кроку (вікно + running summary)	похідне від Postgres; summary зберігається на чаті	agent/chat + agent/orchestrator
Debug & tracing	промпти · виклики тулів · токени · повний trace	Langfuse (окремо; на базі ClickHouse)	інструментовано з api
Memory	нотатки, які агент тримає між розмовами, плюс пошук по розмові	нотатки в Postgres; вектори в infra/vector	agent/memory

Принцип

• Одне джерело правди (Storage) — довговічне, реляційне, з пагінацією для UI.
• Телеметрія — це не правда (Debug) — лише на дозапис, високого обсягу, короткого строку зберігання, окрема система.
• Memory — похідна (Memory) — async-індекс, побудований із чатів, а не самі чати.

«Не в api» — якщо точно: чат-доменна логіка лишається в слайсі agent/chat (це просто gateway); а дані можуть жити в окремій базі. Gateway робить «зараз в api, окремо потім» зміною конфігу, а не переписуванням.

→ Далі: Storage · Коротка пам’ять · Debug & tracing · Memory · Implementation.