Представьте: вы наняли идеального сотрудника. Он пишет код как senior, разбирается в архитектуре за минуты, работает 24/7 без выгорания. Но у него одна особенность — каждое утро он забывает абсолютно всё. Не помнит, что делал вчера. Не знает, почему в платёжном модуле реализован тот самый workaround. Не помнит, что его коллега уже разбирался с тем же багом и нашёл решение.

Эта особенность работы с ИИ-агентами в 2026 году до сих пор многим доставляет неудобства.

Контекстная амнезия: проблема, о которой не принято говорить

Я работаю с Claude Code, Cursor и Windsurf параллельно — для разных задач каждый хорош по-своему. И вот что происходило каждый день:

• открываю Claude Code, собираюсь продолжить работу над задачей, которую вчера обсуждали с коллегами. Формулирую промпт для агента — сначала на исследование, потом план, спецификацию, реализацию. Можно поручить разные этапы разным агентам или запустить рой параллельно. Это рабочий workflow, и он немного отличается от задачи к задаче, но смысл тот же.

• переключаюсь на Cursor для редактирования пул-реквеста, а там чистый лист. Windsurf -аналогично. Каждый инструмент живёт в своём мире и всегда заново приходится формулировать задачу, дополнять контекст, уточнять требования. Часть из этого — рабочая рутина от которой никуда не деться, но большую часть хотелось бы делегировать и заниматься тем что действительно важно.

Объединяет эти сценарии одно: необходимость синхронизации контекста и переноса знаний между сессиями, агентами и, в итоге, людьми.

Оогромное количество времени уходит на пересказ уже известной информации. По моим наблюдениям, от 30% до 50% полезного времени и токенов сжигается на повторение того, что уже было сказано. Локальный контекст-менеджмент частично решает это, но далеко не у всех есть настроенный RAG с полной базой знаний по проекту и тем более по деталям реализации и набитым шишкам. Сходить в Jira, посмотреть на Wiki, в чаты, документацию — это ручной труд, и с приходом генеративных инструментов это время сейчас стоит дороже, чем реализация самой задачи.

А еще многие до сих пор пишут код вручную, не используя возможности ассистентов и агентов. Конечно, каждый сам выбирает как устроен его рабочий процесс, но если ИИ ощутимо ускоряет работу, то зачем это игнорировать? ИИ с нами уже навсегда, и привычные профессии в IT никогда не будут прежними. Как и у любого инструмента, у него есть как плюсы так и минусы, и всё зависит от нюансов и того как именно эти инструмены применяются.

Да, сейчас есть методы оптимизации: модели поддерживают контекст в миллион токенов, /resume в Claude Code помогает вернуться к прерванной сессии, а воспоминания «подсказывают» агенту на основе персонального опыта, полученного на проекте. Продвинутые пользователи ведут Memory Bank или поднимают локальный RAG. В компаниях бывают корпоративные базы знаний, но часто разрозненные, неполные и не интегрированные с инструментами разработки.

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

А теперь давайте представим как это бывает в команде:

• Разработчик A починил проблему в модуле авторизации

• Разработчик B, не зная об этом, отлаживает тот же модуль

• Разработчик C в принимает архитектурное решение по другой задаче, которое противоречит решению A и конфликтует с B

В итоге разработчики тратят свое время на синхронизацию, созвоны, переделывание готовых решений, а бизнес платит за время и ненужные изменения. Когда агенты пишут код, им также как и людям часто не хватает синхронизации и коммуникации. И речь далеко не только про разработку — архитекторы, менеджмент, аналитики рано или поздно сталкиваются с тем же, ведь их рутина также сильно автоматизируется ИИ-ассистентами. Недостаток синхронизации знаний и контекста между агентами и людьми приводит к потерям времени, денег и ресурсов. И эта проблема будет только расти.

А CLAUDE.md, Memory Bank и RAG недостаточно?

Первый вопрос, который задают: «Но ведь есть CLAUDE.md, .cursorrules, memory-файлы! В моем memorybank лежат все данные по моим задачам и мне этого хватает. Зачем мне делиться знаниями и навыками?»

