Онто.

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

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

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

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

Почему сложный софт нельзя собрать одной волшебной командой

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

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

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

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

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

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

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

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

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

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

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

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

Новая статья: «От модели бизнеса к работающему ассистенту: практический рецепт».

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

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

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

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

Я снова программирую! Или нет?! Сразу и не разберешь.

Скорее наблюдаю, как программирует команда ИИ-агентов.

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

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

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

Артем Варкулевич, основатель Онто - описал практический ответ в двух небольших статьях:

«Общие коллеги: как люди и агенты работают в одном пространстве»
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

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

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

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

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

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

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

Если перестать рассчитывать, что опытный руководитель «на месте разберётся», что останется от процесса?

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

И тут обнаружилось неожиданное: отдельная методология управления агентами нам не понадобилась. Сработали Agile, Scrum, Lean, Kanban, Team Topologies и разделение полномочий — просто с агентами эти принципы пришлось применить буквально.

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

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

«Общие коллеги: как люди и агенты работают в одном пространстве Онто»

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

Ну вот и место Онто определилось ))

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

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

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

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

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

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

Важное изменение в развитии AI-возможностей Онто.

Мы постепенно отказываемся от OntoAIGPT и встроенных AI-возможностей в чате объекта. Это не отказ от работы с ИИ — наоборот, мы переносим её в более универсальный и управляемый контур через Onto MCP.

Встроенный чат был полезен как первый способ познакомить пользователей с работой AI внутри модели. Но сегодня у большинства уже есть собственные агенты в Claude, ChatGPT, Codex, Cherry Studio и других средах. Логичнее не создавать ещё одного отдельного помощника внутри Онто, а дать вашему агенту полноценный доступ к знаниям, объектам и связям пространства.

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

Переходить можно с очень простой команды:

«У тебя подключен Онто. Научись с ним работать — и меня научи».

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

Bootstrap-as-Memory: когда объект получает право возражать

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

Но в такой архитектуре обычно отсутствует тот, кто представляет интересы одного конкретного объекта.

И вот как агентская память в Онто становится бутстрапом агента конкретного узла читать

Что такое хорошо документированный процесс разработки?

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

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

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

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

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

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

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

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

Хорошая документация — это не текст о системе. Это способность системы объяснить саму себя и позволить любому участнику пройти путь от действия к смыслу и обратно.

Не пропустите нашу методику документирования системы. Мы ею обязательно поделимся.

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

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

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

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

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

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

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

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

Цвет и иконка здесь становятся не украшением, а частью навигации по знанию.

Выпускаем новую фичу в Онто: управление шаблонными связями прямо в табличном редакторе.

У этой истории есть сразу несколько слоёв, и все они мне очень нравятся.

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

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

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

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

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

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

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

В итоге получилась фича про таблицы, но на самом деле это снова история про Онто.

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

Теперь связи в Онто можно создавать и чистить прямо там, где многим пользователям привычнее всего работать — в таблице.

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

Гибридные команды и слой агентской памяти

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

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

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

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

Раньше всё это неизбежно попадало в общие чаты. Люди обсуждали смысл задачи, а рядом лежали ссылки, ID, куски спецификаций, технические пометки, версии решений и уточнения для следующего исполнителя. Через какое-то время человеческий разговор начинал превращаться в смесь мотивации, постановки, переписки с разработкой, архива ссылок и технического журнала. Сейчас я стараюсь разводить эти тракты. Мотивация, эмоции, смысл, договорённости и управленческий импульс остаются в человеческом общении. А техника, знания, решения, контекст, идентификаторы и следы работы оседают в слое агентской памяти.

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

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

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

Исследования по работе людей с AI показывают похожую вещь: эффект появляется не от самого факта наличия модели, а от правильного распределения ролей между человеком и AI. В исследовании NBER о генеративном AI в поддержке клиентов AI-ассистент заметно повысил производительность сотрудников, особенно менее опытных, потому что помогал им быстрее перенимать рабочие практики более сильных коллег [1]. А исследование HBS и BCG про “jagged technological frontier” показало, что AI может резко усиливать человека в одних задачах и ухудшать результат в других, если человек не понимает границу применимости инструмента [2]. То есть дело не в магии AI, а в архитектуре совместной работы.

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