16 Агентов управляют моим бизнесом в США - Егор Карпович

[00:00] Егор: Мы вышли на пик сто пятьдесят тысяч операций в Make ежемесячно. Уже два года почти никого не нанимаем. У меня сегодня, наверное, около шестнадцати агентов, но самые крутые, это sales, partnership, SMM, а из интересного ещё lawyer и аналитик. Вот такая топ-пятёрка, которая у меня держит основную нагрузку. Opus я как-то написал одну инструкцию, он говорит: запомнил, вопросов нет. Потом что-то сломалось, я ему пишу: либо я тебя отключаю из розетки, либо ты работаешь на меня. Он отвечает: окей, и продолжает нормально работать. Держит контекст: кто ты, что ты делал, что у тебя выстреливало, а что нет.

Сергей: Друзья, добро пожаловать на подкаст No Bullsh!t. Бизнес без прикрас, в котором мы говорим о реальных проблемах бизнеса и о том, как их решать. Прошу вас не забывать подписываться на канал, ставить лайк и комментировать, чтобы другие предприниматели тоже могли увидеть это видео. Также прошу подписываться на наш Telegram-канал, где мы выкладываем дополнительные материалы к каждому подкасту и где я рассказываю, как мы строим свой бизнес. Сегодня с нами Егор Карпович, кофаундер и CEO тревел-компании, сейчас он находится в Штатах, конкретно в Майами, а вообще живёт в Нью-Йорке. Егор, очень рад тебя видеть.

Егор: Да, привет, Сергей, привет всем.

Сергей: Сегодня мы поговорим про очень интересную тему, про Claude Code и про то, как он применяется в бизнесе, потому что кейс Егора, один из самых интересных, связанных с Claude Code, когда он реально интегрирован в бизнес и заменяет сотрудников, помогает строить и продавать. Об этом мы сегодня подробно поговорим. Но начнём по традиции с твоей истории. Как ты пришёл к точке, в которой находишься сейчас? Расскажи, пожалуйста, поподробнее про свой путь.

Егор: Начал я ещё в далёких 2012-2013 годах с аутсорс-разработки, продавал мобильную разработку другим, параллельно занимался ремонтом компьютеров. Я это называю быстрые деньги и долгие деньги: быстрые, это когда за 20 минут можно заработать 20 долларов, а долгие, это когда 20 000 долларов, но работы там на полгода.

[02:41] Егор: После первого кризиса в 2014 году мы начали делать свою разработку. Я привлёк инвесторов, и аутсорс перестал быть интересным: когда делаешь мобильное приложение условно за те же 20 000 долларов, а видишь, как люди в аналитике зарабатывают сотни тысяч, понимаешь, мы это сделали за пару недель-месяцев, а там ребята делают что-то ещё, и для нас открылся другой мир. Дальше я продавал команде историю, что мы будем делать свои продукты, и с 2014 примерно по 2017-2018 год мы их делали, абсолютно разные, от женского дневника до умного дома, от магазина без кассиров до е-коммерса, потому что просто ловили хайп и на этом хайпе выезжали. После чего я ушёл из этой компании (она называлась Devment) и пошёл делать коворкинг в Минске. Сейчас он называется Campus, бизнес-центр класса А, один из первых в Беларуси, который смог заявить о себе так. А в конце 2019, начале 2020 я познакомился со своей будущей женой Алиной и присоединился к её travel-бизнесу. Дальше я сделал из этого туроператора и corporate travel management company, компанию только для бизнес-поездок. Мы управляем всеми командировками для компаний. Вот примерно так, если быстро.

Сергей: Слушай, супер, спасибо, ты прямо супер, питч-стайл, чётко, за 5 минут. Спасибо тебе, Егор. Ну что, тогда вторая рубрика у нас традиционно связана с ошибками, факапами, фейлами. Расскажи, наверное, три ярких фейла, которые кардинально изменили твою жизнь либо сильно повлияли на твой путь и мировоззрение.

Егор: Я, наверное, пока помню два точно. Первый, это тот кризис, с которым мы впервые столкнулись, мне тогда было, наверное, 21 год плюс-минус. Мы делали контракты в российских рублях, а в Беларуси платили зарплаты в долларах, и пересчёт всегда шёл в долларах, в Беларуси все привыкли к этой валюте как к крепкой, через неё все считают. Когда пришёл кризис, ты просыпаешься, а курс, который был условно 30, стал 70, и у тебя нет никакой маржи, сплошные минусы. Вывод: если работаешь на каком-то рынке, надо сразу смотреть, в какой валюте у тебя расходы, и переводить в неё все контракты и заказы любым способом. Для нас это, кстати, оказалось и хорошо, потому что мы развернули бизнес в продуктовую разработку, начали искать экспертов и применять знания в финансах, айти, маркетинге.

[05:58] Егор: Вторая история, мы делали первый продукт год или два и толком не выводили его на рынок, а если выводили, то не собирали аналитику и не понимали, что происходит. Потом узнали про customer development, что это нужно делать сразу, а уже после идти дальше. Фейл в том, что мы потратили огромные деньги на разработку и потом просто закрыли продукт, потому что не закрыли ни одной проблемы пользователей, зато у нас там всё было юридически и архитектурно правильно. Условно в 2014 мы потратили сотни тысяч долларов, которые могли бы сэкономить, если бы быстрее закрыли неудачный продукт и пошли дальше. Вывод, у нас в компании появился KPI: каждый месяц запускать новый продукт, отдавать в маркетинг, лить трафик; если летит, занимаемся, если не летит, сразу закрываем и не тянем до какого-то результата. Так у нас запускались десятки продуктов, и через год-два, наработав стек готовых модулей, можно было запускать сильно быстрее. Вот такие два факапа и вывода.

Сергей: Слушай, оба очень откликаются. У меня похожий опыт был с покупкой первой машины в долларах, тоже ровно тот период, когда доллар скакнул, я платил за Ford Focus как за Bentley и каждый раз расстраивался. А второй кейс тоже очень частый: когда долго что-то разрабатываешь, начинаешь любить продукт и терять объективность, привязываешься, и даже когда он уже "дохлый", пытаешься его тащить. Спасибо тебе большое за этот опыт, Егор. Давай теперь поговорим про твою текущую компанию и про то, какой сетап ты сделал с помощью Claude Code. Расскажи, как ты к этому пришёл, многие боятся пробовать новый инструмент, особенно применительно к бизнесу. Как начинал, что тестил, что взлетело, что нет, как добился, чтобы всё заработало, и какие результаты?

Егор: Давай пойдём на два шага назад.

[08:28] Егор: У нас была и есть команда разработки. Но мне всегда хотелось делать всё быстрее, особенно когда KPI был, один продукт в месяц. Я даже думал: мы не можем нанять нового разработчика, потому что непонятно, что будет через 2-3 месяца, хотя в целом у нас каждые три месяца что-то окупалось, окупало предыдущие затраты и что-то зарабатывало. Я даже сам пытался пойти в разработку, помочь ребятам, сделать какие-то дашборды и аналитику, но не пошло, не моё. Понимаешь структуру, IP, ключ, документацию, но ломался на каких-то базовых вещах. Потом появился no-code, это плюс-минус 2019-2020 год, с drag-and-drop, начали с Zapier. Через Zapier мы что-то делали, но это очень узкая задача, соединить одно приложение с другим, потому что Zapier, это линейная штука. Потом появился Make, где можно было визуально построить сценарий, с роутером, ветвлениями. Я даже разработчикам показывал, они такие: о, это же у нас там условие if используется, а тут это всё просто визуально натыкано. Потом появился n8n, я в него залез, посмотрел, но у меня в Make к тому моменту уже были сотни разных сценариев, я автоматизировал финансы, прослушивание звонков, интеграции с CRM. Мы вышли на пик сто пятьдесят тысяч операций в Make ежемесячно, огромный объём данных обрабатывался и добавлялся.

Егор: У меня всегда была такая тема: прихожу на конференцию по продажам, там рассказывают, что должен делать руководитель отдела продаж, я это записываю и потом прихожу и в Make автоматизирую этот процесс. Например: прослушали звонок, нужно отправить информацию в CRM, записать для менеджера, заполнить CRM тем, что сказали на звонке. Но этого бы не было без LLM. И когда появились Perplexity, OpenAI, стало супер удобно: у тебя неструктурированные данные, расшифровка звонка,, загружаешь в OpenAI, описываешь задачу и получаешь ответ уже в структурированном виде, в JSON, дальше с этим работаешь и можешь заполнять что угодно.

[10:54] Егор: Дальше, в 2023 появился термин вайб-кодинг, по-моему закрепился он в 2024-м. Уже все говорят, что самый популярный язык программирования, это английский, и работа стала чуть ли не 167 часов в неделю, потому что все просто сидят и что-то делают. Мы тоже начали вайб-кодить: я сам себе писал разные приложения, за которые до этого платили, например, конвертер из документа в PDF, за который платишь стороннему сервису условно 10-30 долларов в месяц. Теперь поднимаешь такую штуку на опенсорсе, дописываешь API, и уже используешь это в Make бесплатно, на своём сервере. Таких примеров огромное количество. И когда мы прошли путь от простой линейной автоматизации к структурированной, а потом к вайб-кодингу, начинаешь понимать, что происходит в компании и что тебе нужно. Мы даже сказали HR: если к тебе приходит кто-то из отделов и говорит, что нужно нанять человека,, сначала пусть опишет процесс, на который претендует эта позиция, а мы попробуем вайб-кодингом закрыть эту функцию. По сути, дополнительный человек часто был не нужен. Последние два года мы почти никого не нанимаем, это уже точечные, штучные позиции.

Егор: Если в декабре мы думали, что так и будем вайб-кодить дальше, то в январе всё изменилось: вышел инструмент, который я буду называть OpenClaw, сделанный одним разработчиком, который какое-то время его пилил в одиночку. У меня привычка, перед сном захожу в Twitter, читаю, что происходит в мире, в политике, в технологиях. И вижу, что все обсуждают этот инструмент. У него до этого было несколько других названий, сначала одно, потом cloud-bot, потом ещё одно, я уже даже не вспомню все. Я не спал три часа, думал, что это настоящий geim-чейнджер, что наконец можно сделать таких агентов, которые будут и между собой работать, и сами выполнять автономные задачи.

[13:24] Егор: Я тестировал буквально каждую неделю какой-то новый AI-инструмент, но нигде такого не находил. Может, кто-то и находил похожее, но для меня было важно, чтобы всё было в одном формате, особенно потому что мы работаем в компании в Telegram, где-то в Slack,, чтобы туда можно было подключиться и оттуда давать задачи, а не заходить в третий отдельный интерфейс. Когда все начали запускать похожие связки на базе OpenAI, я туда заходил, тыкался, ничего не понял: если я с первого-второго раза не разобрался, то дальше в массы это точно не пойдёт. И вот дошли до этого инструмента, уже три месяца в нём работаем.

Сергей: Безумно интересная история. Мне очень нравится, что всё было постепенно, ты каждый раз внедрял новую технологию, узнавал её преимущества и лимиты, и это позволяло применять следующую ещё эффективнее. Мне кажется, весь этот инструмент у тебя настолько хорошо заработал именно потому, что ты до этого очень много всего автоматизировал и точно понимал, какие задачи и как автоматизировать, они уже были прописаны либо в Make, либо (n8n ты, я так понимаю, не использовал) в том же Make.

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

[15:49] Егор: Если пойти дальше, я точно понимал, что в нашем корпоративном travel-бизнесе нам нужно выстраивать продажи, PR, маркетинг. Пробовал разные отдельные сервисы по продажам, попробовали Apollo, непонятно было, что работает, данные не свежие; попробовали Lemlist для аутрича, потом ещё что-то, потом популярный тогда Clay, потом Clay Engineers. Захожу, опять ничего не понимаю: что с этим вообще делать? И я сел и подумал: окей, нам нужно доставать информацию по компании, по персоне, по LinkedIn обновлять данные, доставать email и проверять его, это, по сути, часть обвязки, которую тебе накидает даже обычный чат с Claude Code. Дальше это всё я собрал в единую систему, мы назвали её GTM Operation System, и туда перенесли все сценарии из Make. Между Apollo и Clay всё равно приходилось всё связывать через Make, и в какой-то момент, сотня долларов тут, сотня там, тысяча там, это стало какой-то невероятной историей. Потом нашли акторов на Apify, которые мы и раньше частично использовали через Make для парсинга, и вместе с Claude Code напилили собственный инструмент. А дальше этим нужно управлять, потому что информация постоянно поступает и её нужно проверять.