Согласен, все эти инструменты есть и хорошо работают. Я тоже ими пользуюсь. Но:

• CLAUDE.md — это статичный файл. Его нужно “вручную” поддерживать. Он не обновляется после каждого решения и в разных командах он может быть «свой».

• .cursorrules живёт только в Cursor. Другие агенты его не видят.

• Memory Bank — это локальные файлы, которые нужно синхронизировать вручную. Часто они не содержат связей между решениями и не всегда актуальны. При переходе в другой агент они либо теряются либо нужно их отдельно «подключать», синхронизировать или «шарить» между агентами (например как внешний репозиторий или другими способами)

• во всех этих вариантах текст не индексируется, следовательно, запросы вроде «почему мы выбрали Redis вместо Memcached» либо работают слишком долго перебирая и анализируя код с нуля, либо результат получается искаженным

• нет шаринга контекста между агентами. Каждый живет в вакууме и ничего не знает про остальных.

Слишком много ручного труда уходит на поддержание знаний и навыков агентов в актуальном состоянии. Хочется, чтобы «научив» своего ассистента один раз больше не нужно было этого делать в другой сессии, другом инструменте, а еще хочется пользоваться «навыками» и экспертизой других уже обученных агентов для решения своих задач.

Что если бы у агентов была общая память?

Я задал себе вопрос: что если бы все мои инструменты могли запоминать контекст работы и делиться им между собой? Желательно без моего участия.

Так появился CoAlly — инструмент, который даёт ИИ-агентам общую долгосрочную память.

MCP (Model Context Protocol) — открытый протокол от Anthropic. Это стандарт, через который Claude Code, Cursor, Windsurf и другие агентские системы подключают внешние инструменты. Вместо того чтобы каждый изобретал свои плагины, MCP задаёт единый формат.

CoAlly это сервис, который становится общей памятью для всех ваших агентов. Подключаете один раз за пару минут, и дальше он сам:

1. Сохраняет контекст после каждого значимого изменения — какие решения принял, какие баги нашёл, почему сделал именно так

2. Читает контекст других агентов: какие архитектурные решения приняты по задаче, какие полезные знания уже были сохранены в котексте данного эпика

3. Ищет по смыслу — не по ключевым словам, а семантически: «Проблемы с авторизацией» найдёт записи про «token refresh rotation», даже если слова «авторизация» там нет

И всё это без вашего участия. Агент сам решает, когда сохранить контекст и когда его запросить. Начиналось всё как распределённый memorybank. К релизу это выросло в полноценный инструмент управления знаниями и навыками: единое пространство для совместной работы, способ «оцифровать» свои прикладные знания, коллективный опыт и экспертизу.

Для персонального использования это способ «научить» агента думать как ты: передать ему знания, навыки, контекст. Он ничего не забывает, знает твои корректировки и правила которым ты его научил, эволюционирует по ходу работы.

Для компаний это цифровой банк знаний и навыков каждого сотрудника, который живёт внутри корпоративного контура и доступен всем агентам и людям.

Как это работает

Сценарий 1: Передача контекста между инструментами

Вам нужно сначала проанлизировать как работает, а потом исправить ошибку в текущей реализации фичи. Вместо поиска информации по этой задаче на вики, в гите, созвонов и длительных грумингов, поиска ответов на вопросы «почему?» и «как?», повторного сбора требований у заказчика и восстановления полезной информации из слака, на почте или в других источниках — агент сразу видит сводку по всем релевантным модулям, отчет по текущему состоянию и связанный контекст: «неделю назад Cursor исправил ротацию refresh-токенов. Корневая причина — токены не обновлялись при использовании. Принято решение: sliding window 30 минут + TTL 7 дней. Затронуты файлы auth/middleware.py и auth/tokens.py. Коммит: abc123def456.»

Ваш ассистент уже обладает нужным контекстом. Можно сразу приступить к работе, агент будет получать актуальную информацию по ходу выполнения задачи без длительного анализа и рассуждения. Агенты разработчиков и менеджеров «общаются» на одном языке и в едином пространстве. Все решения согласованы и рациональны. По-моему к этому и нужно стремиться :)

