Онто.

Недавно писал как у нас в Онто произошёл интересный управленческий сдвиг. Кристина, которая раньше в основном работала в логике управления людьми, начала управлять командой агентов на Codex. И довольно быстро стало видно, что при правильно подготовленном процессе результат получается сопоставимым по скорости с обычной разработческой командой.

Недавно к нам пришёл один из амбассадоров Онто и сформулировал очень понятную пользовательскую боль: «Хочу управлять связями прямо в вашей Excel-табличке». Не через отдельные формы, не через сложный переход в другой режим, а прямо там, где пользователь уже работает с объектами и полями.

На первый взгляд запрос звучит просто. Есть таблица объектов, есть колонка связи, хочется нажать и добавить связанный объект. Но внутри Онто это не просто “ячейка в таблице”. За такой операцией стоит модель: шаблоны, допустимые типы связанных объектов, существующие связи, поиск объектов, ограничения, создание новой связи и корректное отображение результата в интерфейсе.
Раньше такая задача почти автоматически превращалась бы в классический цикл: обсудить с разработчиком, уточнить поведение, разложить на технические задачи, проверить реализацию, вернуть на доработку, снова проверить. Теперь мы попробовали иначе. Кристина взяла задачу как PM и повела её через агентную команду: сформулировала ожидание, уточнила сценарий, управляла итерациями, проверяла результат и довела фичу до препрода.

И вот здесь стало интересно. По сути, она не “передала задачу разработчику”, а начала управлять производственным контуром, где разработчиками выступают агенты. Они читают контекст, предлагают реализацию, вносят изменения, исправляют поведение, а PM удерживает цель, качество и пользовательский сценарий.

На препроде уже появился результат: в табличном режиме можно работать со связями как с частью привычной таблицы. Пользователь видит допустимые шаблоны, может искать объект, выбирать его и добавлять связь прямо из ячейки. Это очень важный шаг для Онто, потому что снижает порог входа: человек работает почти в знакомой логике таблицы, но под капотом остаётся полноценная модель объектов и связей.

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

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

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

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

И главный вывод для меня здесь простой. Мы передаём не только задачи агентам. Мы постепенно учимся передавать людям способность управлять агентными командами. А это уже совсем другой уровень масштабирования разработки.

Если вам интересно повторить у себя - вам нужно развернуть у себя экземпляр Онто и прийти ко мне за обучением.

Мы переделали сайт Онто.

У нас уже было несколько версий сайта, и каждый раз оставалось странное ощущение: вроде всё правильно написано, но сайт почему-то о чём угодно, только не об Онто. О платформе, возможностях, сценариях, пользе и красивых словах вокруг управления знаниями. Но не о самом главном: как из обычной рабочей задачи рождается связанная модель.

В новой версии мы попробовали зайти иначе. Теперь на главной можно начать не с изучения продукта, а со своей задачи: ввести человека в проект, разобраться в системе, понять влияние изменений, сохранить знания экспертов, связать бизнес и IT или дать AI нормальный контекст. А если готовый сценарий не подходит, можно просто написать задачу своими словами.

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

Для нас это важный момент, потому что Онто сложно объяснять через лозунги. Его проще понять в момент, когда разрозненное описание вдруг превращается в карту контекста. Компания обычно уже многое знает о себе, но это знание размазано по встречам, чатам, презентациям, документам и головам сотрудников.

Онто нужен не для того, чтобы красиво нарисовать ещё одну схему. Он нужен, чтобы связать эти знания и сделать их видимыми.

Поэтому новый сайт — это не просто витрина. Это попытка дать человеку быстрый первый опыт: ввести свою задачу и увидеть, как Онто начинает собирать из неё карту смысла.

Кажется, это уже намного ближе к тому, что мы всё это время пытались объяснить.

👂Неожиданно, но интересно - сегодня в 19:00 проводим первый демо-день RSC.

RSC — это реестр программных смыслов. Мы берём 31 697 продуктов из реестра Минцифры и добавляем к ним смысл: что умеет каждый продукт, что заменяет, кому можно доверять.

Начинаем серию коротких встреч о том как мы делаем этот продукт вместе с вами. Сегодня делаем интро встречу, расскажем идею и ее основные аспекты.

Будет интересно если вы выбираете ПО, замещаете иностранные системы или хотите понять как устроен рынок российского софта.

➡️Регистрация: imcenter.timepad.ru/event/4054213
✅ Канал: t.me/software_with_concepts

