Как внедрить AI Chief of Staff в команду: кейс TeamOS + Robin transcript

Сегодня я покажу, например, там скилы, которые мы в рамках вот TeamOS сделали, и там поширю с вами, как такие же скилы сделать для себя. И забавно ж, если так получится, что всё институциональное знание, которое есть у нас как команд, это всего лишь ээ ну какой-то набор текстовых файлов с скилами и там ещё некоторыми вещами. это эагент, который присутствует во всех наших чатах и, а, уходит на все наши митинги, читает все репозитории, а, и, соответственно, помогает отвечать на вопросы. То есть ты иногда не отдаёшь себе отчёт, что в твоём как бы в твоих репозиториях, в твоих MCP и так далее уже есть куча данных, чтобы инициализировать первую версию вашей а TeamOS. как проверить ценность вашего как бы тимэса. Вы берёте агента, у которого есть это, ну, доступ к репозиторию вот этому Team и у которого нету, и даёте ему одну и ту же задачу. >> По крафту достаточно всё просто. Сложность - это заставить людей рассказать, что и как они делают. И в одиночку вы это дело не вытянете. Вам нужен будет процесс, вам нужны будут последователи, вам нужно будет максимально собирать знания из всех возможных мест и источников. У нас был было обсуждение в одном чатике, где, ну, там мы делаем, планируем рассылку, имеilл-рассылку, и понятно, что, а, копирайтинг, ну, у нас небольшая компания, у нас нет отдельных людей, которые делают копирайтинг и, соответственно, а, проверяют все тексты. Поэтому обычно это такое коллективная работа и аа по письму и потом вдруг для себя понял, что в целом а это должен быть скил. А, то есть скил в терминах агентов, агентский скилл, а, клодкод, неважно, а, который, грубо говоря, собирает все гайдлайны сш, знаете, такие негласные правила, как писать тексты, как мы хотим писать тексты в докумен в наших всех на всех продуктовых поверхностях. и родился скилл. А я его запилил, пошерил с командой, и мы его применили сразу же к одной из задачек и нашли очень интересные штуки, где у нас там одна один из терминов, а, использовался одна и та же концепция называлась двумя разными словами. Из-за этого мог быть могла быть путаница. И подводя к нам к сегодняшней теме лекции, одна из задач, э, а, вот, связанная с - это подмечать, какие повторяющиеся, а, процессы или, э, решения или чек-листы возникают в команде. И чтобы и, грубо говоря, разгрузить себя как botlк, да, которая ну потому что условно другие а коллеги не обладают, например, той компетенцией или той тем знанием, которое есть у вас, а и ждут вашего ответа, ваши ваших комментариев по какому-то результату работы, а разблокировать себя и всю работу через вот такие повторяющиеся аа скилы какие-то. какие-то задокументированные правила. Играет в эту интересную роль. Ну, во-первых, понятно, скилы как концепция это по сути повторяющийся процесс, но с другой стороны, что он помогает замечать, подмечать, вытаскивать э процедуры принятия решения или процедуры, критерии и качества из перегово из транскриптов и переговоров, которые есть в команде, и вытаскивать их в такое институциональное знание. Для меня это был инсайт. Сегодня я покажу, например, там скилы, которые мы в рамках вот TeamOS сделали, и там поширю с вами, как такие же скилы сделать для себя. из такого интересного, наверное, прямо свежего инсайта было, что условно, а, какой-то AI процесс AIG должен сканировать, э, наш, ну, наши все разговоры, неважно каким образом, да, там это Telegram, это разговоры на звонке и так далее. Соответственно, они должны сканировать эти, э, разговоры и то, что происходит в команде, и подмечать а вот такие кейсы, точки, где проявляется какое-то решение или проявляется какое-то атет знание, да, внутреннее знание кого-то из команды и, соответственно, вытаскивать и институционализировать его, экстернализировать это знание в виде вот таких скилов. И забавно, если так получится, что всё институциональная знание, которое есть у нас как команд, это всего лишь ну какой-то набор текстовых файлов с скилами и там ещё некоторые вещами. Один из вообще пунктов моих будет сегодня, что TeamOS - это не про индивидуальные скилы и компетенции, а это про разблокирование работы благодаря тому, что то, зачем часто обращаются одни сотрудники к другим сотрудникам, должно стать вот таким некоторым, а, институциональным знанием. Ну и да, может быть, мы просто набор мы cl набор таких файлов. Ну, посмотрим сейчас у меня там, я думаю, когда мы дойдём до практической части, будет понятно. Я тут недавно проводил тренинг для там крупной компании и вообще удивился, насколько вот там какие-то понятные штуки по работе с Клодом, про которые мы говорим там, не знаю, с начала года, наверное, этого, может, с конца прошлого, они пока ещё не э долетели до крупных компаний. И когда ты просто даёшь, э, вот это понимание, что AI может, грубо говоря, работать с твоими файлами и работать с твоими, э, с твоим компьютером, достаточно просто показать пару кейсов и дальше, а, участники просто сами придумывают все кейсы из за условно 2 часа, показав вещь, через неделю тебе рассказывают, какие штуки они уже автоматизи ровали благодаря там Клоду, курсору и же с ними. И ты понимаешь, насколько разблокирует многие вещи такой инструмент. И я всё больше и больше возвращаюсь к работе. Я не знаю, читали ли эту работу, вкратце, AI - это лампочка или микроскоп? И давайте, кстати, я сейчас расскажу идею, а вы скажете, что вы думаете, это лампочка или микроскоп. В общем, была такая работа, суть которой очень простая. А что лампочка, когда появилась, она повысила производитель нас как людей. А потому что условно мы смогли читать книги по ночам, мы смогли работать цех цеха смогли работать по ночам. Соответственно, это повысило производительность нас как людей. Но после вот такого прыжка производительности, которого он благодаря лампочке мы достигли, в целом все в итоге стали одинаковы. То есть, грубо говоря, да, в некотором периоде был момент, что одни люди, условно пользовавшиеся лампочками и компанией, были более производительны, чем другие. Но постепенно, когда все адаптировали лампочки, производительность поднялась на определённый уровень и дальше не двигалась. что AI - это инструмент, позволяющий создавать новые инструменты повышения производительности. А микроскоп, мы смогли там условно видеть бактерии и после этого начали формулировать, допустим, ряд, ну, условно, пинс, которые решали ряд болезней, которые до того, как мы это не видели, мы не могли как бы их решать. И поэтому, грубо говоря, это инструмент создания новых инструментов повышения производитель, инструмент создания новых лампочек. Вот, как вы думаете, можно в чате проголосовать. И а - это лампочка или микроскоп? Яр сегодня вкратце расскажет про внедрение AI, поскольку мои кейсы будут в основном на уровне там команды из пяти человек. И для кого-то из вас может показаться, что это там, ну, не совсем адекватный пример. И как раз Гаяр расскажет, поделится своим мнением и опытом внедрения в побольше а компанию и департамент, в частности, в одной компании и поделится этим. Так, Андрей, что люди поделятся на тех, кто, аэ, как бы будет воспринимать AI на как лампочки это или микроскопы. О'кей, хорошо. А, Сергей, да, вот и Antropic, и Open AI, ээ, публикуют, э, ряд, э, скажем так, статей и результатов, когда видно, что, в частности, тот, который пошерил сейчас Сергей, а, которые показывают, что AI может, э, создавать сам себя, а, и так называемый self-иovмент происходит. вообще один из основателей э антропика а где-то, наверное, недели три-четыре назад написал статью в своём блоге. Я про него часто рассказываю, Джек Кларк, а про то, что там с вероятностью, по-моему, 60% он дал вероятность, то в, по-моему, до двадцать восьмого года, а, AI сможет создавать, ээ, следующую следующее поколение моделей. Можем потом поразмышлять и поделиться мнениями. Но в целом, да, Сергей, поддерживаю, что вот как раз если мы увидим кейсы, а, типа такого, где, аэ, создание новой модели делается не людьми, а, а, ам, это, конечно, про микроскоп однозначно полностью а поддерживаю. В дополнение к этой статье а рекомендую а вот этот subбstack аport AI он называется вот этот сабstaк Джека Кларка и у него есть вот из а вот а в мае 4 мая вот в этом выпуске он как раз писал про шестидесятипроцентную вероятность в двадцать восьмом году будет создавать и он после этого если кому кто не очень очень текстом. Он после этого выступал на в одном институте. Вот вот это космос. >> А, и он там показывает, как это, как это он видит. Там есть слайды, ээ, вот давайте я его покажу. Вот этот слайд ключевой, где я, собственно, вот как раз видите, э там автономные компании системы вот в двадцать восьмом году я системы, которые э создают сами себя. Очень интересный вообще сабстек я рекомендую а следить. О'кей, давайте тогда начнём. У нас сегодня план такой, это будет, ээ, скажем так, у встречи будут два, наверное, таких больших раздела. Первый раздел - это я расскажу, завём это так, теорию. Я бы не сказал, что вот это прямо теория, но некоторая рефлексия по поводу внедрения AI на уровне команды и вообще зачем. Вот. Аа потом мы посмотрим вот поделится своим кейсом, я поделюсь своим кейсом, а, и мы посмотрим на какие общие и, может быть, разные аспекты и взгляд на AI у, а-э, как бы в внедрении в разные в разного размера команды, компании, департаменты. И вот это, наверное, две большие штуки, которые мы посмотрим: теория и практика. Сразу говорю, не претендую, что это правильно. Шерю, как я про это рефлексирую и почему я пришёл к такому выводу, к таким поинтам. И поскольку это всё ongoиing процесс, то есть, может быть, завтра появится что-то новое, я думаю, что мы будем потихонечку обновлять и может быть я когда-то сделаю дополнительную версию этого. Но в целом основное основная моя мысль, что мы с вами в начале года говорили про то, что как использовать клод-код для своей производительности. И я надеюсь, что большинство из вас знакомо с концепциями скилов, с концепциями агентов. Я сразу говорю, что я так не буду с нуля это объяснять. Но что я почувствовал достаточно, ну вот условно где-то, я думаю, в феврале на себе, что моя производительность достаточно сильно повысилась, я могу, а ну делать какие-то вещи гораздо быстрее, но это не особо повысило производительность команды. И поэтому я стал думать: "О'кей, а что такое внедрять, э, на уровне команды AI и сделать вот эту Team O? Если честно, то я пришёл, что в целом это, наверное, самое важное из Steam O, что это просто некоторое институциональное знание, оформленное в наборе аа условных файлов. По-простому это фолдер или репозиторий, в котором есть набор текстовых файлов. Я вам покажу, а наш пример не в том, чтобы как бы этот, а как, во-первых, создать первую версию этого фолдера, этого репозитория, а второе, как обеспечить, чтобы это знание постоянно, а, ну, как бы обновлялось с тем, когда мир или ваша команда меняется или продукт, и как обеспечить вот это пополнение постоянное а этого репозитория. В этом, на самом деле, а ключевая задача. Поэтому, э, центральный тезис, что это просто база знаний, которая постоянно себя, э, как бы компаундится, да, то есть она себя улучшает. А, собственно, центральный тезис - это просто репозиторий знаний. И ключевая задача, а, создать обеспечить процесс создания первой версии этого репозитория и последующего постоянного пополнения обновления. И возникает вопрос: а как я пойму, что мой работает? Да? То есть вот как я пойму, что этот репозиторий полезный? И как я не думал, а по этому поводу на этот вопрос, я понял, что до того, как я создам какого-то агента, который будет типа нашим тиммейтом, то есть это эагент, который наравне с людьми использует вот этот репозиторий, а для того, чтобы разблокировать людей, то есть помочь людям. И поэтому встал вопрос, что, ну, должна появиться какая-то концепция, какая-то форма агента. И что это за агент? Потому что в основном, когда рассказывают про, а, ну, там, э, агентов в командах, это, эгент, например, для разработки какой-то фичи, для кодревь, а, ещё что-то. И очевидно, что самый главный эагент, и кто следит за каналом, конечно, знает, это Робин. То есть это наш чифов став, э, который наравне с людьми существует во всех наших общих активностях и как я вам сейчас покажу, делает определённые задачи. И вот в апреле я его запустил в компанию. То есть вот я сказал в феврале, марте я стал думать, ну типа моя личная производительность растёт, общая не растёт, как это оформить. Пришёл к тому, что а нужен какой-то агент, который разблокирует меня. И, собственно, поэтому первая версия ТЗ, назовём это так, к Робину, она возникла очень просто. Что по каким вопросам мы, ну или ко мне обращаются постоянно, а мои коллеги, у нас пять человек, поэтому четыре, а коллеги, и, соответственно, э могу ли я эти вопросы переадресовать агенту и благодаря этому делать это лучше, быстрее, не быть вот это вот этим как бы узким местом. И в целом, Робин работает. Э, я сейчас расскажу ключевые юзкейсы, но кто не читал и не знает. Это эагент, который присутствует во всех наших чатах и, а, ходит на все наши митинги, читает все репозитории, а, и, соответственно, помогает отвечать на вопросы и делать определённые это. Да, чаты в телеге в нашем случае, а, и я сейчас буду показывать, это чаты в телеге. Я ещё расскажу, какие другие м поверхности, в которых он присутствует, и каким образом он это всё интернализирует и потом а пополняет вот эту базу э знаний. Какие основные кейсы, а, у Робина, которые вот по частоте использования? Первые - это, я бы сказал, это кейс, а, аналитический, то есть дай мне расклад по пользователю. То есть очень часто, например, мы можем в чатиках обсуждать какого-то юзера, ну, потому что кто-то за зарепортил, ну, какой-то использователь зарепортил проблему или ещё что-то. И мы хотим, чтобы Робин дал полную выкладку. И что, какова какая красота этой выкладки в том, что, во-первых, в общих чатиках достаточно его, да, затегать как бота. А с другой стороны, у него есть доступ не только к аналитическим системам. Тут, видите, это prodдаction баз данных, у него read доступ, понятно? -э Google Analytics и Long Fuse - это система, в которой трекается поведение наших эагентов, которыми пользуются кастомеры, потому что, ну, мы должны понимать там, а, трейсы происходящие. Вот он собирает всю эту информацию, выдаёт, э, а, ответ в телеге и самое главное, что сопровождает этот ответ ссылками на а все эти источники. Если вдруг, ну, например, если возникла какая-то проблема, то так легко, допустим, сразу линк на lfuse trace. И, например, Лёша, когда, чтобы изучить, где агенты пошли не так, он просто нажимает на этот трейс, изучает его и идёт дальше. Второе - это оценка value продукта, то есть кейс одного из пользователей и его поиска клиентов в по одному из регионов. Но основная идея в том, что, э, зачастую обращение к к Робину заключается в том, что мы спрашиваем не что сделал, да, не что делал юзер, а насколько результат, которого юзер, который юзер получил, был адекватно или нет. То есть он не столько аналитик, сколько ближе такой помощник продукта, который оценивает ценность. Третье. Неожиданный кейс, не такой частый, но неожиданный для меня был, когда а наш бэкэндер вернулся с из отпуска. Первое, что он сделал, он спросил Робина, типа, вот я был на в отпуске, что случилось, пока меня не было, что самое важное я должен знать. И поскольку Робин был и на митингах, и во всех чатиках, он, соответственно, это знает. Четвёртое. Зачастую, поскольку небольшая компания, мы, а, какие-то дизайнрешения можем обсуждать в дизайн-чатике. И, соответственно, в этом чатике, э, например, у нас было обсуждение, оптимизировать ли экран под мобилку. По умолчанию понятно, все уважающие себя дизайнеры и разработчики, они, мм, ну, как бы адаптируют сразу под все экраны, но в B2B тулах mobile занимает обычно меньше 20 25% использования. и на раннем этапе оптимизировать продукт и менять продуктовые решения из-за того, что это будет не очень на а мобилке, это, ну, не совсем правильная позиция. Поэтому, допустим, а кейс, который у нас был, а он мы обсуждали, вот кто-то поднял вопрос в стиле: "Блин, а как это будет смотреться на мобилке?" И, соответственно, Оксана задала вопрос Робину, типа, а вообще какая доля наших пользователей пользуется мобилкой? Нам получила ответ, и из этого это повлияло на приоритизацию. И чуть попозже посмотрим, что вообще аа решения, которые принимает команда коллективно, это тоже классный источник, а знания вот общего институционального, которое можно засунуть в, а, в вот в этот и тем самым обеспечить, чтобы какие-то решения принимались или а быстрее, или более качественно, и так далее. Сейчас посмотрим. Ну и последнее, что у нас есть, понятно, митинги, например, а митинг и а Робин участвует в этом митинге участник, да, типа тиммейт. Правда, он не болтает, но может отвечать на вопросы, которые ему задают, потому что зачастую бывает, как вы обсуждаете что-то, а на звонке, в этот момент возник какой-то вопрос, и кто-то начинает лезть в базу, в логи, и это занимает кучу времени. А тут мы просто спросили Робина, он это делает, мы можем пока что-то обсуждать другое. Он проделал, дал отчёт и, соответственно, нам показал. Поэтому вот это ключевые, а, кейсы, которые я вижу. И основная идея, вот смотрите, как бы логика этого всего. Давайте сделаем ФСФ или чиф оперейтинг офисера, которого цель, а, институционализировать все знания, которые возникают в компании, и дать к ним лёгкий доступ всем сотрудникам. Вот. А вкратце, как это работает. Давайте теперь архитектурно, да? А как это выглядит? С одной стороны, у нас есть инпуты, да, то есть откуда Робин вытаскивает информацию про то, что происходит в команде, да, в команде, в продукте и так далее. Во-первых, это понятно сессии, которые есть у людей, да? Я его спросил, типа, Робин, расскажи, что я делал сегодня в Вон. И он даёт вот такой отчёт. Видите? А что важно? Он сразу указывает, например, важные какие-то айдишники, чтобы если вдруг кто-то захочет. И это появилось спустя время. То есть сначала он это не указывал, потом аэ я расскажу про слой памяти, каким образом а это происходит. То мы поняли, что, например, он должен всегда указывать user ID и ещё желательно а ссылку на трейсы в ланфюзи, чтобы можно было е что посмотреть, по какой это агент. Вы видите, он говорит, типа, сегодня ты реально там, а, юзал продукт, в отличие от вчера, а, делал, ну, у меня там четыре, э, аккаунта, он говорит, в одном из аккаунтов ты это всё делал, рассказал, что он делал. Заметьте, а что он делает некоторую, у него есть скилл, я чуть попозже расскажу, где если вопрос касается, например, поведения пользователя, то какие вещи он на какие вещи он должен обращать внимание. И тут мы видим, что а он как раз делает какую-то оценку. Например, агент вернул 17 следов, там, а, вместо десяти и так далее. и некоторую сводку и заметьте некоторый, а, ну, вот оценку по поведению пользова это direct message чат. Точно такой же есть groupе, то, что когда мы говорим с командой о чём-то, раз мы затегали Робина, он ответил. Второе - это что он делает некоторые регулярные операции. И эти операции тоже становятся инпутом для его как бы для вот этого слоя brain, о котором мы сейчас поговорим. В общем, вкратце, поскольку в чатике, в чатиках у нас есть разные чаты, типа он дизайн, он team, он DEF, он agents и так далее, он и там может быть много разных обсуждений. Он присылает, во-первых, утром он присылает общую статистику по продукту, а ночью он присылает дайджест всех разговоров, которые были во всех чатиках. Но параллельно этот дайдст чуть попозже я расскажу, как используется, чтобы, а, дать входную информацию о том, какие решения принимались, какие проблемы открывались. И потом это знание, а, определённым процессом, о котором я чуть попозже расскажу, превращается в знание команды. Сейчас тоже покажу вам пример. То есть вы видите, что вот ночной дайдст, да, он приходит в 3 часа. И тут написано, что, например, Оксана она они обсуждали вот рассылку и там Оксана и Саша обсуждали там какие-то аспекты, она делала текст и имиджи, они, в общем, переговаривались на эту тему. А там, а она сделала прототип ОКС, Даня сделал фичу на пару с Сашей какую-то фичу. В общем, вы видите здесь топики, то есть о чём говорили, и не не менее важное - это decisжены, да, то есть какие а решения принимаются. Чуть попозже вы увидите, как этот лог решений становится инпутом для скилов и знания, которое собирается у команды. Третье, как я уже говорил, уходит на звонки. Вот вы можете посмотреть, что в чатике наравне с вами в participants в зуме есть ons sales associate. Это вот наш э робот, который ходит на чаты и по сути он фидит информацию Робину, а о том, как проходит разговор, ну и, соответственно, готовит митингноци и так далее и тому подобное. Кому интересно будет реализовать, если захотите реализовать такое, то recallл AI очень упрощает задачку вот, чтобы одним одной СДКшкой сразу ходить и в Teams, и в этой стоит копейки. И последнее, а, как я уже заранее сказал, он пассивно индексирует все месседжи, которые прилетают во все чаты. Дальше, а как выгля это инпуты, да? То есть откуда он узнаёт про знания? Ещё, конечно же, репозитории и комиты в репозиториях, которые, а, ну, репозитории продукта, я имею в виду. Мы сейчас увидим на кейсе, будет понятно. Потом а у нас есть слой brain, да? Ну, сам Робин крутится на Manage agents, но для вас я сегодня зашерил репозиторий. Я его чуть попозже объясню и расскажу. Э помимо скилов, которые, э, там я поясню, я сделал спеку для Робина. И условно вы можете эту спеку, а дать своему кодик-агенту, и он по образу и подобию сделает такого Робина. Ну, понятно, он задаст вам вопросы по вашей инфраструктуре. Я чуть попозже расскажу, но в целом тут интересного - это вот взял я эту идею. Первые, кто у кого я увидел, как такое делают, это Open AI со своими со своим репозиторием Сифони, когда они просто выложили спеку и сказали: "Простоправьте своего кодингта на эту спеку, и он вам сделает". И поскольку я понимаю, что вы можете не использовать managed agents или ещё что-то, оформил в виде спеки. Здесь вы видите проблемыs, non goals, описание системы, какой там репозитории, какая система памяти должна быть. В общем, внимательно, если хотите, сможете почитать и реализовать, запустить своего кодинкагента на это. Там нужно будет принять ряд решений и выполнить определённые скилы, которые я тоже расскажу, но в целом а вот этот слой, где это крутится, а вы можете выбирать другой. Понятно, что в лучших традициях там Open Claw, а, и кто был на моём вебинаре по Open Claw, а помнит, что я прямо рассказывал, как мне понравилась идея SOLMD, да, вот этого некоторого файла, который описывает подход. Вот видите, например, когда я показал, как Робин ответил мне на а там ответ. И вот, ну что он, например, там меня чуть-чуть, грубо говоря, потизил, что вот вчера ты не догфудил, а не пользовался вообще онй, а а вот сегодня ты молодец, да? Вот понятно, что это часть его, а характера, который записан в SmD. Вы можете для своей компании команды решить, какой это характер и какую, э, как бы иденти, personality вы хотите дать этому агенту. А, плюс у него есть набор скилов, который сейчас я вам покажу, которые помогают ему, а, помимо СMD делать какие-то, а, задачи. Этот репозиторий по понятным причинам я вам не могу, ну, зашерить, но я как бы покажу некоторые, скажем так, аспекты, поскольку это, ну, крутится всё на agents, мне будет проще, если я покажу это через вам, а один из скилов я просто покажу. Например, есть у него skill data analтик, кото в котором описывается, каким образом отвечать на вопросы, связанные с дата анализ. а UX reviewer, а в котором а ну описано, каким образом, если кто-то просит, э, совет или мы обсуждаем, э, какой-то UI, каким образом отвечать на такие запросы, потому что ну мы там прописали его, чтобы определённые гайдлайны типа там NN Group и там Apple Human Interface Guidelines и так далее, чтобы они учитывались, соответственно, использовались в его ответах. У него есть набор скилов, которые он, которыми он обладает и помогают ему правильней отвечать на вопросы. Дальше у него есть слой памяти, а, безусловно, и тут интересно показать следующее. Это слой памяти как раз, ну, реализованный через opic managed agents memory слой. И смотрите, что в этом слое. Обращаю внимание, это слой памяти Робина. Это не слой памяти ОС, да, ну, то есть вот этой некоторой базы знаний команды. К ней он обращается, и её мы посмотрим через пару мгновений. Это именно слой памяти. И заметьте, что здесь видно. Например, вот есть дайджесты, да? Вот. И каждый день он собирает дайджесты по всему, что, а, обсуждается в чатиках. Заметьте, есть два типаса. Один - это staged, то есть это лернинги, которые он понял, а и предлагает, э, превратить в, ну, трансформировать в долгосрочную память. И а есть проed, то есть это те лернинги, которые я согласился, что надо, ну, запомнить, потому что не всеings, которые, если вы, да, дадите ему самому решать, какие промоутить, у вас будет с очень быстро. Я вас предупреждаю об этом. Но как работает здесь раз в неделю? Он мне присылает а м сообщение, в котором говорит: "У него есть процесс, он анализирует все дайджесты, всё, что ему говорили ребята". Например, он ответил что-то, они сказали: "А, добавляй, пожалуйста, ссылку на Longfuse." Соответственно, он, э, читает это, формулирует в виде вот такого арнинга. Вот как раз, да, а всегда добавля там был кейс, что когда он отвечал, у нас айдишники длинные юзеров, и он их транкейтил в Телеграме. И здесь, э, и Саша или Лёша ему сказали, типа, чувак, так не делай, нам нужны полные айдишники, потому что мы по ним потом ищем. И он как бы этот лернинг себе ну запомнил, а потом мне прислал, говорит: "Э, давай, я хочу запромоутить". Я с ним согласился. И поэтому, видите, этот леning перешёл в проomed, и теперь он учитывает этот аспект в своих ответах. А с некоторым примерно раз в месяц ярнинги, некоторые из лёрнингов переношу в его системный пром. Не все, сразу скажу, но некоторые я переношу, потому что понимаю, что не нужно, чтобы это было отдельным файлом. На системном промфет всегда это помнить. Соответственно, вот такая система памяти самого арниканга, то есть его knowledge и его аarнинса. И понятно, что у него есть базовый нодж про людей. И я для вас сделал, а скилл тоже в общем репозитории, которые я вам, а, зашерил, он есть, который, а, называется вот первый репозито, первый скилл, который надо будет запустить - это init teamos, который делает следующее. Он, а, читает все ваши конверсейшены, которые у вас есть с клодкодом, кодексом и так далее. Ну, здесь оптимизировано по клодкод, но вы легко сможете попросить кодинка агента, что он адаптировал под кодекс. Просто в других местах хранятся эти конверсейшены. Но его задача, когда вы запускаете этот TeamOS, он всё прочитает то, что у вас уже есть, и вот эту первую версию, а слоя командного, какие люди, какие проекты и так далее, он создаст автоматически. И вот там я на днях мы вот в нашем Nattives клубе, а один из участников как раз попробовал применить, и у него был интересный кейс. А его клод-код нашёл в MCP toдуиist. зашёл в Tod, взял все закрытые задачки за период и из этих задачек вытащил информацию, кто участники, ну, команды, какие какой продукт делается, какие фичи. То есть вы даже и Виталий говорит: "Блин, я не ожидал, что Ну то есть ты иногда не отдаёшь себе отчёт, что в твоём как бы в твоих репозиториях, в твоих MCP и так далее уже есть куча данных, чтобы инициализировать первую версию вашей а TeamOS. И, собственно, вот этот скилл это делает, собирает все всю эту информацию, вас немножко опрашивает и потом а в результате создаст что-то похожее на вот это наш team. То есть ещё раз, это по сути репозиторий. Во-первых, самое важное - это, конечно, вот это. То есть это набор знаний, там МД файлов про ваш продукт. И здесь это, например, ваши ideal customer profile, да? То есть какие аа типичные персоны, какие юзкейсы, а с информацией, какой именно клиент этот реализует. А какие customer journeys, да? То есть какие какой product мы хотим, да? Вот у нас есть чёткий product. И поэтому, когда, например, теперь Оксана дизайнит прототип, она указывает при дизайне, а своему кодиагенту, чтобы он сейчас мы увидим в скеле, сначала ознакомился с тем, что у нас за продукт, что у нас за user jрney, какие кейсы и так далее. и после этого дизайнил прототип, потому что я вам покажу сейчас на Ивалах, а на самом деле, а просто разительно отличается результат этого, а, прототипа, который, а, получается, соответственно, то есть это некоторое знание про продукт. Дальше это скилы. И здесь смотрите, вот, допустим, возьмём аа скилл, который, а, делает прототип, соответственно, что мы видим, а перед тем, как делать, во-первых, там output modes, да, что мы используем storyook и поэтому, э, прототип сразу делается как сторибуковский прототип, а, ну, там его стори. И второй вариант может быть это видео, если хочет, ну, тот, кто делает прототип, хочет просто кинуть видео в чатик и показать всем, как это выглядит. И, соответственно, первый шаг или нулевой - это как раз прочитать весь этот productin, чтобы понимать, какие у нас клиенты, юзкейсы и так далее. И дальше уже, видите, описывается сам прототип, как его делать, где искать там примеры, куда записывать. ну, э, дизайн-систему, в общем, какие компоненты используются, где куда записывать прототип и так далее, и, соответственно, как его проверить, там создать гифку иже, а, с ними. Понимаю, что, а, эти скилы, вот, например, этот скилл помогает нам быстрее делать прототипы. Но здесь есть ещё несколько интересных скилов. И вот в начале нашей встречи я рассказывал, что а я понял, эмер а вчера понял, что а надо сделать вот такой скилл. Это скилл, который бы, а, говорил, как правильно писать а на всех продуктовых поверхностях как правильно писать, какие использовать терминологию. Прокт есть глосарий, который автоматически поддерживается. Есть описание объектной модели, то есть какие у нас ключевые объекты, какие, а, переходы из состояния бывают. И дальше некоторые house rules, то есть наши внутренние правила, которые а я или ребята а когда-то обсуждали. Видите, например, а Rule of 3, да? Что, ну, у меня есть Макинсевская какая-то книжка, наверное, Барбара Минто Минто меня научила, что Макинси стараются, если ты делаешь перечисление, это делать всегда три пункта. И, ну, мне нравится этот это правило. Я стараюсь его придерживаться. Поэтому вот тут написано, что когда мы дизайнили, а upgrade сre, я, собственно, там, а, писал про то, что давайте три - это не так много, бла-бла-бла. Ещё помните, когда я вам показал digest, то я показал, то там был раздел decisions, что в каждый день могли приниматься какие-то, э, решения и а классно было бы собирать. Вот, э, в своё время в Твиттере прошла такая, а, ну, популярная статья про контекст графы, может, знаете. И если очень упростить суть этой статьи, что, а, в компании принимаются много решений, и, иаген должен эти трекать, тресить, как, э, принимаются те или иные решения. И вот это как раз -э та же идея, а вот этот скилл, а в котором а что по сути есть? В нём есть набор принципов, которые а мы принимаем. А и многие из этих принципов вы можете проверить, что они я про них, ну, например, прямо one way two way doors я писал в канале. Это я взял у Безуса. а, из какого-то из его книжки или выступления. Мне очень понравилось. И заметьте, что вот наши принципы, да, например, не придумывать новые ментальные модели, то есть не придумывать новые парадигмы, ну, сажаться на те парадигмы, которые уже понятны людям, например, там сайбар в chatчат GPT или Клоди, да, и там, видите, прямо было цитата, где или я, или Оксана, может быть, сказала, что типа канзолей каждую неделю людей каждую неделю используют там чат GPT и нам просто надо адаптировать эту парадигму и не придумывать тогда нам не придётся объяснять наш UI нужно будет делать онбординги и так далее и тому подобное ну и видите здесь набор а decision но про скилы а я хотел сказать очень важную штуку что вы должны их оценивать видите рядом с каждым скилом естьвал и а вот я когда делал сделал такой воевал и запустил. То есть вы что делаете? Как проверить ценность вашего как бы Тимуэса? Вы берёте агента, у которого есть, ну, доступ к репозиторию вот этому Team OС и у которого нету, и даёте ему одну и ту же задачу несколько раз. Ну, здесь, по-моему, я три раза просил а эту задачку выполнить. и смотрит. Ну, понятно, почему три, потому что недетерминированно каждый раз может быть чуть по-другому. И просто посмотрел, а насколько лучше будет аутпут агентов, если у них будет этот TeamOS или они используют этот скилл или нет. И тут, собственно, грубо говоря, а вы можете посмотреть, э, как бы каким образом там он должен принимать решения и результаты, которые у него, собственно, получились. Ну, сейчас покажу. Вот три рана. Видите, что, собственно, вместе с таким репозиторием агент выдаёт более правильный результат с точки зрения объектной модели, а, состояний, терминологии, переиспользования дизайнсистемы и так далее и тому подобное. Вот, собственно, здесь вы видите. Поэтому к чему я вас призываю, что мне кажется важно, поскольку это текстовые документы, что как их проверять, это лучшая проверка, понятно это людьми, но до того, как дать людям, это запустить агентов без контекста на ваш му с тимусами, бес и дать ему типичные задачки, которые вы делаете. Вот, например, когда, а, вчера я сделал вот этот онсокопии, а, да, а можно посмотреть, что, а, я им дал три реальные задачки, когда нужно было составить текст, а, и мы их обсуждали, и, соответственно, а, он выполнил их со скилами и без, и потом, а, посмотрели результат и сравнили его с, а, настоящим. Единственное, один раз только я прогнал. Ну, там как бы нечего было придумывать, там всё всё всё понятно. Заметьте даже, что, а, про ютиэмы, то есть, что он проверяет, что, например, если это там имеilясы, что UTM, а, ссылки. Ну и просто, чтобы закончить этот слайд и передать, то есть я ушёл сильно в откуда черпает знания Робин и агенты, которыми пользуются сотрудники. А это вот этот онбй. А это и дальше понятно, что у Робина есть набор тулов, рук, да, чтобы там делать разные вещи, входить в базу данных, деплоить что-то на сервак там и так далее и тому подобное, проверять сирмку, вот там чекать информацию. Основной как бы поинт что по факту, а вот тот GitHub repositorй, у него есть скилы и первый скилл, который, а, это initos, вот я вам его уже рассказал. А дальше нужно создать вот этот репозиторий аля ons brain. Это как раз вот здесь. И в RID написано, в каком порядке их запускать. И, аэ, вот я вам показал, что у нас есть, а, digдст, ээ, лог всех решений, которые мы принимаем, и из них, э, понимание принципов. И как раз вот этот скилл, его задача- пройтись, а, по, именно так я и сделал, пройтись по всем чатам, звонкам, транскриптам и так далее, вытащить из них, а, решения, которые принимались, и оформить их в виде это. Благо, поскольку Робин в дайджестах собирал decisions, это было очень просто сделать. Я просто запустил его на а все эти дайджесты по дням за Он сделал пулреквест, а я отбирал, какие дизайн decision принципы действительно наши, а какие, ну, у нас нету такого или я считаю, что это одноразовый. этот. И тут есть прин, когда он составляет этот список, он будет говорить вам про то, что, ну, там, если это один раз, то ну, типа, не надо это в принципе возводить и так далее. Про приватность и безопасность тут сразу говорю. комментирует этот аспект Гаяр, но а короче в моей парадигме так, ну для меня, для небольшой компании понятно, мне о'кей, что это улетает всё, а на антропикские сервера. А единственное, понятно, я поставил все галочки, чтобы на этих данных не учились и всё. Но поскольку код и других агентов можно запускать на костомных моделях, то есть для вас это проблема, то идёте по пути, который вам вами может использоваться. Вот, собственно, а безопасность внутри. Смотрите, у меня у Робина только вот если это продакшн системы, то на уровне именно пермишенов, то есть у него доступы везде, то есть что в GitHub, что в этот, но когда он делает прототипы, он в своей как бы в своём смбоксе создаёт эти прототипы там в сторибуковском определённом фолдере там а протоotypes. Поэтому в целом у нас я ему нигде не даю, и я пока сразу говорю, не готов к тому, чтобы right записи были без human in the loop. Поэтому в этом плане вот так регулируется безопасность, >> да. Конечно, вот как я сказал, Наталья поевалом как людям отдавать надо сначала проверить на агенте, а дальше вы сами вот я рассказывал про кейс с дисиженами, то есть он мне предлагает, а я как humanлуop уже выбираю. Ну классический ивал, то есть три уровня. Вот этот, ну, принцип сэндвича, да, что, а, мы делаем проверкой детерминированные проверки, сверху проверки, а, lm as a judge, но третий тип проверки - это вы, люди. Поэтому этот, смотрите, я здесь делаю паузу, чтобы показать другую точку зрения на то, как TeamС внедряется в компании гораздо больше чем а это. И в этом плане Гаяр любезно согласился. Наверное, одним из первых он заговорил про Team S. И поэтому я его попросил в течение 10 минут рассказать своё свой опыт внедрения team в и вообще AI на уровне команды, а не персоналии. И возможно для кого-то этот опыт будет более релевантным с точки зрения размера а компании. Яр, давай. >> Всем привет, меня зовут Гаяр, и я работаю в достаточно большом фэшн ритейле. В Европе. Европа - это сразу много языков. Это социальная защищённость, это GDPR, это Work Council, всякие профсоюзы и так далее и все прочие радости, с которыми вы тут можете столкнуться при внедрении и я. А, и да, сразу хочу сказать то, что это опыт вот одного департамента. Моя команда - это 20 человек. департаменте у нас где-то 80, а раскатывать отдел мы пытались на несколько департаментов сразу. Но это и это да, это лично мой опыт, собственно, это боль была моя инициатива. Это не отражает официальную позицию компании, потому что компания является публичной. по самому team. Я думаю, то, что в Байрам очень подробно всё рассказал, это в целом, если посмотреть с технической точки зрения, это сбор знаний, это построение скилов, это организация доступа к этим знаниям и скилам относительно той платформы, с кото которой вы хотите пользоваться. То есть это clotкод, это кодекс, это что-то ваше кастомное, managed agent, ээ, или еже с ними. И все те тулы, которыми вы хотите дать доступ, это опишки, MCP скилы, через которые он тянет данные и так далее. То есть по механике, я думаю, то, что собрать человеку, который сталкивался с настройкой клод-код под себя, в целом большого труда не составляет. Но на этом простота. Когда вы начинаете разговаривать про компанию, где нет, э, большой инициативы и где, собственно, нету Skin in the game, то есть это не где всё не сплочено там вокруг фаундера и компания, которая не является AI Natives, вы резко столкнётесь с так сказать с определёнными барьерами. Я сразу хочу вам сказать, то есть у вас, если у вас есть инициатива, в одиночку вы это дело не потянете. Вам нужно собирать когорту Adopters, те, которые будут заряжены и которые будут тестировать и помогать вам с внедрением. без э с эпутствующих последователей. Он может остаться вашим личным проектом, а и не раскататься на команду, потому что вы столкнётесь со следующими вызовами. Первое - это просто неприятие AI. Ээ, с чем я лично столкнулся, я был очень сильно удивлён и неприятно поражён том, что, казалось бы, продукт-менеджеры, э, аналитики и даже разработчики, ну, по сути дела, должны отвечать за инновации и внедрение, они очень сильно боятся. Они боятся, как потерять работу. Они боятся то, что их особенные знания ээ утекут куда-то и станут не особенными. У них есть байс того, что они когда-то попробовали там GPT 3,54, и оно не очень пошло, и с тех пор AI не работает и галлюционирует. И, собственно, не особо следят за развитием. Это любая новость может отражаться для них негативом. А вы с ними ничего не поделаете. Ээ и переубеждать их бесполезно. Их нужно показать то, что AI - это мейнстрим. Это нужно показывать то, что я сгенерировал документ. Мы теперь говорим честно, вот это документ был сгенерирован при помощи. Люди, собственно, там отражают, ставят огонёчки, ракетки и очень, ну, позитивно реагируют на то, что включаем менеджмент, то, что да, спасибо, молодцы, что этим делитесь. Показываете, что пример того, что можно с этим делать. А когда вы попытаетесь собрать knowledge layer, вы столкнётесь с тем, что эксперты будут очень сильно защищать свою свою позицию, свою нишу, свои, опять же, уникальные знания. Э особенно если это касается людей, которые понимают, что без своей уникальности они мало где смогут найти другое место работы. То есть это, например, по SAP внедрению не очень большое количество позиции на рынке. То же самое касается Sales Force. То есть это те люди, которые в своё время заняли уникальную нишу Subject Matter Expert и с тех пор, по сути дела, её м эксплуатируют. Но с этим есть ээ подходы того, как это можно с ними, с этими людьми можно работать, потому что вы будете от этих людей зависеть, когда вы будете собирать knowledge layer. То есть они всячески будут саботировать, они будут сопротивляться, очень вяло реагировать, но это проблеме уже не первое десятилетие. И методы мне пришлось делать реch как в целом выцеплять знания. Я перевёл свою памятку, я её пришлю в чатик, но есть различные способы, как дать им критиковать работу. Это интервью, это разбор того, что и как они делали на различных инцидентах. Э, ну, вам нужно будет подбирать подход под каждого человека, как лучше из него извлекать эти знания. Если вы помните первый слайд, - это набор стандартизированных ээ документов, знаний и скилов. В тот момент, когда вы закладываете вот этот foundational layer вашу вашу базу, ваше основание, вам нужно сразу договариваться о стандартах и контрактах того, как люди будут вносить изменения в ваш общий репозиторий. А это может быть, то есть это ваше абсолютно будет решение того, как вы хотите и где вы хотите хостить, собственно, эти скилы, знания и так далее. Но что должно быть едино - это то, как люди их туда добавляют. То есть вам нужно будет договориться о стандартах оформления, добавить детерминистские проверки того, что везде соблюдается нейминг, везде соблюдается иерархия, везде соблюдается там, э, перелинковка документов между собой. Иначе у вас появятся люди с горящими глазами. То есть вокруг и я всегда есть люди, люди с горящими глазами, но как только они начнут приносить свой вклад без стандартов, ваш TEMС станет станет очень сильно дорогим, потому что у агента не будет э правил того, как извлекать знания из общего уровня и как пользоваться скилами. Он начнёт перебирать, он начнёт галлюкционировать, э, и будет жать большое количество токенов. Это то, то, что, собственно, мы тоже прошли в больших компаниях. Ээ редко пользуются для обмена документами, Маркдауном, Гитхабом, а, и всякими текстами файлами, как тем, чем мы привыкли скармливать в cloudкод. То есть обычно это будет либо Microsoft, либо Google, либо Европы. А вам нужно будет понять то, как вы синхронизируете либо же извлекаете источник правды, то есть где лежит лежит ваша продуктовая документация. Например, у нас это Google Drive. Часть документов мы ээ храним копии в knowledge layре часть мы просто пере линкуем. И clot ходит через Google Workspace S, чтобы доставать это. Это очень дорого, потому что это опять тоже жрёт токены, но вам нужно будет принять решение того, как и куда вы ээ ссылаетесь, когда добавляете документы в контекст. А когда вы раскатываете на больше чем 10 человек, вам нужно понимать, э, как этим пользуется, как часто, насколько он полезен. Э, и не просто ли там вы скинули, получили огонёчки в слайке или там в Google чате, и после этого всё замерло или или хуже того отмерло. А вам нужна будет какая-то телеметрия, и вам нужно будет продумывать, э, как вы её собираете. Например, в Е с этим делом не очень просто, потому что любой сбор персональных данных должно проходить через Review, через legal и approvit, потому что это может с точки зрения works может воспользовано против человека как замер его эффективности. А вам нужно будет сделать скилл, который позволит человеку репортить, что что-то пошло не так, скинуть какой-то телеметрию, скинуть какой-то фидбк и так, чтобы это было доступно, по сути дела, в один клик. И обязательно реагировать на эту обратную связь, иначе просто вот этот Flywell, это того, что вы получаете связь, пользуете, сдаёте обратно, люди на дел насаживаются, это дело крутится, иначе его просто ээ этот импульс утихнет и погаснет. Э, собирайте вокруг себя сторонников и всячески подпитывайте и, э, держите этих людей рядом ээ и ээ поощряйте их участие. Вам нужны будут чемпионы в каждом отделе, в каждой команде, кто будет это внедрять, кто будет онбордить, кто будет помогать, потому что опять же в одиночку вы это дело не вытянете. А вам нужно будет обязательно делать регулярные встречи, желательно лицом к лицу, ээ, чтобы опять же получать обратную связь. Это единственное, то, что будет держать э-э интерес и а adoption внедрение, уровень внедрения среди -э вашей аудитории. И а ключевое, самое важное - это контекст. Ээ, скилы строятся там часто одним промтом, но никто Клод сам не достанет или кодекс, что вы там используете, не достанет знания уникальные для вашей команды, для вашего отдела, для вашей компании. А, как правило, все забивают на документацию, и поэтому ваша документация должна жить по мере того, как вы встречаетесь, как вы обсуждаете. Байрам сделал пример того, что происходит, как извлекаются даные из чата. В компаниях вроде нашей есть чаты. Это является очень ценным источником данных. А, но помимо этого есть большое количество встреч. Мы используем Gemini Notes. Да, оно саморизирует, но при этом теряет ээ контекст. Поэтому сырое видео или сырой транскрипт или сырое аудио всё, что вы можете собрать, старайтесь это дело собирать, потому что из сырых знаний вы можете делать большое количество производных. То есть это может ложиться как вашу централизованную просто документацию, как knowledge base. Это может становиться слоем знаний. Для это может становиться просто трассировкой из того, как меняется продукт. То есть в этой точке был такой статус, в этой точке стал такой статус. Вот что изменилось за эти недели там или месяцы. Старайтесь максимально записывать, конечно, согласившись со всеми, э, что происходит навстречу. Для этого есть большое количество прекрасных инструментов. Мои большие любители нди нажимают две кнопки, всё, пошло, пошёл транскрипт. Что вам следует запомнить? По крафту достаточно всё просто. Сложность - это заставить людей рассказать, что и как они делают. И в одиночку вы это дело не вытянете. Вам нужен будет процесс, вам нужны будут последователи, вам нужно будет максимально собирать знания из всех возможных мест и источников. >> Супер. А Гаер, спасибо. Давай пару вопросов буквально. Вот у Натальи есть вопрос по поводу спонсора и заказчика внедрения. Вот в вашем кейсе. Кто оплачивал банкет? Кто заказывал, а кто поддерживал, расскажи чуть-чуть. >> А-а, так, э, у нас спонсором в рамках отдела это был я. У меня у меня достаточное количество asсоority, чтобы это сделать. А, но делал я это не для своей команды. Я делал это для команды, где я увидел, есть большое очень бутылочное горлышко по доступе к аналитике. То есть построил уровень сбора данных и помощь в формировании недельных отчётов и прогнозирование ээ развития там конверсии и так далее. Блин, так сложно по-русски разговорить. >> А хорошо, тут у Андрея, >> ну а да, на уровне на уровне компании у нас ээ достаточно бойкая VP. И, собственно, она вот увидела, что мы готовим в нашем департаменте, притащила тоже ещё пару людей, и теперь мы пытаемся заонбордить product management, то есть мы делаем product management OS. >> А VP по какому?