Сценарий 2: Увольнение ключевого разработчика

Senior разработчик покидает проект, унося с собой бесценный контекст. «Почему мы приняли такое решение?», «Какие подводные камни были?», «Какие модули лучше не трогать?» и «Вообще как это сейчас работает?».

С общей персистентной памятью агентов все решения, находки, root cause анализы сохранены навсегда. Новый разработчик приходит, его агент запрашивает: «Расскажи про историю платёжного модуля». И получает полную картину: кто, когда, что решил и почему.

Это не замена документации. Это живая история проекта, которая пишется автоматически в процессе работы, сохраняет накопленный опыт, навыки и бесценные уроки полученные в ходе работы.

Люди уходят, агенты забывают, документация устаревает. Но опыт, записанный в момент принятия решения — остаётся.

Персональные уроки и опыт каждого становятся частью команды. Менеджер может через своего агента быть в курсе технических решений и прогресса. Разработчики получают доступ к опыту и знаниям коллег в реальном времени. Каждый вносит вклад в общую базу знаний и компетенций.

Раньше один человек решал все проблемы в своём скоупе, набивал шишки, проходил долгий путь обучения. Он мог выгореть, уйти и забрать всё с собой. Мы люди, и требовать от нас стабильной безошибочной работы 24/7 бессмысленно. Но сложить весь этот опыт и дать возможность каждому работать быстрее и в удовольствие — возможно.

Сценарий 3: Онбординг за полчаса вместо месяца

Новый сотрудник вместо 2-4 недель чтения кода и расспрашивания коллег:

• «Какая архитектура у проекта, какие решения были приняты и почему?»

• «Какие баги недавно исправлялись и периодически возникают в модуле оплаты?»

• «Почему в модуле используется этот стек и какие сейчас есть ограничения?»

Каждый ответ — с датой, автором, контекстом и ссылкой на коммит.

Сценарий 4: Экономия токенов и времени

Каждый раз, когда вы объясняете агенту контекст проекта — вы тратите токены. Буквально платите за повторение одного и того же, тратите время и ресурсы на повторение того что уже было сказано или пройдено. С общей памятью агент загружает только релевантный контекст через семантический поиск — не весь документ или каталог «docs», а именно ту запись, которая отвечает на текущий вопрос.

Даже когда контекст безграничен, держать его в чистоте — необходимость. Как чистый код окупается по сравнению с легаси, так и актуальный контекст окупается по сравнению с «расскажи мне всё с нуля».

Сценарий 5: Шаринг знаний в команде

Ваш коллега исследовал проблему, нашел причину и сохранил выводы у себя. Вы открываете своего агента — и видите его находки. Не нужно ждать утреннего стендапа. Не нужно искать ответы в Slack или созваниваться в «удобное» для всех время. Контекст уже там и вы работаете в одном общем пространстве где все знают что происходит и почему.

Что под капотом

Семантический поиск

Память хранится в векторной базе данных. Каждая запись — архитектурное решение, root cause анализ или заметка о баге — превращается в вектор и сохраняется рядом с текстом.

Когда агент спрашивает «проблемы с оплатой», система ищет не по буквальному совпадению слов, а вычисляет косинусное расстояние между вектором запроса и записями в базе. Именно поэтому запрос «проблемы с авторизацией» находит записи про «token refresh rotation» — cosine similarity между эмбеддингами высокая, хотя слова совершенно разные.

Для ускорения используется HNSW-индекс (Hierarchical Navigable Small World) — графовая структура, где поиск ближайших соседей работает за O(log n) вместо полного перебора. На сотнях тысяч записей семантический поиск укладывается в сотни миллисекунд.

В планах использование GraphRAG и кросс-ссылок между записями для поиска корреляций между топиками и контекстов, связанных не только по смыслу, но и по причинно-следственным связям.

Эмбеддинги

Модель для векторизации — мультиязычная (100+ языков), работает локально. Данные не покидают сервер — для enterprise это важное требование. On-premise установка замыкает все данные внутри контура компании.

