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

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) так хорошо работают: приложение и агент — одна система

by Jason Lemkin | Artificial Intelligence (AI), Blog Posts, SaaStr.Ai

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

Most of the discussion about AI agents in B2B right now treats the agent as a feature you ship: a chat box, a copilot, a magical button inside your product. That framing has been throwing people off, including me, for the past year.

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

What’s actually working at SaaStr AI, and the reason 10K and QBee (our AI VP Marketing and AI VP Customer Success) both move the business as much as they do, isn’t the apps themselves. It isn’t the agents themselves either. It’s the pairing.

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

Both are deployed web apps the team uses every day. Real dashboards, real cron jobs, real production substrate. But the deployed app on its own is only half of the system. The other half: we use the Replit Agent to interact with 10K and QBee directly, in a way we couldn’t if they were just standalone published apps. From the cockpit, I (or Amelia, for QBee) can ask the live app questions, fix things inside it, build new features on top of it, all in one conversation. The agent shares the same database, secrets, integrations, and code as the deployed app, so it’s working with the live business, not a copy.

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

In essence, we’re “hacking” the Replit Agent running Claude Sonnet with an extremely rich and context-filled window (that continually compacts but still holds portions of every marketing and customer action we’ve ever done on 10K and QBee) to interact with the AI application and the humans. Together.

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

That combination is the architecture. And once you see it, you can see “AI agent in production” is just the start of what we’ll all be doing soon.

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

A Friday Morning at SaaStr AI

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

From this week. Five minutes of work that wouldn’t have been possible with either piece alone.

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

Our sales exec David sent a note: three new Silvers closed (Manus AI, Jobright, Kris@Work) and Exa upgraded.

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

I asked the Replit Agent to verify against Salesforce. It wrote a quick query, found Manus AI and Jobright already Closed Won, but no opp at all for Kris@Work, and Exa still sitting in Stage 3 Super Gold at $87.5K.

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

I asked it to update the Exa opp: rename it, update it, mark Closed Won today. Done in 30 seconds via jsforce. Then: “draft an email to David flagging the Kris@Work gap and the Exa change, in my voice.” It wrote it, I tweaked one line, it sent via Resend.

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

While we were at it, it built a separate ranker for Deep Dive Workshop invitees: pulled the Bizzabo summit attendees, excluded 71 speakers from a CSV and ~91 sponsor companies from Salesforce, scored against a 150-brand allow-list, spit out a 100-person CSV.

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

That’s a normal Friday at SaaStr AI now. None of those steps are huge individually. The point is they all happened in one thread, against the live business, with judgment in the loop, because the agent had full access to the same systems the deployed app uses.

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

If 10K were just the deployed app, none of that happens. If the agent were a chat box bolted into production, most of it doesn’t happen either. The pairing is what works.

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

Another Example, Different Operator

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

Same week, different person, different kind of work.

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

Amelia, our Chief AI Officer, asked 10K from inside the Replit cockpit: “who do you think we should invite to do a deep dive? probably mostly folks going to summit or rising AI companies, who do you think?”

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

The agent ran 24 actions. Pulled live Bizzabo data: 397 current total CXO summit attendees, 134 CROs, 160 CMOs, 103 FDEs and CCOs. Cross-referenced against the sponsor list. Scored against an AI-native company filter. Built a tiered invite list with reasoning attached to each name.

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

Tier 1 came back as 40 auto-invites: senior, AI-first, already paying for summit access. The output named names and gave a one-line rationale per company:

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». Одно название должности говорит, что она должна быть на каждом воркшопе.

Plus Relevance AI, Amotions AI, Fireworks AI, Crusoe, Horizon3.ai, Shield.AI, Level AI, Conviva, WisdomAI, Explorium, and 25+ more in the bucket.

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

That’s the cockpit doing work no chat box in production could do well: a novel question, judgment in the loop, live data from three systems, qualitative reasoning attached to each name. There’s no pick_deep_dive_invitees tool sitting in the deployed app waiting for that question. The agent built it on the fly because the substrate let it. And it wasn’t me asking. It was Amelia, doing her actual job from her cockpit.

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

823 Commits in Six Months. None of Them Started as Code.

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

The 10K repo has 823 commits in about six months. The vast majority started as me typing a sentence to the agent, not as me writing code.

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

A sample of what got built this way, all triggered conversationally:

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

