# Founder OS #10 – AI для продаж: жёсткий workflow vs agentic workflow

## Метаданные

- **Канал:** AI Mindset
- **YouTube:** https://www.youtube.com/watch?v=CsyhybFuUS8
- **Дата:** 22.11.2025
- **Длительность:** 1:10:47
- **Просмотры:** 200
- **Источник:** https://ekstraktznaniy.ru/video/20385

## Описание

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

Рассмотрим как агент сам восстанавливает LinkedIn-URL, почему он справляется с edge-кейсами лучше жёсткого пайплайна, и какой ценой достигается эта гибкость. 

⚙︎ что используем
• N8N
• Enrichler и аналоги
• LinkedIn API 
• reasoning-модели (O-series, Gemini, Claude)

→ на практике:
• Живой разбор двух подходов: жёсткий workflow vs agentic workflow на примере написания холодного письма по LinkedIn-профилю;
• Решение реальных задач: квалификация лидов, подготовка к звонкам, анализ продаж;

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

Внутри лаборатории мы разбираем три ключевых слоя к

## Транскрипт

### вступление []

И мы в эфире. Ура! Ещё раз всем привет. Давно не виделись на целую неделю. Рад, что мы снова тут. Как обычно каждую неделю Founder Press System. Показываем, что работает у других, нас. Всё на практике, всё на конкретных кейсах. Напомню, это AT. Мы помогаем фаундерам и не только узнать и внедрить в что главное, внедрить свою систему и своё мышление и в свой арсенал и инструменты, а потому что невозможно их внедрить самостоятельно. Собственно, мы и начали эту серию, чтобы посмотреть, как работают других, скопировать, что-то своровать, улучшить своё, покритиковать или посмотреть, как можно а смотреть на инструменты с другой стороны. Мне кажется, это суперважная штука. А и мы как-то очень много ушли в терапию и отошли были от конкретных задачек. Но сегодня мы сосредоточимся на двух частях. Первое у нас будет Байрам. он будет рассказывать супер интересный кейс, э, прос. Ну, sales - это не будет сам не сам кейс, это будет как пример, как можно использовать различные форматы, подходы agentic system, э, и, может быть, другие. И после этого Саша расскажет, какие планы у нас сейчас на будущее, какие у нас лабы готовятся в будущем. И там супер классно, на самом деле, поэтому обязательно нужно досмотреть. Но начнём с Байрама сразу же с коустарта. — Да. Всем привет. Меня зовут Байрам.

### Байрам Аннаков: чем детерминированный workflow отличается от агентного [1:47]

Мы делаем селс автоматизацию. Глобально мы очень много думаем и пробуем и экспериментируем ссистемами и с различными подходами. И последние, наверное, месяцев шесть я замечаю, а Shift, э, в парадигме того, как AI продукты строятся. Вот про этот Shift я хотел поговорить. А в качестве примера мы возьмём очень маленькую, простейшую область sales. Итак, сейчас вы должны видеть мой экран. Вот этот Shift, а он называется adenttic AI. А кто-то называет это агентами, но суть заключается в том, что вместо того, а использовать классический workflow для AI продуктов, когда у вас есть, например, какая-то задача, допустим, написать, э, холодное письмо потенциальному клиенту, и вы выстраиваете, а, чёткий детерминистический workflow, на каких-то шагах этого workflow flow вы используете LН. Ну, допустим, у вас workflow может быть, что, а, покажи формочку, чтобы получить ссылку на профиль LinkedIn профиil потенциального клиента, потом, а, сходишке, а, возьми профиль этого человека. И дальше третье, как раз, где встречается ЛМ. Вызови LLM, дай ей в контекст информацию про этого человека и попроси с заданным промтом составить текст письма. Вот как бы там очень детерминированный workflow. От здесь, как мы понимаем, весь код написан жёстко, каждый шаг делается жёстко, а, соответственно используется только на третьем шаге. А Shift, который я вижу, вместо того, чтобы описывать жёстко workкфлоу, мы отдаём управление всем workкфлоу ЛМК. Лэмка сама, имея промт, вы, может быть, видели там промты курсора или клодкода длинные, большие. А если почитать, то можно увидеть, что как раз это тот самый подход. Делаем длинный промт, описываем, что ей надо, какие задачи ей надо решать. Даём инструменты, которые ей доступны, а она уже сама решает, как, в какой последовательности, сколько раз вызывать эти инструменты, чтобы достичь той цели, которая есть. Вот я для себя метафорично, перед тем, как я ДМ покажу, сравниваю это с двумя типами сотрудников. сотрудники, которые по скрипту делают то, что ты им сказал, и шаг лево, шаг вправо, они уже не знают, что делать. И есть вторая парадигма, когда мы сотруднику сотрудника обучаем каким-то инструментом, но а в какой последовательности, как эти инструменты использовать, он уже решает сам. Главное, чтобы обеспечить выполнение задачи. Вот это, наверное, так метафорично. А чем отличаются два этих workflow? А давайте посмотрим на

### разбор жесткого workflow на примере написания холодного письма [5:12]

примере. Пример мы возьмём. Это задача написания холодного письма. А, очень такой простой пример, чтобы было понятно. В продакшене мы используем там не N, я буду показывать на N, но а, скажем так, с точки зрения философии вся логика останется там же. Для того чтобы получать данные о линкне человека по его адресу, мы использу будем использовать Enrich layer. Это так один из сервисов, который это делает. Ну и как лнку в случае первого типа, это чтобы написать, исполнить промт, а и получить результат холодное сообщение. Во втором случае это полностью управлять workflow агента. Поэтому давайте мы переключимся в Nightn, чтобы я понимал, чтобы у меня был контекст. можете в чат написать плюсик, если вы знакомы с NEN, чтобы я понимал, насколько скажем так понимание этого инструмента. О'кей, супер. Тогда я не буду вдаваться в детали N. Я сосредоточусь на вот этой разнице между двумя этими подходами. Итак, давайте посмотрим первый подход. А, детерминистический workкflow. Исполнение какой-то задачи. Вот у нас есть задача а написание аутрич сообщения. Мы а де у нас по сути три нода. Один - это получить от пользователя а ссылку на человека. Второе - это обратиться к Enrich Layer а и получить данные а LinkedIn профайла. И третье - это написать сообщение. А давайте исполним его и посмотрим на это всё. Сначала я покажу, когда всё хорошо, когда реальность хороша. И в этих случаях, сразу забегая вперёд, детерминистический workкфлоу отлично работают, их не нужно а с ними ничего делать. Ну вот я ввожу, допустим, LinkedIn проиil, исполняю его. О'кей, этот шаг исполнился. Мы получили LinkedIn профиil. А использую а узел, который подтягивает информацию из Ликна. Вот мы видим, что он потянул информацию обо мне. Я свой LinkedIn профиil ввёл, мой summary, мои экспириенсы, а, и так далее и тому подобное. Ну и третий - это, собственно, с GPT41, с инструкцией там, ну, там описание, кто ты такой и что тебе надо сделать, что надо написать сообщение. Мы исполним эту задачку и видим, что, в принципе, вот он написал нам сообщение, что там уже он автоматизирует B2B продажи, но вот мы тоже делаем и продавца, бла-бла-бла. 41 просто, чтобы быстро было, никаких спец этих быстро и дёшево. Но давайте я покажу или может

### что может пойти не так в реальности [8:21]