VP Product. >> VP Product and Tag, то есть она для, а, всей нашей всего нашего бизнес-юнита, она, собственно, руководит продуктом. У Андрея вопрос: а как оценивались результаты по внедрении? То есть какие метрики? Вот ты сказал про телеметрию, можешь чуть побольше про это? А это очень э хороший вопрос по аналитике. Э мы просто замерили количество обработанных аналитических запросов за квартал. >> Угу. >> Это просто было в разы. Ну, мы провели оценку analist против AI analyst. Мы увидели то, что нет никакого расхождения в интерпретации метрик и интерпретации результатов. И сравнили ещё в том числе с другими продуктами, которые у нас, например, там есть Data Bricks G встроенной AI аналитик, который сидит на описанных схемах и датасетах и просто увидели то, что качество результатов нашего агента лучше, чем даёт DataБрикс ээ из коробки. Собранных отчётов, количество собранных ээ запросов. А в в продуктовом в продуктовом ээ о мы ещё пытаемся э сообразить, как мы будем мерить, потому что мы не хотим вот делать вот это именно это exploit matтрик, >> то есть там в количественной. Угу. >> То есть мы ещё, честно, мы ещё не придумали. >> Ещё один вопрос вот от Натальи. порядок стоимости затрат по токенам и как отслеживаете, как вот этот процесс? >> А у нас есть централизованная централизованный продукт, построенный на базе Light LLM. Это такая прокся, которая позволяет через себя пропускать ээ доступы к AWS Bedrock и Open AI. И на её уровне она авторизируется при помощи внутренних токенов. И просто ты можешь всегда сопоставить токен с, ну, то есть с тем, кто количество, какое количество запросов было отправлено, но слава богу у нас на уровне всё достаточно свободно. >> Угу. Угу. А, спасибо, Гаяр. А я сейчас ещё пару слайдов и а мы перейдём в дискуссию, если сможешь. не уходи. Да, я хотел это добавить только одно. Там был поводу приватности >> AWS Bedrock и Open AI, который Enterprise Platform, ну, которые, ну, по токенам, они не используют данные для обучения. >> Угу. Угу. >> И гоняют всё через европейские дата-центры. Поэтому в этом плане всё достаточно >> просто. А вот Гаяр поднял важный вопрос про обновление, ну, как, собственно, должна быть организовано обновление и так далее. Мы договорились в своём кейсе, что у определённых, э, как бы скилов и папок, вот в on brain есть, э, оунеры, и оунеры могут спокойно менять эти фолдеры, файлы, а другие могут делать пулреквесты. Ну, опять у нас маленькая команда, все знают, что такое GitHub. И с помощью своих кодинг-агентов, ну, там, например, Оксана, понятно, она там не разработчик, но её агент может сделать пулреквест. И, соответственно, договорились, что пулреквестами а вносятся изменения. Вот этот contribution, о котором говорил Гаяр. Но ещё есть более детерминистические аспекты а этого. Это, например, вот здесь, например, есть здесь скрипт, а, который называется чекдрифт, да? А что-то изменилось в продукте, а я напомню, что есть объектная модель, да? Ну, типа какие у нас ключевые объекты, какие у них бывают состояния и так далее. И может случиться такая ситуация, что код и вот эта база знаний, продуктовая база знаний, они разъехались в актуальности. И поэтому есть процесс, который делает, проверяет дрифт продуктового знания именно с точки зрения вот то, что касается кода, да, например, объектная модель, да, как вы видите здесь, например, а он проверяет, насколько улетело, и, соответственно, а, обновляет его. И второе, есть такой скилл, тоже то, что сказал как раз Гаяр, что есть скилл, который обновляет продуктовое знание. У нас ээ триггером к обновлению продуктового знания является а weekкли митинг. То есть вот у нас каждый четверг есть weekкли митинг. выкли митингу собирается такая очень большая, то есть по всем комитам в репозиториях, по всем клиентам из CRM собирается такая большая статус апдеdate. Мы с ребятами обсуждаем его, принимаем какие-то решения и так далее. И результат - это summary, да? То есть есть транскрипт сырой и из него summary. Собственно, что делает вот этот скилл? Он автоматом запускается после подготовки вот этого weekкly summary. И как вы видите, здесь он проходится по weekкly summary, по комитам, по Telegram-группе. И есть такое. Я пришёл к тому, что у нас должен быть такой файл, который называется now md, который по сути отражает текущее состояние вот онбрейна. И, соответственно, основная идея, что вот видите, вчера у нас был митинг, поэтому, а, здесь, ну, э, последнее обновление вчера по четвергам у нас выкли митинги. Соответственно, вот этот скилл, а, проходится по всем этим, проверяет текущее состояние versus то, что он узнал из митингов и так далее, и, а, предлагает апдейты к, э, к базе знаний. Я напомню, например, вот этим, а, вот этим фолдером я owур, то есть я могу апдейтить без кого-либо, но ребята могут делать полреквесты. А, например, вот этот скилл, а, вот этот, это скил окс дизайнера Оксана. Видите, тут Фигма, а, и Фронend, то есть, когда, а, надо из прототипа сделать как бы макапы для разработчика или, наоборот, из макапов сделать прототип, короче, и туда, и обратно, а, переход и, соответственно, а, онаунит этот скилл, если кто-то хочет делать апдейты, полquст и так далее. На уровне всем просто выданы рай права на весь GitHub. нету такого прям жёсткого этого детерминистического. Это просто нас там немного и это. Но, конечно, если бы было бы много людей, я бы, ну, жёстче, э, ну, то есть не дал бы там коммитить только через пулреквесты, а, в определённые папки, ну, вот в соответствии с системой Онуши по которой, а, которая есть. Поэтому это действительно очень важный поинт. И мы больше с вами говорили про вот, ну, нодж, скилы, а хуки, да, кстати, я не показал. Есть, безусловно, и хук вот как раз, а, который дрифт, то есть, как перед тем, как комитится, проверяется дрифт и, соответственно, прогоняется актуальность состояния автоматизации. Я вам говорил, там вот morning brief Nightly Dig. Но а мне кажется, вот после того, как вы создадите первую версию этого этого как этого Тимоэса, как я здесь говорил, compounds, да, то есть, что вот этот Flywheel, о котором Гар тоже сказал, нам нужна система, а, вот этого лнинга. И я попробовал вам показать на Робине вот эти staed, promoted, где human review. Надеюсь, примерно показал. Я бы сказал, что это ключевой аспект -э для того, чтобы эта система а жила, обновлялась и была актуальной, потому что как только она становится неактуальна, её ценность сильно а падает вот с точки зрения кодигагентов, которые а используют эту информацию. Собственно, завершая а резюме, это просто репозиторий. Чиф в виде Робина - это просто агент, который, а, разблокирует команду, отвечает на её разного типа вопросы, помогает ей знанием и так далее, но просто, ну, некоторые как бы, ну, вот чифта, сопровождение, которое в какая-то форма, а, через которую вы даёте доступ к этому брейну любому в на удоб удобной поверхности, ну, например, Telegramчат. Но каждый из сотрудников может просто напрямую подключиться к акрепа и свои кодиагентов направлять на него, чтобы прототипы делать лучше и так далее. для Робина. Перед тем, как вы кодикта запустите на спецификацию, которая его построит, вы должны вот этот скилл Робиннит сделать, чтобы выбрать как раз его, а характер и так далее. Ну, дать, короче, некоторую вводную информацию для спецификации, чтобы правильно её реализовать в коде. Вот, сразу скажу, я end to end спецификацию не смог проверить, потому что это требовало бы реализации, но я её проверил достаточно, ну, в большом как бы глубины. Если вы будете эээ использовать для построения своего Робина эту спеку, буду очень благодарен за пулреквесты, фидбэки, ну там, что добавить в этой спеке, что, например, плохо отработало или ещё что-то. Поэтому welcome с фидбеками на эту тему. В целом всё.