Карточка предиктивного прогноза продаж билетов («предскажи, к чему мы выйдем, исходя из последних 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 в один клик.

None of those started as written specs. They started as a sentence. The agent built them.

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

The improvisation runs deeper than feature-building. A typo notification came in for a comp ticket buyer: “Cassidy Centures” should have been “Cassidy Ventures.” I asked the agent if Bizzabo’s API was read-only or could write. It didn’t know, and I didn’t know. Bizzabo’s docs are sparse and our codebase only had read paths wired up. So it probed five different write endpoints in parallel: PATCH on the registration (404), PATCH on a contact (404), PATCH on a properties subresource (404), POST on the registration (404), PUT on the registration with a { properties: { company: "..." } } body (200). It re-fetched to confirm the change stuck, then saved a reusable script for next time. Total time: under two minutes. I never opened a support ticket.

Импровизация идёт глубже постройки фич. Пришло уведомление об опечатке для покупателя 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). Он повторно подтянул данные, чтобы убедиться, что изменение зафиксировалось, потом сохранил переиспользуемый скрипт для следующего раза. Общее время: меньше двух минут. Я не открывал тикет в поддержку.

Same week, an agent-drafted email failed through Resend on first attempt. The agent had tried an unverified domain, and got a 403. So it grepped the codebase, found that the actual verified sender, retried, sent. Then it saved a rule to the project preferences file: agent-initiated emails default to SaaStr 10K, not Jason personally, and noted the only verified send domain. That preference now applies to every future email it sends.

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

The agent didn’t just fix the bug. It updated its own future behavior. That kind of self-modification, against an undocumented API, in two minutes, is exactly what’s hard to replicate inside a deployed app.

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

Why The Pairing Works

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

When the dev agent runs in the same workspace where 10K was built, it has structural advantages that don’t translate to a deployed-only agent:

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

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

This isn’t because the model is magic. It’s because the substrate around the model handles all the unglamorous plumbing. The agent is only as useful as how easily it can reach the things it needs to touch. When the deployed app and the dev agent share substrate, the agent can reach everything the app can.

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

Why A Pure, Isolated Stand-Alone Production Agent Would Fall Short Today

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

You could build an agent fully inside a deployed app. Chat box in the dashboard, gated to admin users, wired to a set of pre-built tools (query_salesforce, send_email, issue_comp_ticket, post_tweet). For routine ops it works fine. Maybe better than the dev agent, because it’s faster and properly auditable.

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

Three things break the moment the work gets non-routine.

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

1. A prod agent can’t write new code.

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

This is the one most founders miss. The dev agent’s superpower isn’t calling pre-built APIs. It’s writing brand-new code on the fly. When I said “find the big-brand CMOs we missed in the deep-dive list,” the agent wrote a new ranker script in two minutes. There was no find_missed_cmos tool sitting there waiting. It invented one.

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

A production agent can only call tools you pre-wrote. The moment the question is novel (“why is the Exa number wrong?”, “can we cross-reference this CSV against Salesforce?”), you’re stuck waiting for someone to write a new tool, deploy it, and try again. In dev that loop is 30 seconds. In prod it’s a sprint.

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

The “agent” part of an agent isn’t tool-calling. It’s writing code to do things you didn’t anticipate.

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

2. No scratch space, no improvisation.

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

Half the work in the David example involved reading a CSV, writing intermediate files, generating four different output CSVs, comparing them, iterating. A deployed container has none of that. You can fake it with object storage and a sandboxed exec, but now you’re building a tiny IDE inside your app, and badly.

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

3. The stakes flip.

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

A dev agent with a bad SQL query annoys me. A prod agent with a bad SQL query updates 400 Salesforce opps and emails 8,000 attendees the wrong subject line.

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

A real production agent needs tight per-tool permissions, audit logs, confirmation flows, rate limits, dry-run modes, evals, rollback. By the time you’ve built all that safety scaffolding properly, you’ve spent weeks and the agent still does less than your dev agent does today, with more friction.

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

The realistic ceiling for a pure production agent on a project like 10K: maybe 60 to 70% of dev-agent capability for operational tasks, and roughly 0% for building or investigation.

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

The Mental Model: Dashboard + Cockpit

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

The framing:

Рамка:

The deployed app is the dashboard. Clean, fast, predictable, boring on purpose. Live numbers, scheduled jobs, newsletters, pipeline tracking. What the team sees and uses.

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

The dev workspace (at least for now, for us, it’s in dev) is the cockpit. Where the operator sits. Same live systems, full IDE, real shell, an agent that can write code. Investigation, copywriting, judgment calls, fixing one-off records, building new scripts.

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

Same substrate. Two interfaces. The dashboard is the read-mostly view. The cockpit is the write-anywhere view.

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

This split has non-obvious benefits:

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

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

That last point is the operating principle: buttonize what’s routine, keep the agent in dev for everything else.

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

One important caveat. This is a snapshot of what works in May 2026, not a permanent law of the universe. Production agent tooling is improving at a rapid pace. Sandboxed code execution, managed integrations, hosted dev environments inside production apps, all of it is getting better fast. The gap between what a dev agent and a prod agent can do will narrow quickly over the next year. For now, for us, the dev workspace is the cockpit. A year from now the answer might be different.

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