кто-то догадается, когда реальность вступает вот в такой workкфлоow, где что-то может пойти не так. Можно в чатик писать или ютиться и говорить, когда мы в реальности такой workflow. Вот, допустим, мы сделали его, запустили в продакшн наши сотрудники, которые пишут про а холодные сообщи. Да, первое, что у нас может зафейлиться вот этот нот. Почему-то Enrichлер недоступен в этот момент или прислал пустое сообщение или ещё что-то. Где ещё? Да, абсолютно всё согласен, Максим. Где ещё? Давайте ещё один пример хотя бы и мы потом посмотрим на эту ситуацию. Вот где, когда ты отдаёшь это реальным пользователям, обычно возникают проблемы, да? Ас упал и упал. Отлично. Особенно с учётом того, что на днях случилось с Cloudfare. Но а действительно из-за того, что нету контроля входныхвыходных данных, то это мой опыт показывает вот работы с реальным позити, конечно, они могут быстро набирая сообщения что-то упустить. Ну, давайте, я очень быстро набирал сообщения и действительно, как Дмитрий пишет, допустим, забыл последнюю а букву в своём профиле и в таком виде а сабмичу это. О'кей. Вот я засабмитил, но последнюю букву, как вы видите, то есть должно было Байрама наков. Я последнюю букву убрал специально. Что у нас получается? Когда мы, а, выполним этот workflow, у нас зафейлится, а, понятно, enrich layer, потому что он не может найти аа просто этот профиль. Ну и, конечно же, если у нас сломался тот, то у нас не сработает, если нам не пришло никакое а профиль, то у нас не сработает надпись. И в принципе, а из-за достаточно этот из-за достаточно маленькой, а опечатки у нас Vus Workflow не работает. И действительно надо реализовывать какие-то обработку ошибок, надо сделать флбеки, надо написать кучу ифов и трайкэтчев, если говорить на программном уровне, чтобы, а, обеспечить устойчивость этого workкфло. Ещё раз я подчёркиваю, что в лабораторных условиях всё хорошо. Когда ты отдаёшь это пользователям, вот тут начинаются проблемы. Давайте теперь посмотрим, как эту же проблему а решал бы решалось бы, если бы был бы так называемый adentic workflow. А я здесь использую как раз

### демонстрация agentic-подхода: модель сама исправляет ошибку [11:09]

агента. Агенту всё, что я дал, это как раз тул, очень похожий на этот л. А, то есть тул, которая тоже обращается кричлееру. А здесь заметьте, что я сделал. Я сказал, этот тул принимает вот этот параметр. Это тот параметр, в котором надо передавать акт. Но в качестве value я сказал, пусть модель сама примет решение, какое значение этому параметру выдать здесь. Давайте посмотрим, что а сейчас а произойдёт, если я выполню этот workflow. А я думаю, что некоторые уже, наверное, а догадались, но давайте посмотрим. А давайте я вы я напомню, у нас всё тот же кейс, когда не хватает одной буквы и в системном промте а системный промт - это, по сути, тот же промт, который а мы ну использовали в а ноде с детерминированным workкflow. Там чуть-чуть может быть подправленный. Давайте посмотрим, что здесь происходит. Вот мы видим, что он сначала обратился к модели, потом дёрнул LinkedIn проиil, неудачно дёрнул, потом опять обратился к LinkedIn к модели. Что-то там крутит, вертит, крутит, вертит. Я там поставил O3 модель, потому что reasoning модели лучше отрабатывают такие, а, кейсы, в смысле, лучше, а, участвует в роли, а, такого менеджера или оркестратора и агентов. И сейчас он, по сути, столкнувшись с проблемой, пытается её сам порешать. И, э, если нам повезёт, мы сейчас посмотрим, он, собственно, эту задачку, а, решит, догадается, что а и вот ключевое слово про если повезёт, чуть попозже я больше про это расскажу. Он догадается, что не хватает какой-то буковки, а, и вызовет тул уже с правильными это. Да, а, конечно, логи сейчас он закончит выполнять и, а, покажу, собственно, а, логи. Ну вот он он, собственно, сделал эту а решил эту а задачку. Что а происходило? Давайте посмотрим логи. Вот. А плохо, сорри, что плохо тут форматируется. Это, к сожалению, проблема N. А давайте в рендарт виде. Но а смотрите, мы просто по а последовательности а запросов поймём, что было. Смотрите, он а ну модель понимает, что ей надо вызвать get LinkedIn. И она вызывает, если тут посмотреть, то она вызывает с, собственно, с параметрами, а, которые изначально пришёл с неправильной последней буковкой. А она получает ошибку, а, от этого и понимает, что-то пошло не так. Она начинает пытаться, а, как бы понять то, что, собственно, было не так. Вот видите, Tool error, что-то пошло не так. Начинает размышлять. Почему так произошло и как надо, может быть, дописать линкты, предположить, что это ошибка, и дописать этот адрес. Дальше она дописывает и уже вызывает, смотрите, параметрами верными. А этот жел получает эти параметры, получает нормальный профиль мой и пишет сообщение, ну, пользователю. И вот он output. Я там просто ещё добавил, а что если человек из теха, то чтобы он, а, рэпом написал это сообщение в стиле рэп. Вот, на самом деле, это, а, это тот кейс, когда на самом деле мы получаем и чувствуем вот эту ключевую разницу между двумя типами workflow. То есть смотрите, что произошло сейчас. Просто сделаем zoom. Если бы был бы человек и он, а, допустим, как и во втором случае, он бы получил, а, вот этот профиль, но с ошибкой и вёл бы в браузер и получил бы, что такого не существует. как сделал бы опытный или сотрудник, у которого, ну, грубо говоря, в хорошем смысле горит, он бы посмотрел, а что там за адрес? Ну вот, по крайней мере, я помню, что одни из лучших разработчиков CTO, когда сталкиваются с проблемами с API, что документация не соответствует реальности, они просто, ну, то, что называется, они начинают напильником дёргать и подкручивать, тестировать, подбирать правильные значения, то, что называется, да, а, и пытаются подобрать правильное значение и, а, подбирают его находят, а, и получают правильный профиль и изучают его и пишут по нему, а, по нему сообщение. Вот именно это же здесь произошло, что я дал инструкции, а, смотрите, какие. И эти инструкции вы напишите только, когда вы в продакшене действительно поработали и понимаете, что начинаете изучать логи, когда ваш детерминированный workflow не отработал так, как надо. И видите, что а часто люди, например, пишут LinkedIn безz. com или забывают последнюю букву или ещё что-нибудь, неважно какой конкретно кейс. Основной поинт, что вы, изучая failр кейсы, начинаете дописывать вот эти ифы или трайкэтчи или гардрейлы. Вот по сути, а этот часть инструкции - это как раз про это, что я говорю, что важно, что пользователь иногда делает ошибки при вводе адреса. Поэтому do your best, чтобы восстановить правильный адрес, если такое случится и ты не сможешь получить профит. И именно это он и сделал. А я сразу скажу, если я сейчас попробую ещё раз выполнить, он может сначала попробовать другой адрес. Например, в моих, когда я готовился, он пробовал, а, беанаков, например. А, но основная идея, что, а, этот workflow гораздо более устойчив к эж-кейсам, к, а, разрывам и к тому, чтобы, имея цель и имея инструменты и входные данные, сделать всё, что в рамках интеллектуальных способностей LLM, возможно, тобы всё-таки добиться результата. Но если мы сравним вот эти

