Why 10K (Our AI VP Marketing) and QBee (Our AI VP Customer Success) Work So Well: The App and the Agent Are One System

Почему 10K (наш AI VP Marketing) и QBee (наш AI VP Customer Success) так хорошо работают: приложение и агент — одна система

автор: Jason Lemkin | Artificial Intelligence (AI), Blog Posts, SaaStr.Ai

Большинство дискуссий об AI-агентах в B2B сейчас рассматривают агента как фичу, которую вы выпускаете: чат-бокс, копайлот, волшебную кнопку внутри продукта. Такая рамка сбивала людей с толку, включая меня, весь прошедший год.

То, что реально работает в SaaStr AI, и причина, по которой 10K и QBee (наши AI VP Marketing и AI VP Customer Success) обе двигают бизнес настолько сильно — это не сами приложения. И не сами агенты. Это связка.

Обе — это развёрнутые веб-приложения, которыми команда пользуется каждый день. Реальные дашборды, реальные cron-задачи, реальный продакшен-субстрат. Но развёрнутое приложение само по себе — лишь половина системы. Другая половина: мы используем Replit Agent для прямого взаимодействия с 10K и QBee — так, как не смогли бы, если бы это были просто отдельно опубликованные приложения. Из кокпита я (или Amelia в случае QBee) могу задавать вопросы живому приложению, чинить в нём вещи, строить новые фичи поверх него — всё в одном разговоре. У агента та же база данных, те же секреты, те же интеграции и тот же код, что и у развёрнутого приложения, так что он работает с живым бизнесом, а не с копией.

По сути, мы «хакаем» Replit Agent на Claude Sonnet с чрезвычайно богатым, наполненным контекстом окном (которое постоянно компактится, но всё равно удерживает фрагменты каждого маркетингового и клиентского действия, что мы когда-либо совершали в 10K и QBee), чтобы взаимодействовать с AI-приложением и людьми. Вместе.

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

Утро пятницы в SaaStr AI

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

Наш sales-менеджер David прислал записку: закрыты три новых Silver-сделки (Manus AI, Jobright, Kris@Work) и Exa проапгрейдился.

Я попросил Replit Agent проверить это против Salesforce. Он написал быстрый запрос, нашёл Manus AI и Jobright уже как Closed Won, но по Kris@Work не было ни одной opp вообще, а Exa всё ещё висела на Stage 3 Super Gold с $87.5K.

Я попросил его обновить opp по Exa: переименовать, обновить, пометить Closed Won сегодня. Готово за 30 секунд через jsforce. Потом: «составь email для David с упоминанием пробела по Kris@Work и изменения по Exa, моим голосом». Он написал, я подправил одну строку, он отправил через Resend.

Заодно он построил отдельный ранкер для приглашённых на Deep Dive Workshop: подтянул участников Bizzabo summit, исключил 71 спикера из CSV и около 91 спонсорской компании из Salesforce, оценил по allow-листу из 150 брендов, выдал CSV на 100 человек.

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

Если бы 10K была только развёрнутым приложением, ничего из этого бы не случилось. Если бы агент был чат-боксом, прикрученным в продакшен, большая часть этого тоже бы не случилась. Работает именно связка.

Другой пример, другой оператор

Та же неделя, другой человек, другой вид работы.

Amelia, наш Chief AI Officer, спросила 10K изнутри Replit-кокпита: «как ты думаешь, кого нам стоит пригласить на deep dive? наверное в основном тех, кто едет на summit, или растущие AI-компании, как считаешь?»

Агент выполнил 24 действия. Подтянул живые данные Bizzabo: 397 текущих участников CXO summit, 134 CRO, 160 CMO, 103 FDE и CCO. Сверил со списком спонсоров. Оценил через фильтр AI-native компаний. Построил многоярусный список приглашённых с обоснованием по каждому имени.

Tier 1 вернулся как 40 авто-приглашений: senior-уровень, AI-first, уже платят за доступ на summit. На выходе — имена и однострочное обоснование по каждой компании:

