Онто.

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

Задача - создание общего шаблона для информации о населенном пункте (на схеме обведен оранжевой линией). Учитываемые параметры этой информации обведены красной линией.

Конечно, можно было бы все эти 5 параметров (Точка во времени, Метод определения, Население, Ссылка, Населенный пункт) непосредственно подчинить объекту "Информация о населенном пункте", но это, скорее всего, повлияло бы на гибкость базы данных.

Вместо этого созданы три дополнительных последовательно вложенных шаблона, причём в первый (Классификаторы) добавляется 2 параметра, во второй (Заявление), третий (Утверждение) и четвертый (Информация) - по одному.

Вчера наконец собрал рабочий Agentic Flow для собственного процесса разработки.

И что интересно — главный вывод у меня получился не про агентов.
А про мотивацию изменений.

Я всё меньше верю в изменения ради самих изменений.

Неважно, о чём идёт речь:
— агентные harness;
— новые архитектурные паттерны;
— очередная модная методология;
— микросервисы;
— event sourcing;
— или любая другая красивая инженерная идея.

Если изменение не решает наблюдаемую проблему, очень высок шанс, что оно просто создаст новую.

У меня всё было наоборот.

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

На скриншотах — не демонстрация красивого фреймворка. Это результат накопленного опыта.

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

Но всё это появилось не потому, что я начал с Agentic Flow. Наоборот.
Agentic Flow появился потому, что процесс уже существовал и был многократно прожит.

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

Поэтому мой совет простой: не начинайте с упряжи.

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

И только потом автоматизируйте то, что действительно болит.

Хороший harness рождается из практики.
Хороший архитектурный паттерн тоже.

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

Не про Онто. Но кажется это достаточно важным что бы написать в канал.

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

Его задача — смотреть на задачу не только с точки зрения реализуемости, но и с точки зрения соответствия общей идее продукта.

Потому что технически можно реализовать почти что угодно. Но не каждое изменение усиливает систему. Иногда фича формально полезна, но уводит продукт в сторону: размывает нарратив, подменяет исходную идею, плодит лишние сущности или начинает тащить в продукт чужую логику.

В Онто это уже стало моей рабочей практикой.

Перед тем как задача уходит дальше, её полезно прогнать через отдельный контур проверки:

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

Для меня это особенно важно, потому что Онто развивается вокруг собственной смысловой модели. Здесь нельзя просто добавлять функции по принципу “можем — значит делаем”. Каждое изменение должно быть согласовано с языком продукта, его философией и способом работы со знанием.

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

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

Они помогают не только делать быстрее.
Они помогают не делать лишнего.

Очень рекомендую.

Продолжаю расширять MCP для Онто.

Теперь агент может работать с диаграммами не только по заранее известному diagram_id, но и через discovery: находить диаграммы, искать их по имени и фильтровать по контекстным тегам.

На первый взгляд это просто удобство навигации.
Но для агентной работы это важнее.

В Онто диаграмма — это не просто картинка. Это визуальный контекст, который ограничивает сцену работы: какие объекты сейчас важны, какие связи попали в фокус, в каком участке модели агент должен рассуждать и действовать.

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

Контекстная диаграмма решает эту проблему. Она задаёт рамку:
— вот этот проект;
— вот этот процесс;
— вот эта часть архитектуры;
— вот эти объекты и связи сейчас имеют значение.

Теперь через MCP агент может сам находить такие визуальные контексты, фильтровать их по тегам, создавать контекстные теги из объектов и размечать диаграммы.

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

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

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

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

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

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

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

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

То есть память должна жить не «где-то в длинной переписке», а рядом с тем, к чему она относится.

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

В этом смысле агентская память — это не просто история сообщений. Это способ удерживать смысл в рабочей системе.

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

Новый человек или агент может прийти не в пустоту, а в уже собранное смысловое поле.

