Почему 10K и QBee работают так хорошо: приложение и agent — это одна система
Сегодня в обсуждениях AI-агентов в B2B агент часто воспринимают как отдельную функцию, которую можно «вшить» в продукт: чат-бот, copilot или волшебную кнопку внутри интерфейса. Именно такой взгляд последние месяцы сбивал с толку и меня тоже.
На практике в SaaStr AI лучше всего работают 10K и QBee — наши AI VP Marketing и AI VP Customer Success. И движет ими не столько само приложение, сколько связка.
Оба решения — развернутые веб-приложения, которыми команда пользуется каждый день. У них есть настоящие дашборды, cron jobs и production-среда. Но само развернутое приложение — это только половина системы. Вторая половина в том, что мы используем Replit Agent, чтобы напрямую взаимодействовать с 10K и QBee так, как нельзя было бы делать, если бы это были просто отдельные опубликованные приложения. Из cockpit я — или Amelia, когда речь о QBee, — могу задавать live-приложению вопросы, исправлять внутри него данные, строить поверх него новые функции, и все это в одном разговоре. Агент использует ту же базу данных, те же secrets, интеграции и код, что и развернутое приложение, поэтому он работает с живым бизнесом, а не с копией.
По сути, мы «взламываем» Replit Agent на Claude Sonnet, давая ему чрезвычайно богатое и насыщенное контекстом окно — оно постоянно сжимается, но все равно хранит фрагменты каждой маркетинговой и клиентской операции, которую мы когда-либо делали в 10K и QBee, — чтобы он взаимодействовал и с AI-приложением, и с людьми. Вместе.
Именно эта комбинация и есть архитектура. И как только это понимаешь, становится ясно: «AI-агент в production» — это только начало того, что скоро будут делать все.
Утро пятницы в SaaStr AI
Пример из этой недели. Пять минут работы, которые были бы невозможны ни с одной частью системы по отдельности.
Наш sales executive David прислал сообщение: закрылись три новых Silvers — 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. Потом я сказал: «Набросай письмо David, укажи на расхождение по Kris@Work и изменение по Exa, в моем стиле». Он написал письмо, я поправил одну строку, и оно ушло через Resend.
Заодно он собрал отдельный ranker для участников Deep Dive Workshop: вытащил attendee из саммита в Bizzabo, исключил 71 спикера из CSV и примерно 91 компанию-спонсора из Salesforce, оценил их по allow-list из 150 брендов и выдал CSV на 100 человек.
Это обычная пятница в SaaStr AI. Ни один из шагов сам по себе не был гигантским. Смысл в том, что все они случились в одной цепочке, на живом бизнесе, с человеческим judgment в контуре, потому что у агента был полный доступ к тем же системам, что использует развернутое приложение.
Если бы 10K был только развернутым приложением, этого бы не произошло. Если бы агент был просто чат-окном, прикрученным к production, большая часть этого тоже не сработала бы. Работает именно связка.
Другой пример, другой оператор
Та же неделя, другой человек, другой тип работы.
Amelia, наш Chief AI Officer, спросила 10K изнутри Replit cockpit: «кого, по-твоему, нам стоит пригласить на deep dive? Наверное, в основном тех, кто идет на summit, или компании, которые активно растут в AI. Кого бы ты выбрал?»
Агент выполнил 24 действия. Он вытянул live-данные из 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 человек на summits. Берем всех.
- 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». Одно название должности уже говорит, что она должна быть на каждом workshop.
Плюс Relevance AI, Amotions AI, Fireworks AI, Crusoe, Horizon3.ai, Shield.AI, Level AI, Conviva, WisdomAI, Explorium и еще 25+ компаний в этой корзине.
Именно так cockpit делает работу, которую chat box в production не смог бы сделать хорошо: новый вопрос, judgment в контуре, live-данные из трех систем, качественное reasoning-обоснование для каждого имени. В deployed app не лежит готовый инструмент pick_deep_dive_invitees, ожидающий такой запрос. Агент создал его на лету, потому что среда это позволяла. И спрашивал не я. Это делала Amelia, выполняя свою реальную работу из cockpit.
823 коммита за шесть месяцев. Ни один не начинался как код
В репозитории 10K за примерно шесть месяцев накопилось 823 коммита. Подавляющее большинство началось с того, что я написал агенту обычное предложение, а не с того, что я сел писать код вручную.
Вот лишь часть того, что было создано таким способом, и все это запускалось в разговоре:
- Карточка прогнозирования продаж билетов («спрогнозируй, где мы окажемся, исходя из последних 30 дней»).
- Слой stale-while-revalidate caching, который сократил холодный старт дашборда с 5–15 секунд до 50 мс.
- Чат-бот с голосовым вводом и ответом, который умеет говорить, слушать и знает live-данные дашборда.
Ни одна из этих вещей не начиналась с письменного ТЗ. Они начинались с одной фразы. Агент строил их сам.
Импровизация уходит глубже, чем построение фич. Пришло уведомление об ошибке в имени покупателя comp ticket: вместо «Cassidy Centures» должно было быть «Cassidy Ventures». Я спросил агента, read-only у Bizzabo API или он умеет записывать данные. Он не знал, и я не знал. Документация у Bizzabo скудная, а в кодовой базе были подключены только read-paths. Поэтому он параллельно проверил пять разных write-endpoint: PATCH по registration (404), PATCH по contact (404), PATCH по properties subresource (404), POST по registration (404), PUT по registration с телом { properties: { company: «…» } } (200). Потом он повторно запросил данные, чтобы убедиться, что изменение закрепилось, и сохранил reusable script на будущее. Вся операция заняла меньше двух минут. Мне не пришлось открывать тикет в support.
В ту же неделю письмо, сгенерированное агентом, не прошло через Resend с первой попытки. Агент попытался отправить его с неподтвержденного домена и получил 403. Тогда он просмотрел кодовую базу, нашел фактического подтвержденного отправителя, повторил попытку и отправил письмо. Затем он добавил правило в project preferences file: письма, инициированные агентом, по умолчанию должны уходить от SaaStr 10K, а не лично от Jason, и зафиксировал единственный подтвержденный домен отправки. Это правило теперь действует для каждого будущего письма.
Агент не просто исправил ошибку. Он обновил свое будущее поведение. Такой self-modification поверх undocumented API за две минуты — именно то, что трудно воспроизвести внутри развернутого приложения.
Почему эта связка работает
Когда dev-agent работает в том же workspace, где строился 10K, у него есть структурные преимущества, которые не переносимы в agent-only production:
- Та же файловая система. Он читает CSV, пишет промежуточные scratch scripts, сохраняет результаты, итеративно дорабатывает. В deployed container нет scratch space.
- Те же secrets. Все 30+ API keys — Salesforce, Bizzabo, Marketo, X, Resend, YouTube — лежат там же как env vars. Нет рассинхронизации между dev и prod, потому что dev и prod разделяют одну и ту же substrate.
- Та же база данных. При необходимости агент напрямую запрашивает production Postgres. Никакой схемы «сначала синхронизируй данные в sandbox».
- Тот же код. Агент за 30 секунд пишет новый TypeScript-скрипт и запускает его на живом бизнесе. Никакого deploy cycle.
- Тот же deploy loop. Когда скрипт становится кнопкой, он уходит в production из того же workspace. Без передачи задач и миграции окружений.
- Та же память. У агента есть context window, которая со временем сжимается, но сохраняет фрагменты каждой маркетинговой и клиентской операции в 10K и QBee. Он помнит правила, которые сам себе сохранил (подтвержденные домены отправки, tone of voice, кто утверждает bulk send), скрипты, написанные на прошлой неделе, и названия только что закрытых сделок. Production-агент в новом сеансе начинает с нуля.
Дело не в том, что модель «магическая». Дело в том, что substrate вокруг модели берет на себя всю неброскую, но важную инфраструктуру. Агент полезен ровно настолько, насколько легко ему добраться до нужных вещей. Когда развернутое приложение и dev-agent разделяют substrate, агент получает доступ ко всему, что доступно приложению.
Почему изолированный standalone production-agent пока уступает
Можно построить агента полностью внутри развернутого приложения. Чат-окно в дашборде, доступ только для admin users, набор заранее подготовленных tool-ов — query_salesforce, send_email, issue_comp_ticket, post_tweet. Для рутинных операций это работает нормально. Возможно, даже лучше, чем dev-agent, потому что быстрее и лучше аудируется.
Но как только работа перестает быть рутинной, ломаются три вещи.
1. Production-agent не может писать новый код.
Это момент, который чаще всего упускают founders. Суперсила dev-agent не в вызове заранее созданных API. Она в том, что он на лету пишет совершенно новый код. Когда я сказал: «найди крупные CMO, которых мы пропустили в списке deep-dive», агент за две минуты написал новый ranker script. Никакого инструмента find_missed_cmos там не было. Он изобрел его сам.
Production-agent может вызывать только те инструменты, которые вы заранее написали. Как только вопрос становится новым («почему число по Exa неверное?», «можем сверить этот CSV с Salesforce?»), вы ждете, пока кто-то создаст новый tool, задеплоит его и попробует снова. В dev этот цикл занимает 30 секунд. В prod это уже sprint.
Смысл слова «agent» не в tool-calling. Смысл в том, что он пишет код для задач, которые вы не предвидели.
2. Нет scratch space — нет импровизации.
Половина работы в примере с David заключалась в чтении CSV, создании промежуточных файлов, генерации четырех разных output CSV, сравнении результатов и итерациях. У deployed container этого нет. Можно притвориться, используя object storage и sandboxed exec, но тогда вы строите внутри приложения маленькую IDE, причем плохо.
3. Меняются ставки.
Dev-agent с плохим SQL-запросом просто раздражает меня. Production-agent с плохим SQL-запросом обновляет 400 opp в Salesforce и отправляет 8 000 участникам письмо с неправильной темой.
Настоящему production-agent нужны жесткие права на каждый tool, audit logs, confirmation flows, rate limits, dry-run режимы, evals и rollback. К тому моменту, когда вы построите всю эту защитную обвязку как следует, вы потратите недели, а агент все равно будет делать меньше, чем делает ваш dev-agent сегодня, и с большим трением.
Реалистичный потолок для чистого production-agent в проекте вроде 10K — примерно 60–70% возможностей dev-agent для operational задач и примерно 0% для построения или investigation.
Ментальная модель: dashboard + cockpit
Формулировка такая:
Dev workspace — это cockpit. Место, где сидит оператор. Те же live-системы, полный IDE, реальный shell, агент, который может писать код. Investigation, copywriting, решения по judgment, исправление разовых записей, сборка новых скриптов.
Один и тот же substrate. Два интерфейса. Dashboard — это в основном режим просмотра. Cockpit — это режим записи куда угодно.
У такого разделения есть неочевидные плюсы:
- Dashboard остается простым. Никаких чат-окон, registry инструментов, админ-панелей агента и отдельной модели прав доступа. Просто dashboard.
- Рискованная поверхность сосредоточена в одном workspace, а не во всем deployment. Ошибки происходят в dev, а не перед пользователями.
- Работа, требующая judgment, находится там, где ей место. Production runtimes по своей природе плохо подходят для импровизации. Dev environments по своей природе подходят хорошо.
- Путь к «превращению в кнопку» понятен. Когда ad-hoc операция повторяется пять раз, она становится кнопкой в dashboard. До этого момента она остается скриптом.
Именно этот последний пункт — операционный принцип: автоматизировать в виде кнопок все, что стало рутиной, а агента оставлять в dev для всего остального.
Есть важная оговорка. Это снимок того, что работает в мае 2026 года, а не вечный закон природы. Production-agent tooling быстро улучшается. Sandboxed code execution, managed integrations, hosted dev environments внутри production-приложений — все это стремительно становится лучше. Разрыв между тем, что может dev-agent, и тем, что может production-agent, быстро сократится в ближайший год. Но пока, для нас, dev workspace — это cockpit. Через год ответ может быть другим.
QBee работает по той же архитектуре
QBee, наш AI VP of Customer Success, был создан Amelia на Replit и теперь управляет 100+ спонсорами, сокращая потребность в человеческом времени на 70%. Та же архитектура, что и у 10K.
Причина, по которой QBee работает, — не только само развернутое приложение. Дело в том, что Amelia может сидеть в Replit cockpit и заставлять QBee переоценивать список спонсоров, писать сообщение в ее стиле, исправлять неверную onboarding-запись, запрашивать live Postgres, запускать новую функцию — и все это в одной цепочке. Deployed app берет на себя рутину. Cockpit — все остальное.
Каждый раз, когда мы пытались протолкнуть больше «интеллекта» внутрь самого deployed app, результат получался хуже, чем если оставить dashboard простым и поднять интеллект на один уровень substrate выше.
Наш cockpit агента и приложения пока не масштабируется на слишком большое число людей
Сегодняшняя схема работает, потому что в cockpit одновременно максимум 1–3 оператора. У агента есть полные права на запись в Salesforce, полные права на запись в Bizzabo, полный доступ к Resend — без границ доступа. Это нормально, когда оператор — founder или senior IC. Но для 10 маркетологов это стало бы катастрофой. Стоило бы кому-то один раз сказать: «отправь письмо с предложением скидки 50%», и агент бы это сделал для 8 000 участников, без approval gate, без rate limit и без rollback.
Cockpit по задумке — это среда с высоким доверием и высокой мощностью. Если в маркетинговой команде 10 человек, архитектура должна вырасти. Cockpit остается для 2–3 операторов. Всем остальным нужен deployed admin app с кнопками, ограниченными по ролям, approval flows для всего разрушительного или широкомасштабного воздействия (bulk emails, изменение суммы opp, все, что затрагивает больше 1 000 записей), полные audit logs каждого действия с индивидуальными credentials и rate limits на bulk operations. Агент в cockpit остается суперсилой операторов. Команда получает безопасные, аудируемые, role-gated инструменты, которые операторы продолжают добавлять по мере того, как pattern из cockpit доказывают свою жизнеспособность.
Это естественное продолжение buttonization. Cockpit — для 1–3 человек, навсегда. Все остальные «летают» через кнопки, которые строит cockpit.
Сработали бы Claude Code или Cursor так же хорошо?
Нам часто задают этот вопрос. Для проекта вроде 10K или QBee — нет, и дело не в модели.
Модель в Claude Code или Cursor примерно эквивалентна той, что мы используем в Replit. Та же семья моделей, то же качество генерации кода, то же reasoning. Если посадить меня писать deep-dive ranker в любом из этих инструментов, результат был бы примерно одинаковым.
Разница — во всем, что окружает модель:
- Managed environment. В Replit Postgres DB, 30+ secrets, deployed URL, cron jobs и workflows находятся в одном месте, которое агент уже понимает. В local-first tool production где-то совсем в другом месте — Vercel, Render, VPS. Агенту трудно добраться до prod logs или prod DB без ручной настройки.
- Deployment loop. В Replit: правка, auto-restart, preview, deploy по кнопке. Local-first: git, CI, host config, env vars в двух местах и вечная рассинхронизация между ними.
- Secrets parity. Dev и prod нативно делят одни и те же secrets. Локально приходится синхронизировать .env и dashboard хоста.
- Готовые шаблоны интеграций. Когда агенту понадобилась аутентификация Salesforce, интеграция уже была настроена. Локально пришлось бы строить OAuth с нуля.
- Непрерывность. Workspace помнит контекст между сессиями: replit.md, базу данных, дерево файлов, deployed URL. Локальные агенты сбрасываются каждый раз, если вы не зафиксировали все вручную.
Claude Code выигрывает для работы с несколькими репозиториями, глубокой интеграции с редактором и всего, что не является deployed web app. Если бы я строил CLI-утилиту или каждый день прыгал между пятью репозиториями, я бы выбрал его. Но для одного сильно интегрированного B2B web app, которому помогает cockpit-agent, substrate делает куда больше работы, чем ему обычно приписывают.
Модель та же. Отличается взлетная полоса под ней.
Пока это не очень распространенный паттерн
Паттерн deployed-app-plus-cockpit-agent в 2026 году пока не стал категорией, к которой массово движутся команды. Большинство B2B-команд с агентами попадают в три другие группы:
- Чат-окна внутри deployed-продуктов. Production-only агенты, внешние или внутренние. Агент — это функция в продукте.
- Кодовые ассистенты вроде Cursor или Claude Code. Инструменты продуктивности для разработчиков, помогающие писать код быстрее. Это не operational interface к живому бизнесу.
- Workflow automation в стиле Zapier. Предопределенные flow, запускаемые событиями. Без разговора, без импровизации.
Подход SaaStr отличается от всех трех. Агент — это не функция продукта, не просто помощник для кодинга и не жесткий workflow. Это conversational interface к живому бизнесу с полным read/write доступом ко всем системам, на которых работает компания, и мы используем его, чтобы управлять компанией каждый день. Я пока не видел, чтобы многие другие команды публично описывали именно такой паттерн.
Частично поэтому он редок: большинству стеков это просто неудобно. Нужна managed environment, которая дает агенту live-интеграции, общие secrets между dev и prod, реальную файловую систему и возможность писать и запускать новый код на живом бизнесе. Replit как раз сочетает все это. Большинство платформ — нет.
Если ваш стек позволил бы сделать это, у вас есть источник leverage, который большинство команд еще не использовало.
Три правила для создания agentic software в 2026 году
Три правила:
Не ship-айте самого агента. Ship-айте то, что агент делает. Когда операции становятся рутиной, выносите их в production как кнопки. Самого агента держите в cockpit, где он может безопасно импровизировать на том же substrate.
Рассматривайте dev workspace как load-bearing часть системы. Это не просто место, где пишется код. Это место, где вы расследуете странные цифры, исправляете плохие записи, пишете тексты, переоцениваете списки, отправляете письма команде. Это полноценная часть operating stack, а не вспомогательная среда.
Оптимизируйте substrate, а не только модель. Маржинальная ценность более умной модели невелика, если агент не может без церемоний добраться до вашей базы данных, secrets, deploys и интеграций. Выбирайте среду, где меньше лишних шагов.
Связка и есть архитектура
Настоящий прорыв в SaaStr — не в 10K. И не в QBee. Он в связке каждого deployed app с cockpit-agent, который разделяет с ним substrate.
Deployed app дает команде стабильную, предсказуемую поверхность. Cockpit дает оператору полную силу агента по отношению к тем же данным, тем же secrets и тому же коду. Те же системы, два интерфейса, разные задачи.
Именно эта архитектура работает сейчас. Большинство founders, которые сегодня ship-ают «AI agents in production», пытаются слить обе поверхности в одну, и получают более слабого агента и более хрупкий продукт. Пока выигрывают те команды, которые держат поверхности раздельно, позволяют каждой быть хорошей в своем, и рассматривают dev workspace как реальную часть operating stack компании.
Это изменится. Инструменты для production-agent догонят, разрыв между dev и prod сократится, substrate станет умнее. Когда это произойдет, cockpit и dashboard, возможно, окажутся гораздо ближе друг к другу. Может быть, вообще станут одним и тем же.
Но пока, для нас, dev workspace — это cockpit. Dashboard — это то, что видят люди. Cockpit — это место, где работа делается.
P.S. Этот пост был написан так же
Наш Replit Agent написал примеры связки Agent + App в этом посте. Он знал их досконально, гораздо лучше, чем смог бы я. Поэтому мы писали это вместе. Agent и человек, App и Agent — все вместе.
Это и есть The Way.
Материал — перевод статьи с английского.