Call to action. прогнать ээ эти скилы, построить м репозиторий и попробовать реализовать роль. Руслан, а давай. >> Да. Всем привет, Байрам Грер, спасибо большое. Очень интересно было послушать. С одной стороны какие-то вещи, которые, наверное, все там или многие из нас подумали. С другой стороны, очень классно посмотреть на такой пример, как вы реально это используете у себя. Вот у нас другая немножко ситуация. У нас там сервисная компания, которая, в общем, делает для других клиентов много чего. И мы, ээ, я хотел рассказать про одну вещь, вот про самый первый пункт, про сбор данных. Э ты так прошёлся коротко, да, что вы собираете там вот с Telegram, ещё вот какие-то датапоинты есть. А мы, э, изначально как-то вот первое приседание примерно такое же сделали. Сделали там Telegram ботов, сделали какие-то интеграции, где-то там собираются эти данные у каждого на компьютере. сделали такой мини САС внутренний, где у нас есть такой портал, куда ты можешь залогиниться и подключить через OA все свои нужные аккаунты, которые тебе нужны: Gmail, календарь, GR, TLDV, там какой-нибудь постгресс, базу данных кастомную. Короче, вот их там типа 150 разных интеграций, что хочешь, можешь подключить, можешь ещё допилить кастомную. и, э-э, сделали несколько клиентских приложений для MacOS, Linux UI, где у тебя, по сути, это ответная часть для этого сервиса. Итого ты логинешься на в облаке, логинишься во все свои аккаунты. И что оно делает? Оно, например, собирает мейлы в виде marркдаун файлов или собирает все дротикеты в виде Markдаdу файлов и обновляет их год, месяц и внизу все имейлы. >> Вот это классная штука, которая нам позволила как бы, во-первых, разграничить права. людям очень легко и просто, потому что до этого у нас была проблема, что мы сделали там одну базу знаний, >> а в итоге выяснилось, что кому-то, в общем, какие-то просто лишние документы, кому-то, например, финансовую информацию лучше вообще не знать, потому что там информация про зарплаты твоих коллег, а может это и не нужно тебе знать. >> Вот. А второе, что мы решили, что, ну, в целом интеграции пилить, конечно, просто, если у тебя есть опыт технический, но сложно, если, как бы, ты ни раз с этим не сталкивался. даже запромтить клод сложно. И поэтому вот эта штука оказалась попроще. Мы тыкаем 1 2 3 4 и у тебя все аккаунты даны. >> И более того, мы сейчас пошли к клиентам. То есть вот у нас есть появляются какие-то клиенты, где мы там что-то им делаем, и мы говорим: "Ребят, вот мы сейчас вам это задеплом отдельную версию, там вот логиньтесь и всё". Мы даже не трогаем, вообще не подходим к этим данным, мы только видим, что папочка появляется на сервере у клиента, и мы теперь можем ей с нашим агентом оперировать, как нам хочется. Вот, вот такая штука там. Потом как-нибудь, может, расскажу поподробнее, как причешу немножко для того, чтобы показывать. Вот. Но сейчас закину в чатик скриншоты, как это выглядит. >> Давай. Супер. Класс. >> Мне немножко напомнил, ну, не совсем, но очень близко Композиioохаub, то есть где, грубо говоря, ты из этого хаба все МCшки, ну, все сервисы, которые тебе нужны, подключаешь и потом один одна точка доступа к этому. Класс. Очень, очень классно. Супер. Хорошо. Ага. >> Да. Да. Ещё пару слов хотел дальше рассказать. Тоже у нас есть ещё одна вещь. В общем, мы тоже думали, как бы нам подойти к этому прости, господи, а итив формату работы компании, да. И мы, ээ, в общем, долгими размышлениями поняли, что один из хороших примеров, один из хороших способов описывать, как у тебя что работает - это BPMN спецификация процессов. И мы сейчас по ней двигаемся. То есть мы описали работу своей компании, описали там работу некоторых своих клиентов и пытаемся теперь упростить эту схему для того, чтобы агенты могли какие-то части этих workкflow автоматизировать. Где нужен человек, значит, пока человек, но с надеждой, что когда-то выйдет там какая-то модель, которая все наши проблемы решит, >> да. >> Вот. И ещё сделали одну вещь. Вот ты тоже частично про это рассказывал. В общем, из этих данных сырых, э, мы создаём сначала какие-то деривативы, то отчёты за день, отчёты за месяц по проекту, по работе команды, по людям, значит, по знаниям. Это всё складывается в те же самые папочки и даётся вот кому э кому как интересно. У нас кто-то работает там с клод-кодом, кто-то работает с курсором, кому-то удобнее вношены я и мы ещё сделали интеграцию, что это всё ещё выгружается в nottion. >> Вот. Э, ну, это так коротко, в общем, про наш опыт. Ещё раз спасибо за за ваш опыт. >> А, хорошо. А пробовали ли какие-либо разные структуры таких баз баззнаний? Ну, например, The Custim вообще, э, хороший вопрос. Поче, грубо говоря, Байрам, почему ты не сделал это как Ztelлька? Ну, типа, а вот, ну, эту базу знаний. Я м не готов даже сразу ответить, потому что я сейчас поразмышляю вслух и если будут допсли, давайте. Короче, затристон это какие-то стейтменты, ну, типа опиниены о чём-то, да? То есть это какие-то стейтменты, а, о чём-то, а, о чём ты думаешь, и они в моей голове достаточно индивидуальны. Потому что это опинены. Если посмотреть вот на те, ну, те документы, которые лежат в Н Brain, то там это скорее чаще всего это или факты, да, то, например, product. Понятно, что в целом это какой-то, а, и их читать вот когда ну ты смотришь как человек и как агент, их гораздо удобнее и проще, а, ну, в режиме документов, ну, связанных нарративных документов. Вот я сейчас думаю, если бы мне нужно было постоянно создавать новые знания на основе, а продуктового, ну вот этого, а описания продукта и бизнеса, грубо говоря, тогда, наверное, Ztel Cust был бы суперудобен, потому что, ну, для меня основное value от Ztel Custon из-за того, что информация организована в виде вот, ну, такого графа стейтментов. или опининов, ты можешь новую информацию генерировать проще. И вот поэтому, наверное, так. По крайней мере, я бы попробовал в рамках такого чисто эксперимента всю текущую базу, поскольку у меня есть Zelлька Cast параллельно для личного вот как раз запустить этим же скилом, атомизировать эту и попробовать какие-то новые контексты вида: "А придумай новую фичу". И тогда, может быть, зателькастана организация этого знания будет гораздо более, ну, адекватная и подходящая, потому что в моей голове по-прежнему Зтелькан - это, а, система, чтобы генерировать новое знание. Вот как как-то как-то так. Если есть ещё мысли на тему, то welcome. По-моему, а Артём присылал эту инфографику. Давайте-ка, я обещал, что мы её посмотрим. Да, вот он space, да, вот и они интеграции. Я понял, да, очень вот мне напоминает Коosio Hub. Э, прям, а, очень похоже, но понятно, вот есть Fil - это штука, >> да, поясню. В облаке не хранятся файлы, это просто хранятся авторизации. Всё, только токены хранятся там на портале, а всё это сыпется на локальные клиенты, на машины, где установлены локальные клиенты. Мы специально не храним это в облаке, чтобы не былор данных, только токены. >> Понял, да? Артём, если хочешь прокомментировать, то давай или я прокомментирую, в смысле, почитаю её вслух, что называется, и посмотрим. Но я вот вижу пересечения некоторые, то есть, да, это вот как раз репозиторий, а, да, архитектура, репозитория, team builds together, скилы, make sense, пулресты, да, мы по сути, а, про это говорили и compounds, то есть вот это decision log, мы говорили про это вот onбординing, да, у меня обычно в Team S есть skillл, который называется онбор Вот Илья тоже наш часть нашего этого ордена AI Nates. Он, к сожалению, сегодня не смог участвовать, но я хотел, чтобы он рассказал, вот он как раз для своей команды онбординг skill делал, чтобы быстро онбордить новых разработчиков. У него такой очень advanced э процесс. И, э, у меня этого нету, потому что у нас нету много новых сотрудников, поэтому, ну, нету этого процесса. А, и, грубо говоря, когда агентов мы он бордим, это просто, а, мы дали ему доступ вот к онin. Но в целом, конечно, полностью поддерживаю, что, конечно, в компании Onбоardдинing Skill на, ну, которая часть этого репа, это супер важная штука. Давайте посмотрим. Там ещё были скрины.