И вот здесь Онто становится естественным местом для такой памяти. Потому что объекты, связи, задачи, решения и контексты уже живут в модели. Значит, и память о работе с ними должна быть адресной — привязанной к объектам, а не размазанной по перепискам.

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

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

👂Расширение Совета сообщества

Рады приветствовать @varkulevich Артема Варкулевича Совете сообщества🤝!!!

Артем - CEO компании «ОНТОНЕТ» (www.ontonet.ru), Более 30 лет в ИТ‑сфере, Работал с ВТБ, участвовал в проектах МТС, МГТС, «ВымпелКом» (в т. ч. в рамках «Совинтел‑Корбина»). Создал и развивает «Онто» — онтологическую платформу для моделирования и анализа сложных систем с использованием ИИ. Успешно запустил стартап по цифровому детоксу предприятия, который заработал 3 млн долларов.

📱 его канал с сообществом - https://t.me/ontonet

#TheDataAdventurersGuild #DataGovernance
#УправлениеДанными
#DataAdventurersBoard

Чем дальше мы выстраиваем собственный процесс производства ПО в Онто, тем сильнее я думаю, что рамку CDO — Chief Data Officer пора расширять.

Не потому что данные стали менее важны. Наоборот.

А потому что в современных цифровых системах ценность всё чаще создают не сами данные, а цифровые активы, построенные на их основе.

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

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

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

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

И вот тут одной роли CDO уже недостаточно.

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

Мне кажется, здесь неизбежно появляется рамка CKO — Chief Knowledge Officer, или шире — офицеров знания.

Их задача — не “вести базу знаний” в старом скучном смысле. База знаний, брошенная в угол корпоративной вики, обычно быстро превращается в кладбище PDF-динозавров.

Речь о другом: о владении знанием как цифровым активом.

Такой актив должен иметь:
— понятную структуру;
— владельцев и зоны ответственности;
— связи с процессами и решениями;
— правила изменения;
— историю происхождения;
— возможность использования людьми, алгоритмами и AI-агентами.

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

С этой точки зрения знание — это следующий класс цифровых активов после данных.

Сначала компании учились управлять данными.
Потом — аналитикой на основе данных.
Теперь придётся учиться управлять знанием, которое связывает данные, процессы, людей и агентов в единую систему.

Поэтому для меня CKO — это не модная новая должность ради красивой аббревиатуры. Это ответ на очень практичный вопрос: кто в компании отвечает за то, чтобы цифровые активы были не просто наборами данных, а работающим знанием?

CDO отвечает за данные.
CKO — за превращение данных, моделей и контекста в управляемые цифровые активы.

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

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

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

В центре манифеста — довольно простая мысль:
мир становится слишком сложным для управления через разрозненные документы, чаты и презентации.
Поэтому нам нужны структуры знания, semantic graphs и “цифровые тени”, которые помогают удерживать контекст, видеть связи и проектировать изменения не вслепую.

На сайте сейчас опубликованы 10 принципов смыслового мышления — про knowledge graphs, моделирование, коллективное мышление, AI и инженерный подход к знаниям.

🌐 Сайт манифеста:
http://sensemanifest.ru
А дальше самое интересное:
манифест не задумывался как “завершённый документ”. Он специально открыт для изменений, критики, дополнений и практических примеров.
Присоединиться можно по-разному:
— подписать и прокомментировать манифест;
— предложить правки через GitHub;
— участвовать в рабочей группе;
— или просто рассказать о нём тем, кому тема тоже откликается.
📦 Репозиторий:
https://github.com/OntoNet/manifest/blob/main/manifest.md

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

Вопрос только в том, научимся ли мы работать с ней осознанно.

⚡️Новый выпуск — Go4AI.59!
Возвращаемся после майских праздников 🙌 Готовы?
Смотрите 18 мая в 19:00 по ссылке: Запись эфира

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

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