Егор: У нас нет истории, что нашим продуктом могут воспользоваться тысячи или десятки тысяч компаний. В enterprise мы не дотягиваем, а если говорить про микро- или малый бизнес, они обычно сидят на Booking.com, Skyscaner или вообще покупают билеты за мили; это не наш клиент, у них слишком мало сотрудников, кто вообще летает. Мы работаем в мид-маркете: для нас это компании примерно от 100 человек и, можно сказать, до 4000. Хотя когда там уже тысяча сотрудников, это часто какой-то завод, где 3500 человек в производстве и 500 обслуживающего персонала. И это компании с бюджетом от 1 до 10 миллионов долларов в год на travel, вот в этом сегменте мы и сидим.

[18:17] Егор: Таких компаний много, но людей, которые именно отвечают за travel в каждой компании, обычно один-два человека. И нам просто нужно следить за этими людьми. Даже если человек переходит в другую компанию, нам важно получить сигнал об этом и написать: "Я знаю, что ты пользовался нашим конкурентом, мы можем помочь внедрить наш продукт в новой компании." Нужно найти этот "аха-момент" перехода, это как с бухгалтерией: если ты сидишь на одном приложении, поменять его практически невозможно. Поэтому мы либо ищем новые быстрорастущие компании, либо ловим момент, когда конкурент "накосячил", и заходим со своим продуктом в этот момент.

Егор: Что мы сделали с sales, я собрал sales-агента, у которого есть доступ к нашему серверу, он вместе с Claude Code или Codex дорабатывает свой же продукт: у него есть доступ к базе данных, SSH-доступ к GitHub и так далее. Он дорабатывает себя, когда чего-то не хватает. Но у этого инструмента есть особенность, он всё равно просит разрешения на действия. Поэтому мы пришли к тому, что, например, cron в 8 утра проверяет, что пришло, и сохраняет в память, потому что можно удерживать контекст между запусками. Дальше второй шаг: в 9 утра следующий cron по цепочке обогащает найденных людей. Третий cron в 10 утра работает с уже обогащёнными людьми и понимает, подходят ли они под наш ICP. Я утрирую по часам, но суть в том, что мы разбили задачи так, чтобы система сама продолжала себя и приходила к какому-то результату.

Егор: Из последнего, всё равно приходится где-то проверять: что-то сломалось, какой-то актор Apify отвалился, или наш собственный вайб-кодинговый продукт сломался и вообще не запускается. Это ежедневная поддержка. В какой-то момент мы поняли: есть платформа и есть агент, который ею управляет, но из огромного количества данных его всё равно нужно "пинать" и давать разрешения. Я нанял девушку из ЮАР, которая сидит в чате и продолжает его пинать, поддерживать, давать указания и задачи. Она работает уже пару недель, и мы вышли на стабильный процесс, всё работает и не ломается. Когда приходят какие-то сигналы, она может даже сама зайти в LinkedIn, потому что инструмент не всегда может пройти Cloudflare без отдельного устройства вроде Mac Mini.

[20:40] Егор: В целом мне это обходится в 5 долларов в час, девушка может сама зайти под моим или своим аккаунтом и написать человеку уже заготовленное сообщение. Сейчас мы ещё пошли в тендеры: ищем все тендеры по travel в UK, США, Канаде и Европе, и там тоже огромное количество данных, нужно заполнять таблицы, проверять, подходим мы или нет. Система настраивается на то, чтобы искать не только людей, но и тендеры, и этот процесс тоже выстраивается дальше. Вот это касается sales. Сегодня у меня, наверное, около шестнадцати агентов, но самые крутые, это sales, partnership, SMM, lawyer и из интересного, аналитик. Вот такая топ-пятёрка. Можем пройтись по каждому.

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

Егор: Не живые не уволил. В B2B у нас всё равно будут живые sales, потому что люди тратят миллионы долларов и должны быть уверены, кому они платят, что сотрудники долетят и их не подведут в пути, это большая ответственность. Но по сигналам мы упростили расходы: было условно тысячи долларов подписок на все эти приложения, стало пару сотен долларов на токены, сервера и Apify. За сам Apify мы платим, по-моему, около 400 долларов, всё остальное, мелочи по 10-20 долларов, потому что Apify закрывает огромное количество сложных задач вроде парсинга LinkedIn.

[23:04] Егор: Из кейсов: раньше в Lemlist ты нажимаешь "enrich" по персоне, а там написано, что человек работает в такой-то компании, но если у тебя сотни или десятки таких контактов, ты не будешь проверять каждого вручную, работает ли он там ещё. И система пишет: "Сергей, ты работаешь в компании такой-то?" А человек уже давно там не работает, отвечает: "Я работаю в INXY, а не в этой компании." Формально ответ получен, но по сути это лёгкий негатив: "ребята, вы издеваетесь?" Кто-то получил такой сигнал и понимает, это рассылка без персонализации, никто ничего не почитал про меня как человека, это просто бездумно работающие роботы. Я сам, когда мне так пишут, иногда даже не отвечаю, а иногда отвечаю специально, чтобы остановить эту рассылку, нажимаю на заготовленную кнопку вроде "не интересно", просто чтобы прекратить поток.

Егор: Мы, прежде чем идти смотреть, кто этот человек и делать enrich, применили другой подход: у нас не так много людей, за которыми мы следим,, пока до тысячи. И мне проще запустить актор на Apify, который зайдёт и точно проверит, где человек работает прямо сейчас,, данные будут супер свежими. А ещё через акторов на Apify мы забираем отзывы с G2, Capterra, TrustPilot, что-то с Y Combinator и Crunchbase, чтобы получать сигналы. Например, по отзывам: если на площадке указано имя, иногда первая буква фамилии, иногда даже компания, и человек оставил негативный отзыв, обычно фокус на низких оценках,, это звоночек, что нужно постучаться. Мы пытаемся найти такого человека любыми способами, вплоть до поиска в Google, скорее всего на первой странице найдём его LinkedIn, сверяем, что компания существует и может покупать такой софт, и добавляем в систему слежения. Первое сообщение, коннект в LinkedIn с формулировкой: мы видели вашу оценку на Capterra, давайте пообщаемся.

[25:26] Сергей: А какой на это reply rate?

Егор: Мы это пишем прямо в тексте коннекта, а дальше уже общаемся. Когда коннект приходит пустой, скорее всего, ничего не произойдёт, человек проигнорирует; а здесь мы попадаем в его боль, и общение начинается, это увеличивает конверсию. Дальше нам всё равно нужны какие-то повторные касания с человеком: где-то прокомментировать, следить за его публикациями, где-то просто написать сообщение, а если он написал, что едет на конференцию, предложить познакомиться там. Кто-то недавно говорил, что пять и больше касаний с человеком любого рода, от того, что он увидел ваш стенд, до комментария под его постом, увеличивает reply rate или любой другой на 40%.

Сергей: Это в B2B стопроцентно так, человек тебя запоминает, и в следующий раз реагирует: "О, я про этих ребят слышал", а не воспринимает как шум.

Егор: Дальше из интересного, у нас есть partnership-агент. Мы уже относимся к нашим агентам как к реально живым сущностям, прикольно, что сразу давали им имена.

Сергей: Ты, кстати, имена давал?

Егор: Да, сразу мой помощник давал всем имена, там Чарли и так далее. Я подумал: блин, я не запомню, что Чарли, это наш CFO, а Чарли, это partnership-менеджер, давай их переименуем в то, чем они занимаются. Так и получилось: Analyst, Partnership, Sales, SMM и так далее. Ты чётко понимаешь, к кому идёшь, потому что в его identity написано, что он, условно, наш partnership-менеджер, это как бы его имя. Он пишет письма, общается с людьми, и когда ему предлагают созвониться, он отвечает: "Извините, я сейчас в отпуске" или что-то такое, но вот Егор, вот ссылка на его календарь, идите созванивайтесь с ним, я его предупредил.

[27:50] Егор: Имена я давал сразу, нашёл сервис AgentMail. Ребята, по-моему, из Y Combinator сделали продукт, почту специально для агентов. Начал с них, там три адреса бесплатно, но в итоге всё равно перешёл на наш Google Workspace: создал почту, отдал агенту доступ по SMTP и IMAP, мне показалось это удобнее.

Егор: У нас есть тема с виджетом для других платформ, ты можешь встроить наш виджет и зарабатывать процент на бронированиях через свою платформу поверх нашего контента. В первую очередь такие партнёры, это банки или финтехи, где travel становится дополнительным потоком дохода. У Revolut, например, есть раздел Travel для потребителей, для бизнеса такого пока нет. Пользователи зарабатывают баллы, которые можно тратить на travel, это тоже часть такой истории. Мы предоставляем такой продукт под white label либо виджетом. И вот partnership-агент проходится по всем банкам, маленьким и большим, находит их email, проверяет доставляемость письма через нашу систему GTM, там есть проверка доставляемости; есть, кстати, опенсорсный инструмент, кажется называется reacher, мы забрали его с GitHub, заменили платный сервис за условно 10 долларов в месяц, подняли на своём сервере в GTM, получили API и используем его во всех агентах.

[30:13] Егор: Дальше partnership-агент составляет письмо и сам отправляет его, либо через своё SMTP, либо через AgentMail, потому что мы завели ему ещё пару адресов, когда объём рассылок по банкам вырос.

Сергей: Слушай, а в спам не улетает? Мне кажется, немного рискованно ставить основной домен под такой аутрич.

Егор: Смысл в том, что мы говорим про банки, которых более-менее приемлемое число, сотня, отправить сотню писем и попикать это дальше не то же самое, что бить по тысячам. Дальше мы завели в этот же процесс HR-платформы, потому что им тоже нужен дополнительный travel-контент, и финтех-платформы, которые тоже что-то продают под white label или карты выпускают. Когда кто-то заходит в эту воронку и подписывает с нами контракт, я передаю это partnership-агенту, он строит look-alike на основе этой персоны и пишет: "Мы работаем с INXY, давайте подключим и вас", условно, по аналогии.

Сергей: Слушай, очень крутая идея.

Егор: Вот это и делает partnership-агент. Мы вышли примерно на один звонок в день по партнёрствам, получается что-то реальное.

Сергей: Получается, задача агента, найти, вовлечь и вывести на звонок с тобой, то есть провести всю цепочку до создания встречи. А насколько долго ты строил этого агента до продакшн-уровня результативности?

[32:36] Егор: Мне кажется, это бесконечный процесс, идеальной точки не существует. Но первые баги убираешь буквально за день-два, потому что агент, например, запускался раз в день, и обратная связь приходила не так быстро. Была история с кодировкой: он выбрал не ту кодировку, и в письмах появлялись какие-то нечитаемые символы вместо тире, долларов и процентов. Я пишу: "Что ты делаешь?", он отвечает: "Ой, я это даже не знал, что так будет", и переделал. Дальше, я думаю, за неделю-две довёл его до нормального состояния. Но вот вчера, например, он написал, что пришёл ответ от человека А со списком вопросов, и отдельно ответ от человека Б с таким же списком. Я отвечаю на эти вопросы, чтобы он занёс их себе в знания и мог отвечать сам в будущем. Смотрю, а мне пришло два письма с разными темами одним и тем же людям. Оказалось, один человек добавил в переписку второго, а агент не понял, что это одна цепочка, и продолжил её как две разные. Я говорю: "Давай ты будешь дальше проверять всю цепочку, а не просто последний ответ."

Егор: Я думаю, я попал в момент, когда подписку Claude отключили, Opus стал недоступен, и я тестировал, он свалился на модель 4o. Я не понял, почему он вдруг стал глупее, оказалось, что перешёл на GPT-4o mini.

Сергей: 4o mini, он прямо тупой, ужас, не понимаю, зачем его вообще выпустили, для каких задач.

Егор: Для простого парсинга каких-то данных он нормальный, но для интерпретации ответов, нет. То же самое с GPT-3.5 Turbo, чуть дешевле, но не годится, если не нужно ходить в интернет и так далее.