### сравнение двух подходов к workflow [18:39]

два два а-а кейса, напишите просто в чат, как а в чём плюс, ну, очевидный плюс а workкфлоу, второго workкфлоу - это что он более устойчив к разрыву. Но в чём минусы, допустим, этого подхода, которые сразу видны были, когда я сейчас исполнял этот workflow, какие вот сразу в глаза бросаются проблемы этого подхода, ну или недостатки, да, долго, да, совершенно верно. О, потому что, смотрите, ему пришлось, по сути, а, пять запросов. Пять раз обратился к, ну, то есть, три раза к модели и два раза он дёргал, а, эту, э, NHL, да, Максим совершенно прав. И это этот у этого недостаточно, что он слишком умный. То есть вот у нас были кейсы не с человеком, правда, а с компанией, когда Или Энричлер, или другой поставщик данных прислал не ту не полную информацию про какого-то из лидов, и он из хедлайна увидел название компании, потому что в headline ему пришёл, а в History он не нашёл, ну, не было почему-то провайдер не ответил. И он что сделал? он додумал, а, ну, из хедлайна, зная название компании, додумал, скорее всего, какая это компания, и сделал запрос дополнительный, чтобы получить профиль этой компании. Потом составил там, а, профиль, ну, там подготовку, письмо для подготовки к звонку, а, к селсзвонку. Но когда он вот искал эту, предположил LinkedIn адрес этой компании из Хедлайна, он взял не ту. И это привело к, а, проблеме, что он создал ну подготовку к звонку по правильному человеку, но не по неправильной компании. Иногда вот эта излиш слишком умность, назовём е так, вот эта способность к тинкерингу, она приводит к тому, что он может сделать неверные самшины, что тоже можно описать в целом. в промте, когда ты с этим время, а, ну и, как мы понимаем, время - это деньги. Ну, в нашем случае весь системный промт три раза отправлялся в ЛН, то есть вместо одного раза. Мы слишком много потратили а денег на эту задачу. Ну, то есть в три раза больше денег. Ну и, как правильно, а, можно догадаться, что где токены, там ещё и не только проблема аэ стоимости, но и переполнение контекста, когда а сбор большого количества вот пока он идёт по вот этим пяти операциям, а контекст наполняется, и это чревато определёнными ошибками. Поэтому, а, закругляясь, я просто сделал один слайд, который, а, суммирует вот эти как бы pros and cons, которые я основные вижу. А у agentive Worflows. Ну, это более устойчивые, более гибкие workflow. В чём гибкость по м получается? В том, что в LLM уже есть куча знаний. Иногда для задач, которые нужно решать, этот косенс знания могут помочь агенту решить ту задачу, которая есть у юзера, если даже вы в коде описали. Это, конечнотельные способности, когда ты анлочишь эту способность, а, даже чуть-чуть не по себе становится, потому что ты понимаешь, это этот продукт-менеджер гораздо круче любого продакт-менеджера, потому что в нём знания всего интернета, и он для косков, которые часто встречаются в интернете, он может сделать а штуки, которые гораздо более круче, чем описать всё это в коде. он лучше справляется счкейсами, с разрывами. Код становится более, а как бы simple, и он может, когда надо, глубже покопать, поскольку он может несколько раз исполнять инструменты. Я сейчас показал только один инструмент, но если бы у него было бы несколько, он мог бы использовать и комбинировать инструменты, чтобы решить ту задачу, которая есть. Ну, как я уже сказал, иногда он слишком а умён, и это проблема, потому что он делает неправильные самtions и приводит нас к неправильным результатам. Может быть, видели, как Клодиус, когда Клод управлял в ндиговым аппаратом, как он выкрутился из своих галлюцинаций, сказав, что это 1 апреля. гораздо больше токенов, что сказывается и на скорости, и на стоимости. И я, э, забыл этот пункт добавить. Это гораздо сложнее, а, дебажить такие workflow, то есть потому что, ну, э, мы видели, во-первых, логов становится больше, во-вторых, э, как бы их надо все читать, это текст, это не код. сложнее тестировать, сложнее дебашить. В качестве такого напутствия я бы сказал так: не считайте, что это

### ограничения: где всё ещё нужен человек [24:15]