➖Вячеслав Осипов — управляющий партнер Центра искусственного интеллекта «ГИПЕРКУБ», партнер НПО «КОНЦЕПТ», эксперт в области ИИ с 15-летним опытом, 7 из которых — в управленческом консалтинге.

➖Руслан Каримов — независимый эксперт.

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

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

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

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

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

Хорошо это стало видно на новой возможности в Онто.

Я как Product сформулировал направление изменения, а дальше Кристину было уже не остановить 🙂
И здесь важно понимать: Кристина вообще-то PM, а не разработчик. Но PM, усиленный нашим техпроцессом и командой агентов (каждый со своей ролью и своим бутстрапом).

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

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

И вот это для меня самое интересное.

Ценность агентной разработки — не в том, что “AI пишет код”.
А в том, что инженерный процесс становится более воспроизводимым и менее зависимым от конкретного человека.

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

То есть история постепенно перестаёт держаться на героизме отдельных инженеров и начинает опираться на процесс.

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

Ну и да — создавать вложенные шаблоны в Онто теперь стало заметно удобнее 🙂
Пользуйтесь.

Друзья,

За последний год в Онто появились партнёры, которые не просто пользуются платформой, а строят на ней собственные продукты — с разработкой через API и MCP, со своей моделью поставки конечным клиентам. Это здорово и именно того масштаба развитие, на которое мы рассчитывали. Но текущая политика лицензирования таких сценариев не описывала — отсюда и обновление.

Главное, что появилось:
Модель встраивания (OEM) — для тех, кто разрабатывает на Онто продукты и поставляет их клиентам. Состоит из трёх частей: оплата за разработчиков, фиксированное право встраивания и эксплуатационные лицензии за конечных пользователей (либо процент с выручки — что больше). Это рыночный стандарт для OEM, и он даёт партнёру около 40% маржи на лицензионной части плюс всю выручку от собственного продукта.

Полный текст политики по запросу.

Теперь чуть более приземлённо — что именно приехало в прод и зачем это вообще нужно.

Мы добавили drag-and-drop в дереве шаблонов Онто.

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

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

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

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

Для меня тут важен не сам drag-and-drop, а следующее:
модель становится пластичной, но не теряет семантическую дисциплину.

То есть менять структуру теперь проще, но это по-прежнему не «вольное таскание коробочек», а работа внутри правил, которые защищают знание от деградации.

Пользуйтесь.

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

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

Недавний пример — фича drag-and-drop в дереве шаблонов. Как Product, я передал её Кристине в работу. И именно здесь стало заметно, что история приобрела отделимые границы: PM получает не только постановку, но и дополнительный ресурс в виде агентов, которые помогают удерживать контекст, уточнять формулировки, проверять ограничения и снижать риск слабых решений.

То есть ценность не в том, что агенты «тоже умеют писать код». Ценность в том, что они помогают удерживать сложность, фиксировать ограничения, не терять контекст и превращать идеи в инженерно устойчивые решения.
Для меня цель достигнута тогда, когда техпроцесс и агентные инструкции позволяют развивать сложную систему даже людям, не очень близким к ИТ.

Похоже, один из таких шагов уже на проде. Пользуйтесь.

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

Проблема не в том, что LLM плохо пишет код.
Проблема в том, что изменение почти никогда не живёт только в коде.

Роли, цели, мотивы, API, состояния, сценарии, тесты, зависимости — всё это обычно размазано по чатам, задачам, голове аналитика и случайным документам.

В новой статье рассказываю, как я перестроил проектирование изменений через:

— чат с агентом бизнес-аналитиком;
— графовую модель изменений;
— MCP-доступ к модели;
— агентский бутстрап;
— формализованный техпроцесс.

На примере фичи агентской памяти показываю, как User Story превращается в граф ролей, целей, мотивов, API и зависимостей, а агент перестаёт быть «чатиком сбоку» и становится частью инженерного процесса.

Главная мысль простая:

Инженерное знание должно работать как код.