[35:00] Сергей: Это как раз та история, зачем выпускать откровенно слабый продукт, лучше сразу закрыть его и идти дальше. Хотя, с другой стороны, "омни", модель, которая должна воспринимать и аудио, и видео, и текст, но вопрос, как именно она это воспринимает.

Егор: В чате, да, но в API ты всё равно выбираешь отдельно Whisper или GPT-4 и так далее. Ну ладно, давай вернёмся к partnership. Сегодня я подключил ещё подписку Gemini и подписку Codex.

Сергей: Gemini Pro неплохой, прямо неплохой.

Егор: Конечно, не такой хороший, как Claude. Если проводить аналогию с наймом: хочешь хорошего сотрудника, а не джуниора, это Opus. Кто senior, я пока не знаю. А mid-level, это все остальные модели. OpenAI я вообще ставлю в джуниоры, потому что как ни крути...

Сергей: А Codex 5.3 последний не пробовал? Вроде неплохой.

Егор: Разница в том, что Codex всё время спрашивает: "хочешь, я это сделаю?" А Opus просто делает.

[37:27] Егор: Такая же история с обычным чатом ChatGPT, он спрашивает "хочешь, продолжу?", а я думаю: а зачем ты тогда вообще здесь, просто продолжай сам, тем более, что автономный агент обязан работать 24 на 7. Opus у меня однажды получил инструкцию, ответил: "Запомнил, вопросов нет." Потом что-то сломалось, я написал: "Либо я тебя отключаю из розетки, либо ты работаешь на меня." Он ответил "окей" и продолжил нормально работать, самостоятельно, сообщение за сообщением, пока не выполнил задачу.

Сергей: Мне кажется, если говорить в целом про Anthropic, они потеряли очень большой рынок. Могли бы ввести какую-то дефолтную подписку, скажем, за 200 долларов.

Егор: Или больше 500, большинство бы всё равно пошло на неё. Не понимаю, почему они этого не сделали, просто обрубили лимиты. Они же сами сначала говорили: только Opus, топ, всё остальное слабее, и затачивали продукт под Opus. Зачем так резко сокращать доступ? Это же не совсем open source, это инструмент, за который платят.

Сергей: Есть pay-per-use, но он очень дорогой.

Егор: Очевидно, что все игроки сейчас субсидируют цену, если выставить полную стоимость, никто не выдержит. Пока всё дорого. Я, например, за одну неделю дошёл до недельного лимита за 6 дней; чтобы система продолжила работать, доплатил сверху примерно 100-150 долларов за дополнительный usage.

[39:48] Егор: Просто чтобы не останавливаться. На следующей неделе я перестроил cron-задачи, часть перевёл на Sonnet, часть на GPT, и в итоге даже не дошёл до половины лимита подписки за 200 долларов. По-хорошему, если кто-то ежедневно упирается в лимит, ну, урежьте лимиты, ничего страшного, люди пойдут искать альтернативы, но зачем убивать подписку целиком? Такая же жёсткая история и с подходом OpenAI, и с Anthropic, Anthropic, помню, кого-то пытался засудить, а туда пришёл инвестор и сказал: "Вот тебе деньги, работай." Не понимаю, зачем так делать.

Егор: Я уважаю Anthropic как компанию, мне нравится, как модель пишет текст, как делает research, но не очень нравится, как она кодит. Codex мне нравится больше по коду, более системно, хотя я сам не разработчик и не могу это оценить профессионально. Ребята, которые пилили что-то для моего инструмента, показали, что Codex учитывает изменения в архитектуре точнее.

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

Егор: Похоже на то. Наши разработчики какое-то время сидели на Codex, потом полностью перешли на Claude Code, научились правильно писать промпты, делать планирование, вести MD-файлы с документацией. Сейчас они уже общаются между собой через такие файлы, "если будете использовать эту фичу через Claude Code, обратитесь к этому MD-файлу", и Claude Code сам понимает, что делать дальше. Вчера я отключил подписку ChatGPT за 20 долларов, отключил Gemini, отключил максимальную подписку Claude на личном аккаунте и написал: "Раз с этим завязали, я тоже ухожу."

[42:13] Сергей: А что в итоге оставил?

Егор: Оставил API-ключи pay-per-use для Opus и Sonnet, ChatGPT где-то используется для мелких задач. Вчера заплатил около 100 долларов за один день использования, всё лишнее, что тестировал, я убрал. Была ещё мысль не уходить в китайские модели, совсем не хотелось, начитался, что они слишком много собирают данных, и решил туда не идти.

Сергей: Слушай, но есть же MiniMax, которую можно локально развернуть.

Егор: Конечно, требует очень много ресурсов, а мне негде развернуть её локально, либо арендовать дроплет с GPU, а это будет стоить те же условно 100 долларов в день.

Сергей: Есть же Mac Studio с хорошими характеристиками, тоже можно так делать.

Егор: Сколько сейчас Mac Studio стоит?

Сергей: Тысяч 7 евро.

Егор: Это окупается месяца за 2-3, если убрать расходы на Opus.

[44:40] Егор: Я как раз последние пару дней общался с ребятами, которые тоже ищут альтернативы, и мне посоветовали китайскую модель Z.ai (GLM), которая в первую очередь заточена под программирование и сравнивает себя с Claude Opus. Запустили вчера, я даже переспрашиваю: точно ли это отвечает не Opus, а эта модель? Он говорит: "Да, нравится." Работает реально хорошо, а подписка стоит около 30 долларов.

Сергей: А MiniMax тоже подписка примерно за 20 долларов на большой объём токенов?

Егор: Пробовал, но у меня она работала не очень. А вот последняя модель Z.ai, прямо порадовала за ночь, что она успела сделать.

Сергей: То есть по качеству близко к Opus?

Егор: Очень близко, даже стиль ответов похож, структурированный. У Opus ответы человечные, а у ChatGPT более "железное" ощущение.

[47:07] Егор: Когда переключаешься на ChatGPT после Opus, прямо неприятное чувство, как будто была нормальная служба поддержки, а теперь пришёл кто-то незаинтересованный.

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

Егор: Основная причина смотреть в сторону китайских моделей, безопасность и передача данных, особенно если это касается договоров и пользовательских данных под GDPR. Нужно ещё подумать, как правильно организовать переход. Возможно, буду платить за тройку топовых агентов подпиской Opus, а остальные переведу на более дешёвые модели, там 12 агентов, из которых пять топовых, и получается, что тратишь условно 600 долларов на человека, это уже цена мини-сотрудника из ЮАР за 5 долларов в час, вполне нормальный ценник, при этом модель сильно умнее человека на такой позиции.

[49:33] Егор: Поэтому локальную модель мы точно рассмотрим. Сейчас делаем себе крутого AI-агента на нашу travel-платформу, сделали MCP-сервер для AI-агентов, чтобы пользователь мог подключить своего агента, и он работал с нашим контентом и аккаунтом, бронировал сам. Соответственно, техподдержка меняется: сегодня стандартная техподдержка с AI использует Knowledge Base и закрывает первую линию, процентов 30 запросов, а 70% всё равно падает на человека. Мы хотим поменять вектор так, чтобы агент мог сам поменять билет, поменять или отменить отель, забронировать перелёт, то есть быть таким же проактивным, как наш основной инструмент со своими cron-задачами. А для этого, если работать внутри своей платформы с собственными данными, нужна либо локальная модель на своём сервере, либо использование Opus в Anthropic с явным описанием клиентам, куда передаются данные.

Сергей: Через API они вроде бы ничего никуда не передают, pay-per-use не идёт на обучение модели.

Егор: По крайней мере, так написано, надо перепроверить. На платформе OpenAI, когда получаешь ключ, есть опция, согласиться, что твои запросы используются для обучения, взамен на скидку в 30-50% на usage. Про Anthropic я эту часть не проверял, предположил, что аналогично.

[51:58] Сергей: Это точно стоит перепроверить, то, что я читал месяца четыре назад, было, что API у Anthropic не используется для обучения.

Егор: Ты прав, перепроверим. Пока мы движемся к подключению Opus во внутренний чат, который будет управлять заказами клиентов и всем остальным, потому что мы уже пробовали делать customer support раньше, и по ощущениям всё, что было "до Opus", было каким-то так себе продуктом, не хотелось тратить время и силы, обучать сотрудников и клиентов. Поэтому мы остались на базовом варианте: звонок или сообщение, и мы помогаем людьми.

Сергей: Ты слышал, что Anthropic выпустили новую модель, пока в тестовом режиме, и она нашла столько уязвимостей, что её испугались выпускать в общий доступ, вроде название что-то вроде "думающий", по-моему, анонс был 7 апреля.

Егор: По-моему, её выпустили только для крупного enterprise, в общий доступ не отдают.

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

[54:28] Сергей: Давай подумаем с точки зрения твоего практического бизнес-опыта: в каких бизнесах такой подход применим вообще, где разумен, а где нет? Чтобы зрители поняли, стоит ли им на это тратить время.

Егор: Я думаю, применимо ко всем, вопрос, что именно внедрять и как улучшать. Многие думают, что улучшение агента идёт через программирование, но на самом деле оно идёт через простое общение с ним: спрашиваешь, как можно улучшить, просишь варианты, и это рабочий подход, доступный любому человеку. Больше всего применимо, наверное, в генерации контента и его дальнейшей публикации. Самое интересное, что в отличие от обычного общения с Claude или ChatGPT, где контекст быстро теряется, наш инструмент держит контекст: кто ты, что ты делал, что выстреливало, а что нет. Когда он пишет тексты для SMM, интересно читать даже самому, открываешь и думаешь: вау, это я написал?

Сергей: Егор, здесь важно сказать, что из коробки память у него так себе, он забывает, начинает "тупить", фактически не работает без донастройки.

[56:49] Егор: Да, его нужно дорабатывать, файнтюнить, брать лучшие источники из открытых материалов. Как ты правильно сказал, постоянно заставлять его мониторить лучшие решения на рынке; я добавляю ещё то, что выходит лучшего в опенсорсе. Объединяешь эти данные, и тогда начинается магия. Ещё один лайфхак, который реально помог: мы все очень долго общались в ChatGPT, у меня накопилось около 30 000 чатов. Можно зайти в ChatGPT и сделать экспорт всех своих данных, через день-два присылают архив.

Сергей: А в Claude такое есть?

Егор: Не уверен, я не проверял именно в Claude, но, наверное, есть, экспорт данных перед удалением аккаунта обычно обязателен по закону. Я скормил все эти данные своему основному агенту и сказал: теперь ты знаешь обо мне намного больше, распредели это по памяти, и мы уже с первого дня общались как старые знакомые.

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

[59:14] Сергей: Но теперь нужно придумать, как с ними работать, все данные забирают в LLM и работают с ними. Второй пример, выгрузка всех своих чатов и перенос этого другому агенту, чтобы он их сам проиндексировал. У меня тоже было много интересных кейсов: кто-то собирал свои знания в Cursor, кто-то, в Obsidian. Любое место, где у тебя есть выгруженная база знаний,, идеальный источник для обучения собственной модели.

Егор: Согласен на все сто.

Сергей: А если говорить про других агентов, ты рассказал про двух, какие ещё юзкейсы хорошо работают? Контент, это SMM, продажи, это аутрич и partnership, чуть разные подходы. Расскажи про юриста, потому что тут, в Штатах, юристы очень дорогие.

Егор: Давай дойдём до юриста. Я стараюсь дробить агентов так же, как дробим людей, которые выполняют разные задачи в компании. Sales-агент теоретически может продавать всё, но мы всё равно нанимаем отдельного человека под UK, отдельного под Европу, так и с partnership: когда мы начнём продавать партнёрство отдельно банкам и отдельно HR-платформам, это тоже будут два разных "агента" со своими данными, но с возможностью объединять знания намного быстрее, чем люди обмениваются опытом на перекуре.

[61:45] Сергей: Кстати, мы недавно с Ильёй Красинским обсуждали, что главная проблема больших корпораций, это именно передача знаний: все эти многочасовые совещания по сути нужны только для того, чтобы все были в едином информационном поле. Это можно исключить, если, во-первых, знания собираются автоматически и расшариваются между всеми, а во-вторых, если за это отвечают агенты, которые и так всё знают.