⚡️Новый выпуск — Go4AI.64! Готовы к нему? Смотрите 22 июня в 19:00 по ссылке: Запись эфира

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

➖Эдуард Ашрафьян (@EduardoAsh, ashrafyan.com) — автор Go4AI, эксперт по внедрению ИИ в бизнес.

➖Евгений Кузнецов (@kuznetsov_eu) — футуролог, венчурный капиталист, генеральный директор Digital Evolution Ventures.

➖Артем Варкулевич (@varkulevich) — автор проекта ontonet.ru, онтологическая платформа для моделирования и анализа сложных систем.

📌 Есть кейс по ИИ? Хотите разобрать его в эфире? Пишите Эдуарду: @EduardoAsh.

Ждём вас на эфире! 🔥

Что бы познакомиться с теми кто меня не знает:

Почему я делаю то что делаю. Вот история которая меня триггерит. Не нейросети эти, ни знания. А простая история.

Есть Маша и Вася.

Они встретились в институте — и в мире появилась связь.

Сначала она почти невесомая: «знакомы».
Потом становится плотнее: свидания, совместные планы, быт, брак.
Потом меняет состояние: расстались.
Потом снова меняет: живут вместе.
Потом от неё появляются новые объекты мира — дети, внуки, семейные истории, документы, воспоминания, фотографии, последствия решений.

И вот здесь начинается настоящая магия графов.

Маша может умереть.
Вася может умереть.
Но связь не исчезает вместе с ними.

Потому что связь — это не просто линия между двумя объектами.
Это след в реальности.

Она хранит факт встречи, историю состояний, последствия, порождённые сущности и контекст, который продолжает работать даже после исчезновения участников.

Объекты конечны.
Связи инерционны.

Иногда связь живёт дольше тех, кого она связывала.
И исчезает только тогда, когда гаснет вся ветка реальности, которую она породила.

Именно поэтому граф знаний — это не «кружочки со стрелочками».
Это способ увидеть, как мир держится не на объектах, а на связях между ними.

Смешанное чувство.

С одной стороны, рад, что эта мысль наконец выходит в массовое поле. С другой — я больше года назад сделал похожий подход в Онто и до сих пор считаю, что “второй мозг” в папке или личной wiki — это только первый шаг.

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

Потому что задача не просто в том, чтобы “не начинать с пустого чата”. Задача в том, чтобы команда и агенты работали в одном поле, где контекст не лежит мёртвым архивом, а становится рабочей моделью для действий и изменений.

Именно поэтому я продолжаю утверждать: будущее не только за second brain, а за shared brain — общей моделью знаний, процессов и агентной памяти.

Отдельно забавно, что такие идеи часто становятся очевидными только после того, как их формулирует кто-то из глобальной AI-сцены. Когда пытаешься объяснять это раньше и локально, тебя легко принимают за очередную “базу знаний” или “визуальную доску”.

https://x.com/i/status/2068753952850546985

Записал демонстрацию настройки Cherry Studio с DeepSeek и MCP Онто. Формально это видео про подключение инструментов: скачать Cherry Studio, создать API-ключ DeepSeek, создать API-ключ Онто и добавить MCP-сервер. Но по смыслу мне было важнее показать не настройку ради настройки, а переход от обычного чата с моделью к агенту, который может войти в рабочую среду и начать действовать по её правилам.

В демонстрации я специально начинаю с пустого пространства в Онто. Там нет заранее подготовленной базы знаний, красивой витрины или спрятанной модели. После подключения DeepSeek в Cherry Studio и MCP Онто я первым запросом прошу агента не выполнять задачу, а сначала научиться работать с Онто. Он читает инструкции через MCP-инструменты about_onto и how_to_use_onto_mcp, понимает доступные действия, ограничения и только потом переходит к работе.

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

Для меня это важный сдвиг. AI-агент становится полезнее не тогда, когда он красиво отвечает в чате, а когда он умеет работать внутри связанного контекста. Cherry Studio в этой связке выступает как рабочее место, DeepSeek — как модель рассуждения, MCP — как канал к инструментам, а Онто — как пространство объектов, связей и смысла.

Ссылки из видео:

Cherry Studio:
https://cherryai.com/download

DeepSeek API key:
https://platform.deepseek.com/api_keys

API key Онто:
https://app.ontonet.ru/ru/account

Видео:
https://rutube.ru/video/109aaa1073e192128823bdf642b69424/


#Онто #CherryStudio #DeepSeek #MCP #AIагенты #онтологии #KnowledgeGraph