серебряная пуля. Нет, ни в коем случае. Но я очень рекомендую взять один там chain workflow, то есть классический детерминированный workflow, где есть много вот ифов обработки результатов, много, а, moving parts, да, много разных внешних API используется, много разных тулов. очень широкая, а space возможных входных данных. Вот и complicated такие флоучарты. Попробуйте его переписать как агентский workflow, там логику я вам дал, и сравните вот бенефиты, которые открываются и трейдофы. Я скажу сразу, что вот мы, а, где-то, наверное, два или 3 месяца назад начали transition а из детерминированных workflow cadenic. И есть ряд задач, особенно поисково-реческих задач. Ну, в sales - это, допустим, resarch потенциальных клиентов, где агенты просто убивают по устойчивости качеству ресрча и а аутпуту, но не по скорости и стоимости. Они просто убивают детерминированного workкфлоу, поэтому возьмите, сравните и для себя, а уже примите решение, бизнес-решение, насколько это имеет смысл. Вот в целом всё, что я хотел рассказать. Если одним предложением Workflow - это новая парадигма того, как делать AI продукты. У неё свои плюсы и минусы, поэтому надо экспериментировать и сравнивать. — Спасибо большое. Классный пример, мне кажется, как показывает. Вроде как понятный формат, но на примерах и на каждых маленьких шагах становится проще. Да, сейчас как раз вопросыответы. Поэтому если что-то возник, будет классно их задать. Собственно, первое, — да, я вижу, Илья задал. А я буду из чата. Да, — да, Илья, да. Вот смотрите, первый workflow, который мы перевели, а, внк, это а поиск лидов по а так называемому портрету а идеального клиента. Смотрите, в чём проблема, почему как бы это сложный workкlow, потому что источники данных для правильной оценки, насколько потенциальный клиент подходит под портрет идеального клиента, а очень много. Иногда их нужно выполня, ну, вызывать в некотором цикле. Ну, как минимум это LinkedIn, Polo веб-сайт компании, Google Poиск, там, Zoomino и какие-нибудь пропрайтори data source. И вот этот процесс, ну, например, мне надо кусочек данных, я получаю из веб-сайта, кусочек данных я получаю из Линна, а из Линкна я получаю хинт, который позволяет мне сделать более правильный Google запрос, чтобы получить более релевантные результаты, чтобы лучше оценить вот этого потенциального клиента. Понимаете, да, вот эту сложность. Это такой deep resarch like а процесс, когда у тебя много тулов, где которыми надо жонглировать для а достижения определённой цели. Весь этот workflow мы перетащили. И я прямо с точки зрения именно качества аутпута 10x точно может быть больше. Вот сейчас мы смотрим на workflow, связанный с как бы подготовкой и интерпретацией. звонка. В общем, там какая проблема? У каждого человека свои предпочтения на какую информаюзера информацию при подготовке к salesзвонку он хочет обращать внимание и в какой форме. И получается, что агент там играет выполняет две роли. Во-первых, вот такой опять миниarch сильно более миний, чем а resarch, который вот для поиска потенциальных клиентов под ICP, но а тем не менее resе. А второе, что форма и а потребности к а форматированию данных и запоминанию персональных предпочтений, агент решает гораздо лучше. Ну и последнее. Этот workflлоow пока есть только в прототипе, не в продакшене. Вот мы его, а, там будем реализовывать. Анализ, а, данных по продажам. То есть, смотрите, у вас есть куча данных, например, в CRM, и вы хотите реализовать, ну, например, анализ аутрич компании, а, за определённое время с рекомендациями, что делать. Почему здесь проблема? Что аутпут одного из этапов работы является инпутом и инпутом к плану анализа. То есть, поскольку данные могут прийти в разном а формате, нужно составить план анализа данных после того, как ты изучил структуру данных. Вот это прописать все эти ифы в коде - это очень сложная задача. Поэтому мы отдаём это агенту. Более того, агент пишет код питоновский, который, как data scienтист бы написал, ну, анализирует эти продажи и получает инсайты. И на основе своего как бы знания, которое у него есть, плюс поиска бенчмарков в интернете, он делает сравнительный анализ. Он, например, говорит: "У вас конверсия 2% из холодного письма в а интерес, ну, в звонок, грубо говоря, в готовность на звонок". А, а в вашей индустрии, потому что он в интернете нашёл, это 5%. Значит, вы делаете что-то не то. И по моему мнению, вот где точки разрыва и что вам надо поэкспериментировать. Вот такие вещи вы не опишите в детерминированном виде. И это надо отдавать на а на такие workflows, да. Почему мы ответил Илья, а почему мы не используем Nend Production? Ну, потому что Nen, ну, для нас это для меня лично это такой вот почему я здесь simple написал в скобках. А потому что он действительно simpleм. То есть барьеры входа, что если ты умеешь программировать, очень низкие, да, для ат. Но когда тебе нужно делать, вот, допустим, возьмём вот этот кейс с анализом и интерпретацией, э, salesданных, тебе надо, а, генерировать код, исполнять код, интерпретировать результаты, а, работать с файловой системой и так далее и тому подобное. Вот это всё когда ты начинаешь реализовывать, это становится всё очень сложным, а, тяжело управляемым и поддерживаемым. И, конечно же, а гибкость инструмента, который, ну, гибкость кода, вы знаете, Andre любит говорить, люди, которые умеют программировать, любую задачу нодчворкера решают быстрее. Ну, просто потому, что они могут использовать автоматизацию, чтобы что-то делать. Вот это похожий стейтмент, что, а, да, в итоге NEN превращает всё в код, но, имея доступ к коду, мы можем лучше и гибче делать какие-то задачи. Например, задача управления контекстом. Вся область так называемого контекст инжениринга появилась как проблема, как ответ на проблему из-за как раз adentic workflows, потому что контекст стал переполняться кучей вот этих вызовов. И поэтому контекст ежедне появился. Поэтому, э, мы используем просто, ну, как бы, а, фреймворки, агентские фреймворки на в коде, чтобы, а, иметь более гибкие возможности для кодирования этих workflows, для подключения тулов и управления контекстом. Насколько adentive подход в среднем удорожает workflow? Где-то, а, в 3 тире10 раз в зависимости от workflow прямо. сильно. Поэтому, а, вот, кстати, тоже важный поинт, я не сказал. Обычно что получается? А зачастую вот в наших Workflows, как у нас есть оркестраторагент, вот он использует хорошую крутую модель типа O3 или Gemini 2 с. Вот сейчас мы тестируем на Gemini 3, а, то есть reasoning модель, но какие-то кусочки работы, а, выполняет, например, а, Gemini Flash. А, потому что вот как раз из-за стоимости. Почему я сказал отх до десяти? Потому что если вот как раз не разбивать, то будет 10x точно. Но если вы будете подменять в нужных узлах, а как бы, ну, более мелкими модельками, то вы как раз можете сократить эти штуки. Да. Валентин, почему 41? Хороший вопрос. Почему не GPT5? В общем, у меня какие-то пока плохие впечатления о GPT5. 251 всё стало получше. И, наверное, там в своих примерах я буду уже 5:1 использовать, но вот как-то 4:1 это как-то вот для нас это такая рабочая лошадка. Вот в продакшене, кстати, мы не перешли на пять на пятёрку, а вот на 41 вот мелкий workflow, где не нужен ризаник, потому что очень классная, устойчивая рабочая лошадка. Я думаю, что на 5. 1 будет то же самое, когда мы потестим. Просто она только вышла альна. Это скорее, преференсы и, а-а, привычка, чем какой-то взвешенный анализ. Поэтому не обращайте слишком много внимания а на это. Вроде ответил на всё. — Да, вроде ответили на всё. Это супер. Слушай, так подробно э ответами. Очень классно. Спасибо большое, на самом деле. Может, может нет, ни у кого нету больше вопросов. Поэтому ещё раз спасибо. Классные опыты, мне кажется, нужно взвешивать, ээ, дороже стоит готовые результаты, либо всё-таки, э, уже можно что-то не автоматизировать. — Вот, кстати, помните мою метафору. Иногда нужны сотрудники, которые тупо делают. Они дешевле, меньше требуют управления и так. Но иногда нужны, э, такие independent тинкереры, и это, я думаю, зависит от внешней среды и от сложности, а, задач. Сорри, что перебил. Меня просто хотел отправить к вот этой метафоре в начале, аэ, презентации, потому что я её потом не донёс. Но моя основная мысль была, что вот так надо думать про эти два типа workfalls. — А можешь привести примеры ещё, какие принципы workfall вы делаете? То есть link - это стандартно достаточно эсот. Может быть ещё что-то, что-то интересное, необычное, может быть, новое. — Не, глобально четыре к Ну мы же от процесса продаж пляшем, а не от возможности AI, да? То есть четыре задачки, ну, ключевые, я считаю, есть в, а, в sales, ну, допродажные, потому что мы пока фокусируемся на это поиск, э, людей, квалификация входящих лидов, это подготовка, проведение и, а, обработка звонка. И четвёртое - это анализ продаж. И потом замыкается круг, потому что из-за анализа продаж вы можете поменять портрет идеального клиента, чтобы искать по-другому своих целевых клиентов и так далее и тому подоб. Поэтому это четыре ключевых юзкейса, которые я вижу. Ну, есть юзкейс с генерации коммерческих пропоулов и контрактов, но мне кажется, что он, ну, уже более-менее структурирован пандадоками и же с ними. — А вы обычно подключаетесь, получается, к какой-то команде сеус? который уже продаёт, и помогаете им нагонять лидов и потом адаптировать их кретику. Прикольно, — да, наш вин, что 70-80% работы современного B2B sales - это автоматизируемо уже автоматизируемо с точки с помощью лмок. И вот мы хотим довести как бы команды до вот такого уровня автономии. — Может какие-то цифры было бы интересно. Ну, то есть ты упомянул бенчмарк. Понятно, что есть по индустриям, но вот в твоёй нише насколько вы увеличиваете процент продаж, насколько помогаете ребятам? — На самом деле, я бы так сказал, мы делаем а в три раза дешевле, а в два раза больше, чем делает человек. Вот, например, если мы возьмём outч, а есть, наверное, во-первых, ну, я шерю, там, кто не знает, у меня есть канал, там есть прямо бенчмарки, например, потричу. Я шерил полинкты Аутрич прямо я говорил, если у вас плохо работает outichч, то сравниваем вот эти бенчмарки и вот как искать проблему. Поэтому я бы туда отправил э посмотреть, но для каждого бизнес-процесса есть а какие-то бенчмарки, а и они позволяют тебе понимать, что что-то идёт не так, а и где можно. Но я сразу, наверное, предупрежу, если вы будете автоматизировать свой sales, начинайте с очень простых аа рутинных задач. Ваши селзы делают постоянно. Что-то типа, а, написание текста письма. Они, может быть, это делают сейчас в чат GPT. тизируйте им вот этот вот этот, как мой коллега говорит, я, говорит, иногда считаю, что мы люди как курьеры э доставки еды, только мы доставляем не еду, а информацию между разным софтом. Ну, мы что-то нашли в одном софте, потом что-то вбили в другой софт, оттуда получили что-то вбили в третий, отправили в LinkedIn, засунули в чат GPT и так далее. Найдите вот эти workflow, вот когда люди постоянно, а, прыгают