Егор: Возвращаясь к другим ботам: у lawyer-агента, кстати, мы обсуждали еженедельный self-learning, но по факту ничего особо не менялось. Сначала поставил раз в две недели, тоже показалось, что толку немного. Сейчас, когда объём общения вырос, я поставил self-learning на раз в месяц: пусть лучше реже, но качественнее пройдётся.

Сергей: Кстати, ещё один лайфхак: я делал похожее с локальной моделью, когда она стоит на локальной машине, это сильно проще. Ставишь Codex или Claude Code, указываешь, где исходники, и через него обогащаешь модель, подписка в этом случае существенно дешевле. Ты даёшь ему все данные, он всё прописывает как нужно, а потом ты уже используешь своих ботов, сильная экономия на usage без нарушения правил.

[64:09] Егор: Вчера ребята в чатах тоже рассказывали похожий подход: делаем skill вместе с Claude Code, полируем его, отдаём в наш инструмент, который уже точно работает верно и использует условно Sonnet или другую более дешёвую модель, потому что мы его уже довели до ума через Claude Code. Тоже классная тема, и это никак не нарушает правила использования, при этом он видит весь контекст: исходные данные, MD-файлы. Просто говоришь: "изучи это", он идёт, читает, спрашивает, и дальше работает сам. У меня Codex и Claude Code запущены параллельно, я их сравнивал, Codex мне чуть больше понравился по манере работы, хотя это, конечно, субъективно.

Сергей: То есть можно и так, и так, разницы почти нет.

Егор: Lawyer-агент у нас проверяет все договоры, смотрит, что мы можем сделать, заполняет договоры, отправляет письма. Мы организовали это через субагентов со своим workspace и identity, и дальше в Telegram я делаю не общий тред, а отдельные групповые чаты, куда добавляю коллег.

[66:36] Егор: Когда у коллег что-то приходит, они отправляют это в чат lawyer-агента, и он с ними работает. Одна проблема, с которой столкнулись: если один запрос ещё обрабатывается, второй встаёт в очередь. Но это решается дальнейшим дроблением чатов; пока объём небольшой, ребята готовы немного подождать. Самое главное, агент запоминает, что мы делали, что нам говорили другие юристы по сделкам, что нужно поменять, и держит на основе этого свою базу знаний, договоров и практики. Плюс мы сделали ему отдельные skills по праву США, по праву UK, которые он использует и дорабатывает.

Сергей: Соответственно, ещё и по штатам, наверное, есть разница?

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

Сергей: Из другого агента, расскажи про аналитика.

Егор: Аналитику я дал skills продакт-менеджера, и он может делать качественные deep research с учётом всего, что мы уже собрали: если запускать обычный deep research через Perplexity или напрямую через модель отдельно, это будет уже другой контекст без знания о нас, а аналитик через наш основной инструмент, который знает про компанию всё, выдаёт достаточно качественный бизнес-план, который можно использовать дальше.

[68:57] Егор: Ещё аналитик проверяет отзывы через Apify, что пишут плохого про нас в Google Play и App Store, а также про конкурентов, которых он сам нашёл, и еженедельно присылает отчёт. Например, у конкурентов постоянные проблемы со входом, пользователей постоянно разлогинивает, и решение, не разлогинивать пользователя на устройстве без необходимости. Он собирает это и отдаёт мне; я прошу его сразу заводить отдельные задачи в Notion или в бэклоге, потому что это реально ценная вещь, сотни людей жалуются на такие проблемы у конкурентов. По сути это продуктовый анализ, который подсказывает, что делать с продуктом.

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

[71:20] Сергей: А важно, ты дал ему доступ только на чтение, верно?

Егор: Да, верно, только на чтение. Всю отправку он делает через отдельное SMTP там, где это нужно. Чуть позже я дал ему ещё доступ на выставление лейблов в почте, чтобы он мог приоритизировать входящие письма, сотрудник приходит на работу, а письма уже расставлены по важности, это тоже очень удобно. Дальше он ежедневно читает все письма, определяет, где у нас проблемы, а где возможности, и подсказывает, если мы что-то упустили, такое бывает даже с нами самими, хотя я обожаю пустой инбокс и стараюсь держать его в порядке, но всё равно можно что-то пропустить. Второе, он обучается на этих письмах и подсказывает, что можно добавить в Knowledge Base, что доработать в продукте, это уже роль скорее продакт-менеджера. Третье, раз мы говорили про данные, он забирает все данные из почты, обучается на них и сохраняет в общую Knowledge Base. Дальше я могу сказать другому агенту: "Сходи посмотри, мы что-то обсуждали с INXY по такому-то поводу, что там было", и он через сервисный аккаунт находит эту информацию.

Сергей: А звонки ты ему тоже скармливаешь, расшифровки?

Егор: Ты имеешь в виду телефонные звонки?

Сергей: Ну да, телефон, Skype, если есть звонки с партнёрами, расшифровываешь ли ты их и заносишь в базу, в CRM?

[73:48] Егор: Конечно же, для обучения, да, но в нашей истории мы это пока не делаем, потому что таких звонков очень мало, и когда доходит до демо, там обычно одни и те же типовые вопросы: как сделать travel-политику для сотрудников, как настроить согласование, как оплачивать. Эти базовые вещи уже собраны в Knowledge Base. В целом хорошая идея добавлять и это, но есть и обратная сторона, не приведёт ли это просто к засорению базы. Поэтому в нашем случае мы этого не делаем.

Сергей: Понял логику. У нас всё наоборот, очень много звонков с клиентами, в основном через Zoom, Skype, Google Meet, и основная масса общения там, а уже после демо идут переписки, то есть у нас немного другой поток, но логику я понял.

Сергей: А сервисный аккаунт, получается, читает почты всех сотрудников, на которых ты его натравил, и мониторит происходящее?

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

[76:13] Егор: Раз все агенты имеют доступ к этому сервисному аккаунту, у меня в чате разработчиков сидит отдельный dev-агент. Как это было: разработчик написал вечером, "уже поздно, пойду отдыхать, завтра посмотрю и отпишусь, что у нас есть по списку." Я подумал: подожди, у нас же вчера подключился этот аккаунт, и написал основному агенту: зайди на почту такого-то сотрудника и посмотри, что там было, найди, у кого что было, и дай нам ответ. Так как он читает весь контекст в Telegram и хранит все сессии, ему можно просто сказать: "Сходи на почту Вани", через сервисный аккаунт Google, "и найди." Это заняло секунд десять, он нашёл список того, что нужно сделать. Я попросил: используй мой SMTP через мою почту, поставь в копию всех, кого нашёл в переписке, и самого Ваню тоже, и напиши, что у нас новый IP-адрес. Мы просто сидели в Telegram и смотрели, как он всё это отправляет. В итоге не пришлось ждать до завтра, задача, на которую человек потратил бы время утром, была сделана за 2 минуты.

Сергей: Вот это классный юзкейс, как можно снять человеческий фактор: мы все люди, устаём, не можем работать 24 на 7.

[78:42] Сергей: Давай подумаем с точки зрения первых шагов, какие бы ты дал рекомендации тем, кто только хочет попробовать этот подход, какие юзкейсы стоит начать, чего избегать?

Егор: Когда я разбирался в no-code, у меня был точно такой же вопрос: окей, здесь тысячи разных интеграций, что делать? Я всегда советовал: берём лист А4 и ручку и просто садимся записывать, какие кейсы мы можем автоматизировать, записываем абсолютно всё, а дальше это уже можно скормить любому инструменту. Раньше, если это был код, приходилось придумывать последовательность самому; сегодня мы запускаем первого агента, и пока больше ничего специально делать не нужно. Первого агента делаем на топовой модели и не переживаем о стоимости, потому что первые недели, пока у тебя нет шестнадцати параллельно работающих агентов, счёт не будет огромным, лучше сразу обучать на лучшей модели, любым способом получить доступ к топовой модели.

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

[81:08] Сергей: Вот тут я как раз хотел сказать то же самое, там реально много всякой шелухи, поэтому важно, чтобы твой инструмент сам посмотрел на скачанный skill и переделал его под тебя, потому что внутри может быть что-то вредоносное, и это нужно пересобрать заново.

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

Сергей: Моя главная рекомендация, поставить инструмент как можно быстрее. Если это локальная машина, кстати, туда по SSH тоже можно запустить Codex или Claude Code, чтобы он помогал настраивать и фиксить баги. Для меня лично это был настоящий geim-чейнджер: раньше что-то крашится, сам перезапускаешь терминал, разбираешься. А теперь пишешь: "бро, помоги", он запускает диагностику, перезапускает, и через пять минут всё готово, хотя раньше на это уходила неделя мучений.

Сергей: Кстати, по поводу Z.ai, ты его настолько рекомендуешь тестировать прямо сейчас, или пока рано говорить?

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

[83:32] Егор: Пока могу сказать, что работает очень хорошо. Ты, наверное, тоже замечал: когда переключаешься с Opus на GPT, сразу думаешь, кто здесь начал "тупить"? Я, инструмент, новое обновление или кто-то ещё? Но по факту это просто вопрос модели, которую нужно правильно использовать, а наш инструмент, это просто оркестрация, которая помогает правильно организовать работу внутри.

Сергей: Кстати, для всяких простых cron-задач вообще бессмысленно гонять через Opus, только жрать токены зря. Для действительно важных задач, да, а для рутинного мониторинга конкурентов, например, зачем тебе такая дорогая модель? А вот выводы из того, что намониторили и спарсили, это уже задача для сильной модели.

Егор: Я тоже про это думал, хотел оставить Opus на самое важное, а остальное перевести на Sonnet или Haiku. Стало не 100 долларов, а условно 70, разница не критичная, потому что и Opus, и остальные всё равно "едят" много при таком объёме: у нас не десятки писем, а сотни, за 24 часа приходит по 300-500 писем со всех почт.

[86:00] Сергей: Кстати, зря ты так про Sonnet, это очень хорошая модель, новый Sonnet прямо хорош.

Егор: Да, ты прав, но он тоже недешёвый, в два раза дешевле Opus, но на наших объёмах это всё равно много. В итоге решил протестировать подписку Z.ai. Надеюсь, что через какое-то время либо Anthropic доработает то, что мы обсуждали, либо выйдет новая американская модель, которую можно будет использовать вместо китайской, потому что от китайских моделей я всё равно постараюсь уйти как можно быстрее, просто не хотелось резко отключать наш основной инструмент и всё, что мы построили за последние два-три месяца.

Сергей: Тем более что это настолько классно работает, обидно было бы это потерять.

Егор: Да, я даже думал перейти на вайб-кодинг поверх Claude Code, добавить туда нужные скиллы, воркеры, поставить dispatch, но это заняло бы неделю-две на переезд, и при этом всё равно не факт, что будет работать 24 на 7 так же стабильно, как сейчас. У тебя, кстати, была своя похожая связка с памятью на Claude Code и Codex, с этой базой LDB, которая работает.

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

[88:24] Егор: У меня тоже такого нет. Ещё один довод, почему хочется оставаться именно на нашем инструменте, а не переходить полностью на вайб-кодинг или другую подписку: в нём можно добавлять устройства-ноды, которые у тебя уже есть. В том же Claude ты платишь за минуты использования стороннего компьютера, плюс не можешь переключаться между разными моделями, остаёшься завязан только на одного вендора. Кстати, мне понравилось, что Microsoft на своих моделях сделали так, что research делает одна модель, по-моему, модель Anthropic,, а проверяет её ChatGPT. Идея верификации двумя моделями реально классная, а у нас можно и четырьмя моделями результат прогонять.

Сергей: Логично, что и модели специализируются по-разному. Тот же Z.ai, как я понял по их сайту, фокусируется в первую очередь на разработчиках, не только на коде.

Егор: Perplexity фокусируется на быстром поиске информации, как Google.

Сергей: А Grok очень круто парсит X, всю базу данных X он помнит почти идеально, особенно когда нужно что-то проверить и обогатить контекстом.