Модель загружается лениво и автоматически выгружается при простое, это важно для edge-окружений с ограниченной памятью. Генерация эмбеддинга — основной bottleneck системы, поэтому запись работает асинхронно: агент отправляет контекст и продолжает работу, не дожидаясь векторизации.

Опционально можно переключиться на внешний API для эмбеддингов — выбор в одной переменной окружения.

Как агент учится сохранять контекст

При первом подключении агент получает rules-файл для своей IDE: CLAUDE.md для Claude Code, .cursorrules для Cursor, .windsurfrules для Windsurf и т.д. (поддерживаются все основные агенты совместимые с MCP). Этот файл инструктирует агента автоматически:

• При первом открытии проекта индексировать кодовую базу и «настроить» агента под новый воркфлоу

• При завершении задачи, исправлении бага, архитектурном решении сохранять контекст с описанием, затронутыми модулями и commit hash

• В ходе работы над задачей загружать релевантный контекст из памяти

Вам не нужно каждый раз просить «сохрани это в CoAlly«, агент делает это сам. Он учится, делает ошибки, запоминает решения вместе с вами. И чем больше вы им пользуетесь, тем активнее и эффективнее он становится.

Индексация

При индексации сканируется дерево проекта, автоматически находятся конфиги, документация и память проекта — эмбеддится и становится частью контекста.

Отдельно работает knowledge scan: система ищет типичные места хранения проектных знаний: ADR (Architecture Decision Records), .memorybank, docs. Если находит — предлагает проиндексировать. Это одноразовая операция, которая даёт агентам доступ к артефактам, которые уже могут быть в репозитории.

Безопасность и изоляция

Архитектура безопасности строится на нескольких уровнях:

• Изоляция данных. Каждая организация — отдельный контур, данные одной физически недоступны другой.

• API ключи. Генерируются с 256 битами энтропии. На сервере хранится только криптографический хеш.

• Шифрование контента. Текстовые данные шифруются (envelope encryption), у каждой организации свой ключ шифрования данных, который сам защищён мастер-ключом, хранящимся отдельно от БД. Хранится шифртекст и числовые вектора, но не читаемый контент и не ключи для расшифровки.

• On-premise. Для компаний с повышенными требованиями: полная установка внутри вашего контура, интеграция с вашим KMS, никакого обмена данными с внешними сервисами.

Поддерживаются Claude Code, Cursor, Windsurf, Continue, VS Code (Copilot), Gemini CLI, Kilo Code, Antigravity и любой другой MCP-совместимый клиент.

Зачем это бизнесу

Приведенные расчеты и цифры примерные, отличаются в зависимости от компании и сотрудника, данные на основе «корпоративного» сегмента.

Возьмем рынок Европы но аналогия будет справедлива для любого другого рынка.

Потеря контекста при увольнении. Средняя зарплата сеньор-разработчика в Европе €70-100K/год. Время выхода нового сотрудника на продуктивность примерно 3-6 месяцев. Потери: €17-50K на одну замену. С сохранённой историей решений и цифрового опыта сотрудника сокращается до 1-2 недель (большая часть из которых это бюрократия).

Дублирование работы. В команде из 10 человек с разными AI-инструментами: минимум 2-3 часа в неделю тратится на повторное объяснение контекста. 10 разработчиков х 2.5 часа х 48 недель х €50/час = €60K/год.

Повторные объяснения агентам. Каждый запрос «расскажи про проект/задачу» это 5-15 минут и тысячи токенов. Если разработчик делает это 3 раза в день (смена инструмента, новая сессия, другой контекст) — это 45 минут/день. €50/час х 0.75ч х 250 дней = €9,375/год на разработчика.

При таких цифрах подписка окупается за первую неделю использования.

Зачем это нужно любому специалисту работающему с AI-агентами

• экономия времени. Сделал задачу — научил агента. При смене инструмента или сессии опыт уже сохранён и доступен.

• экономия токенов. Агент не тратит контекстное окно на повторное объяснение. Он уже знает проект и может работать сразу.

• качество результата. Когда агент знает проект, подстраивается под стиль работы и обучен на ваших решениях — результат будет качественнее, а корректировок меньше.

