Cogitor

Persistent cognitive runtime for AI agents — слой памяти, поддерживающий непрерывность знаний, состояния, решений и контекста агента между независимыми сессиями. Не «чат с памятью» и не RAG по истории разговоров.

Статус: реализация, Фаза 2 из 8. Схема данных и миграции готовы; система уже дог-фудится на собственной разработке (ingestion + минимальный MCP). README описывает, что строится и почему; ход работы — в плане реализации (см. ниже).

Проблема

Агент может быть очень умным внутри одной сессии, но при следующем запуске просыпается с частичной амнезией. Типовая «память агента» — embeddings + similarity search — это поиск по прошлому, а не память. На вопрос:

Почему мы отказались от RabbitMQ в проекте X?

такая система вытащит пять разговоров со словом RabbitMQ. Cogitor должен ответить:

14 июля RabbitMQ рассматривался для фоновых задач. 16 июля выбрали Redis + Celery ради простоты MVP — зафиксировано в DECISION-007. 2 августа вопрос поднимался снова из-за требований к durability; решение не изменено.

Для этого нужна история состояния и решений, а не похожий текст.

Ключевые идеи

• Event sourcing. Эпизодическая память (append-only лог всего, что происходило) — единственный первичный слой. Факты, решения, сущности, связи и состояние проекта — производные проекции, которые строит батчевый Consolidator и которые можно перестроить заново, более умной моделью, хоть через год.
• Темпоральность. Каждый факт и каждая связь несут valid_from / valid_to, recorded_at и цепочки supersede. «Broker = Redis» → «Broker = RabbitMQ» — это не два конкурирующих эмбеддинга, а история с одной активной версией.
• Решения — first-class объекты. ADR-подобные записи (вопрос, решение, обоснование, отклонённые альтернативы, статус) — отдельная сущность памяти, а не абзац в тексте.
• Provenance обязателен. Каждая проекция ссылается на исходные эпизоды. Агент цитирует, а не реконструирует.
• Context Assembler. При старте новой сессии агент не перечитывает историю — он получает собранный под токен-бюджет бандл: состояние проекта, активные решения, дайджест последних событий, релевантные факты.
• LLM не владеет памятью. Источник истины — реляционный SQL-стор; vector-слой — только retrieval-индекс; LLM — только интерпретация.
• Local-first. SQLite одним файлом (WAL, sqlite-vec, FTS5), без демонов и облака. PostgreSQL — целевой бэкенд серверного варианта, схема диалектно-нейтральна.
• MCP-first. Интерфейс — MCP-сервер поверх Python SDK: Cogitor подключается к Claude Code и любому MCP-хосту и дог-фудится на собственной разработке.

Чем Cogitor отличается

Zep/Graphiti, Mem0, Letta, LangMem закрывают части задачи (темпоральные графы, факт-экстракция, memory API). Ниша Cogitor — decision-centric и project-state-centric память, родная для процесса разработки: ADR как объект памяти, восстановление контекста проекта при холодном старте, local-first, MCP-first.

Главный критерий готовности v0.1 — cold-start eval: свежая сессия без истории отвечает на ≥15 из 20 золотых вопросов вида «почему мы отказались от X» — верно и с цитированием provenance (даты, номера решений), а не правдоподобной реконструкцией.

Планируемый стек

Python 3.12+ · SQLite (WAL, sqlite-vec, FTS5) · SQLAlchemy Core + Alembic · MCP SDK · PostgreSQL (CI-гейт портируемости и будущий серверный режим).

Дорожная карта v0.1

• Фаза 0 — prior art и закрытие открытых вопросов (эмбеддинги, модель консолидации, захват эпизодов) — обзор
• Фаза 1 — scaffold, схема данных, миграции, CI
• Фаза 2 — ingestion + минимальный MCP (старт дог-фудинга)
• Фаза 3 — Consolidator: извлечение проекций
• Фаза 4 — canonicalize: dedup / supersede / conflict
• Фаза 5 — retrieval + Context Assembler
• Фаза 6 — полный MCP-сервер
• Фаза 7 — cold-start eval и доводка

Дальше (вне v0.1): procedural memory, memory decay, graph engine, многопользовательский режим, Cogitor Assistant — JARVIS-подобный ассистент поверх Core.

Документация

• Техническая спецификация v0.1 — архитектура, модель данных, ADR-решения, риски
• План реализации — фазы, оценки, контрольные точки