### Q&A с Байрамом [39:00]

между кучей софта. И начните с их автоматизации, потому что это даёт, во-первых, быстрые победы, а, во-вторых, траст от команд, что это, ну, AI может делать, может помогать и автоматизировать. А дальше уйди идите в более сложные задачи вот анализа продаж и так далее, потому что там, а, как бы, ну, больше челленджей и проблем, которые могут случиться. — Ну и, наверное, может последний вопрос по поводу какого-то такого чуть-чуть будущего. Сейчас вы вот закрываете аутрича в первую очередь и анализ. Думаешь ли ты, что вот следующие шаги уже можно автоматизировать? уже насколько готовы инфраструктура для того, чтобы и звонки, и какие-то дополнительные вещи уже могли, потому что много объявлений, но как будто бы нет до конца достаточно юзкейсов этого. — Да, я думаю, можно я одну картинку покажу про а она описывает наш vision и отвечает хорошо на твой вопрос. В общем, глобально, вот вы знаете, что есть пять уровней автономии Selfdriving Cars. Вот мы также смотрим на salesпрос, что есть пять уровней автономии sales организации. В перво на нулевом уровне всё делается руками. И вот наш вин - это когда человек ничего не делает, сидит, кайфует, а робот или набор роботов за него делает задачу по обеспечению продаж. И вот если посмотреть здесь ну на сайте можно увидеть описание каждого из уровней и какую задачу на этом уровне решает LLM Versus человек. Вот, например, там на первом уровне LM просто там генерирует контент, допустим. А человек выбирает. И вот наш вин какой, что любая sales-команда должна пройти вот эти уровни. И поэтому как бы в итоге, да, наша цель вообще весь Revenue Generation был на автопилоте, но я сразу скажу, что я пока не вижу, что технология это сможет сделать, но я точно вижу, что уже у наших клиентов третий уровень есть, когда целый workflow end to end обеспечивает набор иагентов. А когда, ну вот, допустим, возьмём outч. Полностью для наших клиентов обеспечивают наши агенты. Но когда, а, возникает необходимость человеке, когда, допустим, исчерпали вот этот сегмент пользова целевого целевой аудитории, вот что делать дальше? Вот тут нужен человек, потому что он говорит: "А давайте попробуем ещё вот таких ребят. А давайте вот таких". И получается, человек супервайзит. И когда в рамках более маленькой цели агент исчерпывает способы и методы достижения этой цели, новую цель или новые эксперименты по достижению цели лучше формулирует для неё а человек, а она уже дальше исполняет. Вот такая у нас как бы логика. Поэтому я считаю, что третий уровень, ну, я вижу, что это работает у нас клиентов, но вот уровень, как а мы ничего не делаем, а знаете, вот это мечта любого CO, что он ничего не делает, а продажи идут, да, ну, для sales организаций, поэтому он нанимает Head of Sales. Вот, грубо говоря, а sales плюс всезы эту задачу бы делал, а роботы. И пока мы, конечно, не там. Ну, какие-то элементы начинают возникать. Самый сложный пока элемент - это сприятие людей продаж. Что люди хотят покупать у людей, я так упрощу. И вот это, я думаю, в каких-то индустриях и для каких-то сегментов людей будет acceptable покупать B2B продукты у роботов, но для кого-то это будет не acceptable. Это уже вопрос. привычек и культурного контекста. — Блин, ну опять нету серебряной пули. — Да, конечно, — жалко, конечно. Ну и рад, на самом деле, что потому что с автономными машинами там хотя бы инфраструктура накаменна, её нужно прямо очень мощно переделывать для того, чтобы она стала необходимой. А здесь код в интернете, который гораздо проще и быстрее. И вроде как — сильно быстрее идёт этот прогресс. Ещё раз спасибо, очень классно. — Удачи. — Да. поширил презентацию. Как? — Отлично. А-а, вот такие вот кейсы. А напоминаю, что можно оставить тоже заявку, можно выступить у нас, если у вас есть крутой кейс, и мы будем очень рады этому. Заявочка будет напишу здесь в чатик, скину и, естественно, на Ютубе в описании также она будет. Но сейчас мы будем возвращаться к Александру, который так трагично вошёл в кадр для того, чтобы он всё-таки немножко рассказал нам про будущее MNS, по что там чуть меньше, может быть, оптимизация, но что-то, что даст возможность нам думать классно в следующем году. Ну для этого нужно сначала включить микрофон.

### AI Mindset: context lab [44:31]

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

### как подвести итоги года: методологии и подходы к самоанализу [45:15]