Harvey: John Haddock (CBO), James Hunsberger (Head of GTM Tech), Kexin Chen (VP Mktg), плюс ещё 3 человека на стороне CS. Они отправляли 6 человек на саммиты. Зафиксировать всех. Aurasell: Jason Eubanks, CEO/Co-founder. Спонсор + summit + AI-first. Тройное да. Ontra: Leslie Olsen, CMO. Ontra перешла в AI-native. Commvault: Carilu Dietrich, «VP of AI and Marketing Excellence». Одно название должности говорит, что она должна быть на каждом воркшопе.

Плюс Relevance AI, Amotions AI, Fireworks AI, Crusoe, Horizon3.ai, Shield.AI, Level AI, Conviva, WisdomAI, Explorium и ещё 25+ в этой корзине.

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

823 коммита за шесть месяцев. И ни один из них не начинался как код.

В репозитории 10K 823 коммита примерно за шесть месяцев. Подавляющее большинство начиналось с того, что я печатал предложение агенту, а не писал код.

Образец того, что было таким образом построено, всё запущено разговорным путём:

Карточка предиктивного прогноза продаж билетов («предскажи, к чему мы выйдем, исходя из последних 30 дней»). Слой кэширования stale-while-revalidate, который снизил холодный старт дашборда с 5–15 секунд до 50 мс. Трекер открытий рассылок Marketo, автоматически обнаруживающий программы по соглашению об именовании и обходящий bulk-экспорт окнами по 60 дней, чтобы обойти лимит пагинации Marketo в 1000 строк. Голосовой чат-бот, который говорит, слушает и знает живые данные дашборда. Инструмент ежедневной рассылки на базе Beefree с интеграцией WordPress, AI-ранжированием постов, секцией подкаста и пайплайном отправки через Resend. Вариант еженедельной рассылки с браузером SaaStr YouTube, фидом подкаста Libsyn и секцией «Tweets of the Week», подтягивающей топ-твиты @jasonlk, отранжированные по вовлечённости. Конструктор рассылок для участников SaaStr Annual с drag-to-reorder блоками секций, редактором уровней спонсоров и импортом сессий из Bizzabo в один клик.

Ни одно из этого не начиналось как написанная спецификация. Они начинались как предложение. Агент их построил.

Импровизация идёт глубже постройки фич. Пришло уведомление об опечатке для покупателя comp-билета: «Cassidy Centures» должно было быть «Cassidy Ventures». Я спросил агента, является ли API Bizzabo read-only или может писать. Он не знал, и я не знал. Документация Bizzabo разрежена, а в нашей кодовой базе были подключены только пути на чтение. Поэтому он зондировал пять разных write-эндпоинтов параллельно: PATCH по registration (404), PATCH по contact (404), PATCH по properties subresource (404), POST по registration (404), PUT по registration с телом { properties: { company: "..." } } (200). Он повторно подтянул данные, чтобы убедиться, что изменение зафиксировалось, потом сохранил переиспользуемый скрипт для следующего раза. Общее время: меньше двух минут. Я не открывал тикет в поддержку.

На той же неделе письмо, составленное агентом, не прошло через Resend с первой попытки. Агент попробовал неподтверждённый домен и получил 403. Тогда он прогрепал кодовую базу, нашёл реальный подтверждённый отправитель, повторил, отправил. Затем сохранил правило в файл предпочтений проекта: письма, инициированные агентом, по умолчанию идут от SaaStr 10K, а не от Jason лично, и пометил единственный подтверждённый домен отправки. Это предпочтение теперь применяется к каждому будущему письму, которое он отправляет.

Агент не просто починил баг. Он обновил собственное будущее поведение. Такая самомодификация, против недокументированного API, за две минуты — именно то, что трудно воспроизвести внутри развёрнутого приложения.

Почему связка работает

Когда dev-агент работает в том же воркспейсе, где была построена 10K, у него есть структурные преимущества, которые не переносятся на агента, существующего только в продакшене:

Та же файловая система. Он читает CSV, пишет промежуточные черновые скрипты, выкладывает результат, итерирует. У развёрнутого контейнера нет scratch-пространства. Те же секреты. Все 30+ API-ключей (Salesforce, Bizzabo, Marketo, X, Resend, YouTube) прямо тут как переменные окружения. Никакого расхождения между dev и prod, потому что dev и prod делят субстрат. Та же база данных. Агент при необходимости напрямую запрашивает продакшен-Postgres. Никаких «сначала синхронизируй данные в песочницу». Тот же код. Агент пишет новый TypeScript-скрипт за 30 секунд и запускает его против живого бизнеса. Никакого цикла деплоя. Тот же loop деплоя. Когда скрипт становится кнопкой, он шипится в том же воркспейсе. Никаких передач, никакой миграции окружений. Та же память. У агента есть контекстное окно, которое со временем компактится, но сохраняет фрагменты каждого маркетингового и клиентского действия, которое мы совершали в 10K и QBee. Он помнит правила, которые сам себе сохранил (подтверждённые домены отправки, голос бренда, кто одобряет массовые рассылки), скрипты, которые он написал на прошлой неделе, имена сделок, которые мы только что закрыли. Production-агент в свежей сессии стартует с нуля.

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

Почему чисто изолированный standalone-production-агент сегодня не справился бы

Вы можете построить агента целиком внутри развёрнутого приложения. Чат-бокс в дашборде, ограниченный admin-пользователями, подключённый к набору заранее построенных инструментов (query_salesforce, send_email, issue_comp_ticket, post_tweet). Для рутинных операций это работает нормально. Может быть, лучше, чем dev-агент, потому что быстрее и нормально аудируется.

Три вещи ломаются в момент, когда работа становится не-рутинной.

1. Prod-агент не может писать новый код.

Это то, что большинство фаундеров упускает. Суперспособность dev-агента — не вызов заранее построенных API. Это написание совершенно нового кода на лету. Когда я сказал «найди CMO крупных брендов, которых мы пропустили в списке deep-dive», агент написал новый скрипт-ранкер за две минуты. Не было инструмента find_missed_cmos, сидящего в ожидании. Он его изобрёл.

Production-агент может вызывать только те инструменты, которые вы заранее написали. В момент, когда вопрос становится новым («почему число по Exa неверное?», «можем ли мы скрест-проверить этот CSV против Salesforce?»), вы застреваете в ожидании, пока кто-то напишет новый инструмент, задеплоит и попробует снова. В dev этот цикл — 30 секунд. В prod — спринт.

«Агентная» часть агента — это не вызов инструментов. Это написание кода для вещей, которых вы не предвидели.

2. Нет scratch-пространства — нет импровизации.

Половина работы в примере с David включала чтение CSV, запись промежуточных файлов, генерацию четырёх разных выходных CSV, их сравнение, итерации. У развёрнутого контейнера ничего этого нет. Можно сымитировать через объектное хранилище и sandboxed exec, но тогда вы строите крошечную IDE внутри своего приложения, и плохо.

3. Ставки переворачиваются.

Dev-агент с плохим SQL-запросом меня раздражает. Prod-агент с плохим SQL-запросом обновляет 400 opp-сделок в Salesforce и рассылает 8000 участникам письмо с неправильной темой.

Настоящему production-агенту нужны точечные пермишены по каждому инструменту, audit-логи, потоки подтверждения, rate limits, режимы dry-run, evals, rollback. К моменту, когда вы нормально построите все эти страховочные леса, вы потратите недели, а агент всё равно будет делать меньше, чем ваш dev-агент сегодня, и с большим трением.

Реалистичный потолок чистого production-агента на проекте вроде 10K: возможно, 60–70% от возможностей dev-агента для операционных задач, и примерно 0% для постройки или исследования.

Ментальная модель: Dashboard + Cockpit

Рамка:

Развёрнутое приложение — это дашборд. Чистый, быстрый, предсказуемый, специально скучный. Живые цифры, запланированные задачи, рассылки, отслеживание пайплайна. То, что команда видит и использует.

Dev-воркспейс (по крайней мере сейчас, для нас, он в dev) — это кокпит. Где сидит оператор. Те же живые системы, полная IDE, реальный shell, агент, который может писать код. Расследования, копирайтинг, оценочные решения, починка единичных записей, постройка новых скриптов.

Один и тот же субстрат. Два интерфейса. Дашборд — это вид преимущественно на чтение. Кокпит — это вид на запись куда угодно.

У этого разделения есть неочевидные преимущества:

Дашборд остаётся простым. Никакого чат-бокса, никакого реестра инструментов, никакой админ-панели агента, требующей своей собственной модели разрешений. Просто дашборд. Рискованная поверхность — это один воркспейс, а не вся развёртка. Ошибки случаются в dev, а не на глазах у пользователей. Работа с суждением живёт там, где должна. Production-runtime по своей природе плохи в импровизации. Dev-окружения по своей природе в ней хороши. Путь продвижения ясен. Когда ad-hoc операция повторяется пять раз, она становится кнопкой в дашборде. До этого она остаётся скриптом.

Последний пункт — это принцип работы: превращай рутинное в кнопки, держи агента в dev для всего остального.

Одна важная оговорка. Это снимок того, что работает в мае 2026, а не вечный закон вселенной. Инструментарий production-агентов улучшается стремительно. Sandboxed-исполнение кода, управляемые интеграции, хостинговые dev-окружения внутри production-приложений — всё это быстро становится лучше. Разрыв между тем, что может dev-агент и prod-агент, быстро сузится за следующий год. Сейчас, для нас, dev-воркспейс — это кокпит. Через год ответ может быть другим.

QBee работает на той же архитектуре

QBee, наш AI VP of Customer Success, была построена Amelia на Replit и сейчас управляет 100+ спонсорами с сокращением человеко-часов на 70%. Та же архитектура, что и у 10K.

Причина, по которой QBee работает — не само развёрнутое приложение. Дело в том, что Amelia может сидеть в Replit-кокпите и иметь QBee, которая переранжирует список спонсоров, составит сообщение её голосом, починит плохую запись онбординга, запросит живой Postgres, зашипит новую фичу — всё в одном треде. Развёрнутое приложение обрабатывает рутину. Кокпит — всё остальное.

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

Наш cockpit «agent + app» не масштабируется (пока) на слишком много людей

Сегодняшняя установка работает, потому что в кокпите 1-3 оператора, максимум. У агента полная запись в Salesforce, полная запись в Bizzabo, полная отправка через Resend, никаких границ разрешений. Это нормально, когда оператор — фаундер или senior IC. Это была бы катастрофа, если бы 10 маркетологов имели такой уровень доступа. В первый раз, когда один из них сказал бы «отправь письмо со скидкой 50%», агент бы это сделал — на 8000 участников, без ворот одобрения, без rate limit и без отката.

Кокпит по замыслу — высокодоверительная, высокомощная среда. С маркетинговой командой из 10 человек архитектуре придётся расти. Кокпит остаётся на 2-3 операторах. Всем остальным достаётся развёрнутое админ-приложение с кнопками, ограниченными ролями, потоками одобрения для всего разрушительного или с широким охватом (массовые рассылки, изменения сумм по opp, всё, что затрагивает более 1000 записей), полными audit-логами каждого действия с per-person учётками и rate limits на массовые операции. Агент в кокпите остаётся суперспособностью операторов. Команда получает безопасные, аудируемые, role-gated инструменты, которые операторы продолжают добавлять, когда паттерны из кокпита себя доказывают.

Это естественное расширение принципа кнопкизации. Кокпит — для 1-3 человек, навсегда. Все остальные ведут самолёт через кнопки, которые строит кокпит.

А Claude Code или Cursor сработали бы так же хорошо?

Нам часто задают этот вопрос. Для проекта вроде 10K или QBee — нет, и причина не в модели.

Модель в Claude Code или Cursor примерно эквивалентна той, что мы используем в Replit. То же семейство, то же качество генерации кода, то же рассуждение. Если бы вы посадили меня писать deep-dive ранкер в любом из инструментов, результат был бы примерно одинаковый.

Разница — во всём, что вокруг модели:

Управляемое окружение. В Replit Postgres DB, 30+ секретов, развёрнутый URL, cron-задачи, workflow — всё живёт в одном месте, которое агент уже понимает. С local-first инструментом «продакшен» — это где-то совсем в другом месте (Vercel, Render, VPS). Агент не может легко дотянуться до prod-логов или prod-БД, если вы вручную не подключите это. Loop деплоя. В Replit: правь, авто-перезапуск, превью, деплой по кнопке. Local-first: git, CI, конфиг хоста, переменные окружения в двух местах, расхождение между ними навсегда. Паритет секретов. Dev и prod нативно делят секреты. Локально вы синхронизируете .env с дашбордом хоста. Готовые паттерны интеграций. Когда агенту понадобилась авторизация Salesforce, интеграция уже была подключена. Локально он строил бы OAuth с нуля. Непрерывность. Воркспейс помнит контекст между сессиями: replit.md, БД, дерево файлов, развёрнутый URL. Локальные агенты сбрасываются каждую сессию, если только вы вручную не записали всё.

Claude Code выигрывает для работы с несколькими репо, глубокой интеграции с редактором, всего, что не является развёрнутым веб-приложением. Если бы я строил CLI-инструмент или прыгал между пятью репо в день, я бы перевернул ответ. Для одного интеграционно-тяжёлого развёрнутого B2B-веб-приложения в паре с агентом-кокпитом субстрат делает больше работы, чем ему обычно отдают должное.

Модель та же. Различается взлётная полоса под моделью.

Этот паттерн пока не распространён

Паттерн «развёрнутое-приложение-плюс-кокпит-агент» — это не та категория, к которой большинство команд движется в 2026. Большинство B2B-команд, использующих агентов, попадают в три других ведра:

Чат-боксы внутри развёрнутых продуктов. Только production-агенты, обращённые к клиентам или внутренние. Агент — это фича в продукте. Кодинг-ассистенты вроде Cursor или Claude Code. Инструменты продуктивности для разработчиков, используемые чтобы писать код быстрее. Не операционные интерфейсы к живому бизнесу. Workflow-автоматизация в стиле Zapier. Заранее определённые потоки, запускаемые событиями. Никаких разговоров, никакой импровизации.

Установка SaaStr отличается от всех трёх. Агент — не фича в продукте, не просто кодинг-помощник и не фиксированный workflow. Это разговорный интерфейс к живому бизнесу с полным доступом на чтение/запись ко всем системам, на которых работает компания, и мы используем его для управления компанией изо дня в день. Я пока не видел публично, чтобы многие другие команды описывали этот паттерн.

Часть причины, почему он редок: большинство стэков не делает это лёгким. Вам нужно управляемое окружение, которое даёт агенту живые интеграции, разделяемые секреты между dev и prod, реальную файловую систему и возможность писать и запускать новый код против живого бизнеса. Replit так получилось, что комбинирует всё это. Большинство платформ — нет.

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

Три правила постройки агентного софта в 2026

Три правила:

Не шипите агента. Шипите то, что агент делает. Кладите операции, которые агент выполняет, в продакшен в виде кнопок, как только они становятся рутиной. Держите самого агента в кокпите, где он может безопасно импровизировать против того же субстрата. Рассмотрите возможность относиться к dev-воркспейсу как к несущей конструкции. Это не просто место, где пишется код. Это место, где вы исследуете странные числа, чините плохие записи, составляете тексты, переранжируете списки, рассылаете письма команде. Это реальная часть операционного стэка, а не побочное окружение. Оптимизируйте субстрат, а не только модель. Маргинальная ценность более умной модели мала, если агент не может дотянуться до вашей БД, ваших секретов, ваших деплоев и ваших интеграций без церемоний. Выберите окружение, минимизирующее церемонии.

Связка — это и есть архитектура

Настоящий ансклок в SaaStr — это не 10K. И не QBee. Это связка каждого развёрнутого приложения с агентом-кокпитом, разделяющим его субстрат.

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

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

Это изменится. Инструментарий production-агентов догонит, разрыв dev-prod закроется, субстрат станет умнее. Когда это произойдёт, кокпит и дашборд могут оказаться гораздо ближе друг к другу. Может быть, одним и тем же.

Однако пока, для нас, dev-воркспейс — это кокпит. Дашборд — это то, что видят люди. Кокпит — это там, где делается работа.

P.S. Этот пост был написан так же

Наш Replit Agent написал примеры Agent + App в этом посте. Он знал их назубок, гораздо лучше, чем мог бы я. Так что мы написали это вместе. Агент и Человек, Приложение и Агент, все вместе.

Это и есть The Way.