Статья:
https://ontonet.ru/learning/tpost/r8dlesip81-inzhenernoe-znanie-kak-kod-zachem-ya-svy

Продолжаем расширять возможности MCP для Онто.

В Онто появился новый механизм структурного поиска по связям, а в MCP — tool, который делает его доступным агентам напрямую.

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

То есть искать не только по классу объекта, но и по тому, с чем он связан и через какой тип связи.

Например, теперь можно:

— найти объекты класса A, которые связаны с объектами класса B;
— найти сущности, связанные с конкретным объектом;
— отбирать объекты сразу по нескольким структурным условиям;
— строить прикладные проекции в сервисах-потребителях, не зашивая бизнес-логику внутрь Онто.

Для MCP это особенно важно, потому что агенты получают не эвристический, а нормальный relation-aware search tool.
То есть агент больше не «догадывается» о структуре графа и не собирает её из набора разрозненных вызовов, а работает через понятный и проверенный контракт.

При этом мы специально не пошли в сторону тяжёлого graph DSL.
Контракт сделан простым и надёжным:

— только прямые связи, one-hop;
— AND между условиями;
— OR внутри списков значений;
— без вложенной булевой экзотики;
— без multi-hop traversal;
— без лишней магии.

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

Именно такие штуки постепенно переводят нас от “модель где-то лежит” к “модель реально участвует в работе агентов и сервисов”.

У меня уже довольно давно вся разработка построена на агентах.

Они пишут спецификации к изменениям, согласуют друг с другом контракты данных и требования, а потом реализуют. По сути, все крупные изменения в Онто за последние полгода — уже AI-driven.

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

И тут внезапно получилась почти классическая трёхзвенка:

— Онто как база данных,
— backend, который переводит контракт в бизнес-логику,
— desktop-приложение как пользовательский интерфейс.

И, честно говоря, мне это очень понравилось.

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

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

И вот тут началось самое смешное.

Уже на первой итерации у меня появилась роль онтологического DBA — агента, который настраивает модель пространства в Онто.

А следом закрепилась наша отдельная любовь — QA-агент, который умеет тестировать backend до того, как тот уходит на фронт.

То есть слой ролей, который раньше считался исключительно человеческим, начинает довольно уверенно раскладываться на агентные функции.

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

Сделали для подписчиков Онто с выделенным экземпляром новую возможность:
теперь MCP можно использовать внутри компании по HTTP через API key.
На практике это даёт больше гибкости, чем OAuth, особенно там, где нужно быстро и предсказуемо настраивать взаимодействие между инструментами, агентами и механизмами автоматизации.
То есть MCP в Онто теперь можно использовать не только как способ ручного подключения клиента, но и как рабочий интерфейс для автоматизации.
Ниже — важный нюанс: разные клиенты настраиваются по-разному.

Cursor
"onto": {
"url": "https://[domain]/mcp",
"headers": {
"X-Onto-Api-Key": "api-key-...."
}
}
Codex
[mcp_servers.appx]
command = "npx"
args = [
"mcp-remote",
"https://[domain]/mcp",
"--header",
"X-Onto-Api-Key:api-key-....",
]
Claude
"appx": {
"command": "npx",
"args": [
"mcp-remote",
"https://[domain]/mcp",
"--header",
"X-Onto-Api-Key:api-key-...."
]
}

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

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

В рамках этой архитектуры добавили поддержку MAX как полноценного рабочего канала наряду с Telegram.

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

То есть процесс перестаёт зависеть от конкретного интерфейса и начинает жить поверх модели, жизненного цикла и семантики.

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

Опубликовал пакет n8n-nodes-onto в npm:
https://www.npmjs.com/package/n8n-nodes-onto

Что это даёт на практике:

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

По сути, это ещё один шаг к тому, чтобы знание становилось частью автоматизации, а не лежало отдельно в виде документов, таблиц и чатов.