что классно подводить итоги кода. Мы все это делаем. Об этом, по крайней мере, все везде говорят. И мы хотим тоже такое что-то сделать. У нас есть контекстная лабба, мы её так и назвали, потому что это контекст. Мы все понимаем, что контекст нам нужен. Мы понимаем его в последующем можно использовать. Вот там пару технических примеров. Там терапия тоже пример менее технический, но мы тоже понимаем, что везде нужно что-то про себя сохранять, где-то держать и под запрос вызывать. Пример этого, э, я потратил, наверное, предыдущую неделю на то, чтобы помимо того, что я уже несколько лет это делаю лично, на то, чтобы собрать какие-то методологии относительно контекста года. И, конечно, это можно показать в каком-то таком режиме, что да, у меня есть обсидиан, да, мой обсидиан страшный, он выглядит вот в каком-то таком режиме. Там за 5 лет уже там 15. 000 заметк накопилось. Ну, я думаю, что все видели похожие слайды от меня. Хочется меньше вот об этом, больше про подход к сбору вот таких историй и более, наверное, даже не техническим, а самоисследовательским. Давайте такую метафору возьму. Вот. И есть много подходов, э, и технических, и нетехнических. Вот, начиная от какого-то ТГА Форта, который запустил эту историю с нодж-менеджментом, у него есть свой стек подведения итогов года, геокомпас, пирамида дилса, колесо баланса. Есть куча всяких методик того, как оценить нашу жизнь. И часто мы это делаем под Новый год. Посмотреть календарь, посмотреть картиночки по месяцам и расписать его как-то. У меня есть там пару таких рефлексий, которые я проводил за предыдущие годы. Тоже смотрел по месяцам, использовал обсидиан для этого. В обсидиан тоже есть пару прикольных настроек и плагинов, которые позволяют это делать. Рисовал там какую-то пирамиду дилса, рисовал колесо баланса тоже кодом с помощью я ещё до того, как я там не особо где-то развит был. Вот какие-то такие вещи было бы прикольно поделать и понять, что для этого нам нужно, и, возможно, что для этого нужно будет более системно там собрать в следующем году. Не знаю, для меня вот, наверное, открытием, не открытием, а систематизация этого года стало просто правило подписывать ивенты в календаре и цветом, и именем правильно. Ну вот просто внимательно относиться к тому, как подписаны ивенты в календаре. Соответственно, весь мой обсидиан начал заполняться названием заметок, транскриптов, файлов, так как он у меня присутствует в календаре. Общая то сейчас я параллельно с этим звонком, ну, у меня есть тут какой-то resarch, какие-то мои метрики, я задизайнил эту презентацию. Я использовал для этого код-код, который подключен примерно к такому же хранилищу, в том же Обсидиан. Я попытался собрать все эти ресерчи и сделать под эту презентацию. Вот получилась презентация достаточно красивая. Причём, на мой взгляд, это тоже такой немного недооцененный способ, а как делать презентации. Мы там все друг другу советуем гамма, ещё какие-то сервисы создания этих презентаций. Мне кажется, презентации сейчас можно делать просто из Маркдауна, очень костомными интерфейсами, просто имея свои дизайнерские паттерны. Вот получилась такая презентация, что, на мой взгляд, тоже красиво, а она соответствует нашему стилистику, и сайты и всё такое. Я тут хочу кратко просто пробежаться. Я на самом деле практически не читал. Она просто собирает мой resarch, который я собирал в обсидиан последнюю неделю. Логически, да, она показывает, наверное, что мы хотим сделать. Параллельно с этим у меня есть как бы сайт, ну, более, наверное, структурно это всё описывает, где, э, есть программа, есть спикеры, тут что-то сказано про спикеров. Есть, наверное, многим известный Лёша Мельнинщик, Лена Серегина с метриками, Лёша Мельничик с каким-то более социальным подходом. Есть какие-то инструменты, подходы и так далее. Да, он тоже был сделан где-то в связке с Обсидиан. Но вот сейчас, наверное, было интересно вот такой вот формат презентации сделать, да, тут может я покажу буквально пару слайдов и вместе можно подумать, а как реально можно людям помочь собрать контекст. Возможно, кто-то из вас захочет прийти, в каком-то формате даже выступить там или просто поделиться. Вот поскольку у нас есть полтора месяца там до конца года, как бы мы собирали этот контекст, да, обладая чуть большим, наверное, каким техническим навыком. Вот тот же список методологий, который я смотрел, который я делал. А, возможно, мы могли бы посмотреть там структуру созданных файлов наших волтах, обсидианах и прочих. Возможно, мы могли бы как-то выгрузить историю календаря, всей истории чата, возможно, там придумать какие-то категории, метрики, не знаю, принципы, по которым мы хотим эту информацию для себя разнести и распределить. То есть я бы сказал, что вот эти штуки, они нужны скорее для того, чтобы оттолкнуться и посмотреть. Мне кажется, что мы здесь немножко более сложным таким техническим инструментарием владеем. Мы можем сами, наверное, придумать какую-то какой-то подход, который позволит собрать данные из чего-то, календарь чаты, история браузинга, что-нибудь ещё. А как отправная точка и из неё в рамках нескольких фреймворках посмотреть на то, что происходило в течение года. Понятно, что там где-то есть история про всё-таки то, что это надо делать, ну, не автоматизированным workflow. Вот нажал кнопку, получил какую-то там табличку, вряд ли она нам что-то даст. Тут важно всё-таки такую человеческую работу тоже проводить. Там буквально пойти в каждый месяц, там поскролить альбомы, посмотреть картинки. И вот где этот баланс? Может быть, это даже открытый вопрос. Где этот баланс между технической и человеческой частью этого процесса? Что бы вы, например, хотели посмотреть, а в конце года? На что обратить внимание? Какие, возможно, знаю, элементы входящих данных вы здесь видите? Что из этого могло бы нам помочь, чтобы подвести итог году по структуре? Да, мы хотели бы это всё сделать достаточно адвансно, но да, мы хотели бы людей синхронизировать и поговорить о том, не знаю, объединяться в группы, как трекать какие-то эмоции, как, ну, то, что мы делали на с Лёшей Мельничком на почти на каждой нашей лаборатории, как смотреть в календарь, где это хранить. А второй неделе мы бы посмотрели на разные обвязки, а, тулов приоритизации и подключения по MCP разных других задачников и систем хранения командных данных. Наверное, такой есть подход. Есть Лена Серегина, наверное, многие тоже могли её слышать. Она больше через такой и подход к метрикам. Большой бкграунд дата аналитики, но она сейчас это трансформирует в сторону именно такого более человеческого подхода. И тут тоже можно для себя выделить, ну, по сути, ритуалы или практики такие, которые могли бы нам работать и упрощать, помогать нам в жизни. Вот это мы тоже сделаем. И на базе этого мы даже хотим родить что-то в виде такого дэшборда. Дэшборд сейчас не заполнен. Это, наверное, тоже такой прототип, где можно трекать какие-то истории по согласно тем метрикам, которые каждый для себя выработает, ну, и смотреть на него в перспективе там какого-то периода года. Я понимаю, что этих трекеров много, но мне кажется, тут как раз-таки кайф в том, что эти штуки можно рождать очень быстро и очень персонализированно. Возможно, та плейлабы для кого-то будет такой персональный дашборд, который будет показывать то, как у него, а там устроен его критерий, его метрики, его какие-то важные поинты по жизни. Да. Что я тут ещё хотел показать про пирамидумерик? Э, это пример просто какой-то практики, да? Потом на это всё хотелось бы тоже накладывать и AI, вот, и построение дашборда, возможно, выгрузка с каких-то данных физических Apple Health Push или какие-то такие истории, тоже можно попробовать это сделать и в конце, наверное, спланировать э то, как мы бы хотели пойти в следующий год, что с собой забрать. лучше, не знаю, настроить пару правил для себя самого, чтобы с собой взять какой-то принцип составления календаря или подходов или автоматизации, которые к концу следующего года нам дали бы больше данных для того, чтобы проанализировать и оценить там результат своего года, своей жизни. В общем, такой набор задач. Тут много каких-то технических данных и подходов, но, наверное, многим тут всё знакомо, а, которые мы можем и хотим применять. Да, она начнётся у нас 8 декабря, к ней можно присоединиться. Или, что более, наверное, интересно, пока это время у нас есть, можно попробовать поисследовать, поделиться, обсудить здесь, обсудить в чате, что вам из этого отзывается, что вам из это, что вы из этого пробовали, на что вы смотрите в конце года, каким фреймворком вы пользуетесь. Ээ, как вы его сделали более техничным сеяй, возможно, там за последнее время? Может, у кого-то есть в этом плане мнение, высказывание, как реакция, по

### обсуждение: эмоции, личный опыт, методы рефлексии [54:03]

