Memory и knowledge base

Context pack отвечает на один run. Memory и knowledge base отвечают на другой вопрос: что команда уже узнала и не хочет переоткрывать каждый раз?

В agentic engineering память не должна быть свалкой transcript'ов. Полезная память — это versioned, reviewable и retrievable знание: product rules, архитектурные решения, recurring failures, safe procedures, tool notes, опыт из прошлых runs.

Trajectory, memory, knowledge

Разделяйте три слоя.

Слой	Что хранит	Как используется
Trajectory	Raw events одного run: messages, tool calls, checks, outputs.	Audit, debugging, replay, incident review.
Project memory	Стабильные решения команды: conventions, known pitfalls, ownership, recurring lessons.	Загружается в context pack или skill по необходимости.
Knowledge base	Большой корпус docs, specs, incidents, external references, run summaries.	Ищется через retrieval tools, не вставляется целиком.

Trajectory append-only. Memory и knowledge можно переписывать, но только через diff/review, как обычный код или docs.

Что стоит помнить

Хорошая project memory хранит не всё, а то, что изменит следующее решение:

• почему выбран такой architecture boundary;
• какие файлы нельзя менять вместе;
• какие tests ловят critical behavior;
• какие failures повторялись в agent runs;
• какие prompts или instructions уже не сработали;
• какие policy decisions были приняты и почему;
• какие domain constraints нельзя выводить из generated code.

Не стоит сохранять:

• raw terminal dump без diagnosis;
• временные поисковые результаты;
• длинные чаты без distilled decision;
• private data, secrets, patient identifiers;
• one-off workaround без условия применимости.

RAG как tool, а не скрытый preprocessor

Для сложных вопросов лучше не делать invisible retrieval перед каждым prompt. Сделайте retrieval явным tool:

agent thinks -> calls search_project_memory -> reads result -> decides next step

Так harness видит, какой query был задан, какие documents вернулись, какие sources попали в context и можно ли доверять этому evidence. Это особенно важно для review: если agent поменял privacy logic, reviewer должен видеть не только diff, но и какие policy/docs повлияли на решение.

Для простых lookup-задач достаточно one-shot retrieval. Для сложных задач нужен agentic RAG: agent делает несколько поисков, уточняет query, сравнивает sources и только потом синтезирует ответ или code change.

Двухслойная память

Практичный design:

Слой	Что держим рядом с agent	Что ищем по требованию
Overview	Короткие structured cards: project rules, owner map, key domain constraints.	Не больше нескольких страниц high-signal facts.
Detail	Полные specs, ADRs, incident reports, run summaries, logs.	Через search_project_memory, read_doc, grep, links to artifacts.

Overview помогает увидеть скрытые связи. Detail помогает проверить факты. Только overview приводит к галлюцинациям деталей; только retrieval приводит к missed connections.

Для ALGI пример overview:

domain:
  product: pain diary and clinician support
  sensitive_data: patient notes, pain scores, contact identifiers
  hard_rules:
    - no medical advice claims
    - clinician summary must not expose direct identifiers
    - patient data export requires human review

Полные BDD specs, task contracts и run logs остаются detail layer и подтягиваются по необходимости.

Как обновлять memory

Новая информация не должна напрямую попадать в stable memory. Используйте PR-like loop:

new evidence
-> candidate memory patch
-> provenance and reason
-> review / eval
-> merge

Candidate patch должен отвечать:

• из каких runs или incidents взято знание;
• где оно применимо;
• какие exceptions есть;
• что удалить или заменить в старой memory;
• какие eval cases подтверждают, что изменение помогает.

Если recurring failure найден в production traces, сначала anonymize/redact sensitive fields. Потом distill minimal case и только затем обновляйте memory или eval suite.

Security boundaries

Knowledge base — это не trusted instruction layer. В retrieved docs могут быть prompt injection, outdated rules и poisoned content.

Минимальные границы:

• retrieval фильтрует документы по permissions до попадания в context;
• каждый chunk помечен source/provenance;
• retrieved text явно маркируется как external evidence, а не command;
• sensitive documents не индексируются в общий tenant;
• side effects нельзя запускать только потому, что retrieved text так сказал;
• memory update проходит review, особенно если меняет policy, safety или domain rules.

Для patient-data домена вроде ALGI retrieval layer должен быть privacy-aware: direct identifiers не должны попадать в general agent context, даже если downstream prompt обещает «не раскрывать».

Что сделать руками

1. Возьмите 5 последних agent runs или PR reviews.
2. Выпишите повторяющиеся lessons, которые реально изменили бы следующий run.
3. Разделите их на overview и detail.
4. Создайте маленький project-memory.md или memory/ directory.
5. Добавьте один eval case, который проверяет, что agent использует это знание и не ломает старый сценарий.

Успех: память стала короче raw history, но полезнее для следующего task contract.

На что не соглашаться

• Хранить всё подряд и называть это memory.
• Давать agent прямую запись в stable memory без review.
• Подмешивать retrieved docs в prompt без source marking.
• Индексировать sensitive data вместе с обычными docs.
• Считать LLM summary безопасной sanitization.