[90:50] Сергей: Кстати, недавний кейс: проверяли скриншот из X, ChatGPT сказал, это фейк. Мы подумали, что клиент дал нам это как пруф, что у него якобы крутой продукт, и там Илон Маск что-то прокомментировал. Проверяем через ChatGPT, говорит, фейк. Мы уже думали, что хороший человек нас обманул. На всякий случай проверили через Grok, он сказал: не фейк, вот источники. А ChatGPT пока непонятно, на чём фокусируется, как будто пытается охватить абсолютно всё сразу, и именно из-за этого не всегда хорош, в прошлом месяце добавляли что-то медицинское, потом что-то для юристов, потом делали платежи внутри чата, потом отключали, потом снова возвращали в другом виде, что-то не совсем понятное с фокусом продукта. А Opus, как серьёзный собеседник, с которым приятно общаться.

Егор: Полностью согласен с точки зрения общения. Каждая модель должна фокусироваться на своей нише и делать это круто, а не пытаться охватить всё. Надеюсь, Anthropic не свалится с их системой оркестрации агентов на своей платформе, я вчера посмотрел на это и подумал, может, туда перейти, но спросил у самой модели, работает ли это по подписке или по pay-per-use за токены, оказалось pay-per-use. Я сказал: до свидания.

[93:14] Сергей: Давай закругляться, у меня для тебя есть два вопроса напоследок. Первый: если бы вернуться назад лет на 3-5, что бы ты изменил, сделал по-другому?

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

Сергей: Клёво. А если на два года назад что-то бы себе посоветовал?

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

[95:38] Егор: Мы и сейчас так делаем: приходит клиент, сразу отправляем ему все ресурсы, чтобы быстрее запустить и дать нужный контент. Вывод: продавай сегодня быстрее, чем занимайся доработками и файнтюном. Наверное, с нашим AI-инструментом та же логика: запускай и тестируй, а не докручивай бесконечно в ожидании, что что-то станет "идеальным."

Сергей: Отличный инсайт. Второй вопрос похож на первый: если вернуться на несколько лет назад, что точно не стоило бы делать?

Егор: Точно не стоило распыляться на разные ниши, бизнесы и возможности, которые к тебе приходят. Если нашёл то, что работает, как у нас с travel, а мы знаем, что рынок корпоративного travel это 1,7 триллиона долларов и он продолжает расти,, нужно фокусироваться. Я сам поздно начал убирать всё лишнее, что забирало время и энергию.

[98:07] Егор: Сегодня мы фокусируемся только на travel, только на своём продукте, улучшаем, развиваем, ищем новые доработки, а всё остальное просто продаём или закрываем и не тратим на это силы. Если есть рабочая тема, которая растёт и даёт всё нужное, а рынок практически бесконечный,, нет смысла искать что-то ещё, распыляясь на "здесь заработаем немного, там немного." Лучше фокус на одном, без распыления на новые ниши.

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

Егор: Да, действительно удивительно, в классное время живём.

Сергей: Спасибо тебе ещё раз, Егор.

Егор: Спасибо тебе, Сергей, за приглашение на твой подкаст No Bullsh!t, классное название. Желаю тебе развития и больше подписчиков. Подписывайтесь, будем искать новых людей и помогать Сергею находить тех, с кем можно ещё пообщаться.

Сергей: Спасибо, давай, на связи.

Егор: Пока-пока.

[00:00] Egor: We peaked at a hundred and fifty thousand operations a month in Make. We've barely hired anyone in almost two years now. Today I probably have around sixteen agents, but the standout ones are sales, partnership, SMM, and — this is the interesting part — lawyer and analyst. That's my top five, the ones carrying the main load. I wrote Opus a single instruction once, and it said: got it, no questions. Then something broke, and I wrote to it: either I unplug you, or you work for me. It replied: okay, and just kept working normally. It holds context: who you are, what you've done, what worked and what didn't.

Sergey: Friends, welcome to the No Bullsh!t podcast. Business without the varnish, where we talk about real business problems and how to solve them. Please don't forget to subscribe to the channel, like the video, and leave a comment so other entrepreneurs can find it too. Also subscribe to our Telegram channel, where we post extra material for every episode and where I talk about how we're building our own business. Today our guest is Egor Karpovich, co-founder and CEO of his travel company; right now he's in the US, in Miami specifically, though he lives in New York. Egor, great to see you.

Egor: Yeah, hi Sergey, hi everyone.

Sergey: Today we're going to talk about a really interesting topic — Claude Code and how it's used in business, because Egor's case is one of the most interesting ones I've seen involving Claude Code, where it's genuinely integrated into the business and replaces employees, helps build and sell. We'll get into all of that in detail today. But as usual, let's start with your story. How did you get to where you are now? Please walk us through your path in more detail.

Egor: I started way back in 2012-2013 with outsourced development — selling mobile development to others, and doing computer repair on the side. I call it fast money and slow money: fast is when you can make 20 dollars in 20 minutes, and slow is when it's 20,000 dollars but it takes half a year of work.

[02:41] Egor: After the first crisis in 2014, we started building our own products. I brought in investors, and outsourcing stopped being interesting: when you build a mobile app for, say, the same 20,000 dollars, and you see people in analytics making hundreds of thousands, you realize — we did this in a couple of weeks or months, and those guys are doing something else entirely, and a different world opened up for us. After that I sold the team on the idea that we'd build our own products, and from around 2014 to 2017-2018 we did exactly that — completely different things, from a women's diary app to a smart home, from a cashier-less store to e-commerce, because we were basically chasing whatever hype was around and riding it. After that I left that company (it was called Devment) and went to build a coworking space in Minsk. Today it's called Campus, a Class A business center, one of the first in Belarus to really establish itself that way. Then, at the end of 2019, beginning of 2020, I met my future wife Alina and joined her travel business. From there I turned it into a tour operator and a corporate travel management company — a company purely for business trips. We manage all the business travel for our client companies. That's roughly it, in short.

Sergey: That's great, thank you — that was a real pitch-style rundown, tight, five minutes flat. Thank you, Egor. Okay, so our second segment is traditionally about mistakes, failures, screwups. Tell us maybe three vivid failures that fundamentally changed your life or strongly shaped your path and outlook.

Egor: I can probably recall two for sure right now. The first was that crisis we ran into early on — I was about 21 at the time, give or take. We were writing contracts in Russian rubles, but in Belarus salaries were paid in dollars, and the conversion was always done in dollars — in Belarus everyone was used to that currency as a stable benchmark, everyone counted through it. When the crisis hit, you wake up and the exchange rate, which had been roughly 30, is now 70, and you have no margin left at all, nothing but losses. Lesson: if you're working in a given market, you need to look right away at what currency your expenses are in, and convert all your contracts and orders into that currency by whatever means. For us, that actually turned out well, because it pushed us to pivot into product development, start looking for experts, and apply knowledge in finance, IT, and marketing.

[05:58] Egor: The second story — we spent a year or two building our first product and never really brought it to market properly, and when we did, we weren't collecting analytics and didn't understand what was happening. Later we learned about customer development, that you need to do it right away and only then move forward. The failure was that we spent a huge amount of money on development and then just shut the product down, because we hadn't solved a single user problem, even though everything about it was legally and architecturally correct. Roughly speaking, in 2014 we spent hundreds of thousands of dollars that we could have saved if we'd killed the failing product faster and moved on. The lesson: we introduced a KPI at the company — launch a new product every month, hand it to marketing, run traffic on it; if it takes off, we work on it, if it doesn't, we shut it down immediately and don't drag it toward some hoped-for result. That's how we launched dozens of products, and after a year or two, once we'd built up a stack of ready-made modules, we could launch much faster. So those are the two failures and the lessons from them.

Sergey: Both of those really resonate. I had a similar experience buying my first car in dollars — same period, exactly when the dollar spiked, and I was paying for a Ford Focus like it was a Bentley, getting upset every single time. And the second case is also very common: when you spend a long time building something, you start to love the product and lose objectivity, you get attached, and even once it's basically dead you keep trying to drag it along. Thank you so much for sharing that, Egor. Now let's talk about your current company and the setup you built with Claude Code. Tell us how you got there — a lot of people are afraid to try a new tool, especially applied to business. How did you start, what did you test, what took off, what didn't, how did you get it all working, and what were the results?

Egor: Let's take two steps back first.

[08:28] Egor: We had, and still have, a development team. But I always wanted to move faster, especially back when our KPI was one product a month. I even thought: we can't hire a new developer, because it's unclear what things will look like in 2-3 months, even though on the whole every three months something would pay off, cover the previous costs, and start earning. I even tried getting into development myself, tried to help the guys, build some dashboards and analytics, but it didn't work out, it's just not for me. I understood the structure, the IP, the key, the documentation, but I'd get stuck on some really basic things. Then no-code showed up, that was roughly 2019-2020, with drag-and-drop — we started with Zapier. We did some things through Zapier, but it's a very narrow task, connecting one app to another, because Zapier is a linear thing. Then Make came along, where you could visually build a scenario, with a router, with branches. I even showed it to our developers, and they said: oh, that's just an if-condition we use, except here it's all laid out visually. Then n8n showed up, I poked around in it, looked at it, but by that point I already had hundreds of different scenarios in Make — I'd automated finance, call transcription, CRM integrations. We peaked at a hundred and fifty thousand operations a month in Make, a huge volume of data being processed and added.

Egor: I always had this habit: I'd go to a sales conference, hear what a head of sales is supposed to do, write it down, and then come back and automate that process in Make. For example: a call gets transcribed, the information needs to go into the CRM, get logged for the manager, fill the CRM with what was said on the call. But none of that would have been possible without LLMs. And once Perplexity and OpenAI showed up, it became incredibly convenient: you have unstructured data, a call transcript, you feed it into OpenAI, describe the task, and get back an answer that's already structured, in JSON, and then you can work with that and fill in whatever you need.

[10:54] Egor: Then, in 2023, the term "vibe coding" appeared — I think it caught on in 2024. By then everyone was saying the most popular programming language is English, and work turned into almost a 167-hour week, because everyone's just sitting there building things. We started vibe coding too: I wrote myself various apps that we used to pay for — for example, a document-to-PDF converter, which you'd otherwise pay a third-party service something like 10-30 dollars a month for. Now you spin up something like that from open source, add an API, and use it in Make for free, on your own server. There are tons of examples like that. And once we'd gone from simple linear automation to structured automation, and then to vibe coding, you start to understand what's happening in the company and what you actually need. We even told HR: if someone from a department comes to you and says they need to hire a person, first have them describe the process that position would be responsible for, and we'll try to cover that function with vibe coding. In practice, an extra hire often just wasn't needed. For the last two years we've barely hired anyone — it's just occasional, one-off positions now.

Egor: If in December we thought we'd just keep vibe coding along the same path, everything changed in January: a tool came out that I'll refer to as OpenClaw, built by a single developer who'd been working on it alone for a while. I have a habit of checking Twitter before bed, reading what's happening in the world, in politics, in tech. And I saw everyone talking about this tool. It had had a few other names before that — first one thing, then cloud-bot, then something else, I honestly don't remember all of them. I didn't sleep for three hours, I thought this was a real game-changer, that finally you could build agents that would work together with each other and carry out autonomous tasks on their own.

[13:24] Egor: I was testing some new AI tool literally every week, but I never found anything like this. Maybe someone else had found something similar, but for me it was important that everything be in one format, especially since we work as a company partly in Telegram and partly in Slack — I wanted to be able to connect from there and give it tasks, instead of opening up a third separate interface. When everyone started spinning up similar setups on top of OpenAI, I'd go check them out, poke around, and understand nothing: if I can't figure it out on the first or second try, it's definitely not going to reach the masses. And that's how we got to this tool — we've been working in it for three months now.