How to upgrade, hub and spoke, да? One power user. Output, full adoption. Ну, delegation, понятно. И эта часть Share context, да, это репозитории Share Queries. Вот это интересно. А я про это не рассказывал. В общем, если видели, вопрос такой: должны должно ли взаимодействие с вашим условным а Робином у а этого у Шопиifая он называется Ривер? Долж должно ли оно быть публичным или индивидуальным иб Ну вот я рассказывал систему, в которой у нас есть димы, да, с Робином и есть общие как бы SH groups, где мы болтаем. Вот. А у Shopify интересный подход. Они сказали, что все взаимодействия должны быть публичны. То есть не може нельзя болтать с ривером. не публично. На каждое общение создаётся канал, ну, например, вот Тоби Riv. И это публичный канал, то есть в Слэке. И, грубо говоря, все другие видят, как вы общаетесь, и тем самым они как бы учатся, как правильно. Вот как Гаяр привёл пример, что они подсвечивают, когда типа документ сделан при помощи я и так далее. Вот это примерно та же идея, что, грубо говоря, если все смогут подглядывать, как вы, как Power usеer, а, используете Робина, а то тогда они быстрее будут учиться, а как максимально эту ценность из него вытаскивать. В моём случае, вот я сказал, у нас индивидуальные и общие, и я в общем чатике обычно спрашиваю что-нибудь пока, особенно когда новую фичу, например, добавил в этого в Робина. Я показываю или когда меня что-то спрашивают, в общем чатике, я вместо того, чтобы ответить, пишу типа Робин и говорю: "Вот посмотри, тут Саша спрашивает, ответь". А, и тем самым я показываю, что типа, ребят, вы можете спросить у Робина, а не у меня.