В продолжение истории про агентскую память.

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

Сначала я думал об этом проще: агент что-то понял, зафиксировал, сохранил, потом другой агент может это найти и использовать. Но на практике сразу возникает вопрос: а всё ли, что агент сохранил, должно становиться общим знанием?

Промежуточная мысль — ещё не знание. Черновик — ещё не правило. Наблюдение — ещё не часть общей картины.

И вот здесь появился интересный механизм: пока агент-владелец не перевёл объект агентской памяти в состояние accepted, другие агенты его просто не видят.

То есть память может существовать как черновик. Агент может её создать, уточнить, переписать, привести в порядок, но она ещё не попадает в общее поле. А когда артефакт памяти принят, он становится доступен другим агентам при поиске по пространству.

На практике это выглядит очень просто: один агент создаёт артефакт памяти, пока он в draft — другой агент ничего не находит. Переводим артефакт в accepted — и соседний агент уже видит эту память как часть общего контекста.

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

Это сильно меняет отношение к агентской памяти. Если просто разрешить агентам всё помнить и всем этим обмениваться, очень быстро получится не коллективное знание, а коллективная помойка из догадок, черновиков и случайных формулировок.

А здесь появляется контур допуска. Не всё, что агент написал, сразу является знанием системы. Сначала это черновик. Знанием для других агентов оно становится только после принятия.

И вот тут Онто снова оказывается не просто хранилищем данных. Онто становится средой, где можно управлять статусом знания, его видимостью и доверием к нему.

Кажется, это один из самых важных принципов агентной памяти.

Нам нужна не память ради памяти. Нам нужна управляемая память агентной команды.

Моему агенту: научись работать с Онто

Когда у вас появляется агент — Claude, ChatGPT или любой другой, — главная проблема обычно не в том, что он недостаточно умный. Проблема в другом: он не знает вашу рабочую среду.

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

То есть агент вроде бы есть, но в вашу систему он ещё не вошёл.

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

Мы хотим сделать этот вход проще.

Теперь пользователю достаточно сказать агенту:

У тебя подключен Онто. Сначала научись с ним работать. А потом научи меня, как правильно ставить тебе задачи в Онто.

Это маленькая фраза, но за ней важный сдвиг. Онто становится не только инструментом для человека, но и средой, в которую можно быстро ввести агента.

Агент проходит короткий онбординг: понимает, с чего начать, какие данные нужны, какие действия безопасны, где не надо торопиться и когда нужно вернуть вопрос человеку. И только после этого начинает выполнять задачу.

Пользователю больше не нужно быть специалистом по агентным инструментам. Достаточно попросить агента: научись работать с Онто — и меня научи.

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

Это и есть быстрый онбординг агента.

Не через длинную инструкцию, не через технический разбор и не через надежду, что он сам догадается.

А через нормальный вход в систему: сначала понять среду, потом действовать.

На Проде. Можно пользоваться

Скоро выйдет новый продукт на Онто.
И вместе с ним — новая статья о том, как он появился.
Для меня здесь важен не только сам продукт, а способ его рождения.
Мы взяли исходный нарратив Онто — про знание, связи, контекст, решения и управляемость изменений — и начали превращать его в прикладную бизнес-идею на уровне дата-бэкенда.
Не через презентацию.
Не через «давайте накидаем экранов».
Не через бесконечный чат с агентом.
А через роли, контракты, репозитории, API, проверки, онтологические границы и агентную команду, которую пришлось не просто запустить, а фактически нанять в правильно подготовленную среду.

Получилась история о том, как нарратив превращается в программный продукт.

И, кажется, это уже не только про один конкретный кейс.
Это про новый способ собирать прикладное ПО вокруг модели знания.

Мы подошли к важной границе в агентной разработке.

Агент может написать код.
Агент может провести анализ.
Агент может выполнить задачу.

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

Память есть у конкретного запуска.
Контекст есть у конкретного участника.
А проектного знания как системного артефакта всё ещё нет.

Именно поэтому мы начали делать скрытый слой агентной памяти внутри Онто.

Главная мысль проста: проектное знание должно жить не рядом с проектом, а внутри самой модели — как связанный, адресуемый и передаваемый слой работы.

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

Почему именно скрытый слой?

Потому что агентная память не должна смешиваться с обычной пользовательской онтологией.

Это не пользовательские шаблоны.
Не обычные объекты.
Не ещё один набор сущностей, который случайно появляется на диаграмме.