крайней мере, на то, что вы увидели. Был бы рад сейчас кратенько это обсудить. — Ну, мой комментарий первый. Я помню на сайте всё ещё есть вкладка, что создать свою конституцию. Мне это очень нравится. возможность создать что-то, от чего можно отталкиваться. Понятно, что 15. 000 документов - это именно трек от которого можно идти, но конституция как будто возвучит что-то, что можно применять вот прямо сейчас эту штуку. Я думаю о ней уже 2 годаы. Как можно задать конституцию для себя, потом для семьи, как потом её переложить в какую-то локальную контекст, который может отталкиваться другие лмки. И мне было бы это супер классно, интересно. Я бы с радостью дошёл до этого формата. — Тут видишь, ещё классно, что есть ещё тоже такое, мне кажется, очень похожий, возможно, более технический там подход. Системный промт, свой системный промт. То есть, как мы для модели это делаем, да, мы можем для себя сделать системный промт, через который мы смотрим на многие вещи. для проекта можно сделать системный промт или какой-то там набор критериев, который говорит о том, нужна ли нам сейчас эта инициатива или нет, нужен нам ли это сейчас клиент, например, на консалтинг или мы занимаемся больше своими делами. Мне кажется, вот ещё штуки, которые классно как бы с собою забрать в Новый год и хотя бы какое-то время повести. Поэтому, да, это просто какие-то метафоры. Мне кажется, что каждому отзывается какая-то вот своя конституция, вот классный термин, который, видишь, на тебя как-то влияет, работает. Понят по понятным причинам. Можешь рассказать по каким, но как бы мне понятным. Мне кажется, у каждого есть какие-то свои такие истории, триггеры, метрики, как угодно их можно называть, которые будут работать и классно их для себя определить. Может тогда кто-то поделится такими метриками, триггерами и способами, которые вы уже используете, — как-то отреагировать или там эмоцию какую-то высказать. Давай, — на самом деле, я же пошла анализировать, что могло бы быть голден сигналами для терапии. спросила GPT на основе своей терапии, потому что так глубоко не смотрела в анализ, потому что системно анализировать себя - это вообще очень а сложно и мало кто этим занимается, потому что это требует времени концентрации. Возможно, фреймворк вот этого обращения внимания на себя здесь стоит поисследовать. Ну, типа, метрики просто метрики они ни зачем. вопрос, куда мы их встраиваем. — Абсолютно верно. Мне кажется, это как раз-таки рычаг. А потому что метрики- это можно положить. Главное, как можно их поддеть и применить с большим усилием. — Вот я нашёл конституцию на сайте. — А может ещё у кого-то есть мысли? — Я могу пару слов. А слышно, слышно меня? Да. — Да-да-да. Я, — э, уже какое-то время а занимаюсь таким трекингом своих характеристик. Например, нахожу какую-то неудовлетворительный результат в жизни в своей. Разбираю, какая у него причина, какое у меня было ложное понимание до этого. Конечно же, с наставником, не сам, с ментором, а, и предпринимаю, какое новое понимание принимаю для себя и какие новые действия делаю. А дальше это новое понимание должно стать привычкой, автоматическим. И я для себя сделал в кликапе такую систему, по сути, как мой бэклог, бэклог моих характеристик. И у меня есть в фокусе какой-то набор. И должно быть там лучше не больше одной, но у меня бывает два-три. Например, не судить людей как-то называть неправильно, открытость и честность, а видеть возможности. Ну, это из того, что у меня конкретно сейчас открыто в Кликапе. И я цель какая? Произвести 20 повторений в своём опыте вот успешных повторений нового применения этого понимания. И тогда я себе сдвигаю движочек как прогресс такой прогресс бар. И когда доходит до двадцати, перетаскиваю всё, она у меня стала автоматической привычкой. То есть у меня это новое понимание прижилось в жизнь. И перехожу к следующему. А их там много, на самом деле, по разным сферам, по разным характеристикам. И вот таким образом я двигаюсь. И можно в течение года потом проследить, сколько там перешло в автоматический режим, а сколько ещё висит в бэклоге нерешённых всяких штук. Ну, я себе вижу такой измеримый процесс развития, собственно. Вот. — Да, как прокачка. Точно. РПГЭшка такая, только персонаж. Я в этом случае стопроцентная аналогия. Да. — Ну, Дмитрий точно проще. На прошлых э разах он показывал своего ассистента, который его пинает постоянно и помогает ему сохранять эти вещи. — Да. Да, я ещё его даже уже поднастроил. Он теперь мои с консультацией успехи раскладывает по вот этому прогрессу. То есть я бывает ленюсь там двигать эти движочки в кликапе, а теперь МCпишка, это всё классно работает. Он там сам находит, мне говорит: "Можно подвинуть вот этот движок с 17 на 18? Подвинем? Давай, двигайся". — Я тут вот специально открыл к привычки. На самом деле, я даже больше хотел по открыть просто подход и вспомнить о том, что мы тут многие про build in public, Leon in public, вот что-то in public. Мы с этого, наверное, принципа всегда начинали, когда ещё обсидиан лаборатории делали. Это про то, что мы было классно бы какой-то публичные версию вот этого держать. у кого-то свои там способы ээ предъявляться миру, но как бы тут много людей сейчас как бы пытается об этом как-то заявлять. Вот отчасти, наверное, нашей деятельности. Это тоже про какою-то открытость, наверное, наших подходов. Я просто не перестаю вспоминать Никиту, знакомой мой, который вот как раз, наверное, с которого и загорелся когда-то лет, может быть, семь назадвосемь. У него эта система то обсидиан, то сейчас у него какой-то другой стек. По-моему, он на рейзере это сейчас делает. Это, в общем, неважно. У него есть абсолютно всё, что он делает в своей продуктивити с само вот ээ такой развитии темы. Он постоянно сгружает все конфиги всех маковских приложений, там Фокус, то, над чем он сейчас работает, там привычки вот выгруженные, там setup, ну вот те штуки по продуктивности, которые делают абсолютно все вот микроулучшения своего своей рутины он трекает и ведёт в виде такого открытого болта, не очень большого, но очень системного. Тут же, в том числе, про какие-то принципы, что его мотивирует по жизни, что даёт ему смыслы. Вот, мне кажется, вот это вопрос по том, а где и как вот об этом говорить, показывать, возможно, в рамках хотя бы ивентов вот аля нашего спейса или каких-то других вещей. Мне кажется, это какой-то хороший поинт обсудить, а где и как это вести, для кого это вести, только для себя или, возможно, с каким-то внешним комиттом, как это показывать. Ну, по крайней мере, меня эта штука всегда интересует. И поэтому всплывает идея каких-то вот таких вот персонализированных дашбордов, может быть, даже каких-то публичных, которые будут показывать там мой прогресс, может, для семьи хотя бы, да, или для как какого-то круга людей. Вот, может быть, такая тема тоже кого-то заинтересует, и из этого тоже можно собрать какой-то микропроект под Новый год. Ещё может кто-то, Петя, я видел, ты хотел вроде говорить. Может, ты хочешь ещё или кто-то ещё? — Ага, да. Привет. Я хотел сказать, что очень прикольно меня прямо отзывается относительно контекста подведений. Ты спрашивал, кто как вообще подводит. Я использую старую довольно штуку Compсва. Там интересно, что настало вот буквально совсем недавно возможность автоматизировать. Типа ты можешь выгрузить как раз, да, календарь, а посещение, историю с фотками. Прикольно там Geoо выгрузить, посмотреть вообще где было, что. А с кем были встречи, с кем была коммуникация, там WhatsApp дёрнуть, тележку. Ну, в общем, прикольные штуки можно получать, как бы. А это просто как фрейм, но его можно дополнять вот этими вещами и себе выдёргивать и смотреть вообще, что было. И довольно интересно, аа получается, ну, как бы посмотреть на прошедший год и посмотреть вообще, что там, а, получилось с точки зрения какого-то расширения там круга взаимодействия, например, с людьми или проектов новых каких-то, которые были сделаны. Это интересный кейс. И ты сказал ещё по поводу отслеживания эмоций. Тоже прикольно вот свой какой-то дэшборд хотелось бы. А потому что у Appла там, условно говоря, неудобно и выгрузить никуда нельзя. У how we feel потрясающий, классный интерфейс, классная аналитика, всё супер, а удобно, но только вытаскивать в CSвишку там куда-то себе складывать, да, только через и да, и он прям очень классный. Сделать что-то типа такого для себя, наверное, было бы прикольно, чтобы у себя это оставалось очень понятно. У них интерфейс удобный. Они добавили ещё кучу всего, но самое прикольное - это интерфейс. Единственное, что не нравится, что они какие-то эмоции окрашивают, что типа это что-то негативное вот или там позитивное, а это, ну, некорректно, на самом деле, на мой взгляд. В смысле? Вот, короче, прикольно посмотреть на сбор именно контекста, как можно его с одной стороны собирать, а с другой стороны тречить в течение года, чтобы потом не собирать, например, в конце года, а можно было там помесячну, условно говоря, чекать. Это, короче, классная лапа. Интересно. — Класс. Приходи, если что. Ну или как бы в рамках спейса можно тоже прийти и с каким-то своим там исследованием показать к чему пришёл. Так что оба варианта доступны. Спасибо. Вот его кайф обсидиана в том, что вот достаточно быстро всё находится, в том числе там эта методология оказалась у меня тоже тут есть. Помню, я её так и не прошёл до конца, но я её тут заготовил. Ребята, кто-то ещё может поделится, посоветует скорее в формате втором. Мы сейчас достаточно активно готовимся к этой лаборатории, поэтому любой инпут, он может помочь, на самом деле. И сace здесь может послужить таким форматом, где сделать это можно в том числе. А потому что мы говорили об этом в течение уже 3х месяцев. Мне кажется, какой-то такой нитью тянулось. Конечно, называем это Founder Operation System, но в целом многие из эвентов, которые здесь были, они были как раз-таки про себя. Мм. Они были частями очень фрагментированно. Хочется собрать это воедино, а хочется сделать это более, а понятно продуктовой штукой, которую можно взять, пройти и получить конкретный результат, а не под себя. И если у вас есть кейсы, м, с радостью. — Я тут ещё подчеркну, что вот меня лично вот впечатляют такие вот форматы. Ну то есть это кастомная презентация, я не знаю, уровень там питча, например, или чего-то такого, которое было сделано чисто из 20 marркдаун файлов, которые я сказал: "Вот есть сайт, мне нравится, как выглядит этот сайт". Ну то есть очень хочется сделать есть how feel, скачать пару скринов, сказать хороший интерфейс, а вот мои метрики, которые я трачу в обсидиан через N8N, сделай мне такой интерфейс и где-нибудь размести его. Вот прямо хочется какие-то такие штуки поделать. То есть такие oneшот, там, тришот промнг, ээ, который позволяет такие штуки под себя разворачивать, если мы знаем, где этот контекст хранится. Вот пример этой презы. Меня лично вот как бы визуально эта презаит, как она показывается. Я стрелками сейчас переключаю слайды. Она выглядит, ну, на мой взгляд идеально, с какими-то скринами скруглёнными. Ну, то есть это топ. Такие штуки надо уметь рождать, а для этого уметь хранить контекст и быстро его находить. Вот. Нора об этом тоже как бы эта история. Да, мы про э-э какой-то подход к исследованию, трекингу, но в том числе и про выгрузку куда-то в виде какого-то там дашборда, графика, метрики, презентации. Это тоже часть этого пути. Ну и да, наверное, в этом ещё как бы идея, наверное, нашего подхода, что вот, ну, у нас она идёт таким зимним к этот. А что есть вот эта вот контекстная лаба, что мы хотим до конца года завершить год с каким-то контекстом, и потом с 19 января у нас будет такая плотная история, ну, в нашем формате там ромтинг и мышление и творчество, и весь этот подход. Но это, наверное, вы все знаете уже просто это мы делаем тоже. А может ещё кто-то поделится, посоветуют Оля, — выводы какие-то по метрикам ещё делать? Ну, то есть как последний этап. Вот вы всё собрали, собрали условно пинки себя, текст, метрики, какой-то аутпут из этого какой-то генерализованный. Типа совет себе у тебя классно, Саш, было, как ты сам себе давал, а напутствие на день, по-моему, в таком бодром варианте. Так, и здесь можно какую-то такую автоматизацию прикрутить поверх. Мы всё проаналити, давайте уже что-то, какой-то выход. — Такое даже обсидиан у меня было. Да, я помню, о чём речь. Наверное, оно было в Superвиспер, да, такие штуки. Мне кажется, Дима тоже прекрасно в этом штуке продвинулся со своими вот помощью в этом процессе себе. И мне кажется, ещё один там топовый подход мы увидим у Майка Яна 4 декабря, по-моему, он к нам придёт. Это фаундер мани чата. У него, по-моему, офигенная система про смыслы исследования себя и подход через, ну, такое глубокое самоисследование. Он тоже будет показывать вполне адвансный стек курсора и, э, трекинга голосовых заметок с часов. Вот, вот эта связка, что я себе отмечаю то, что со мной происходит, и у меня есть какая-то, ну, наверное, конституция, да, наверное, это вот хороший термин вот здесь, которая у него прописана и согласно которой он, э, соотносится каждый раз, когда с ним что-то происходит. А насколько это алайнится с моими ценностями? А насколько это там близко к тому, что я хочу себе делать? Притом, а, меня, наверное, перекашивает немножко больше в сторону там звонков, каких-то стратегий. Там у меня достаточно много коммуникации, а у него такая чисто ээ речерская история. Он не трекает ничего лишнего. У него очень чистый волд, а, но при этом наполнены уже там 1. ся3 заметок. И там всё про там личные ценности и устремления. Мне кажется, это тоже очень классный подход, когда мы идём по такой стороне чистоты, чистоты ценности, осознания, зачем мы это делаем, максимального, ну, как бы такой фильтрации того, что попадает внутрь нас. Вот, мне кажется, это тоже увидим классный подход. И от этого тоже может — спойлеры пошли. — В общем, — надо такое всё-таки, мне кажется, рассказывать. У нас все ивенты названы, просто нумерация меняется, а внутри на самом деле много чего классного происходит. Сейчас в — общем, да, как обычно открытый формат. То есть мы что-то называем, потом её в процессе дорабатываем и, может быть, саже процессе самой лаборатории это тоже как-то поменяет немножко и фокус, и тольность. Как минимум, мне кажется, мы нашли каких-то интересных людей помимо нас, которые классно об этом думают и

### завершение выпуска [1:10:00]

говорят и с опытом. Вот. Так что приглашаем высказаться, поучаствовать, рассказать о своём каком-то подходе в этом плане. — Возможно, это как раз-таки формат, где можно найти это время и найти время на самое важное в вабе по контексту. А это был Founder Operation System. Мы явно будем строить ещё personal operation system уже в декабре. А уже есть лекторы, уже есть чуваки, которые помогут и проведут по всему этому формату. Каждую неделю мы встречаемся по четвергам, а ещё ни одного не пропустили. А и ещё раз спасибо всем. — Спасибо, что пришли.