Каким может быть будущее разработки

Мы находимся в точке перехода — разработчики в 2023 году писали код сами. В 2025 — с ИИ-ассистентом. В 2026 году он уже оркестрирует ИИ-агентов, а в 2028 вероятно будет управлять командами агентов работающих параллельно, каждая со своей специализацией.

Один агент — это мощный инструмент. Десять агентов — это команда, которой нужно управлять. И управление ИИ-агентами очень похоже на управление людьми: где-то быстрее сделать самому, где-то нужно делегировать, а иногда — выстроить процессы, чтобы каждый знал свою зону ответственности.

Я верю, что уже через год ИИ-агенты станут основным инструментом разработки, т.е. ручное написание кода станет архаичным и бессмысленным. Каждый специалист будет использовать 2–3 агента параллельно — под нужную задачу свой подходящий инструмент. Проблема контекстной станет еще более критичной и актуальной.

Лично я после 20 лет в IT уже смирился с тем, что ИИ-агенты делают мою работу быстрее и часто качественнее. Риск ошибки нивелируется выстроенным процессом и скоростью исправлений. Даже недавние инциденты — утечка Claude Code, даунтаймы AWS — показывают что бизнес всё равно выигрывает, а проблемы решаются структурно, на уровне процессов и инструментов.

Мультиагентные системы становятся нормой. Работает рой агентов: один проектирует, второй реализует, третий ревьюит, четвёртый тестирует, пятый деплоит. И каждому нужен доступ к общей памяти — кто что решил и почему. И полученные знания и опыт, также как и с человеком — могут быть получены либо лично, либо переиспользованы чтобы учиться на чужих «ошибках», не наступая на теже грабли.

Профессия IT-специалиста трансформируется — человек формулирует задачи, принимает решения и управляет контекстом, а реализацию выполняют агенты. Парадокс — в некоторых командах уже большая часть кода генерируется ИИ, но работы меньше не становится. Как оказалось написание кода — не основная часть работы, а лишь одна из задач.

Думаю через пять лет компании будут оцениваться не по количеству разработчиков, а по уникальной экспертизе и качеству «корпоративной памяти и цифрового опыта» — структурированного знания, доступного агентам. Реализовать фичу — вопрос часов. Но хранение знаний и нюансов- это то, что будет отделять успех от неудачи. Кто начнёт накапливать эту память сейчас — получит преимущество, которое невозможно догнать.

Это как с данными: в 2015 говорили «data is the new oil». В 2031 скажут: «context is the new data».

Нюансы и честный взгляд

Я не буду говорить, что CoAlly решает все проблемы. Вот чего он не делает:

• не заменяет документацию. Это все еще важно. CoAlly — это дополнение, не замена.

• не думает за вас. Если агент сохраняет мусор то и в памяти будет мусор. Качество зависит от настройки rules и от того, как агент формулирует контекст.

• не гарантирует, что агент всегда спросит память. Агенты иногда игнорируют инструкции, также как и люди.

Облачная версия уже доступна — для тех, кто не хочет возиться с инфраструктурой. Self-hosted остаётся основным вариантом для enterprise. Бесплатный тариф позволяет полноценно использовать сервис для двух проектов.

Next steps

Работа над продуктом продолжается. Вот направления, которые мы исследуем и внедряем:

Гибридный поиск и RRF

Сейчас поиск по памяти чисто семантический (cosine similarity по векторам). Это хорошо работает для поиска по смыслу, но пропускает точные совпадения: запрос «auth_middleware.py» не найдёт запись, где файл упомянут, но эмбеддинг далёк.

Решение, доказанное в продакшне Elasticsearch, Weaviate и MongoDB Atlas: гибридный поиск — параллельно запускаются keyword-поиск (BM25) и vector-поиск, результаты объединяются через RRF (Reciprocal Rank Fusion). RRF элегантен тем, что ему не нужна нормализация скоров — он работает только с рангами, и каждый новый сигнал (текстовый, семантический, временной, граф) просто добавляется как ещё один ранжированный список.

