Transcription
Если ты занимаешься разработкой и внедрением автоматизации с использованием искусственного интеллекта в бизнес, теперь это не работает. Ну а если хочешь узнать, что именно сейчас работает, то досмотри это видео до конца. Я в этом видео подробно расскажу свои мысли за последние 6 месяцев. Объясню, почему автоматизация больше не работает, и подробно покажу, куда сейчас всё это двигается.
Буквально ещё год назад мне было очень интересно автоматизировать процессы. Пришёл лид, улетело письмо или отправилось сообщение, закончилась встреча, создалась задача, и всё это прекрасно работало. В какой-то момент я понял, что это всё дело как-то слишком мелко, оно недальновидно. И в конечном итоге такие компании, как Openii, Antropi, Google, они создадут свои собственные инструменты. Они встроят их ровно в ту среду, где уже работает бизнес, где уже работают клиенты. Это готовые пользователи, которым нужно лишь дать эти дополнительные инструменты.
Почему же отдельно взятые автоматизации больше не дают результата? Что же делать вместо них? Если вы предприниматель и думаете, как же применить AI всерьёз, внедрить его в свою компанию, внедрить его в свои процессы, а не просто поиграться с CH GPT или с Clot Cor, или же вы разработчик, который занимается вайп-кодингом, делает автоматизация и тоже на этом зарабатывает, то то следующие 10-15 минут именно для вас.
Давайте по чесноку. Почти все начинают плюс-минус одинаково. Берут какой-то процесс, автоматизируют один шаг, например, форума на сайте, попадаюсь в CRM, улетает письмо, приходит уведомление в Telegoo на каком-нибудь NAN или даже уже с вайп-кодингом можно это всё сделать на каком-нибудь Питоне или джаваскрипте. Собственно, смысл один - это просто workкflow автоматизация. Собрать такую цепочку сегодня может вообще абсолютно кто угодно за вечер. И это нормально. Это даёт, в принципе, быстрый эффект. Это создаёт ощущение того, что ты некий вот такой вот автоматизатор, добавил туда ещё агента, который делает сари и всё. Но по большому счёту, это всего лишь-навсего некий пластырь. Мы ускорили всего лишь один шаг. И на этом всё.
Смотрите, тут очень важно различать три вещи. Есть чатбот, любой чатбот, чат GPT, он отвечает в окне, ждёт, пока вы сами чего-нибудь ему отправите. Есть некая автоматизация, некий такой рабочий процесс, который поделён на множество шагов. Это некий жёсткий сценарий, в котором, если если X, то Y, да, там возможны вариации, возможны разветления, и он ломается, как только реальность чуть-чуть отходит от этого сценария. И есть, собственно, AI агент. Он сам принимает решение, он сам выбирает действия и сам его выполняет внутри вашей системе. Вот к агентам, собственно, мы идём. Но чтобы агент работал по-настоящему, ему нужно ещё кое-что, чего у автоматизации нет и быть не может. По крайней мере, в том виде, котором я описал, в виде неких точечных workflow. И какими бы классными не были агенты, которые мы точечно внедряем в том же Workflow, в NA10, тут всё равно вся эта идея ломается.
Проблема ведь не в том, что мы не можем отправить письмо по триггеру или не можем закинуть сообщение. Всё это мы можем. Проблема в том, что система ничего не знает, что она делает, выполняя очередной раз этот самый workкфло. Вот не знает, кто этот клиент. Он не знает, что мы уже ему обещали на прошлой неделе, в прошлом месяце, в прошлом году. не знает, давали ли мы ему скидку, не знает почему, не знает, кто вообще в нашей команде, не знает, кто за него отвечает и кто должен подтвердить этот ответ. Он не знает, какие есть риски, а каких рисков нет. Он вообще ничего не понимает, что делать, если клиент ответит не по сценарию. Можно хоть сколько городить промптов, можно наваливать в базу знаний, в рак, большое количество разных документов, делать кучу разных условий, но это не то, как должен работать агент. Я это называю так. Это AI без контекста бизнеса. Это просто дорогой, если то, то, значит, сделай это с красивым текстом. И сколько таких автоматизаций ты не нагороди, умнее бизнес не становится. И всё это потому, что каждый этот агент, он живёт в своём углу, и ничего они друг про друга толком и не знают. Мы, как разработчики, их программируем, но дальше этих рельс они никуда свернуть не могут.
И вот здесь происходит самое главное изменение. Этот сдвиг, который произошёл конкретно у меня в голове. Я называю это переходом от automation first к context first. То есть старый подход - это триггер, действия, результат. Мы всё это время отвечаем на вопрос, как ускорить этот шаг. А новый подход начинается не с автоматизации, он начинается с ядра. Сначала объекты, события, контекст, правила, решения. И только потом сверху на это всё накладываются агенты со своими действиями. Разница вот в чём. В старом мире автоматизация - это центр всего. В новом - это просто руки. Один из способов сделать что-то поверх ядра. Сначала мы собираем бизнес так, чтобы его понимал агент, а действия уже потом.
Если у вас появился вопрос: "Какого чёрта я вообще про это сейчас говорю?" А всё потому, что агенты упёрлись. Они упёрлись не в модель. Модели сейчас прекрасные, они упёрлись в контекст. Смотрите, три вещи. Первое, у модели ограниченный бюджет внимания. Чем больше ты ей пихаешь, тем хуже она соображает. большой контекст, он деградирует. Есть так называемая смартзона и есть так называемая dumb зона. Зона, когда модель просто тупит. Поэтому промт инжиниринг превращается по сути в контекст инжениринг. Я думаю, что это все уже сейчас понимают. Важно не просто промтик какой-то собрать, а подобрать правильный контекст под каждый шаг агента. Второе. Агенты в бизнесе падают не потому, что модель такая тупая, а потому, что у них нет никаких бизнес-определений или бизнес-ориентиров. Они не знают, где правда, какие должны быть правила использованы, какие есть источники данных и какие данные нужно использовать в тех или иных процессах. Ну и третье, самое важное. Системы хранят данные, но не хранят решения. У вас, например, в CRM записана скидка 15%. А вот почему дали её? Кто её разрешил? На основании чего, с какого перепуга у этого клиента 15, а у другого пять? Этого нету нигде. Это та самая дыра, которую сейчас все и пытаются закрыть. Все хотят персонализации, все хотят, чтобы агенты заменили нам продажников. Но как же это сделать, если ядро, на которое можно опереть такую систему с агентами, его попросту не существует в 99,5% всех компаний. И сейчас многие, понимая это, бросились собирать это самое ядро. Но об этом мы поговорим чуть дальше.
И чего бы вы там не подумали, может быть, это какая-то моя личная фантазия, посмотрите, вот куда идут большие платформы. Они все идут сейчас ровно туда же. Sales Force делает Agent Force и сажает агента не отдельно там куда-то в какой-то отдельный блок автоматизации, а они сажают его поверх своих данных о клиенте. Hubspot делает бриз. Это AI прямо внутри CRM, который тянет историю сделок, тянет переписки. Service Now встраивает агенты в свою платформу. PWC прямым текстом называет это центральной нервной системой для корпоративного AI. Эрнастон Ян раскатывает свою агентную операционку на 400.000 сотрудников. Никто из них не продаёт бота отдельно. Все продают агента, встроенного в контекст компании. Вывод тут очень простой. Если ты не строишь ядро, ты просто поставщик чатботов, и ты очень скоро потеряешь вообще любую ценность вместе со своим продуктом на рынке автоматизации.
Всё это меня привело к формулированию идей бизнес ОС. Я думаю, что уже многие стали замечать, что вот это вот слово ОС, ОС оно очень часто начинает фигурировать и в социальных медиа, и в различных статьях, в блогпостах, даже от крупных компаний. Давайте разберёмся, что же вообще такое ядро. Я его называю бизнес ОС. Это операционная система бизнеса. И сразу скажу, чем она не является. Это не ещё одна сире, это не чатбот, это не автоматизация, это не workflow и это не набор каких-то рандомных интеграций. БизнесOS - это некий слой, где бизнес хранит свои объекты, события, правила, решения, контекст и историю действия таким образом, чтобы и люди, и агенты работали из одной общей картины. И логика тут такая. Сначала мы собираем ядро, которое состоит из объектов, событий, память, правил, прав, решения с полным просматриваемым аудитом всех событий. Потом мы уже поверх него строим интерфейс. Может быть любой, может быть меenger, CRM, dasшборд, а, почтовый клиент. И только потом мы начинаем встраивать туда вертикальных агентов, которые начинают работать в продаже, в поддержке, в финансах, в маркетинге. А абсолютно разницы нет. Самое главное, что у нас есть этот самый контекст. БизнесOS - это, по сути, данные плюс контекст, плюс агенты, плюс процессы, плюс governance, плюс метрики. Никакой ни чатбот, ни RPA, ни дашборд. Это просто единый слой исполнения. execution layer, в котором агенты начинают работать в контексте того, что сейчас происходит сегодня, сейчас, в эту минуту времени.
Если всё ещё непонятно, давайте проще объясним, буквально на пальцах. Вот на примере одного лида. Возьмём один и тот же лид. Просто в двух параллельных мирах. В мире автоматизации лид. Вообще, что это такое? Это просто уведомление. Пришёл лид, напиши менеджеру. Всё дёрнули, забыли. Может быть, чатботик пошёл с ним пообщался на базе промпта, на базе какой-то там базой знаний в раксистеме. В мире бизнес оли - это объект. У него есть источник, у него есть владелец, у него есть статус, насколько он попадает в профиль клиента. Вся есть история касаний, заметки со звонков, возражение, бюджек. Следующий шаг лок решений, статус согласований. И по сути любой агент может это читать, обновлять по определённым правилам. Понимаете, в чём разница? С одной стороны, это просто стикер на холодильнике, а справа - это досье, которое живёт, помнит и видоизменяется во времени. Один и тот же лид, но во втором случае с ним уже можно работать всерьёз.
Из чего вообще состоит ядро? А то я тут говорю бизнес ОС. Ядро, ядро. Что вообще как конкретно? Давайте разберём слои этого ядра. А в его основании состоит контекст компании, кто мы, что продаём, какие у нас есть правила, какие цели, какие задачи. Над ним уже память, это документы, история сделок, переписки. Следующий слой - это агенты, продажи, поддержка, финансы. Это не универсальный и, а это конкретно взятые специалисты со своим набором скилов, со своим набором MCP, со своим набором а прав, разрешений и инструкций. Над ними есть некий дирижёр, который решает, кто что делает и где останавливается на согласование. Дальше есть руки, то есть есть интеграции с CRM, допустим, с почтой, с какими-то ERP системами, там 1S или САП. Без них агент только болтовня. Вот пока нет нормальной интеграции, а в любом формате, лишь бы был доступ к этим данным, это всё просто болтовня. После этого у нас идёт уже governments, то есть это права, это логирование, это подтверждение, это эскалация на человека, если это необходимо. То есть это не просто какая-то обезьяна с гранатой, а это вполне себе полноценная система, как привык работать бизнес. Ну и на самом верху у нас уже есть некая приборная панель: "А что улучшить, на сколько, за сколько денег?" То есть это любой вид взаимодействия с системой, какой удобно. Если у бизнеса есть своя система, где удобно этим управлять и видеть, о'кей, если нет, то агент может сам создать абсолютно любой интерфейс, который будет удобен. То есть интерфейс может меняться, агент может меняться, модель может меняться. Сегодня вышел опус, завтра ведь вышел мифас. Но самое главное, что ядро оно остаётся. Особенно вот этот вот слой решений. Это не просто скидка 15%. А почему дали? Какое-то исключение, кто подтвердил, до какой даты? Это и есть тот самый слой, которого нигде нет.
Я до этого упоминал про вертикального агента. Что это вообще такое? Почему он вертикальный? Вертикальный - это агент, который не универсальный, он не может всем подряд помочь с разными вопросами и запросами. А это очень такая узкая роль. Это очень конкретный специалист. Это агент, который может, например, только квалифицировать лидов, только собирать разные предложения. агент сортировки обращений или, например, агент проверяющих счетов, агент по фолоапам после встречи, агент по утренним брифингам для собственника бизнеса. Ну вот что-то такое. И у каждого такого агента есть очень чёткая рамка. Он знает, какие объекты ему доступны, какие интеграции у него есть. У него есть свой собственный набор скилов. он понимает, какие события он может создавать, какие решения он может предлагать, что он может сделать сам, а где обязан позвать человека обязательно и как он, собственно, за это вообще отчитывается. И, наверное, самая точная в метафора была бы это один агент - это один сотрудник с ролью, доступами KPI, с руководителями, а не универсальной волшебной Ии.
А теперь ключевой момент про архитектуру, на котором вообще большая часть всех внедрений ломается. Как вообще делать плохо, если хотите знать, моё мнение, по крайней мере, каждому агенту можно дать свою память, свои правила, дать ему доступы. На старте вроде кажется очень быстро, вау, эффект достигнут, все хэппи, но потом начинается сущий ад. Продажи обещают одно, доставка знает другое. Поддержка не видит коммерческих условий, финансы не понимают, почему дали скидку. Ну а собственник вообще не видит единой картины. Есть куча каких-то тараканов, которые делают каждый как маленькая белка в колесе, какую-то свою работу. Вроде бы как бы автоматизировано, но нету общей единой какой-то цельной картины. 10 агентов - это, по сути, 10 фрилансеров, у которых нету вообще никакого менеджера. И как мне кажется, нужно по уму сделать это одно ядро снизу основа, то есть то самое ядро, о котором я говорил ранее. Объекты события, память, правила, решения, права, всё это здесь есть. А сверху вертикальные агенты, и они все работают из одного и того же контекста. Агенты разные, ядро одно. Вот тогда это не зоопарк, а вполне себе нормальная компания, где у каждого есть роль. Есть кожаные сотрудники, а есть и и сотрудники. И у тех, и у других есть и доступы, и общий источник правды.
Покажу простой пример для понимания. Например, вот sales followup. Обычная история. Вот как было. Д приходит через форму, например, менеджер видит уведомление минут через 40, открывает CRM, гуглит компанию, копирует пару фактов, пишет ответ руками и забывает всё это поставить в FUP. Через неделю лит остыл и всё это дело было впустую. А как же это может быть, когда сверху ядра стоит агент, ли падает и сразу становится объектом. За 2 минуты агент сходил на сайт, погуглил, нашёл что-то в LinkedIn, нашёл что-то в открытых источниках, понял контекст, например, образовательный центр, восемь филиалов, ещё цел за, значит, это активные продажи. Оценил, насколько лид подходит, может подготовить персональный ответ и двинуться на следующий шаг. Если нужна скидка или обещание, он не отправляет сам, а создаёт запрос на согласование. Решение пишется в логе. Follow поставлен. Задачка в CRM создана. Собственник всё это видит на утреннем брифе. Ну 40 минут превратились в две. Менеджер не пишет с нуля и ни один вид не теряется. Вот в этом и есть вся разница. Возможно, это не самый оптимальный пример, но это просто один из примеров, когда агенты работают и настроены правильно. Они всегда в контексте.
Возможно, у многих возникнет вопрос. То есть AI сам всё решает и всё это сам отправляет и скидки даёт. На самом деле нет. И это очень принципиальная разница. Цепочка всегда такая: агент предлагает ядро записывает, человек отобряет, ну, какие-то самые высокорисковые моменты, инструмент исполняет, а ядро логирует результат. Три роли: агент, исполнитель и аналитик. Он не владелец правды. Ядро является источником правды. А человек- хозяин рисковых решений. Именно за ним последнее слово. Автономность мы задаём явно по уровням. На нуле агент только подсказывает. Дальше готовит черновик и отправляет человек. Ну а следующий уровень - это когда человек жмёт кнопку согласовать и пошла автоматически. Если готовы ещё дальше, то агент сам делает мелкие безопасные действия по правилам. И всё, что серьёзно, цена, договоры, юристически. Цена, договоры, юридические моменты, найм, деньги, никогда без человека. Ну, по крайней мере, пока. То есть живой, в кавычках, агент, он действительно может менять мир. Он может создать документы, записать в одинску, отправить письмо, но только через согласование и аудит. Без этого одна автономная ошибка может стоить вам э доверия. И на этом всё.
И вот какой вопрос может быть следующий. Тимур, ты, конечно, молодец, но это всё звучит как какие-то заоблачные космические компании, у которых триллионные обороты, и всё это не про нас. И нам тут делать нечего. Мы маленький свечной заводик автоматизировали, сделав ему чат ботика в Телеграме, и на этом все счастливы. Но на самом деле нет. Минимальная вот ядро, оно буквально на коленке может собираться на том, что уже есть, ну, Notion, Air Table, Google Sheets, вот хотя бы какая-то база. Что для этого нужно? Первое - это просто некая таблица объектов. Лиды, клиенты, сделки, задачи, встречи, решения. Второе - это лог событий. Каждое важное действие, его надо просто записать. кто, когда, по какому объекту, какой был результат. Третье - это лог решений. Это какие были скидки, какие были исключения, согласование, риски, почему так, а не сяк. Четвёртое - это простой файл правила, что агент может сам, а что только черновиком и требует согласования с человеком, что вообще ему трогать нельзя. Пятое - это некий такой инбокс агента. Агент не делает всё напрямую. Он создаёт предложение, человек одобряет его или отклоняет. Ну и шестое - это ежедневный бриф. Что изменилось? Где застряли? Где что ждёт согласование? Седьмое - это агент сверху. Не 10, а один. Например, тот самый followup агент. Один агент над одним процессом. Получается так, что мы начинаем с одного процесса, потому что ядро наше охватывает этот процесс. И чем больше ядро охватывает процессов, тем больше мы можем нанять тех самых агентов, сотрудников, которые уже будут работать внутри контекста.
Я вот тут подумал, как же вообще подойти к этому вопросу. С одной стороны, хочется написать просто какое-то коробочное решение и всем подряд его накатывать, но мне кажется, это такой вариант не очень рабочий. Получится какая-то коробка условным GPT. И вот выкатываешь её и говоришь: "Теперь у вас всё автоматизировано". А второй вариант - это каждый раз для нового клиента всё писать с нуля. И всегда кажется, что это самый лучший путь, потому что у нас всё очень индивидуально и хочется очень много денег получить за такую разработку. Но на самом деле не так много клиентов готовы за это платить. Все хотят рабочее, надёжное решение, при этом у которого было бы и сбалансированная цена, и сбалансированная скорость. Мне кажется, что это оба варианта не самые оптимальные. Я поизучал эту тему, и мне приглянулся очень путь, по которому пошёл палантир. Третий путь, который они придумали, называется Forward Deployed Engineer. Инженер, который развёрнут на передовой, то есть непосредственно внутри клиентского бизнеса. Идея там такая: инженер, он не сидит в офисе вендера, то есть у нас в офисе. Он приходит вовнутрь бизнеса, приходит к клиенту в его реальные данные, в его реальные процессы и доводит до результата под конкретную боль. Не продал и ушёл. Не мы здесь сами всё автоматизируем и вам внедрим, а конкретно там на месте он прямо встраивается туда. И мне кажется, что именно благодаря такой моделир как раз-таки и вырос именно в этом направлении. Антология в центре у них, а инженеры, собственно, на местах. Есть один нюанс. У палантир это супер дорого, поэтому далеко не всем это по карману. Это, наверное, только гигантские компании могут себе позволить такого вендера. А вот мой вариант разворота модели - это FDE на местах плюс иагенты как мультипликаторы. То есть агенты делают черновую интеграцию, предлагают объекты, генерируют сценарии, а человек-инженер просто курьрует и закрывает последнюю мелю. То есть то самое доменное знание, которое машина никак вот сама по себе не угадает. И ещё одно отличие от палантир, у них сверху ядра некое приложение, которое надо ещё вообще собрать. А у нас сверху это агенты. Это и дешевле внедрять, и нет какого-то потолка. То есть сначала кто-то должен построить дашборд. На самом деле нет. В случае, если дашборд очень нужен, его может построить сам агент. В итоге получается некий класс полантира по контексту, но, конечно же, не по цене, потому что её не потянет средний бизнес в СНГ.
Так вообще технически всё это происходит. Мы не приносим пустой лист, мы не приносим какую-то жёсткую коробку, мы приносим некий такой полуфабрикат, то есть заготовку ядра, у которого уже есть точки забораго самого контекста, то есть коннекторы. Коннекторы для CRM, для ERP системы, для мессенджеров, для календарей, для 1S, для СА, для Oracle, то есть большое количество коннекторов, то есть некий такой скелет, на который уже конкретный бизнес садится очень быстро, потому что эти системы уже внедрены и работают. Инженер не пишет коннекторы с нуля, он просто подключает всё это и настраивает. И здесь ещё очень важный принцип. Коннектор - это не комдити, их полно. Это не наша ценность. То есть можно даже найти open source, ценность в антологии и сценарий, который поверх этого всего. Поэтому коннекторы берём готовые, а силы вкладываем, собственно, в само ядро. Под капотом каждый источник отдаёт несколько потоков: структуру, объекты и связи, поток изменений, чтобы агенты реагировали на события и некие неструктуированные там договоры, письма, комментарии, разного рода артефакты. Самое главное - это стабильная идентичность и прослеживаемость или обозреваемость. Не знаю, как тут лучше даже сказать. То есть от любой генерации агента можно провалиться до документа источника. Есть такое слово треacing, наверное, здесь применимо. Это, собственно, и есть та защита от галлюцинаций. Всегда можно отследить, с чем агент работал.
Дальше, когда контекст подключен и ядро наполнено, инженер разворачивает поверх него вертикальных агентов. под конкретные процессы клиента. Это не какие-то абстрактные демки, это вполне себе конкретные агенты на живых данных. Алоп по продажам, сортировка обращений в поддержку, обработка счетов, документы и какие-то кокпиты для собственника, дашборды под реальную боль, которую мы увидели на диагностике. То есть это та самая тонкость, ради которого всё это и делается. Инженер настраивает агента для того, чтобы он корректно выполнял эти сценарии. Ценность по сути не в платформе вообще. Она в конкретных отработанных сценариях уже на реальных болях клиентов. А агент по сути получает не голый доступ к базе с возможностью писать любые запросы, а вполне себе аккуратный заземлённый набор инструментов поверх своего же собственного ядра. Это и безопаснее, да и предсказуемее.
И самое интересное, что система она нестатичная, она постоянно дописывает сама себя. Вот смотрите, ядро накапливает контекст, события, решения, и агенты на этом учатся. Уточняют правила, расширяют сценарии, улучшает свои скилы. То есть даже саму антологию, то есть структуру бизнеса, агенты собирают автоматически. То есть они берут какие-то метаданные из EURP системы, например, там 1С или сиремки, и предлагают черновики. То есть человек только курьирует смысл и действия. Сверху всего этого живёт то, что я называю слой. Он раз в неделю смотрит, что выиграли, что проиграли, какая маржа, какие сегменты, обновляет плейбуки, цены, скилы. То есть компания из неких наборов проектов, а или разрозненных каких-то автоматизаций, она превращается в такую вот систему, которая сама себя улучшает. Ну и сразу сниму возражение, потому что я уже слышал это не раз, когда делился этой информацией с людьми. Что касается самонадстройки, то есть это не просто э делает, что хочет. Всё идёт через те же согласования, через права, через аудит, про который я ранее говорил. То есть, по сути, каркасы границы задаёт человек. Внутри границ система достраивается уже сама. То есть некий selfimoving, но под контролем.
Ну и последнее, самое, наверное, интересное - это про деньги, про модель оплаты, потому что она тут принципиально другая. Ты платишь не за то, что тебе настроили какие-то workflow, сценарии, внедрили автоматизации. Ты платишь за вполне себе конкретный результат, за закрытые лиды, за сокращённое ручное время, за обработанные обращения. Риск смещается на исполнителя, а значит, клиенту гораздо легче сказать да. И это автоматически отстраивает нас от разных код агентств, откодиагентств, которые могут продавать за Fix Price не самый лучший продукт или продают себя по часам. И, кстати, это ровно та же логика, которую YC сейчас проповедует для AI сервисных компаний. Продавай результат, а не места, не токены. Пилот - это есть продукт. То есть процесс - это и есть продукт. И принцип, который я считаю честным, если мы не измеряем себя, мы не имеем права продавать измерения. Тот же рой, который мы обещаем клиенту, мы сначала считаем его на себе.
Если из всего этого видео, которое непланово у меня затянулось, взять лишь одну единственную фразу, то она будет такая: "Автоматизация делает действия, ядро бизнеса хранит понимание, и агенты становятся по-настоящему полезными только со вторым". Мне, на самом деле, больше абсолютно неинтересно строить просто автоматизацию. Они ускоряют отдельные шаги, но не собирают мозг компании. Интереснее собрать ядро. кто клиент, что произошло, какие решения приняты, что можно агенту, а где всё-таки нужен человек, и уже поверх него собирать агентов по продажам, по поддержке, по финансам, абсолютно любых. Агент Безидра - это умный сценарист. Агент Поверх Бизнес ОС - это часть операционной системы компании.
Если вам это откликнулось, обязательно ставьте лайк, и я разберу уже живое демо такого ядра в следующем видео. Ну а в комментах напишите, что думаете, согласны ли с моими тезисами по поводу Бизнес УС ядра или всё-таки будем пилить по старинке автоматизации? Увидимся в следующем видео. Пока.
[музыка]
Life whispers as the circuit home.