Forwarded from Масштабирование IT-продуктов // LOSI.vc (Alexander Gribanov)
Я снова программирую! Или нет?! Сразу и не разберешь.
Скорее наблюдаю, как программирует команда ИИ-агентов.
ИИ агенты — уже не экзотика: они пишут код, анализируют рынок, готовят материалы и помогают управлять продуктом. Но довольно быстро возникает следующий вопрос: как превратить несколько сильных помощников из разных чатов в устойчивую команду, которая не теряет контекст между запусками и умеет работать вместе с людьми?
Получил ответ и практический опыт его применения внутри команды продукта Онто. Хочу поделиться.
Напомню, что Онто - это среда, в которой люди и ИИ-агенты могут работать как одна команда — с общим контекстом, ролями, задачами и историей решений.
Артем Варкулевич, основатель Онто - описал практический ответ в двух небольших статьях:
«Общие коллеги: как люди и агенты работают в одном пространстве»
https://learning.ontonet.ru/tpost/cchk57af91-obschie-kollegi-kak-lyudi-i-agenti-rabot
«Куда поселить агента: зачем гибридной команде пространство Онто»
https://learning.ontonet.ru/tpost/slycmci8u1-kuda-poselit-agenta-zachem-gibridnoi-kom
Буду рад обсуждению с теми, кто уже использует агентов в своих продуктах: как личных помощников, цифровых сотрудников или полноценную часть производственного процесса.
Скорее наблюдаю, как программирует команда ИИ-агентов.
ИИ агенты — уже не экзотика: они пишут код, анализируют рынок, готовят материалы и помогают управлять продуктом. Но довольно быстро возникает следующий вопрос: как превратить несколько сильных помощников из разных чатов в устойчивую команду, которая не теряет контекст между запусками и умеет работать вместе с людьми?
Получил ответ и практический опыт его применения внутри команды продукта Онто. Хочу поделиться.
Напомню, что Онто - это среда, в которой люди и ИИ-агенты могут работать как одна команда — с общим контекстом, ролями, задачами и историей решений.
Артем Варкулевич, основатель Онто - описал практический ответ в двух небольших статьях:
«Общие коллеги: как люди и агенты работают в одном пространстве»
https://learning.ontonet.ru/tpost/cchk57af91-obschie-kollegi-kak-lyudi-i-agenti-rabot
«Куда поселить агента: зачем гибридной команде пространство Онто»
https://learning.ontonet.ru/tpost/slycmci8u1-kuda-poselit-agenta-zachem-gibridnoi-kom
Буду рад обсуждению с теми, кто уже использует агентов в своих продуктах: как личных помощников, цифровых сотрудников или полноценную часть производственного процесса.
❤2
Большинство бизнес-ассистентов начинают работу с восстановления контекста: читают документы, выделяют сущности и заново выясняют, как связаны проекты, договоры, люди и решения. Даже если все данные переданы, при следующем запуске эту картину приходится собирать заново — и она может немного отличаться от предыдущей.
В Онто мы проверили другую конструкцию. Ассистента можно один раз учредить как постоянную роль и поместить в пространство, где предметная область уже представлена объектами и связями. В статье показываем этот механизм на простом примере ветеринара, который начинает работу не с файла «наши коты», а с уже существующей модели животных и их владельцев.
Практическое применение начинается там, где вместо котов появляются договоры, платежи, обязательства, продукты, работы и подразделения. Финансовый контролёр сможет работать с общей моделью бюджетов и платежей, операционный ассистент — видеть сроки, ресурсы и зависимости, а продуктовый аналитик — связывать потребности с функциями и решениями. Разные роли получают свои полномочия, но опираются на одно устройство бизнеса, а не на несколько независимо собранных версий компании.
Новая статья — о том, как перестать каждый раз объяснять ассистенту, в каком мире он находится, и начать создавать устойчивые прикладные роли вокруг модели реального бизнеса.
В Онто мы проверили другую конструкцию. Ассистента можно один раз учредить как постоянную роль и поместить в пространство, где предметная область уже представлена объектами и связями. В статье показываем этот механизм на простом примере ветеринара, который начинает работу не с файла «наши коты», а с уже существующей модели животных и их владельцев.
Практическое применение начинается там, где вместо котов появляются договоры, платежи, обязательства, продукты, работы и подразделения. Финансовый контролёр сможет работать с общей моделью бюджетов и платежей, операционный ассистент — видеть сроки, ресурсы и зависимости, а продуктовый аналитик — связывать потребности с функциями и решениями. Разные роли получают свои полномочия, но опираются на одно устройство бизнеса, а не на несколько независимо собранных версий компании.
Новая статья — о том, как перестать каждый раз объяснять ассистенту, в каком мире он находится, и начать создавать устойчивые прикладные роли вокруг модели реального бизнеса.
🔥2
Большой промпт может однажды превратить универсальную языковую модель в убедительного бизнес-ассистента. Но в следующей сессии всё приходится собирать заново: объяснять устройство компании, перечислять ограничения и надеяться, что роль будет интерпретирована так же, как в прошлый раз.
В предыдущей статье я писал о том, почему ассистенту полезно дать внешнюю модель бизнеса. Теперь перехожу к практике: как на основе этой модели создать устойчивую роль, которую можно повторно запускать в новых сессиях без нового пересказа всей предметной области.
В качестве сквозного примера я взял аналитика расчётов с персоналом. Мы последовательно определяем его бизнес-результат, описываем нужную часть модели, учреждаем базовое агентное население, задаём территорию и ограничения роли, регистрируем её в пространстве, а затем проверяем на реальной задаче.
Главное изменение здесь не в размере промпта. Модель пространства отвечает на вопрос, что известно о бизнесе, роль определяет, зачем и в каких границах действует ассистент, а стартовая команда только выбирает уже учреждённого участника. Так ассистент перестаёт быть удачной формулировкой в одном чате и становится повторно запускаемым жителем пространства.
Новая статья: «От модели бизнеса к работающему ассистенту: практический рецепт».
В предыдущей статье я писал о том, почему ассистенту полезно дать внешнюю модель бизнеса. Теперь перехожу к практике: как на основе этой модели создать устойчивую роль, которую можно повторно запускать в новых сессиях без нового пересказа всей предметной области.
В качестве сквозного примера я взял аналитика расчётов с персоналом. Мы последовательно определяем его бизнес-результат, описываем нужную часть модели, учреждаем базовое агентное население, задаём территорию и ограничения роли, регистрируем её в пространстве, а затем проверяем на реальной задаче.
Главное изменение здесь не в размере промпта. Модель пространства отвечает на вопрос, что известно о бизнесе, роль определяет, зачем и в каких границах действует ассистент, а стартовая команда только выбирает уже учреждённого участника. Так ассистент перестаёт быть удачной формулировкой в одном чате и становится повторно запускаемым жителем пространства.
Новая статья: «От модели бизнеса к работающему ассистенту: практический рецепт».
🔥1
Почему сложный софт нельзя собрать одной волшебной командой
Нейросеть отлично справляется с отдельным, понятным поручением. Она может быстро сделать лендинг, форму или небольшой сервис — всё, что целиком помещается в один замысел. Но сложный продукт не создаётся за один подход. Он развивается годами, а тысячи изменений, сделанных разными людьми и агентами, должны продолжать работать как единая система.
Представьте, что мы не рисуем красивую комнату, а много лет строим и перестраиваем большой дом. В нём уже есть стены, проводка, трубы, вентиляция, привычки жильцов и решения, принятые несколько лет назад. Нельзя просто позвать очередного мастера и попросить: «Сделай здесь красиво». Он может прекрасно выполнить поручение, но одновременно пробить трубу, перекрыть проход или установить выключатель, который неожиданно управляет светом в соседней комнате.
С программами происходит то же самое. Каждое изменение по отдельности может выглядеть разумным, но вместе они постепенно перестают складываться в целое. Причём это не обязательно приводит к явной поломке. Гораздо хуже, когда программа запускается, код компилируется, функции что-то делают — но уже никто не понимает, почему система устроена именно так и что разрушится после следующего изменения.
Обычные проверки замечают лишь самые грубые ошибки. Это как инспектор, который убедился, что дом не рухнул и электричество включается. Но он не проверяет, почему спальня соединена дверью с подъездом, три выключателя делают одно и то же, а новая кладовка перекрыла жильцам дорогу на кухню. Технически дом существует, но его смысловая конструкция уже начала расползаться.
Поэтому при агентной разработке недостаточно точнее формулировать очередное поручение. Нужна общая, постоянно поддерживаемая картина продукта: что мы строим, зачем существует каждая часть, с чем она связана, какие решения уже приняты и какие ограничения нельзя нарушать. Чем быстрее ИИ создаёт новые элементы, тем важнее становится эта дисциплина.
В Онто такая картина существует отдельно от конкретного человека, документа или нейросети. Если продолжить аналогию, это живой паспорт дома: план помещений, схема коммуникаций, назначение каждой комнаты, история решений и правила перестройки. Перед началом работы агент может увидеть не только своё поручение, но и связанные требования, компоненты, решения и последствия изменения. После завершения работы он может зафиксировать, что именно поменялось.
Более того, в пространстве могут жить отдельные агенты-смотрители. Один следит за архитектурой, другой — за требованиями, третий — за качеством и проверками. Они не заменяют общую модель продукта, а помогают сохранять её живой и не позволяют тысячам локально правильных изменений превратиться в глобально бессмысленную систему.
Онто не обещает волшебную кнопку, которая сама создаст сложный продукт. Нейросеть уже умеет быстро класть кирпичи. Наша задача — помочь ей помнить, какой дом мы строим, как устроены его стены и почему он до сих пор не развалился.
Нейросеть отлично справляется с отдельным, понятным поручением. Она может быстро сделать лендинг, форму или небольшой сервис — всё, что целиком помещается в один замысел. Но сложный продукт не создаётся за один подход. Он развивается годами, а тысячи изменений, сделанных разными людьми и агентами, должны продолжать работать как единая система.
Представьте, что мы не рисуем красивую комнату, а много лет строим и перестраиваем большой дом. В нём уже есть стены, проводка, трубы, вентиляция, привычки жильцов и решения, принятые несколько лет назад. Нельзя просто позвать очередного мастера и попросить: «Сделай здесь красиво». Он может прекрасно выполнить поручение, но одновременно пробить трубу, перекрыть проход или установить выключатель, который неожиданно управляет светом в соседней комнате.
С программами происходит то же самое. Каждое изменение по отдельности может выглядеть разумным, но вместе они постепенно перестают складываться в целое. Причём это не обязательно приводит к явной поломке. Гораздо хуже, когда программа запускается, код компилируется, функции что-то делают — но уже никто не понимает, почему система устроена именно так и что разрушится после следующего изменения.
Обычные проверки замечают лишь самые грубые ошибки. Это как инспектор, который убедился, что дом не рухнул и электричество включается. Но он не проверяет, почему спальня соединена дверью с подъездом, три выключателя делают одно и то же, а новая кладовка перекрыла жильцам дорогу на кухню. Технически дом существует, но его смысловая конструкция уже начала расползаться.
Поэтому при агентной разработке недостаточно точнее формулировать очередное поручение. Нужна общая, постоянно поддерживаемая картина продукта: что мы строим, зачем существует каждая часть, с чем она связана, какие решения уже приняты и какие ограничения нельзя нарушать. Чем быстрее ИИ создаёт новые элементы, тем важнее становится эта дисциплина.
В Онто такая картина существует отдельно от конкретного человека, документа или нейросети. Если продолжить аналогию, это живой паспорт дома: план помещений, схема коммуникаций, назначение каждой комнаты, история решений и правила перестройки. Перед началом работы агент может увидеть не только своё поручение, но и связанные требования, компоненты, решения и последствия изменения. После завершения работы он может зафиксировать, что именно поменялось.
Более того, в пространстве могут жить отдельные агенты-смотрители. Один следит за архитектурой, другой — за требованиями, третий — за качеством и проверками. Они не заменяют общую модель продукта, а помогают сохранять её живой и не позволяют тысячам локально правильных изменений превратиться в глобально бессмысленную систему.
Онто не обещает волшебную кнопку, которая сама создаст сложный продукт. Нейросеть уже умеет быстро класть кирпичи. Наша задача — помочь ей помнить, какой дом мы строим, как устроены его стены и почему он до сих пор не развалился.
❤3
Карточка Jira постепенно превращается в маленькое кладбище контекста. В ней лежат постановка задачи, уточнения, гипотезы, логи, результаты проверок, объяснения решений и переписка нескольких исполнителей. Человеку уже трудно понять, что из этого описывает систему сейчас, а что было лишь промежуточной версией. Агенту ещё сложнее: в новой сессии ему приходится заново восстанавливать ход чужой работы из этой свалки.
В Онто мы разделили два слоя. В видимой людям модели остаются подтверждённые факты о системе: компоненты, требования, связи, дефекты, решения и текущее состояние объектов. Агентская память хранит другое — как агент исследовал конкретный объект, какие гипотезы проверял, что отверг, на какие доказательства опирался и какой контекст передал следующему исполнителю.
Так память не висит отдельным бесконечным архивом переписки, а прикрепляется к тем объектам модели, которых касается. Новый агент может восстановить не весь проект целиком, а историю работы именно с нужным контрактом, дефектом, оборудованием или архитектурным решением. При этом человек видит и контролирует оба слоя.
В новой статье — четыре прикладных сценария и пошаговый рецепт работы с агентской памятью в Онто: от первой записи до передачи задачи другому агенту и восстановления работы в новой сессии.
В Онто мы разделили два слоя. В видимой людям модели остаются подтверждённые факты о системе: компоненты, требования, связи, дефекты, решения и текущее состояние объектов. Агентская память хранит другое — как агент исследовал конкретный объект, какие гипотезы проверял, что отверг, на какие доказательства опирался и какой контекст передал следующему исполнителю.
Так память не висит отдельным бесконечным архивом переписки, а прикрепляется к тем объектам модели, которых касается. Новый агент может восстановить не весь проект целиком, а историю работы именно с нужным контрактом, дефектом, оборудованием или архитектурным решением. При этом человек видит и контролирует оба слоя.
В новой статье — четыре прикладных сценария и пошаговый рецепт работы с агентской памятью в Онто: от первой записи до передачи задачи другому агенту и восстановления работы в новой сессии.
👍1
Мы зарелизили новую версию сайта Онто: https://ontonet.ru/
В этот раз нам было важно не просто перечислить возможности платформы, а подробнее рассказать о самом методе работы со знаниями. Как начинать с конкретной задачи, выделять объекты и связи, собирать из них живую модель, а затем использовать структурированное знание в работе — в том числе в процессе производства ПО. Требования, решения, архитектура, задачи и участники при таком подходе существуют не в отдельных документах, а в общем связанном контексте.
Для самой платформы Онто мы сделали отдельный раздел: https://ontonet.ru/product. Там подробнее показали, как устроены пространства, общая память, живые диаграммы и работа AI непосредственно с объектами модели.
Заметно усилился и блок «Живой пример» на главной странице. Если раньше можно было сделать небольшую модель знания, то тТеперь можно поиграть с готовыми вопросами, получить ответ нейросети и сразу увидеть, на какие объекты модели она опиралась. То есть посмотреть не только на ответ, но и на его основание.
Посмотрите сайт и расскажите, удалось ли нам объяснить Онто понятнее.
В этот раз нам было важно не просто перечислить возможности платформы, а подробнее рассказать о самом методе работы со знаниями. Как начинать с конкретной задачи, выделять объекты и связи, собирать из них живую модель, а затем использовать структурированное знание в работе — в том числе в процессе производства ПО. Требования, решения, архитектура, задачи и участники при таком подходе существуют не в отдельных документах, а в общем связанном контексте.
Для самой платформы Онто мы сделали отдельный раздел: https://ontonet.ru/product. Там подробнее показали, как устроены пространства, общая память, живые диаграммы и работа AI непосредственно с объектами модели.
Заметно усилился и блок «Живой пример» на главной странице. Если раньше можно было сделать небольшую модель знания, то тТеперь можно поиграть с готовыми вопросами, получить ответ нейросети и сразу увидеть, на какие объекты модели она опиралась. То есть посмотреть не только на ответ, но и на его основание.
Посмотрите сайт и расскажите, удалось ли нам объяснить Онто понятнее.
👍2
Мы опубликовали открытую методологию ведения проектов разработки ПО основанной на графе знания.
Она связывает работу от причины её появления и ожидаемого изменения до требований, выполнения, проверки, выпуска и обратной связи. Методология не заменяет Scrum, Kanban или внутренние регламенты — она помогает не потерять исходный смысл и подтвердить, что достигнут именно нужный результат.
Но главное для нас в другом. Такая модель открыла путь к AI-native процессу производства ПО.
AI-native — это не чат-бот у каждого сотрудника. Чтобы агент стал участником производства, он должен видеть цели, объекты работы, зависимости, полномочия и критерии завершения. В Онто люди и агенты работают с одной связной моделью, поэтому агент может восстановить контекст, найти пропуски, провести проверку или подготовить решение, не присваивая себе человеческие полномочия.
Теперь мы предлагаем компаниям пройти этот путь на собственном процессе: провести диагностику, адаптировать методологию и реализовать рабочий контур в Онто.
Результат пилота измеряем по сквозной трассируемости работ, времени восстановления контекста, числу возвратов и доле операций, которые можно безопасно передать агентам.
Методология: https://ontonet.ru/methodology
Предложение для компаний: https://ontonet.ru/companies/software-development
Она связывает работу от причины её появления и ожидаемого изменения до требований, выполнения, проверки, выпуска и обратной связи. Методология не заменяет Scrum, Kanban или внутренние регламенты — она помогает не потерять исходный смысл и подтвердить, что достигнут именно нужный результат.
Но главное для нас в другом. Такая модель открыла путь к AI-native процессу производства ПО.
AI-native — это не чат-бот у каждого сотрудника. Чтобы агент стал участником производства, он должен видеть цели, объекты работы, зависимости, полномочия и критерии завершения. В Онто люди и агенты работают с одной связной моделью, поэтому агент может восстановить контекст, найти пропуски, провести проверку или подготовить решение, не присваивая себе человеческие полномочия.
Теперь мы предлагаем компаниям пройти этот путь на собственном процессе: провести диагностику, адаптировать методологию и реализовать рабочий контур в Онто.
Результат пилота измеряем по сквозной трассируемости работ, времени восстановления контекста, числу возвратов и доле операций, которые можно безопасно передать агентам.
Методология: https://ontonet.ru/methodology
Предложение для компаний: https://ontonet.ru/companies/software-development
🔥3❤1
Структурированное знание как способ снизить зависимость от конкретной LLM
Мы провели эксперимент: дали четырём разным языковым моделям — Qwen3.8-27B, DeepSeek Reasoner, GPT-5.6-sol и Claude Opus 4.8 — доступ через MCP к одной и той же структурированной модели знания в Онто. После этого моделям была задана одинаковая последовательность аналитических вопросов. Главный результат: несмотря на различия в стиле, глубине рассуждений и способе оформления ответа, все четыре модели сохранили общую предметную рамку и пришли к совместимым по смыслу выводам.
В нашем эксперименте система координат находилась не внутри LLM. Она была вынесена во внешний структурированный слой: понятия, роли, критерии и отношения между ними были явно зафиксированы в Онто. В такой архитектуре нейросеть не должна заново изобретать предметную модель. Она получает уже заданную структуру и использует её как основание для ответа.
Получается разделение ответственности:
Онто хранит предметное знание, его структуру, критерии и связи;
LLM находит нужные элементы, интерпретирует их применительно к вопросу и формирует понятный человеку ответ.
Именно структурированное знание становится инвариантом между разными моделями. Можно менять нейросеть, но предметная система координат остаётся прежней.
При этом модели не становятся полностью одинаковыми. В эксперименте часть моделей следовала исходной структуре почти буквально, а часть расширяла её, добавляла собственные критерии или делала дополнительные выводы. Отличались строгость оценок, внимание к неявным аспектам, глубина критики и стиль аргументации. То есть влияние конкретной LLM сохраняется — но перемещается на другой уровень. Модель влияет преимущественно на качество интерпретации и форму рассуждения, а не создаёт предметную рамку с нуля.
Это принципиальная разница.
Если знание находится только внутри весов модели, смена LLM означает смену носителя знания. Новую модель приходится заново настраивать, дообучать или подробно погружать в контекст. Если же знание вынесено во внешний структурированный слой, LLM становится заменяемым интеллектуальным исполнителем. Новая модель подключается к той же базе понятий, критериев и отношений и может продолжить работу в общей системе координат.
Такой подход потенциально даёт несколько эффектов:
Снижается зависимость от поставщика модели.
Организация не привязывает свою предметную логику к одной конкретной нейросети.
Упрощается замена и сравнение LLM.
Модели можно оценивать на одной базе знания, не обучая каждую из них заново предметной области.
Знание обновляется в одном месте.
Изменение критерия или связи в структурированной модели становится доступно всем подключённым LLM.
Сокращается потребность в предметном дообучении.
Необязательно помещать всю логику предметной области внутрь весов каждой модели. Часть специализации переносится из обучения в управляемый внешний контекст.
Повышается проверяемость ответов.
Можно проследить, на какие внешние понятия и критерии опиралась модель. Это не делает внутренние рассуждения LLM полностью прозрачными, но позволяет проверять основания ответа.
Мы провели эксперимент: дали четырём разным языковым моделям — Qwen3.8-27B, DeepSeek Reasoner, GPT-5.6-sol и Claude Opus 4.8 — доступ через MCP к одной и той же структурированной модели знания в Онто. После этого моделям была задана одинаковая последовательность аналитических вопросов. Главный результат: несмотря на различия в стиле, глубине рассуждений и способе оформления ответа, все четыре модели сохранили общую предметную рамку и пришли к совместимым по смыслу выводам.
Это важно, потому что обычно значительная часть предметного знания неявно находится внутри самой нейросети. Мы рассчитываем, что модель «знает» необходимые понятия, правильно понимает их взаимосвязи и одинаково интерпретирует используемые термины. Но разные модели обучены на разных данных, используют разные механизмы рассуждения и могут по-разному восстанавливать контекст. Поэтому при смене модели часто меняется не только качество текста, но и сама логика анализа.
В нашем эксперименте система координат находилась не внутри LLM. Она была вынесена во внешний структурированный слой: понятия, роли, критерии и отношения между ними были явно зафиксированы в Онто. В такой архитектуре нейросеть не должна заново изобретать предметную модель. Она получает уже заданную структуру и использует её как основание для ответа.
Получается разделение ответственности:
Онто хранит предметное знание, его структуру, критерии и связи;
LLM находит нужные элементы, интерпретирует их применительно к вопросу и формирует понятный человеку ответ.
Именно структурированное знание становится инвариантом между разными моделями. Можно менять нейросеть, но предметная система координат остаётся прежней.
При этом модели не становятся полностью одинаковыми. В эксперименте часть моделей следовала исходной структуре почти буквально, а часть расширяла её, добавляла собственные критерии или делала дополнительные выводы. Отличались строгость оценок, внимание к неявным аспектам, глубина критики и стиль аргументации. То есть влияние конкретной LLM сохраняется — но перемещается на другой уровень. Модель влияет преимущественно на качество интерпретации и форму рассуждения, а не создаёт предметную рамку с нуля.
Это принципиальная разница.
Если знание находится только внутри весов модели, смена LLM означает смену носителя знания. Новую модель приходится заново настраивать, дообучать или подробно погружать в контекст. Если же знание вынесено во внешний структурированный слой, LLM становится заменяемым интеллектуальным исполнителем. Новая модель подключается к той же базе понятий, критериев и отношений и может продолжить работу в общей системе координат.
Такой подход потенциально даёт несколько эффектов:
Снижается зависимость от поставщика модели.
Организация не привязывает свою предметную логику к одной конкретной нейросети.
Упрощается замена и сравнение LLM.
Модели можно оценивать на одной базе знания, не обучая каждую из них заново предметной области.
Знание обновляется в одном месте.
Изменение критерия или связи в структурированной модели становится доступно всем подключённым LLM.
Сокращается потребность в предметном дообучении.
Необязательно помещать всю логику предметной области внутрь весов каждой модели. Часть специализации переносится из обучения в управляемый внешний контекст.
Повышается проверяемость ответов.
Можно проследить, на какие внешние понятия и критерии опиралась модель. Это не делает внутренние рассуждения LLM полностью прозрачными, но позволяет проверять основания ответа.
Но уже сейчас можно сформулировать подтверждённый инженерный вывод:
внешнее структурированное знание заметно снижает разброс смыслов между разными LLM и позволяет им работать в общей предметной системе координат.
👍3❤2🔥2💯1🦄1
В рамках нашей стратегии Product Ops мы добрались до инфраструктуры продукта.
AI-native команда не может заканчиваться на готовом коде. Кто-то должен провести изменение через окружения, сохранить нужную конфигурацию, доставить правильную версию и проверить результат. Если всё это по-прежнему держится в голове одного человека, значит Ops ещё не стал частью агентского производства.
Мы провели аудит шести контуров и 58 развёртываний Онто, зарегистрировали 30 инфраструктурных дефектов, собрали исполняемый тракт доставки и дистиллировали роль инфраструктурного агента.
Теперь человек задаёт результат и границы операции, а агент самостоятельно проводит изменение до работающего продукта и возвращает доказательства.
Новая статья продолжает историю нашего ящика с умными инструментами — теперь они осваивают Ops.
AI-native команда не может заканчиваться на готовом коде. Кто-то должен провести изменение через окружения, сохранить нужную конфигурацию, доставить правильную версию и проверить результат. Если всё это по-прежнему держится в голове одного человека, значит Ops ещё не стал частью агентского производства.
Мы провели аудит шести контуров и 58 развёртываний Онто, зарегистрировали 30 инфраструктурных дефектов, собрали исполняемый тракт доставки и дистиллировали роль инфраструктурного агента.
Теперь человек задаёт результат и границы операции, а агент самостоятельно проводит изменение до работающего продукта и возвращает доказательства.
Новая статья продолжает историю нашего ящика с умными инструментами — теперь они осваивают Ops.
❤1
«Где у вас цены?», «Что выбрать для небольшой команды?», «А для обычного пользователя MCP включён?», «Можно ли начать с пилота?» — оказалось, что одна таблица с тарифами на все эти вопросы не отвечает.
Поэтому на странице продукта появился помощник по лицензированию Онто. Просто опишите свою ситуацию одной фразой — без анкеты и долгого диалога. Помощник определит подходящий вариант: бесплатное облако, частное облако, on-prem или OEM, учтёт число пользователей, образовательные условия, пилот, Developer- и Runtime-лицензии.
Важная деталь: нейросеть здесь не придумывает цену. Она только понимает запрос и извлекает параметры, а стоимость рассчитывается по зафиксированным правилам. В результате вы получаете итоговую сумму, её составляющие и существенные условия расчёта.
Каждый запрос обрабатывается отдельно, история не сохраняется. Если расчёт подходит, его можно сразу отправить нашей команде и продолжить обсуждение уже предметно.
Попробовать:
https://ontonet.ru/product
Поэтому на странице продукта появился помощник по лицензированию Онто. Просто опишите свою ситуацию одной фразой — без анкеты и долгого диалога. Помощник определит подходящий вариант: бесплатное облако, частное облако, on-prem или OEM, учтёт число пользователей, образовательные условия, пилот, Developer- и Runtime-лицензии.
Важная деталь: нейросеть здесь не придумывает цену. Она только понимает запрос и извлекает параметры, а стоимость рассчитывается по зафиксированным правилам. В результате вы получаете итоговую сумму, её составляющие и существенные условия расчёта.
Каждый запрос обрабатывается отдельно, история не сохраняется. Если расчёт подходит, его можно сразу отправить нашей команде и продолжить обсуждение уже предметно.
Попробовать:
https://ontonet.ru/product
👍3❤1
Всё началось с очень простого вопроса:
«Расскажи об этом пространстве».
На него легко ответить, если пространство небольшое и все участники давно знают контекст.
Но по мере развития Onto появляется другая ситуация: в пространство приходят новые люди, новые агенты, новые модели. И каждому нужно быстро понять — что здесь происходит, зачем это пространство существует и чему здесь можно доверять.
Раньше агенту приходилось собирать такой ответ по косвенным признакам: читать инструкции, смотреть документы, анализировать доступные ему данные и пытаться сложить из них общую картину. Получалось странно: у пространства есть собственная модель, данные, правила и инструменты — но нет простого способа спросить его: «Кто ты?»
Теперь есть. У каждого пространства Onto может быть собственная официальная декларация. Она объясняет три вещи: зачем существует пространство, где проходят его границы и где искать достоверную информацию и нужные действия.
Поэтому новый человек или новый агент больше не должен сначала изучать внутреннее устройство пространства, чтобы понять, как с ним работать.
Можно просто спросить:
«Расскажи об этом пространстве».
И получить ответ не от конкретного агента, не из случайного локального файла и не из догадки модели. А от самого пространства.
У пространства Onto появился собственный голос.
«Расскажи об этом пространстве».
На него легко ответить, если пространство небольшое и все участники давно знают контекст.
Но по мере развития Onto появляется другая ситуация: в пространство приходят новые люди, новые агенты, новые модели. И каждому нужно быстро понять — что здесь происходит, зачем это пространство существует и чему здесь можно доверять.
Раньше агенту приходилось собирать такой ответ по косвенным признакам: читать инструкции, смотреть документы, анализировать доступные ему данные и пытаться сложить из них общую картину. Получалось странно: у пространства есть собственная модель, данные, правила и инструменты — но нет простого способа спросить его: «Кто ты?»
Теперь есть. У каждого пространства Onto может быть собственная официальная декларация. Она объясняет три вещи: зачем существует пространство, где проходят его границы и где искать достоверную информацию и нужные действия.
Поэтому новый человек или новый агент больше не должен сначала изучать внутреннее устройство пространства, чтобы понять, как с ним работать.
Можно просто спросить:
«Расскажи об этом пространстве».
И получить ответ не от конкретного агента, не из случайного локального файла и не из догадки модели. А от самого пространства.
У пространства Onto появился собственный голос.
❤1👍1🔥1
Мы тут привлекли к разработке еще одного из наших фаундеров (@LosiVC ) и вот что получилось
Саша добавил в Онто возможность, которая на первый взгляд выглядит довольно локально: агент может взять уже размещённые на диаграмме объекты и показать существующие между ними связи. На скриншоте он получает один объект, собирает его окружение на два уровня и строит из него связанную диаграмму.
Но для меня здесь гораздо интереснее не сама функция, а способ, которым она была произведена.
Мы постепенно отрабатываем метод подготовки продакт-стюардов, работающих вместе с AI-командами. Продакт-стюард удерживает предметный смысл, границы системы и критерии качества, а AI-команда берёт на себя всё большую часть производственного цикла — анализ, проектирование, реализацию, проверки и интеграцию изменений.
В случае этой задачи сначала было зафиксировано предметное намерение: показать на диаграмме связь между уже существующими объектами. Затем оно было проведено через модель продукта и канонический backend-контракт. В результате одна и та же способность теперь доступна и через REST, и через MCP, но бизнес-логика при этом не размножается: агент не изобретает собственный способ создать связь, а использует те же правила, что и остальные части системы.
Именно это для нас сейчас самое важное. Мы учимся не просто ускорять разработчика с помощью AI, а строить AI-команды, способные производить сложные системы инженерным способом.
То есть масштабируем не количество промптов и не количество AI-фич.
Масштабируем сам способ производства.
А для вас — просто новая возможность в Онто. Можно дать агенту объект, попросить собрать его окружение и показать связи — и через несколько минут получить диаграмму, которую вручную пришлось бы собирать довольно долго.
Выглядит впечатляюще.
Саша добавил в Онто возможность, которая на первый взгляд выглядит довольно локально: агент может взять уже размещённые на диаграмме объекты и показать существующие между ними связи. На скриншоте он получает один объект, собирает его окружение на два уровня и строит из него связанную диаграмму.
Но для меня здесь гораздо интереснее не сама функция, а способ, которым она была произведена.
Мы постепенно отрабатываем метод подготовки продакт-стюардов, работающих вместе с AI-командами. Продакт-стюард удерживает предметный смысл, границы системы и критерии качества, а AI-команда берёт на себя всё большую часть производственного цикла — анализ, проектирование, реализацию, проверки и интеграцию изменений.
Это принципиально отличается от привычной GenAI-разработки, где процесс часто выглядит как бесконечная цепочка «промпт → код → посмотрели → поправили → следующий промпт». Пока задача небольшая, такой режим может быть эффективным. Но с ростом системы он быстро превращается в хаос: логика начинает дублироваться, решения расходятся между интерфейсами, а никто уже не понимает, где находится источник истины.
В случае этой задачи сначала было зафиксировано предметное намерение: показать на диаграмме связь между уже существующими объектами. Затем оно было проведено через модель продукта и канонический backend-контракт. В результате одна и та же способность теперь доступна и через REST, и через MCP, но бизнес-логика при этом не размножается: агент не изобретает собственный способ создать связь, а использует те же правила, что и остальные части системы.
Именно это для нас сейчас самое важное. Мы учимся не просто ускорять разработчика с помощью AI, а строить AI-команды, способные производить сложные системы инженерным способом.
То есть масштабируем не количество промптов и не количество AI-фич.
Масштабируем сам способ производства.
А для вас — просто новая возможность в Онто. Можно дать агенту объект, попросить собрать его окружение и показать связи — и через несколько минут получить диаграмму, которую вручную пришлось бы собирать довольно долго.
Выглядит впечатляюще.
🔥5✍1👍1
Я тут, короче, помогаю одним активистам-экологам. Им нужно по фотографии хвоста понимать, какого именно кита они встретили. Не получить бесценный ответ «на снимке кит», а отличить Стаса от Петра и связать новую встречу с конкретной особью. Для начала у меня было шесть фотографий — не шесть тысяч и не шесть на каждого кита, а вообще шесть.
И я прямо представил, как красиво эту задачу можно продать. Сначала объясняем экологам, что без репрезентативного датасета ничего не получится, поэтому следующие два года они будут фотографировать китов. Потом разметка, команда компьютерного зрения, обучение, эксперименты, инфраструктура — и вот в особенно удачной для подрядчика версии мы уже обсуждаем 100 миллионов рублей. Экологи хотели узнавать Стаса, но теперь у них есть дорожная карта цифровой трансформации, а у Стаса — обязанность обеспечить обучающую выборку.
Я вместо этого потратил три дня на другую постановку задачи. Мне ведь не обязательно учить собственную нейросеть узнавать Стаса, если можно отдельно описать, чем он отличается от Петра. Готовую Vision-модель я использовал как зрение, а в Онто описал признаки и знания о конкретных китах. Нейросеть рассматривает фотографию, система сопоставляет увиденное с каталогом, а пользователь получает гипотезу о конкретной особи и объяснение, на чём она основана.
То есть я не совершил прорыв в обучении нейросетей на шести фотографиях. Я вообще не стал делать обучение собственной нейросети обязательным условием решения задачи. Если у нового кита есть различимые признаки и эксперт может их описать, его можно добавить через знания в каталоге. При этом шесть фотографий, конечно, не доказывают точность на любых снимках: качество ещё нужно проверять на новых наблюдениях. Но проверять полезную систему и два года финансировать обещание когда-нибудь её получить — несколько разные предложения для заказчика.
Меня во всей этой истории интересуют даже не столько киты, сколько привычка IT подменять задачу любимым способом её решения. Человек приходит с вопросом «как мне узнавать животных», а уходит с обязательством содержать вашу ML-команду. И дальше ему объясняют, почему это объективно сложно, долго и дорого, хотя дорогой может быть не его задача, а ваша неспособность посмотреть на неё иначе. Иногда самая ценная работа инженера — вычеркнуть из проекта технологию, которую ему очень хотелось применить.
Я всё ещё считаю, что IT-проекты должны быть дешёвыми в разработке и приносить реальную ценность. Не потому, что труд разработчика ничего не стоит, а потому, что хороший разработчик должен сокращать путь к результату, а не обосновывать длину этого пути. Для этого я и делаю Онто: чтобы предметное знание можно было непосредственно использовать в работающей системе, а не каждый раз заново оплачивать попытку засунуть его в нейросеть. Экологам нужен способ узнать Стаса, а не почётное право профинансировать наши технологические амбиции.
И я прямо представил, как красиво эту задачу можно продать. Сначала объясняем экологам, что без репрезентативного датасета ничего не получится, поэтому следующие два года они будут фотографировать китов. Потом разметка, команда компьютерного зрения, обучение, эксперименты, инфраструктура — и вот в особенно удачной для подрядчика версии мы уже обсуждаем 100 миллионов рублей. Экологи хотели узнавать Стаса, но теперь у них есть дорожная карта цифровой трансформации, а у Стаса — обязанность обеспечить обучающую выборку.
Я вместо этого потратил три дня на другую постановку задачи. Мне ведь не обязательно учить собственную нейросеть узнавать Стаса, если можно отдельно описать, чем он отличается от Петра. Готовую Vision-модель я использовал как зрение, а в Онто описал признаки и знания о конкретных китах. Нейросеть рассматривает фотографию, система сопоставляет увиденное с каталогом, а пользователь получает гипотезу о конкретной особи и объяснение, на чём она основана.
То есть я не совершил прорыв в обучении нейросетей на шести фотографиях. Я вообще не стал делать обучение собственной нейросети обязательным условием решения задачи. Если у нового кита есть различимые признаки и эксперт может их описать, его можно добавить через знания в каталоге. При этом шесть фотографий, конечно, не доказывают точность на любых снимках: качество ещё нужно проверять на новых наблюдениях. Но проверять полезную систему и два года финансировать обещание когда-нибудь её получить — несколько разные предложения для заказчика.
Меня во всей этой истории интересуют даже не столько киты, сколько привычка IT подменять задачу любимым способом её решения. Человек приходит с вопросом «как мне узнавать животных», а уходит с обязательством содержать вашу ML-команду. И дальше ему объясняют, почему это объективно сложно, долго и дорого, хотя дорогой может быть не его задача, а ваша неспособность посмотреть на неё иначе. Иногда самая ценная работа инженера — вычеркнуть из проекта технологию, которую ему очень хотелось применить.
Я всё ещё считаю, что IT-проекты должны быть дешёвыми в разработке и приносить реальную ценность. Не потому, что труд разработчика ничего не стоит, а потому, что хороший разработчик должен сокращать путь к результату, а не обосновывать длину этого пути. Для этого я и делаю Онто: чтобы предметное знание можно было непосредственно использовать в работающей системе, а не каждый раз заново оплачивать попытку засунуть его в нейросеть. Экологам нужен способ узнать Стаса, а не почётное право профинансировать наши технологические амбиции.
👍6👏1
Сергей Трушкин — амбассадор Onto, инженер-системотехник, оргдизайнер и практик цифровой трансформации. Много лет он занимается тем, что нам особенно близко: как превращать знания, данные и цифровые инструменты не в очередной IT-проект, а в реальное повышение производительности.
Недавно Сергей выступил на ВДНХ, в лектории Департамента инвестиционной и промышленной политики Москвы. Говорил про искусственный интеллект, графы знаний и ресурсно-целевое управление — то есть про то, как собрать разрозненные данные и коммуникации в работающую систему управления.
Мне особенно нравится, что Сергей смотрит на ИИ не как на модную технологию, а как на часть производственного контура. Не «куда прикрутить нейросеть», а как изменить сам способ работы организации и помочь людям принимать более качественные решения.
Запись лекции:
https://rutube.ru/video/5f2876ae6d9bab645639c2f991dbf239/
Недавно Сергей выступил на ВДНХ, в лектории Департамента инвестиционной и промышленной политики Москвы. Говорил про искусственный интеллект, графы знаний и ресурсно-целевое управление — то есть про то, как собрать разрозненные данные и коммуникации в работающую систему управления.
Мне особенно нравится, что Сергей смотрит на ИИ не как на модную технологию, а как на часть производственного контура. Не «куда прикрутить нейросеть», а как изменить сам способ работы организации и помочь людям принимать более качественные решения.
Запись лекции:
https://rutube.ru/video/5f2876ae6d9bab645639c2f991dbf239/
🔥4❤1🥰1