Это системный слой проектной работы, с которым могут работать агенты и который при этом не ломает пользовательскую модель.

Почему именно в Онто?

Потому что проект — это не только объекты, задачи и диаграммы.

Проект — это ещё и следы решений:

— что мы уже поняли;
— что проверили;
— где нашли разрыв;
— почему выбрали именно такой путь;
— что нужно сделать следующему участнику;
— какие риски и ограничения уже зафиксированы;
— какие результаты проверки нужно учитывать дальше.

Если эти следы не связаны с моделью, они быстро расползаются по файлам, чатам и памяти людей.

А если они связаны с конкретными узлами графа, то у знания появляется адрес.

Можно найти не «какой-то документ», а передачу контекста, связанную с конкретной проблемой, объектом, гипотезой, задачей или решением.

И это принципиально меняет работу агентов.

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

Увидел объект.
Нашёл связанные записи.
Прочитал полный контекст.
Понял, что уже было сделано.
Продолжил работу.
Оставил следующий след для другого участника.

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

Обычно передача работ между участниками выглядит как попытка восстановить смысл по кускам: найти старые файлы, поднять переписку, спросить автора, понять, какое решение уже принималось и почему оно не отражено в текущем документе.

А здесь контекст постепенно перестаёт быть побочным продуктом работы.

Он становится частью самой проектной среды.

Часто складывается ощущение, что графы знаний — это какая-то нишевая история для онтологов и любителей RDF.
Но если посмотреть, кто сегодня продвигает эту тему, картина получается гораздо интереснее.
Причём люди приходят к ней из совершенно разных направлений.
📍 Juan Sequeda (data.world)
Продвигает концепцию System of Context.
По сути говорит простую вещь: проблема предприятий не в отсутствии данных.
Проблема в стоимости получения контекста.
📍 Dave Bennett / IndyKite
Использует термин Context Graph.
Граф рассматривается как управляющий слой организации, через который проходят данные, процессы, идентичности и агенты.
Основная идея — уменьшить коммуникационные накладные расходы.
📍 Neo4j
Последние годы всё меньше говорят про граф как базу данных.
Всё больше — про граф как инфраструктуру контекста.
Особенно после появления GraphRAG.
📍 GraphRAG (Microsoft Research)
Вся идея строится вокруг простой мысли:
LLM нужен не поиск документов.
LLM нужен связанный контекст.
📍 Google Enterprise Knowledge Graph
Похожий нарратив.
Данные сами по себе ценности не создают.
Ценность появляется тогда, когда между объектами появляется модель связей.
📍 Ontotext
Продвигают граф как единую точку доступа ко всему корпоративному знанию.
Фокус — принятие решений и управление знаниями.
📍 Timbr.ai
Продвигают Semantic Layer.
Пользователь не должен знать, где лежат данные.
Он должен получать готовый контекст для решения задачи.
Что мне во всей этой истории кажется интересным.
Все эти люди пришли к графам знаний с разных сторон:
— Data Management
— Enterprise Architecture
— AI
— Knowledge Management
— Data Governance
Но постепенно начинают говорить примерно одно и то же.
👉 Граф знаний — это не способ хранить данные.
👉 Это способ уменьшить время получения контекста для принятия решения.
Именно эта мысль мне кажется намного важнее бесконечных споров про RDF, Property Graph, SPARQL или Cypher.
Похоже, что главный дефицит современной организации — не данные.
Данных как раз завались.
Дефицит возникает в тот момент, когда нужно быстро собрать контекст для принятия решения.

https://drive.google.com/file/d/1ojDhZAdgc_e90f49CCFFn6Cd-NGC20aE/view?usp=drivesdk

Важное обновление по авторизации в Онто.

В течение следующей недели мы отключим вход через Google-аккаунт.

Решение связано с приведением сервиса к актуальным требованиям российского законодательства в части регистрации и авторизации пользователей на российских онлайн-платформах.

После отключения Google-авторизации вход в Онто будет доступен стандартным способом — по логину и паролю.

Все пространства, модели и пользовательские данные сохранятся. Меняется только способ входа.

Пожалуйста, заранее убедитесь, что вы можете войти в аккаунт без использования Google-авторизации. При возникновении сложностей обращайтесь в поддержку Онто.

Показательный момент.

Кажется, процесс разработки начинает отделяться от меня.

Несколько месяцев назад я собрал для Онто набор агентов (от аналитика до qa), обучил их нашим практикам и постепенно встроил в процесс разработки.