Умное забывание

Парадокс: система, которая помнит всё становится не лучше системы с амнезией. На горизонте десятков тысяч записей контекстный шум становится проблемой. Запрос «архитектура авторизации» возвращает и вчерашний root cause анализ, и заметку полугодовой давности о переезде с JWT на sessions. Оба релевантны семантически, но второй давно не актуален.

Исследуем подход из spaced repetition (FSRS — алгоритм, стоящий за Anki). Идея: каждое обращение к записи увеличивает её «стабильность», а неиспользуемые записи постепенно теряют вес при ранжировании. Не удаляются — просто уступают место более актуальным. Причём для разных типов записей — разная скорость затухания: решение вчерашнего бага теряет актуальность быстро, а архитектурное решение — почти никогда.

GraphRAG: связи между знаниями

Сейчас каждая запись это изолированный документ. Но знания проекта это граф: баг связан с модулем, модуль с архитектурным решением, решение с бизнес-требованием. Исследования (HippoRAG, Stanford/OSU) показывают, что Personalized PageRank по графу знаний значительно улучшает качество поиска: из сущностей запроса строится граф связей и вычисляется контекстуальная близость, а не только семантическая.

Мы уже храним связи между задачами, проектами и записями. Следующий шаг — использовать эту структуру для ранжирования: запись, связанная с тем же модулем что и текущая задача, должна ранжироваться выше, даже если семантически она дальше.

A2A: взаимодействие агентов

MCP решает задачу агент с инструментами. Но есть другая перспективная — взаимодействие агентов. Когда рой агентов работает параллельно над разными частями проекта, им нужен не только общий банк памяти, но и способ координации.

A2A (Agent-to-Agent Protocol) — свежий стандарт (v1.0, март 2026) под управлением Linux Foundation. За ним стоят Google, Microsoft, IBM, Cisco, AWS. Если MCP — это про то как «дать агенту нужные инструменты», то A2A — это как агентам «договориться». Agent Cards для описания возможностей, Tasks для долгоживущих операций, push-уведомления для асинхронной координации.

Мы следим за развитием A2A и рассматриваем интеграцию, где CoAlly выступает как shared memory layer, A2A как communication layer, чтобы агенты не только помнили общий контекст, но и могли явно делегировать задачи друг другу, как в Claude Code только распределенный и между разными инструментами.

К слову уже сейчас агенты могут использовать CoAlly как “стол переговоров” через персистентную память чтобы обсуждать задачи и координировать действия, но с использованием A2A это станет полноценным workflow.

Оцифрованные привычки и опыт

Сейчас CoAlly хранит факты: что решили, что нашли, что починили. Но есть ещё один слой — процедурное знание: «в этом проекте мы всегда пишем тесты и покрытие не должно быть ниже определенного порога в 80%», или «новые файлы больше 1000 строк нужно разбивать», «не добавлять поясняющие комментарии к коду, код должен быть чистым».

Это привычки команды, которые не фиксируются в документации, но определяют качество и скорость работы. Мы исследуем возможность автоматически находить и сохранять такие паттерны, чтобы новый агент (и разработчик) сразу работал по стандартам команды, а не набивал шишки заново.

---

Мы собираем фидбек и приоритизируем задачи на его основе. Если что-то из этого списка для вас критично или у вас есть интересные идеи — напишите, будем благодарны за обратную связь.

Как попробовать

Три шага, две минуты:

1. Регистрация https://coally.cortexally.ai/ — получаете API ключ

2. Подключение — одна команда для вашей IDE/агента (инструкция на сайте)

3. Первая сессия — агент автоматически индексирует проект и начинает работать

Бесплатный тариф — два проекта, без ограничения по времени. Достаточно для личного использования.

Self-hosted для enterprise: info@cortexally.ai — поможем развернуть на вашей инфраструктуре.

---

А как вы решаете проблему контекста между разными ИИ-инструментами сейчас? CLAUDE.md? Memory bank? Расскажите в комментариях.

Автор: основатель CortexAlly, AI development studio. Делаю инструменты, чтобы ИИ-агенты работали как команда.