QBee Runs The Same Architecture

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

QBee, our AI VP of Customer Success, was built by Amelia on Replit and now manages 100+ sponsors with a 70% reduction in human hours. Same architecture as 10K.

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

The reason QBee works isn’t the deployed app alone. It’s that Amelia can sit in the Replit cockpit and have QBee re-rank a sponsor list, draft a message in her voice, fix a bad onboarding record, query the live Postgres, ship a new feature, all in one thread. The deployed app handles the routine. The cockpit handles everything else.

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

Every time we’ve tried to push more “intelligence” into the deployed app itself, we’ve gotten a worse result than keeping the dashboard simple and putting the intelligence one substrate-level up.

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

Our Agent + App Cockpit Wouldn’t Scale (Yet) With Too Many Humans

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

Today’s setup works because there are 1-3 operators in the cockpit, max. The agent has full Salesforce write, full Bizzabo write, full Resend send, no permission boundaries. That’s fine when the operator is the founder or a senior IC. It would be a disaster if 10 marketers all had that level of access. The first time one of them said “send an email offering 50% off,” the agent would do it, against 8,000 attendees, with no approval gate, no rate limit, and no rollback.

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

The cockpit is a high-trust, high-power environment by design. With a 10-person marketing team, the architecture has to grow. The cockpit stays at 2-3 operators. Everyone else gets a deployed admin app with role-gated buttons, approval flows on anything destructive or wide-reach (bulk emails, opp amount changes, anything touching more than 1,000 records), full audit logs of every action with per-person credentials, and rate limits on bulk operations. The agent in the cockpit stays the operators’ superpower. The team gets safe, audited, role-gated tools the operators keep adding to as patterns from the cockpit prove themselves out.

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

This is the natural extension of buttonization. The cockpit is for 1-3 people, forever. Everyone else flies the plane through the buttons the cockpit builds.

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

Would Claude Code Or Cursor Work As Well?

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

We get this question a lot. For a project like 10K or QBee, no, and the reason isn’t the model.

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

The model in Claude Code or Cursor is roughly equivalent to what we’re using in Replit. Same family, same code generation quality, same reasoning. If you sat me down to write the deep-dive ranker in either tool, the output would be about the same.

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

The difference is everything around the model:

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

Управляемое окружение. В 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 wins for multi-repo work, deep editor integration, anything that isn’t a deployed web app. If I were building a CLI tool or jumping across five repos a day, I’d flip the answer. For a single, integration-heavy, deployed B2B web app paired with a cockpit agent, the substrate is doing more work than people give it credit for.

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

The model is the same. The runway underneath the model is what differs.

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

This Pattern Isn’t Common Yet

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

The deployed-app-plus-cockpit-agent pattern isn’t really a category most teams are building toward in 2026. Most B2B teams running agents fall into three other buckets:

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

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

The SaaStr setup is different from all three. The agent isn’t a feature in the product, isn’t just a coding helper, and isn’t a fixed workflow. It’s a conversational interface to the live business, with full read/write access to every system the company runs on, that we use to operate the company day to day. I haven’t seen many other teams describe this pattern publicly yet.

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

Part of why it’s rare: most stacks don’t make it easy. You need a managed environment that gives the agent live integrations, shared secrets across dev and prod, a real filesystem, and the ability to write and run new code against the live business. Replit happens to combine all of those. Most platforms don’t.

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

If your stack would let you do this, you have a leverage source most teams haven’t tapped yet.

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

Three Rules For Building Agentic Software In 2026

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

Three rules:

Три правила:

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

The Pairing Is The Architecture

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

The real unlock at SaaStr isn’t 10K. It isn’t QBee. It’s the pairing of each deployed app with a cockpit agent that shares its substrate.

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

The deployed app gives the team a stable, predictable surface. The cockpit gives the operator full agent power against the same data, the same secrets, the same code. Same systems, two interfaces, different jobs.

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

That’s the architecture that’s working right now. Most founders shipping “AI agents in production” today are trying to merge the two surfaces, and ending up with a worse agent and a more fragile product. The teams that win, for now, are the ones that keep the surfaces separate, let each one be good at what it’s good at, and treat the dev workspace as a real piece of the company’s operating stack.

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

This will change. The production-agent tooling will catch up, the dev-prod gap will close, the substrate will get smarter. When it does, the cockpit and the dashboard might end up much closer together. Maybe the same thing.

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

For now though, for us, the dev workspace is the cockpit. The dashboard is what people see. The cockpit is where the work gets done.

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

P.S. This Post Was Written The Same Way

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

Our Replit Agent wrote the examples of Agent + App in this post. It knew them cold, far better than I could have. So we wrote this together. Agent and Human, App and Agent, all together.

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

This is The Way.

Это и есть The Way.