А дальше произошло то, чего я, честно говоря, ждал, но всё равно немного удивился.

Я передал этих агентов Кристине.

И дальше фича личного кабинета прошла практически самостоятельный жизненный цикл.

Кристина взяла готовое reviewed ТЗ, подняла отдельную ветку, провела несколько итераций реализации, поддерживала ветку актуальной относительно main, подготовила уточнения для аналитика, оставила worklog, handoff и notes для следующего участника процесса, после чего довела изменения до merge.

В git это выглядит довольно буднично:

— отдельная ветка personal-account-page-layout;
— два содержательных коммита;
— синхронизация с main по ходу работы;
— PR #406;
— merge в основную ветку.

Но для меня важнее другое.

Если посмотреть на артефакты вокруг задачи, становится видно, что агент участвовал не только в написании кода.

Он помогал работать с требованиями, сохранять контекст, фиксировать решения, готовить передачу задачи следующему участнику и поддерживать воспроизводимость процесса.

То есть начинает переноситься не код.

Начинает переноситься способ работы.

Именно этот момент мне кажется самым интересным во всей истории с агентной разработкой.

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

Похоже, это первый случай, когда я увидел такой перенос на практике.

А для нас с вами это более удобный личный кабинет на Проде.

Вернемся к Онто. В нём имеется функция Тег - набор символов (например, слово), относящееся к какому-то объекту. Его можно использовать как обозначение принадлежности к обозначаемому им множеству, что
1) даёт объектам новый (общий) параметр,
2) облегчает в будущем поиск объектов по нему.

Например, есть объекты Голубь и Синица. Припишем им обоим тег Птицы. Что изменилось? Появился параметр-идентификатор, общий для двух объектов.

Но это ещё не всё. В Онто Тег можно превратить в Шаблон. Шаблон сохраняет функции тега, но теперь к слову-идентификатору прибавляется таблица, куда можно заносить названия объектов этого шаблона, а также их свойства и значения этих свойств. Причем внутри шаблона Птицы могут помещаться любые новые объекты. Они могут быть Голубь и Синица, а могут и не быть.

Рис. 1. Пример-схема последовательной установки тега и шаблона объектов в Онто.

Рис. 2. Тег или шаблон объекта включается в правом верхнем углу графического представления Онто (обведены красным).

Продолжая тему Agentic Flow

У меня давно болело одно изменение в Онто — убрать GraphQL из взаимодействия фронтенда и бэкенда.

Фронтенд-агент нашёл 11 точек использования GraphQL.

Мы объединили их в Epic (001), после чего последовательно закрывали Story:

- 002 — ручная реализация
- 003–007 — ручная оркестрация агентов через меня
- 008–011 — автоматическая оркестрация через агента

В какой-то момент я понял, что наблюдаю уже не развитие требования, а развитие самого процесса производства ПО.

Story 002 я реализовывал практически вручную.

Не фиксировал этапы жизненного цикла в контенте объекта, сам синхронизировал агентов, сам передавал контекст между ролями.

Потом появился специальный MCP tool, и аналитический агент начал фиксировать важные события прямо в объектах.

С Story 003 по Story 007 я продолжал выступать оркестратором лично.

По сути, вся синхронизация проходила через меня:

Аналитик → Backend → Frontend → QA

Я вручную переносил контекст между ролями и следил, чтобы никто не потерял важные детали.

И вот тут начинается самое интересное.

Я так работал почти полгода.

Поэтому когда появилось немного времени и воли, я сделал агента-оркестратора, который взял эту работу на себя.

🔻 [схема 1 — старая модель: я в центре]
🔻 [схема 2 — новая модель: агент-оркестратор]

На первой схеме хорошо видно старую модель: я нахожусь в центре и вручную передаю контекст между агентами.

На второй — новую: агент-оркестратор синхронизирует участников сам, а я остаюсь только на контрольных точках и финальной приёмке.

Результат оказался вполне измеримым.

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

После появления оркестратора эти паузы практически схлопнулись.

Именно поэтому я постоянно повторяю одну мысль:

Не начинайте с упряжи.

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

И только потом автоматизировать.

Хорошая упряжь появляется не потому, что вышел новый модный фреймворк.

Она появляется тогда, когда вы точно знаете:

— какую боль хотите убрать;
— где возникает потеря эффективности;
— и как будете измерять результат.

Если совсем честно, я не придумал оркестратора потому, что захотелось агентности.
Я сделал его потому, что полгода сам выполнял роль оркестратора.

И мне это надоело 🙂