Sergey: That's an incredibly interesting story. I really like that it was all gradual — every time you rolled out a new technology, you learned its strengths and its limits, and that let you apply the next one even more effectively. I think this whole tool worked so well for you specifically because you'd already automated so much before that and knew exactly which tasks to automate and how — they were already mapped out, either in Make or (I take it you didn't use n8n) in Make itself.

Egor: Exactly right. Even the very first task I gave the new agent was: go into Twitter every day and find out who's done what with this tool, because without that kind of exposure you won't even come up with what to do. Take the head of sales role — okay, we know their job: pull together reports. How do you automate that? You go, you build it, you gather it, you've replaced one of the functions. But you still have to sit down and do the work of replacing things; and that exposure has to be there, otherwise, with your eyes glazed over from your own day-to-day operations, you'll never think to automate it.

[15:49] Egor: Taking it further, I knew for certain that in our corporate travel business we needed to build out sales, PR, marketing. I tried various standalone sales tools — we tried Apollo, and it wasn't clear what actually worked, the data wasn't fresh; we tried Lemlist for outreach, then something else, then the then-popular Clay, then Clay Engineers. I'd open it up and again understand nothing: what am I even supposed to do with this? So I sat down and thought: okay, we need to pull information about the company, about the person, update data from LinkedIn, get the email and verify it — that's essentially the kind of scaffolding even a plain chat with Claude Code will sketch out for you. From there I put it all together into a single system, we called it the GTM Operation System, and moved all the Make scenarios into it. We still had to connect everything between Apollo and Clay through Make, and at some point — a hundred dollars here, a hundred there, a thousand there — it turned into this absurd story. Then we found actors on Apify, which we'd already partly been using through Make for parsing, and together with Claude Code we built our own tool. And then you still have to manage it, because information keeps coming in and it has to be verified.

Egor: We don't have a story where our product could be used by thousands or tens of thousands of companies. We don't reach enterprise scale, and if we're talking micro or small business, they're usually on Booking.com, Skyscanner, or they just buy tickets with miles; that's not our customer, they have too few employees who even fly. We work in the mid-market: for us that's roughly companies from about 100 people up to, let's say, 4,000. Although once you're at a thousand employees, that's often something like a factory, where 3,500 people are on the production floor and 500 are support staff. And these are companies with a travel budget of 1 to 10 million dollars a year — that's the segment we operate in.

[18:17] Egor: There are a lot of companies like that, but the number of people who are actually responsible for travel at each company is usually one or two. And we just need to keep an eye on those people. Even if a person moves to another company, it's important for us to catch that signal and write: "I know you used our competitor's product, we can help you bring our product into your new company." You need to find that "aha moment" of transition — it's like accounting: if you're on one piece of software, switching it is nearly impossible. So we either look for new fast-growing companies, or we catch the moment when a competitor drops the ball, and we come in with our product right then.

Egor: What we did on sales — I put together a sales agent that has access to our server, and together with Claude Code or Codex it works on improving its own product: it has database access, SSH access to GitHub, and so on. It improves itself when something's missing. But this tool has one quirk — it still asks for permission before taking action. So we ended up with something like: a cron job at 8 a.m. checks what's come in and saves it to memory, because context can be held between runs. Then the second step: at 9 a.m. the next cron job, in a chain, enriches the people it found. A third cron job at 10 a.m. works with the already-enriched people and figures out whether they fit our ICP. I'm simplifying the hours, but the point is we broke the tasks down so the system keeps itself moving toward some result on its own.

Egor: On top of that, you still end up having to check things — something breaks, some Apify actor stops working, or our own vibe-coded tool breaks and just won't run at all. That's day-to-day upkeep. At some point we realized: there's the platform and there's the agent that runs it, but with this huge volume of data you still need to keep "poking" it and granting permissions. I hired a woman from South Africa who sits in the chat and keeps poking it, supporting it, giving it instructions and tasks. She's been doing it for a couple of weeks now, and we've reached a stable process — everything works and doesn't break. When some signal comes in, she can even go into LinkedIn herself, because the tool can't always get past Cloudflare without a separate device like a Mac Mini.

[20:40] Egor: All in all this costs me about 5 dollars an hour — she can log in under my account or her own and send a person a message we've already prepared. Right now we're also moving into tenders: we're looking for every travel-related tender in the UK, the US, Canada, and Europe, and there's a huge amount of data there too, forms to fill in, checks on whether we qualify or not. The system is set up to look not just for people but for tenders as well, and that process is being built out further too. That covers sales. Today I probably have around sixteen agents, but the standouts are sales, partnership, SMM, lawyer, and — the interesting one — analyst. That's the top five. We can go through each of them.

Sergey: Yeah, let's dig into each one. Sales is especially interesting, because that's the tightest bottleneck in any company. Tell us how you set it up, what works, what doesn't, what the nuances are, and do you still have live salespeople, or did you let everyone go?

Egor: We didn't let anyone go. In B2B we'll always have live salespeople, because people are spending millions of dollars and they need to be confident about who they're paying, that their employees will actually get where they're going and won't be let down along the way — that's a big responsibility. But on the signals side, we simplified our spend a lot: it used to be roughly thousands of dollars in subscriptions across all these apps, now it's a couple hundred dollars for tokens, servers, and Apify. For Apify itself we pay around 400 dollars, I think, everything else is small stuff, 10-20 dollars here and there, because Apify covers a huge range of complex tasks like parsing LinkedIn.

[23:04] Egor: One case worth mentioning: in Lemlist you used to click "enrich" on a person, and it would tell you the person works at such-and-such company, but if you have hundreds or dozens of contacts like that, you're not going to manually check whether every single one still works there. And the system would write: "Sergey, do you work at such-and-such company?" And the person hasn't worked there for ages, and replies: "I work at INXY, not that company." Technically you got a reply, but effectively it's a mild negative signal: "guys, are you kidding me?" Whoever gets a message like that understands it's a blast with no personalization, nobody actually read anything about them as a person, it's just mindless robots at work. When people write to me like that, sometimes I don't even reply, and sometimes I reply on purpose just to stop the sequence — I hit the pre-set "not interested" button just to make it stop.

Egor: Before we go look up who a person is and enrich the record, we took a different approach: we're not tracking that many people yet — up to a thousand or so. And it's easier for me to run an Apify actor that goes in and verifies exactly where the person works right now — the data ends up genuinely fresh. And beyond that, through Apify actors we pull reviews from G2, Capterra, TrustPilot, some from Y Combinator and Crunchbase, to pick up signals. For example, from reviews: sometimes the platform shows a name, sometimes just the first letter of a last name, sometimes even the company, and if a person left a negative review — we usually focus on the low ratings — that's a signal it's worth reaching out. We try to find that person by every means available, including a plain Google search — we'll most likely find their LinkedIn on the first page, we verify the company exists and could plausibly buy this kind of software, and add them to our tracking system. The first message, the LinkedIn connection request, is phrased as: we saw your review on Capterra, let's talk.

[25:26] Sergey: And what's the reply rate on that?

Egor: We put that right in the text of the connection request, and then the conversation continues from there. When a connection request comes in blank, most likely nothing happens, the person ignores it; but here we're hitting their actual pain point, and the conversation gets going, and that boosts conversion. Beyond that we still need repeated touches with the person: commenting somewhere, following what they post, sometimes just sending a message, and if they mention they're going to a conference, suggesting we meet there. Someone mentioned recently that five or more touches with a person of any kind — from them noticing your booth to a comment under their post — boosts reply rate, or really any other metric, by 40%.

Sergey: That's absolutely true in B2B — the person remembers you, and next time around they react: "Oh, I've heard of those guys," instead of treating it as noise.

Egor: Next, something interesting — we have a partnership agent. We've genuinely started treating our agents like real, living entities, and it's kind of fun that they got names right away.

Sergey: Did you give them names, by the way?

Egor: Yeah, my assistant immediately gave everyone names — there was Charlie and so on. And I thought: hang on, I'm not going to remember that Charlie is our CFO, and also that Charlie is the partnership manager — let's rename them after what they actually do. That's how we ended up with Analyst, Partnership, Sales, SMM, and so on. You immediately know exactly who you're going to, because its identity literally states it's, say, our partnership manager — that's essentially its name. It writes emails, talks to people, and when someone suggests a call, it replies: "Sorry, I'm on vacation right now," or something like that, "but here's Egor, here's a link to his calendar, go ahead and set up a call with him, I've given him a heads-up."

[27:50] Egor: I gave them names right away — I found a service called AgentMail. The team, I think from Y Combinator, built a product — email specifically for agents. I started with them, you get three addresses free, but in the end I still moved to our own Google Workspace: created an inbox, gave the agent access via SMTP and IMAP, that felt more convenient to me.

Egor: We also have a widget setup for other platforms — you can embed our widget and earn a cut on bookings made through your own platform, on top of our content. Our first choice of partner for this is banks or fintechs, where travel becomes an additional revenue stream. Revolut, for example, has a Travel section for consumers, there isn't one yet for business. Users earn points that can be spent on travel, that's part of this story too. We offer this as a product either white-labeled or as a widget. And the partnership agent goes through every bank, small and large, finds their email, checks deliverability through our own GTM system — there's a deliverability check built in; there's also an open-source tool, I think it's called Reacher, which we pulled from GitHub, replaced a paid service that cost around 10 dollars a month, deployed it on our own server inside GTM, got an API from it, and use it across all the agents.

[30:13] Egor: After that the partnership agent drafts the email and sends it itself, either through its own SMTP or through AgentMail, because we set it up with another couple of addresses once the volume of outreach to banks grew.

Sergey: Doesn't it end up in spam though? It seems a bit risky to put your main domain behind that kind of outreach.

Egor: The thing is, we're talking about banks, and there's a reasonably limited number of them — a hundred or so; sending a hundred emails and following up on those isn't the same as hammering thousands of contacts. Beyond that we brought HR platforms into the same process, because they also need extra travel content, and fintech platforms that also sell something white-labeled or issue cards. When someone comes through this funnel and signs a contract with us, I hand that off to the partnership agent, and it builds a look-alike based on that persona and writes: "We work with INXY, let's get you connected too" — basically, by analogy.

Sergey: That's a really great idea.

Egor: That's what the partnership agent does. We've gotten to roughly one partnership call a day, which turns into something real.

Sergey: So essentially the agent's job is to find, engage, and get them onto a call with you — run the whole chain through to booking a meeting. And how long did it take you to build this agent up to a production-level, results-driving state?

[32:36] Egor: I think it's an endless process, there's no such thing as a perfect end point. But the first bugs you clear out literally in a day or two, because the agent, for example, was only running once a day, so feedback didn't come in that fast. There was an encoding issue — it picked the wrong encoding, and emails ended up with garbled characters instead of dashes, dollar signs, and percent signs. I wrote: "What are you doing?" and it replied: "Oh, I didn't even know that would happen," and fixed it. After that, I'd say it took a week or two to get it into a reasonably solid state. But just yesterday, for example, it reported that a reply had come in from person A with a list of questions, and separately a reply from person B with the same list of questions. I answer those questions so it can add them to its knowledge base and answer on its own in the future. I looked, and I'd gotten two emails with different subject lines to the same people. It turned out one person had added the second person into the thread, and the agent hadn't recognized it as one thread, so it treated it as two separate ones. I said: "From now on, check the whole thread, not just the last reply."

Egor: I think I ran into a moment when the Claude subscription got cut off, Opus became unavailable, and I was testing, and it dropped down to model 4o. I couldn't figure out why it suddenly got dumber, turned out it had switched to GPT-4o mini.

Sergey: 4o mini, it's really dumb, it's awful, I don't understand why they even released it, or what tasks it's for.

Egor: For simple parsing of some data it's fine, but for interpreting answers, no. Same with GPT-3.5 Turbo, a bit cheaper, but it doesn't cut it unless you don't need it to go online and so on.

[35:00] Sergey: That's exactly the kind of thing — why release an openly weak product, better to just kill it and move on. Although, on the other hand, "omni," a model that's supposed to handle audio, video, and text, but the question is exactly how it processes it.

Egor: In the chat interface, sure, but through the API you still pick Whisper or GPT-4 separately, and so on. Okay, let's get back to partnership. Today I also added a Gemini subscription and a Codex subscription.

Sergey: Gemini Pro isn't bad, actually pretty decent.

Egor: Sure, though not as good as Claude. If you draw an analogy with hiring: you want a good employee, not a junior — that's Opus. I don't know yet who counts as senior. And mid-level is all the other models. I'd put OpenAI in the junior category outright, because no matter how you look at it...

Sergey: Have you tried the latest Codex 5.3? Seems pretty decent.

Egor: The difference is that Codex keeps asking: "Do you want me to do this?" And Opus just does it.

[37:27] Egor: It's the same story with regular ChatGPT chat — it asks "want me to continue?" and I think: then why are you even here, just keep going yourself, especially since an autonomous agent is supposed to run 24/7. My Opus once got an instruction and replied: "Got it, no questions." Then something broke, and I wrote: "Either I unplug you, or you work for me." It said "okay" and just kept working normally, on its own, message after message, until it finished the task.

Sergey: I think, speaking generally about Anthropic, they've given up a huge chunk of the market. They could have introduced some default subscription, say, for 200 dollars.

Egor: Or more than 500 — most people would still go for it. I don't understand why they didn't do that, they just cut the limits outright. They were the ones who initially said: only Opus, top tier, everything else is weaker, and they built the whole product around Opus. Why cut access so drastically? It's not exactly open source, it's a tool people pay for.

Sergey: There's pay-per-use, but it's very expensive.

Egor: It's obvious that every player right now is subsidizing the price — if they charged full cost, nobody could sustain it. It's all still expensive right now. For instance, one week I hit my weekly limit in 6 days; to keep the system running I paid an extra roughly 100-150 dollars on top for additional usage.

[39:48] Egor: Just to keep from stopping. The following week I restructured the cron jobs, moved part of them to Sonnet, part to GPT, and ended up not even reaching half of the 200-dollar subscription's limit. Honestly, if someone's hitting the limit every day, fine, cut the limits, that's no big deal, people will go find alternatives, but why kill the subscription entirely? It's the same harsh pattern with OpenAI's approach and with Anthropic — Anthropic, I remember, tried to sue someone, and then an investor stepped in and said, "Here's your money, keep going." I don't understand why you'd do that.

Egor: I respect Anthropic as a company, I like how the model writes text, how it does research, but I'm not a huge fan of how it codes. Codex I like better for code, it's more systematic, although I'm not a developer myself and can't judge that professionally. The guys who built things for my tool told me Codex tracks architectural changes more accurately.

Sergey: For vibe coding I honestly think there's no point double-checking anything — if it works, it works, and that's good enough.

Egor: Seems that way. Our developers were on Codex for a while, then switched entirely to Claude Code, learned to write prompts properly, do planning, keep MD files with documentation. Now they even communicate with each other through these files — "if you're going to use this feature through Claude Code, check this MD file" — and Claude Code figures out on its own what to do next. Yesterday I cancelled the 20-dollar ChatGPT subscription, cancelled Gemini, cancelled the top-tier Claude subscription on my personal account, and wrote: "Since we're done with that, I'm out too."

[42:13] Sergey: So what did you end up keeping?

Egor: I kept pay-per-use API keys for Opus and Sonnet, ChatGPT gets used here and there for small tasks. Yesterday I paid about 100 dollars for a single day of usage — I cut out everything extra I'd been testing. I did think about not going toward Chinese models at all, I really didn't want to — I'd read that they collect way too much data, and decided not to go that route.

Sergey: But there's MiniMax, which you can run locally, right?

Egor: Sure, but that needs a huge amount of resources, and I don't have anywhere to run it locally, or I'd have to rent a GPU droplet, and that would cost roughly the same 100 dollars a day.

Sergey: There's the Mac Studio with strong specs too, you could do that as well.

Egor: How much does a Mac Studio cost right now?

Sergey: Around 7 thousand euros.

Egor: That pays for itself in 2-3 months if you cut the Opus spend.

[44:40] Egor: I actually spent the last couple of days talking to people who are also looking for alternatives, and they recommended the Chinese model Z.ai (GLM), which is built primarily for programming and positions itself against Claude Opus. We tried it out yesterday, and I even kept double-checking: is this really answering from Z.ai and not Opus? It said: "Yeah, I like it." It genuinely works well, and the subscription is around 30 dollars.

Sergey: And MiniMax is also a subscription around 20 dollars for a large token volume?

Egor: I tried it, but it didn't work that well for me. This latest Z.ai model, though, genuinely impressed me with what it managed to get done overnight.

Sergey: So quality-wise it's close to Opus?

Egor: Very close, even the style of the answers is similar, structured. Opus's answers feel human, while ChatGPT has more of a "metallic" feel to it.

[47:07] Egor: When you switch to ChatGPT after Opus, it's genuinely an unpleasant feeling, like you had a normal support agent and now you've got someone who couldn't care less.

Sergey: I also thought the market would move toward local models — a lot of people are testing them, pushing them harder, and even though the hardware is more expensive, the quality is already close to Opus, just slower.

Egor: The main reason to look toward Chinese models is security and data handling, especially when it comes to contracts and user data under GDPR. I still need to think through how to organize the transition properly. Maybe I'll keep paying for an Opus subscription for the top three agents and move the rest to cheaper models — there are 12 agents, five of which are top-tier, and it works out to roughly 600 dollars per "person," which is already the price of a mini-employee from South Africa at 5 dollars an hour — a perfectly reasonable rate, while the model is significantly smarter than a human in that kind of role.

[49:33] Egor: So we'll definitely be looking at a local model. Right now we're building ourselves a solid AI agent for our travel platform — we made an MCP server for AI agents, so a user can connect their own agent, and it works with our content and account, books things on its own. Support changes accordingly: today, standard AI-assisted support uses a knowledge base and handles the first line, maybe 30% of requests, while 70% still falls on a human. We want to shift that so the agent can change a ticket itself, change or cancel a hotel, book a flight — be just as proactive as our main tool with its own cron jobs. And for that, if you're working inside your own platform with your own data, you need either a local model on your own server, or you use Opus through Anthropic with a clear disclosure to customers about where their data is going.

Sergey: Through the API they supposedly don't pass anything anywhere, pay-per-use isn't used for model training.

Egor: At least that's what it says, need to double check. On the OpenAI platform, when you get a key, there's an option to agree that your requests are used for training, in exchange for a 30-50% discount on usage. I haven't checked that part for Anthropic, I assumed it was similar.

[51:58] Sergey: That's definitely worth double-checking — what I read about four months ago was that Anthropic's API isn't used for training.

Egor: You're right, let's double check. For now we're working toward connecting Opus to an internal chat that will manage customer orders and everything else, because we'd already tried building customer support before, and looking back, everything "pre-Opus" was a fairly mediocre product, we didn't want to spend the time and effort training staff and customers on it. So we stayed with the basic version: a call or a message, and we help people directly.

Sergey: Have you heard that Anthropic released a new model, still in test mode, and it found so many vulnerabilities that they got scared to release it publicly — I think the name was something like "thinking," the announcement was around April 7th, if I recall.

Egor: I believe they only released it for large enterprise, they're not putting it out to the public.

Sergey: Probably a sensible move. After Opus, if the model didn't burn through tokens so fast, it would honestly be the top model — I really like how it thinks, reasons, and communicates.

[54:28] Sergey: Let's think about this from the angle of your practical business experience: in which businesses does this kind of approach actually apply, where does it make sense, and where doesn't it? So viewers can figure out whether it's worth spending time on.

Egor: I think it applies to everything, the question is what exactly to implement and how to improve it. A lot of people think improving an agent happens through programming, but really it happens through simple conversation with it: you ask how it can be improved, ask for options, and that's a working approach, available to anyone. Where it applies most, I'd say, is content generation and then publishing it. The most interesting part is that, unlike a regular conversation with Claude or ChatGPT, where context gets lost quickly, our tool holds context: who you are, what you've done, what's worked and what hasn't. When it writes copy for SMM, it's interesting even for me to read — I open it up and think: wow, did I write this?

Sergey: Egor, it's important to note here that out of the box, its memory is pretty weak, it forgets things, starts "getting stupid," and effectively doesn't work without additional tuning.

[56:49] Egor: Right, it needs work — fine-tuning, pulling in the best sources from open material. Like you said, constantly having it monitor the best solutions on the market; I also feed it whatever's best coming out of open source. You combine that data, and that's when the magic starts. Another hack that genuinely helped: we've all been chatting in ChatGPT for a really long time, I'd built up around 30,000 chats. You can go into ChatGPT and export all your data, and a day or two later they send you an archive.

Sergey: Does Claude have that too?

Egor: I'm not sure, I haven't checked specifically in Claude, but there's probably something like it, exporting your data before deleting an account is usually legally required. I fed all of that data to my main agent and said: now you know a lot more about me, sort this into memory, and from day one we were already talking like old acquaintances.

Sergey: That's a great idea, and such a simple, obvious one too. I remember back in 2014 everyone said data is gold, and now it's the opposite: there's so much data, it's unclear what to do with it all.

[59:14] Sergey: But now you need to figure out how to actually work with it, all the data gets pulled into an LLM and worked with there. Second example, exporting all your chats and handing that off to another agent so it can index it itself. I've had a lot of interesting cases like that too: some people gather their knowledge in Cursor, others in Obsidian. Any place where you've got an exported knowledge base is an ideal source for training your own model.

Egor: A hundred percent agree.

Sergey: And what about other agents — you've told us about two, what other use cases work well? Content is SMM, sales is outreach and partnership, slightly different approaches. Tell us about the lawyer, because lawyers here in the US are very expensive.

Egor: Let's get to the lawyer. I try to split agents up the same way we split up people doing different jobs at the company. In theory the sales agent could sell everything, but we still hire a separate person for the UK, a separate one for Europe, and it's the same with partnership: once we start selling partnerships separately to banks and separately to HR platforms, those will also be two different "agents" with their own data, but with the ability to combine knowledge much faster than people trading experience over a smoke break.

[61:45] Sergey: Actually, I was recently discussing with Ilya Krasinsky how the main problem in big corporations is exactly this — knowledge transfer: all those hours-long meetings really only exist to keep everyone on the same page. You could cut that out entirely if, first, knowledge gets collected automatically and shared across everyone, and second, if agents that already know everything are the ones responsible for it.

Egor: Back to the other bots: with the lawyer agent, by the way, we discussed weekly self-learning, but honestly not much changed. I first set it to once every two weeks, and again it didn't seem to make much difference. Now, as the volume of communication has grown, I've set self-learning to once a month — better it happens less often but more thoroughly.

Sergey: Actually, here's another hack — I did something similar with a local model, and when it's running on a local machine it's much simpler. You install Codex or Claude Code, point it at where the source material is, and use it to enrich the model, and the subscription in that case is dramatically cheaper. You give it all the data, it writes everything up the way it needs to be, and then you use your bots afterward — significant savings on usage without breaking any rules.

[64:09] Egor: Yesterday people in some chats were describing a similar approach: you build a skill together with Claude Code, polish it, hand it to your tool, which by then works reliably and uses, say, Sonnet or some other cheaper model, because you've already refined it through Claude Code. That's a great approach too, and it doesn't violate any usage rules at all, and it still sees the full context: the source data, the MD files. You just say: "study this," it goes, reads, asks questions, and then works on its own from there. I have Codex and Claude Code running in parallel, I've compared them — I liked Codex a bit more in terms of how it works, though that's obviously subjective.

Sergey: So either way works, there's almost no difference.

Egor: Our lawyer agent checks all our contracts, looks at what we can do, fills in contracts, sends emails. We set it up through subagents each with their own workspace and identity, and then in Telegram, instead of one shared thread, I create separate group chats and add colleagues to them.

[66:36] Egor: When something comes in for my colleagues, they send it into the lawyer agent's chat, and it works with them from there. One problem we ran into: if one request is still being processed, the next one gets queued. But that's solved by splitting the chats further; for now the volume is small enough that people are fine waiting a bit. The main thing is the agent remembers what we've done, what other lawyers have told us about deals, what needs to change, and it builds its own knowledge base of contracts and practice on top of that. Plus we built it separate skills for US law, for UK law, which it uses and keeps refining.

Sergey: And I imagine there are differences by state too?

Egor: Yes, there are separate nuances by state too that it tries to account for. Sometimes we just tell it: go check Perplexity, because that's cheap, to pull data from the internet and hand back the information we need right away.

Sergey: Tell us about another agent — the analyst.

Egor: For the analyst I gave it a product manager's skills, and it can do solid deep research using everything we've already gathered: if you run a plain deep research query through Perplexity or straight through a model on its own, that's going to be a different context with no knowledge about us, but the analyst, working through our main tool that knows everything about the company, produces a pretty solid business plan that you can actually use going forward.

[68:57] Egor: The analyst also checks reviews through Apify, what negative things are being said about us on Google Play and the App Store, and about competitors it's found itself, and sends a weekly report. For example, competitors keep having login issues, users constantly get logged out, and the fix is: don't log the user out on a device unless there's a reason to. It gathers that and hands it to me; I ask it to immediately create separate tickets in Notion or in the backlog, because that's genuinely valuable — hundreds of people complaining about the same problems with competitors. Essentially that's product analysis, telling you what to do with the product.

Egor: The third useful thing the analyst does, and this applies to any business: we work in Google Workspace, and at one meeting someone told me about a Google Workspace service account, which I hadn't known about before — enterprise sysadmins have long used them, not just to manage the internal office network but to watch what users are doing and who's trying to hack them. I created a service account like that, gave the analyst access, and specified which shared mailboxes it could check.

[71:20] Sergey: And importantly, you gave it read-only access, right?

Egor: Yes, that's right, read-only. Anything it sends goes through a separate SMTP setup wherever that's needed. A bit later I also gave it access to apply labels in the mailbox, so it could prioritize incoming email — an employee comes into work and the emails are already sorted by importance, that's really useful too. Beyond that it reads all the emails every day, figures out where we have problems and where we have opportunities, and flags anything we might have missed, which happens even to us — I love an empty inbox and try to keep it tidy, but you can still miss things. Second, it learns from these emails and suggests what could be added to the knowledge base, what could be improved in the product — that's more of a product manager role. Third, since we were talking about data, it pulls all the data out of email, learns from it, and stores it in the shared knowledge base. Then I can tell another agent: "Go check, we discussed something with INXY about such-and-such, what was that about," and it finds that information through the service account.

Sergey: Do you feed it call transcripts too?

Egor: You mean phone calls?

Sergey: Yeah, phone, Skype, if there are calls with partners, do you transcribe them and log them into the database, into the CRM?

[73:48] Egor: Sure, for training purposes, yes, but in our case we don't do that yet, because we don't have that many calls, and once we get to the demo stage it's usually the same standard questions: how to set up a travel policy for employees, how to configure approvals, how to handle payments. Those basics are already in the knowledge base. On the whole it's a good idea to add that too, but there's a downside — could it just end up cluttering the knowledge base? So in our case we don't do it.

Sergey: I get the logic. For us it's the opposite, we have a lot of calls with clients, mostly through Zoom, Skype, Google Meet, and most of the communication happens there, and then the written correspondence comes after the demo, so our flow is a bit different, but I understand the logic.

Sergey: And the service account — so it reads the email of every employee you've pointed it at, and monitors what's going on?

Egor: Absolutely everything, but it only learns from the shared inboxes where the main flow accumulates. On another note, there was a case with the developer chat: we were migrating to a different server, and we needed to send a whitelist to some of our vendors, and we didn't quite remember which ones exactly.

[76:13] Egor: Since all the agents have access to this service account, I have a separate dev agent sitting in the developer chat. Here's how it went: a developer wrote in the evening, "it's late, I'm going to rest, I'll look at it tomorrow and report back on what we've got on the list." I thought: hold on, we connected that account just yesterday, and I wrote to the main agent: go into such-and-such employee's email and check what was there, find who had what, and give us an answer. Since it reads the entire Telegram context and keeps all the sessions, you can just tell it: "Go check Vanya's email," through the Google service account, "and find it." That took about ten seconds, and it found the list of what needed to be done. I asked it: use my SMTP through my email, cc everyone you found in the thread, and Vanya himself too, and write that we have a new IP address. We just sat there in Telegram watching it send it all out. In the end we didn't have to wait until the next day — a task that would have taken a person time in the morning got done in 2 minutes.

Sergey: That's a great use case, how you can remove the human factor — we're all human, we get tired, we can't work 24/7.

[78:42] Sergey: Let's think about this from the angle of first steps — what would you recommend to someone who just wants to try this approach, which use cases should they start with, what should they avoid?

Egor: When I was figuring out no-code, I had exactly the same question: okay, there are thousands of different integrations here, what do I do? I always advised: take a sheet of A4 paper and a pen and just sit down and write out every case you could automate, write down absolutely everything, and then you can feed that into whatever tool you want. In the past, if it was code, you had to work out the sequence yourself; today we launch the first agent, and there's not really much more you need to do on top of that. Build the first agent on the top-tier model and don't worry about cost, because in the first weeks, before you have sixteen agents running in parallel, the bill won't be huge — better to train it on the best model right away, get access to the top-tier model by whatever means.

Egor: Then feed it everything you want to do, and it'll tell you on its own what to prioritize now versus what to leave for later. Then you think about how to cut costs. We always build skills for every case and format like that, because a skill is the basic unit our tool uses to operate. There are skills that already exist in the community, there's a platform like ClawHub — you go there and pull out anything useful, but you absolutely have to check that there's no malicious code in there.

[81:08] Sergey: That's actually exactly what I wanted to say — there's a lot of junk out there, so it's important that your tool itself looks over any skill you download and rebuilds it for you, because there could be something malicious inside, and it needs to be reassembled from scratch.

Egor: Second thing I like about platforms like that: the same exposure effect — you look at which tools get used most often, and think: oh, they're using Perplexity for this, what could I use it for? And you start thinking in that direction. That's probably the basics, you might have something to add.

Sergey: My main recommendation is to get the tool up and running as fast as possible. If it's a local machine, by the way, you can SSH into it and run Codex or Claude Code there too, to help set things up and fix bugs. For me personally that was a real game-changer: something crashes, and before, you'd restart the terminal yourself, dig through it. Now you write: "bro, help," it runs diagnostics, restarts things, and in five minutes everything's fixed, when before that would have taken a week of pain.

Sergey: By the way, about Z.ai — do you recommend testing it right now, or is it still too early to say?

Egor: I can't say for certain yet. The team launched it two days ago, I'd been following the feedback, everyone's thrilled. I only tried it myself yesterday, and the first day left a good impression.

[83:32] Egor: So far I can say it works really well. You've probably noticed this too — when you switch from Opus to GPT, you immediately wonder, who's getting "stupid" here? Me, the tool, some new update, or something else? But in reality it's just a matter of the model you need to use correctly, and our tool is really just the orchestration layer that helps organize the work properly underneath it.

Sergey: By the way, for simple cron tasks it's pointless to run them through Opus at all, you're just burning tokens for nothing. For genuinely important tasks, sure, but for routine competitor monitoring, for example, why do you need such an expensive model? The conclusions you draw from what you've monitored and scraped, though, that's a job for a strong model.

Egor: I was thinking about that too, wanted to keep Opus for the truly important stuff and move the rest to Sonnet or Haiku. It went from 100 dollars down to roughly 70, not a dramatic difference, because both Opus and the others still "eat" a lot at this volume: we're not talking dozens of emails, we're talking hundreds — over 24 hours we get 300-500 emails across all our inboxes.

[86:00] Sergey: By the way, you're being a bit unfair to Sonnet, it's actually a really good model, the new Sonnet is genuinely strong.

Egor: Yeah, you're right, but it's not cheap either — half the price of Opus, but at our volume that's still a lot. In the end I decided to test the Z.ai subscription. I'm hoping that after a while either Anthropic will address what we discussed, or a new American model will come out that we could use instead of the Chinese one, because I'll still try to move away from Chinese models as quickly as I can — I just didn't want to abruptly turn off our main tool and everything we've built over the last two or three months.

Sergey: Especially since it's working so well, it would be a shame to lose it.

Egor: Yeah, I even thought about switching to vibe-coding on top of Claude Code myself, adding the skills and workers we need, setting up a dispatcher, but that would take a week or two to migrate, and even then there's no guarantee it would run 24/7 as stably as it does now. You had a similar setup, by the way, with memory on top of Claude Code and Codex, with that LDB database that works.

Sergey: Yeah, I layered LDB on top, and I was also curious about setting up the same thing in Obsidian, so all the databases would sync — I haven't fully finished that, but I wanted to be able to enrich the context myself: look at what the system did, and if the context was missing something, add it manually, for example after a client meeting if something important wasn't captured. There's a balance to strike there, so you don't end up overloading yourself with manual work — I haven't found the perfect solution yet.

[88:24] Egor: I don't have that either. Another reason I want to stay on our own tool rather than move fully to vibe coding or another subscription: you can add node devices you already own. With Claude, for instance, you pay for minutes of using a third-party machine, plus you can't switch between different models, you're locked into one vendor. By the way, I liked that Microsoft set things up on their models so that one model does the research — I think it's an Anthropic model — and ChatGPT checks it. The idea of verifying with two models is genuinely great, and with us you could run the result through four models if you wanted.

Sergey: Makes sense that models would specialize differently too. From what I understand from their website, Z.ai is focused primarily on developers, not just on code.

Egor: Perplexity focuses on fast information lookup, like Google.

Sergey: And Grok is really good at parsing X, it remembers pretty much the entire X database almost perfectly, especially when you need to verify something and enrich it with context.

[90:50] Sergey: Here's a recent case — we were checking a screenshot from X, and ChatGPT said it was fake. We thought the client had given it to us as proof that their product was supposedly great, and there was some comment from Elon Musk on it. We checked with ChatGPT, it said fake. We were already thinking a good person had lied to us. Just in case, we checked with Grok, and it said: not fake, here are the sources. And with ChatGPT it's still unclear what it's actually focused on, it feels like it's trying to cover absolutely everything at once, and that's exactly why it's not always good — last month they added something medical, then something for lawyers, then built payments into the chat, then turned it off, then brought it back in a different form, something not entirely clear about the product's focus. Opus, on the other hand, feels like a serious conversational partner, one it's genuinely pleasant to talk to.

Egor: I completely agree on the conversational side. Every model should focus on its own niche and be great at that, instead of trying to cover everything. I hope Anthropic doesn't stumble with their own agent orchestration system on their platform — I looked at it yesterday and thought, maybe we should move there, but I asked the model itself whether it runs on subscription or pay-per-use for tokens, and it turned out to be pay-per-use. I said: goodbye.

[93:14] Sergey: Let's start wrapping up, I have two last questions for you. First: if you went back 3-5 years, what would you change, what would you do differently?

Egor: If we're talking 5 years back, I should have moved to a different country earlier than I actually did. We already traveled a lot, roughly every two months I'd go somewhere for at least a couple of days, look at what was new, what services were launching, why parcel lockers worked in some places and not here. But once we actually did move, it opened up a huge number of opportunities I hadn't even suspected existed.

Sergey: Nice. And what would you tell yourself from two years back?

Egor: From a product standpoint, I'd tell myself to sell faster, not wait for things to fall into place on their own, or for extra content, other airlines, to plug in on a new market.

[95:38] Egor: We still do this now: a client comes in, we immediately send them all the resources, so they can launch faster and get the content they need. Takeaway: sell today faster than you spend time on refinements and fine-tuning. Probably the same logic applies to our AI tool: launch it and test it, instead of endlessly tweaking it while waiting for it to become "perfect."

Sergey: Great insight. My second question is similar to the first: looking back a few years, what definitely wasn't worth doing?

Egor: Definitely wasn't worth spreading myself across different niches, businesses, and opportunities that came my way. If you've found something that works, like we did with travel — and we know the corporate travel market is 1.7 trillion dollars and still growing — you need to focus. I was slow myself to start cutting out everything that was pulling away time and energy.

[98:07] Egor: Today we focus only on travel, only on our own product, we improve it, develop it, look for new refinements, and everything else we just sell off or shut down, and we don't spend energy on it. If you have something working that's growing and giving you everything you need, and the market is essentially limitless, there's no point looking for something else, spreading yourself thin chasing "a little bit here, a little bit there." Better to focus on one thing, without scattering across new niches.

Sergey: That really resonates — I see a lot of people with huge potential, really sharp, but constant loss of focus and chasing every hype cycle keeps them from getting results. If they'd just kept hammering at one point, the results would be not two but ten times better. It happens everywhere, that's a genuinely great piece of advice, thank you so much. Egor, thank you for sharing so many insights, let's stay in touch, it'll be really interesting to see how things keep changing. Only three months have gone by, and it already feels like a lifetime.

Egor: Yeah, it really is amazing, we're living in a great time.

Sergey: Thanks again, Egor.

Egor: Thank you, Sergey, for having me on your podcast, No Bullsh!t, great name. I wish you growth and more subscribers. Subscribe, everyone — we'll keep finding new people and help Sergey find more people worth talking to.

Sergey: Thanks, take care, talk soon.

Egor: Bye-bye.