В любой B2B-команде размером от двадцати человек есть Notion-страница «Как мы работаем». Её открывают на онбординге, проходят по диагонали, ставят галочку и больше не возвращаются. Через шесть месяцев процесс уже не такой, как на странице, а через год расхождение становится системным: новые сотрудники задают одни и те же вопросы в чате, потому что страница врёт, а никто этого не отметил. В материале PagerDuty, посвящённом определению runbook описывается типовой паттерн: команда без исполняемых runbook-ов в инциденте тратит первые минуты не на устранение проблемы, а на восстановление того, кто что должен делать. Регламент существует, но не управляет ничем.

За этой бытовой картиной стоит структурная проблема. Корпоративный регламент в виде документа — это описание мира как он должен быть. Операционная политика — это правило принятия решения в конкретной ситуации с конкретными входными данными. Между ними не косметическая разница, а категориальная. Документ обращается к человеку и предполагает, что человек его прочитает, запомнит и применит. Политика обращается к системе и предполагает, что система её соблюдает, проверяет и фиксирует исключения. Первый формат тиражируем через копипасту. Второй — версионируем, исполняем и аудируем.

Этот сдвиг выходит из узкого инженерного сегмента в массовую практику, а не остаётся эксклюзивом крупного инженерного бизнеса. Дисциплина policy-as-code, выросшая из инфраструктурного мира, доросла до уровня зрелости, при котором её можно применять к управленческим решениям. Архитектура памяти агентов даёт примитив для хранения граф-структуры этих решений. Управляемые среды исполнения для крупных языковых моделей позволяют использовать эти модели как ограниченных по политике исполнителей, а не как свободных текстогенераторов. Эти три слоя — формальные правила в коде, графовая память, контролируемая среда исполнения ИИ-моделей — совпадают к тому моменту, когда скорость принятия решений становится критичной величиной, и документ-регламент перестаёт быть первичным артефактом.

Почему регламент как документ не работает?

Документ-регламент страдает теми же тремя дефектами, что любой документ-как-источник-истины, но с операционными последствиями, которые не списываются на «устарело — обновим».

Первый дефект — разрыв между описанием и решением. Регламент описывает шаги, политика описывает условие. Страница «как мы квалифицируем входящего лида» в Notion перечисляет пять шагов; в живой работе менеджер принимает решение «передавать ли в отдел продаж или закрывать как мусор» по семи признакам, четыре из которых не описаны нигде. Эти четыре признака — реальная политика компании. Они живут в голове у трёх старших менеджеров и передаются на онбординге устно. При уходе одного из них часть политики исчезает, и об этом узнают по росту числа жалоб.

Второй дефект — отсутствие исполнителя. У документа нет того, кто его соблюдает. Считается, что соблюдает человек, но человек принимает решение в условиях усталости, цейтнота, неполной информации и легко конкурирующих интерпретаций. В инженерной культуре эта проблема решена давно: ни одна команда уровня Netflix или Stripe не полагается на то, что инженер «вспомнит политику безопасности». Политика выражена кодом, валидатор отвергает деплой, нарушающий её, и инженер физически не может проигнорировать правило. В операционных отделах аналогичной дисциплины почти не существует — за исключением узкого сегмента финансовых рабочих процессов, где её требует регулятор.

Третий дефект — отсутствие истории. Регламент в Notion не помнит, когда и почему правило изменилось. Эта же проблема в инженерном мире решалась в последние 15 лет через дисциплину commit-сообщений и ADR-документов, фиксирующих контекст решения в момент его принятия. Версионная история страницы есть, но она показывает diff текста, а не контекст решения. На вопрос «почему мы перестали закрывать сделки в пятницу» страница ответит словом «потому что мы решили так делать», а реальная причина — конкретный провалившийся релиз шесть месяцев назад — не зафиксирована нигде, кроме как в памяти трёх человек. При смене этих троих причина исчезает, правило остаётся как карго-культ, и через два года кто-то его молча отменяет, не зная истории.

Эти три дефекта не лечатся «лучшим Notion» по той же причине, по которой не лечится документ как примитив знания в целом: они вшиты в природу документа как акта рефлексии после события. Регламент пишется тогда, когда уже принято решение, как должно быть. Политика работает тогда, когда решение ещё принимается. Чтобы перевести одно в другое, нужно изменить единицу — со страницы на правило-в-исполнении.

Что такое исполняемая политика как артефакт

Исполняемая политика (executable policy) — это правило принятия решения, выраженное в формальном языке, которое исполняется средой исполнения и порождает аудиторский след с временем, актором, входными данными и результатом. Не текст про правило, а само правило, доступное для машинной проверки.

Разница укладывается в три практических критерия, которые можно проверить в любой команде:

Первые три строки — категориальные; последние две — экономические и как раз объясняют, почему первые три выливаются в операционную бесполезность документа.

В инженерном мире эта концепция реализована в проекте Open Policy Agent (OPA), который принят в CNCF на уровне graduated в феврале 2021 года, через 5 лет после запуска проекта в 2016 году и используется крупными технологическими компаниями для проверки облачных конфигураций, прав доступа Kubernetes и контрактов API. OPA задаёт язык Rego, в котором правило описывается как «при таких входных данных вернуть такое решение». Правило живёт в репозитории на GitHub рядом с тестами, проходит ревью пулл-реквестом и развёртывается как любой код. У этой архитектуры есть конкретные свойства, которые отсутствуют у Notion-страницы: правило проверяется автоматически на каждом релевантном событии, его нарушение блокируется или эскалируется, история изменений живёт в коммитах с обязательным описанием.

Тот же подход в виде Sentinel у HashiCorp применён к управлению инфраструктурой: прежде чем Terraform создаёт ресурсы, набор политик проверяет, не нарушает ли изменение требования безопасности, расходов или соответствия. Решение «можно ли развернуть эту конфигурацию» принимается не инженером и не страницей в Confluence, а исполняемой политикой с аудиторским следом.

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

Граф решений как форма политики

Линейный список правил перестаёт работать, как только правил становится больше 30–40. Зависимости между ними не описываются плоской таблицей: «эскалировать инцидент» зависит от типа клиента, тарифа, истории взаимодействия, текущей загрузки команды и времени суток. Это не таблица, это граф. И именно как граф решений политика становится управляемым артефактом.

Графовые системы для агентной памяти, такие как Graphiti — открытый временно́й граф знаний, решают близкую задачу: фиксируют сущности, отношения и время их валидности. Тот же примитив применим к политике. Узел графа — это правило с условием и результатом. Ребро — это зависимость одного правила от другого. Двойная метка времени, как у Graphiti, отвечает на вопрос «с какого момента это правило действует и когда оно перестало действовать». Изменение правила не затирает старое — добавляет новый узел с новыми границами валидности. На вопрос «как мы решали этот случай в марте» система отвечает не догадкой, а извлечённым состоянием графа на марте.

Этот сдвиг меняет саму единицу, с которой работает регламент. Документ остаётся — но как проекция графа, рендер для конкретного читателя в конкретный момент. Онбординг новичка читает «текущее состояние политики на сегодня» как сгенерированный из графа документ; аудит получает diff между двумя моментами; владелец процесса работает не с текстом, а с самими узлами и ребрами. Документ перестаёт быть источником и становится одной из возможных поверхностей чтения.

Где это уже работает в управленческой плоскости?

Узкий, но показательный сегмент, где исполняемая политика управляет операцией — финансовые рабочие процессы в крупных компаниях. Правила соответствия (compliance) описаны не страницей в Confluence, а исполняемыми правилами в системах вроде ServiceNow или внутренних оркестраторах. Заявка на договор проходит через граф проверок, каждая из которых имеет аудиторский след; отклонение фиксируется как событие; политика версионируется и пересматривается раз в квартал. Это работает по принуждению регулятора — но архитектурно то же самое применимо к любому операционному процессу, где решения принимаются часто: скидка выше порога без согласования начальника — такое же policy rule, как порог выделения ресурсов в Kubernetes-кластере.

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

Третий сегмент — корпоративные политики использования крупных языковых моделей. Модель контекстного протокола (Model Context Protocol) от Anthropic сам по себе не является policy-framework — это протокол подключения модели к источникам данных и инструментам. Но он создаёт точку, в которой политика может сработать: какие серверы разрешены конкретному агенту, какие действия он может выполнять, какие фильтры наложены на данные. Именно эта слойность — протокол внизу, исполняемые правила вверху — превращает корпоративный вопрос «по каким правилам наш агент имеет право действовать» из теоретического в инженерный.

Объединяет эти три сегмента одно: в каждом из них регламент в виде документа физически не справляется со скоростью и плотностью операции. Документ работает, пока решений мало и они принимаются медленно. Когда решений тысячи в сутки и они должны приниматься за секунды, документ исчезает из контура — либо как формальный артефакт без операционной нагрузки, либо целиком уступая место исполняемой политике.

Что меняется для трёх типов читателей

Для основателя на стадии 15–50 человек тест простой. Возьмите три решения, которые ваша команда принимает чаще всего — квалификацию лида, эскалацию клиента, согласование скидки — и спросите, где живёт правило. Если ответ «у нас есть страница в Notion», откройте её и сравните с тем, как реально решает старший менеджер. Если расхождение очевидно после трёх минут разговора — у вас нет операционной политики, у вас её описание шестимесячной давности. Конкретное действие: возьмите одно из этих правил и опишите его как граф — узлы условий, узлы результатов, явные исключения. Это уже политика, даже если граф пока живёт в одной таблице. Дальше — выбор между человеческим исполнением и автоматическим — становится инженерной задачей, а не управленческим спором.

Для руководителя операционного блока полезен другой вопрос: какой процент решений в вашем отделе принимается «по практике», а не «по регламенту». Если ответ выше 20% — у вас есть устная политика, которой нет в письменном виде. Этот сегмент несёт двойной риск: уход носителя практики обнуляет часть политики, и аудит не может проверить её исполнение. Перевод этого сегмента в исполняемые правила имеет более высокую отдачу, чем редактура существующих документов. Начинать стоит с правил, у которых уже есть автоматический триггер — то есть с тех, где наступление условия фиксируется системой, а не человеком.

Для инженера, оценивающего проект, тест третий: посмотрите, есть ли в продукте отдельный артефакт «policy» — репозиторий, рендер графа, версионная история правил с описанием контекста изменений. Если есть и он живёт как код — продукт устойчив к смене людей: правила переживают уход носителя практики, и накопленный опыт каждой итерации остаётся в системе. Если политика живёт в свободном тексте промптов и инструкций для команды поддержки — любая смена ключевого менеджера переписывает половину поведения системы, и проектная работа не накапливается.

На что мы будем смотреть дальше

Если тезис верен, в течение ближайших 12–18 месяцев в управленческом сегменте должны появиться три явления. Первое — публичные открытые наборы политик для типовых операционных решений по отраслям, аналог того, как для инженерного мира появились библиотеки готовых правил OPA для Kubernetes и облаков. Сейчас каждый бизнес пишет свою политику квалификации лида с нуля; первая попытка стандартизации станет сигналом зрелости рынка. Второе — появление продуктов, где граф политики является самостоятельным артефактом, а не модулем поверх привычного офисного стека. Это другой вид инструмента, а не «Notion с автоматизацией». Третье — рост сегмента аудита и переноса политик: когда правила компании выражены как граф, миграция между поставщиками операционных систем становится не «выгрузить документы», а «перенести граф». Появление переносимых форматов для управленческой политики скажет, что сегмент перестал быть привязан к одному вендору.

Регламент как документ проживёт долго — у него есть инерция и чувство контроля у руководителей, привыкших работать с текстом. Но в той части бизнеса, где операционная скорость определяет экономику, документ уже не первичен — его место занимает исполняемая политика как самостоятельный артефакт. Первым сигналом будет не публичный манифест, а появление открытых библиотек операционных политик в одной из плотных отраслей — так, как это произошло в инженерной дисциплине, когда общие Kubernetes-политики внезапно обнаружились на GitHub в виде воспроизводимых наборов, а не внутренних wiki-страниц. Какой сегмент сделает этот шаг первым — открытый вопрос; ответ на него заметен только постфактум, по появлению переносимых форматов между вендорами.

Главное

• Корпоративный регламент в виде Notion-страницы описывает мир как должно быть; операционная политика описывает правило принятия решения в конкретной ситуации. Это два разных артефакта, и первый никогда не становится вторым автоматически.
• Документ-регламент имеет три структурных дефекта: разрыв между описанием и решением, отсутствие исполнителя, отсутствие истории контекста. Все три не лечатся «лучшим Notion».
• Исполняемая политика — это правило в формальном виде, которое исполняется средой исполнения с аудиторским следом. В инженерной плоскости это реализовано через policy-as-code (OPA, Sentinel); в управленческой — пока узко, но архитектурно готово.
• Граф решений с двойной меткой времени заменяет линейный список правил. Документ остаётся как проекция графа, а не как источник истины.
• Сдвиг наблюдается там, где скорость операции превышает скорость ручной интерпретации регламента: финансовое соответствие, инцидент-менеджмент, политики использования агентов. Первый отраслевой сегмент, где это станет нормой, окажет большее влияние на рынок операционных инструментов, чем любой обобщённый прогноз в тех же границах.

FAQ

Чем исполняемая политика отличается от хорошо написанного регламента? Регламент описывает, как должно быть и предполагает, что человек его прочитает и применит. Политика выражена в формальном языке, исполняется средой и фиксирует каждое решение с временем и входными данными. Разница не в качестве текста, а в том, кто является исполнителем.

Нужно ли переписывать все Notion-страницы в исполняемый вид? Нет. Документы остаются полезными как референс и обучающий материал. Переводить в исполняемый вид нужно те правила, где решение принимается часто (10+ раз в день), быстро (быстрее 60 секунд на решение) и имеет проверяемый результат. На практике это не все сотни внутренних регламентов, а узкий поднабор «горячих» правил, вокруг которых разбивается основное операционное время команды.

Как понять, что у нас есть ±устная политика», не отражённая нигде? Простой тест: выберите 5 частых решений (эскалации, скидки, обработка жалоб, приоритизация заявок) и попросите двух старших менеджеров отдельно описать, как они принимаются. Если расхождение выше 30% хотя бы по 2 из 5 — у вас есть устная политика, и это норма, а не исключение.

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

Где живёт это в бизнес-модели? Соседний сюжет — в разборе service-as-software: когда выручка билингуется за исход, а не за лицензию, исполняемая политика становится опорной точкой, в которой провайдер отвечает за SLA, а не за факт доступа.

В марте 2026 года Жюльен Бек из Sequoia опубликовал статью «Services: The New Software», к которой за два месяца публично вернулись Y Combinator в RFS Summer 2026 и Bessemer в AI Pricing Playbook: на каждый $1 расходов корпоративного бизнеса на программное обеспечение приходится примерно $6 на людей, которые делают сервис, поддерживаемый этим программным обеспечением (Julien Bek, Sequoia Capital - Services: The New Software, 5 March 2026). До 2026 года инструментальный слой ($1) брали поставщики SaaS, сервисный слой ($6) - операторы, агентства, штатники. Vertical AI впервые в истории корпоративного программного обеспечения претендует на оба слоя одной транзакцией - и это та часть тезиса, которую Sequoia формулирует как верхний потолок, а не центральный прогноз.

Это смена правил, по которым продукт извлекает выручку: не лицензия на инструмент, а оплата за результат работы, выполненной агентом на стороне поставщика. Y Combinator в Summer 2026 Request for Startups ставит ту же рамку - буквальная формулировка с открывающей страницы: «AI has stopped being a feature and started being the foundation» (Y Combinator, Requests for Startups, Summer 2026). В английской терминологии это закрепилось как service-as-software (SaaS2, SaS); по-русски - модель, в которой агент продаёт результат, а не инструмент.

Сдвиг, который пока называют не своим именем

Service-as-software чаще всего описывают как «следующее поколение SaaS» - удобная, но обманчивая формулировка. Меняется ценностная единица: SaaS продаёт лицензию на инструмент и выставляет счёт за seat; service-as-software продаёт завершённую работу и выставляет счёт за outcome - закрытое обращение, оформленную декларацию, забронированную встречу.

В классическом SaaS поставщик отвечает за работоспособность инструмента - ответственность за результат лежит на клиенте. В service-as-software поставщик принимает на себя стоимость вычислений, ошибки и интеграцию - в обмен на цену, анкорованную против стоимости труда, а не инструмента.

Bessemer формулирует это короче: «По мере перехода от consumption через workflow к outcome-pricing вы принимаете больший риск по себестоимости в обмен на более плотное совпадение с ценностью» (Bessemer Venture Partners, AI Pricing Playbook). 92% AI-компаний, по данным того же отчёта, уже работают в смешанных моделях, где база подписки сочетается с usage- или outcome-компонентом.

Та же оптика звучит и в публичных материалах руководства Y Combinator: десятки вертикалей - здравоохранение, юриспруденция, финансы, страхование, compliance, логистика, customer service - пока находятся в single-digit проникновении AI, а расходы на труд в каждой исчисляются $100B+ в год (Y Combinator RFS Summer 2026). Победитель в такой вертикали - не «SaaS-юникорн с $100M ARR», а значимая доля сервисного слоя индустрии, перепрошитая под экономику программного обеспечения.

Что показывают компании, которые уже играют по новым правилам

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

Harvey, юридический AI, дошла от нуля до $195M ARR за 36 месяцев (Sacra, Harvey at $195M ARR). Чек - $1 200-$2 500 на одного юриста в месяц, минимум 20 рабочих мест, двенадцатимесячный контракт. Это формально per-seat, но ценовой якорь - не «лицензия на программное обеспечение». Якорь - 5-7% от стоимости рабочего времени associate в крупной юридической фирме. Если AI-инструмент стоит как 5% от человека, которого он частично заменяет, $14 000 за рабочее место в год становятся не дорогими, а очевидными. По данным того же Sacra-профиля, Harvey движется в сторону revenue-share: доля с billable hours, выставленных клиентам через AI (Sacra, Harvey at $195M ARR). Это переход от per-seat к outcome без отказа от первого.

Sierra, AI для customer support, собрала $100M ARR на чистой outcome-модели: оплата только за разрешённое обращение, сохранённую подписку, состоявшийся апсейл (Sierra, Outcome-based Pricing). Стартовый контракт - $150 000 в год, с расширением до $1M+ при многоканальной голосовой интеграции. Sierra доказала, что в узком домене с измеримым исходом можно совсем отказаться от seat. Но даже у Sierra модель смешанная: для рутинной маршрутизации обращений действует per-conversation, для ценных разрешений - per-resolution. Чистый outcome-pricing - миф, к которому индустрия стремится, но в производственном развёртывании всегда живёт гибрид.

Intercom Fin - самая чистая иллюстрация принципа: $0.99 за разрешённое обращение, никаких seat-fee (Intercom Pricing). Outcome определён однозначно: Fin закрыл тикет без передачи человеку. Bessemer использует Fin как эталонный пример совпадения ценообразования с ценностью.

Glean показывает противоположный паттерн - расширение поверх классического SaaS, а не замена ему. База $45-50 на пользователя в месяц, надстройка Work AI за $15, отдельный SKU за governance, новый consumption-billing для агентных нагрузок поверх per-seat. Результат: $100M → $200M ARR за 9 месяцев, оценка $7.2B (Futurum Group on Glean). Прикладное следствие: устойчивый SaaS может не ломать существующую модель, а добавлять новые ценовые слои сверху — без перехода на чистый outcome-pricing.

Между четырьмя кейсами есть общее, и оно фиксируется по их же публичным материалам (Sacra Harvey, Sierra outcome-pricing, Intercom pricing, Futurum on Glean). Никто из них не продаёт «AI-инструмент». Harvey продаёт замещение стоимости юриста, Sierra - закрытое обращение, Intercom - разрешённый тикет, Glean - слой корпоративного знания. Каждая компания смогла объяснить клиенту единицу ценности, против которой выставляется счёт, и привязать её к показателям, которые клиент уже считает внутри своей отчётности.

Почему формула «5-7% от стоимости труда» меняет калькуляцию?

В классической экономике корпоративного программного обеспечения цена продукта анкорилась против цены другого продукта. Salesforce стоил против Siebel, потом против HubSpot. Потолок задавался не «сколько ценности», а «сколько готов платить клиент относительно альтернативного программного обеспечения». Это давало 80-90% валовой маржи, потому что предельная стоимость дополнительной лицензии стремилась к нулю.

В service-as-software цена анкорится против стоимости труда, который продукт замещает. Это поднимает потолок: годовой бюджет на двадцать associate в крупной юридической фирме при базе $250-400 тыс. в год на человека - это $5-8M, и $300 000 за инструмент, который реально снимает 15-20% их операционной нагрузки, выглядит дёшево. Но это же опускает валовую маржу: AI-first компании работают на 50-60%, а не на 80-90% (Bessemer AI Pricing Playbook). Себестоимость вычислений вернулась в баланс.

Следствие, которое часто пропускают: в SaaS underpricing вреден, но в service-as-software он смертельно опасен. Поставщик берёт на себя стоимость inference, ошибки, дообучения и поддержки рабочего процесса. Один power-user, который генерирует 10x ожидаемого объёма outcome, способен в один квартал увести юнит-экономику в отрицательную зону. Replit в 2025 году публично прошёл через колебания валовой маржи от 36% до минус 14% за два месяца (Sacra, Replit profile); GitHub Copilot при базовой цене $10 терял до $20 на среднем пользователе и до $80 на heavy-user, что привело к переходу на usage-based pricing в 2026 (DevOps.com, GitHub resets Copilot pricing). Каждый кейс - не сбой стартапа, а структурное следствие новой модели.

Net revenue retention 130%+, который по бенчмаркам Bessemer относится к top decile в классическом SaaS, в выживших service-as-software компаниях становится не идеалом, а условием существования. Harvey демонстрирует 290% YoY роста по данным Sacra - траектория, типичная для service-as-software: от per-seat к revenue-share, от ассистента к workflow-платформе по мере углубления в клиентскую операцию.

Где эта рамка ломается и кто проигрывает

Консенсус Sequoia / YC / Bessemer выглядит ровным, но у него есть три уязвимые точки, которые часто опускают в венчурных текстах.

$1:$6 - это верхний потолок, а не центральный прогноз. Sequoia осторожно подчеркивает это в своём же материале (Bek, Services: The New Software): реальный capturable share зависит от того, насколько глубоко поставщик входит в операцию клиента. В большинстве вертикалей сервисный слой не сжимается до нуля - AI ассистирует человеку, а не замещает его полностью. Реалистичный диапазон захвата для удачной AI-первой компании в 2026 году - не «6× software-рынок», а порядка 1.2-2× software-бюджета вертикали. Это всё равно огромный рынок, но венчурная презентация с множителем «×6» в слайде TAM обычно разбивается о первый квартал продаж.

Риск, переданный поставщику, не нравится крупным клиентам. В регулируемой отрасли CFO неохотно подписывает контракт, в котором внешняя система отвечает за исход операции. В страховании, медицине, финансах compliance-команды требуют человеческого надзора как условие закупки - это возвращает гибрид к per-seatу и снижает долю outcome-компонента в итоговом чеке. Регулятор страхового рынка ЕС в обзоре генеративного AI 2025 года прямо фиксирует доминирование human-in-the-loop как нормы в страховой индустрии (EIOPA Generative AI EU Market Survey - разбор RPC Legal). Крупный юридический, финансовый и медицинский enterprise подписывает service-as-software медленнее, чем ожидает венчурная форвард-проекция.

Три условия удачи редко выполняются одновременно. Модель работает, когда клиент уже мерит исход в своём дашборде, стоимость замещаемой операции достаточно высока, чтобы окупить себестоимость inference, и поставщик финансово выдерживает первоначальный период отрицательной маржи на heavy-userах. В большинстве сделок хотя бы одно из условий отсутствует - и «outcome-pricing» в контракте превращается в слайд о будущем, а счёты выставляются по usage с минимальным консьюмпшеном.

Проигрывают в этой модели три категории. Универсальные «AI-агенты» без вертикальной экспертизы зажаты между управляемыми платформами гиперскейлеров и узкими отраслевыми продуктами. Классический per-seat SaaS, который не успел нарастить consumption-billing поверх своей подписки, проигрывает в renewals к концу 2026 - 92% AI-компаний уже работают в гибридах, по данным того же Bessemer AI Pricing Playbook. Консалтинговые контракты по «AI-трансформации», которые заканчиваются отчётом, а не выходят в продукт внутри операции клиента, не замыкают петлю «решение → исход» и не накапливают защиты поверх лицензионного слоя — подробнее этот механизм разобран в «Trajectory Data: the Decision→Outcome Loop Moat».

Где компаундирующая защита - и почему универсальная обвязка её не даёт

Это и есть та граница, которая отделяет vertical AI с устойчивой выручкой от стартапов, делающих «универсального AI-агента» и упирающихся в потолок на $1-3M ARR. Вертикальные AI-платформы воспроизводят паттерн, который раньше дал Veeva в фармацевтике, Procore в строительстве, ServiceTitan в сервисном бизнесе. Veeva в продуктовой развёртке Vault AI встраивает агентов прямо в отраслевые модули (Veeva Vault AI) - это сигнал, что отраслевой SaaS не намерен отдавать сервисный слой горизонтальным игрокам. NFX в анализе data network effects формулирует условие устойчивости: данные должны быть автоматически захвачены при использовании продукта, давать видимое клиенту улучшение, иметь высокий порог входа для конкурента и медленную асимптоту насыщения (NFX, The Truth About Data Network Effects). Большинство B2B-компаний этот тест не проходят: они собирают данные, но улучшение продукта происходит вручную, а не непрерывно.

Закрытая петля «решение → исход» в конкретной операционной среде - это то, что нельзя восстановить ретроспективно из логов. Через 12 месяцев работы внутри одного клиента у поставщика накапливается доменная модель данных, набор воспроизводимых решающих правил и история фактических исходов под каждым решением - три слоя, которые в академической литературе и индустрии обозначаются как domain model, business logic и outcome history. Это и есть compounding switching cost: горизонтальная обвязка не может воспроизвести их без аналогичного срока работы внутри той же операции.

Универсальный AI-агент, который ставится из конфига за один спринт, в эту защиту не попадает. Он сжимается между управляемыми платформами от Anthropic, OpenAI, AWS и узкими отраслевыми продуктами с собственным системным учётом, регуляторным контекстом и многолетними данными. Средний слой исчезает - и у большинства горизонтальных агентных продуктов нет ответа на этот сжимающийся спред.

Где это работает, где нет, и что важно проверить до контракта

У service-as-software есть условия применимости, и три из них определяют, работает ли модель в конкретной вертикали.

Первое условие — измеримый исход. Регулятор страхового рынка ЕС в обзоре генеративного AI 2025 года (EIOPA — разбор RPC Legal) и McKinsey в State of AI 2025 (Global Survey on AI) фиксируют одно и то же: в регулируемых сервисах человеческий надзор остаётся доминирующим, а галлюцинации — главным цитируемым риском. Compression цены подтверждена в узких доменах с однозначным правильным ответом (поддержка, бронирования, рутинные документы) и не подтверждена там, где исход размыт или требует регуляторного одобрения.

Второе условие — клиент уже считает этот исход. Bessemer в AI Pricing Playbook прямо фиксирует: outcome-pricing работает там, где выбранный value metric уже входит в публичную отчётность клиента (Bessemer AI Pricing Playbook). CFO, который мерит «разрешённые тикеты» или «выигранные тендеры» до того, как поставщик пришёл, — это правильный value metric. Если единицу измерения нужно изобретать вместе с продуктом, цикл сделки удлиняется, а отказ становится дешёвым.

Третье условие — достаточная маржа в операции, чтобы было что замещать. Bek в том же Sequoia-эссе осторожно отмечает: дисраптить работу за $50 в час сложно, замещать работу за $500 в час — оправдано (Bek, Services: The New Software). На нижнем краю операционной экономики переход в outcome-pricing не окупает себестоимость вычислений.

Эти три условия складываются в практический фильтр: модель работает только при пересечении измеримого исхода, его уже существующего учёта у клиента и достаточной маржи операции. Если хотя бы одно условие отсутствует, разумнее оставаться в гибриде с большой долей фиксированной подписки и небольшой usage-надбавкой, а не запускать чистый outcome-pricing.

Для руководителя, который оценивает внедрение: чем меряет себя поставщик в публичных кейсах? Если только «сэкономленные часы» - это эффект первого года в горизонтальной обвязке. Если в SLA фигурирует измеримый бизнес-результат, привязанный к финансовой отчётности клиента, - это другая категория контракта, и она требует другой due diligence.

С инженерной точки зрения главный технический риск — отсутствие фиксации decision traces с первого дня. Связка «решение → исход» — архитектурное решение, которое нельзя добавить позже; без неё через 12 месяцев у компании будут логи, но не будет компаундирующей защиты.

Главное

• $1:$6 - это не метафора. Sequoia формализовала: software-слой и services-слой исторически делили выручку 1 к 6; service-as-software забирает оба одной транзакцией. Это смена правил захвата, а не следующее поколение SaaS.
• Цена анкорится против труда, не против программного обеспечения. Это поднимает потолок ($150K-$1M+ годовых контрактов на одного клиента) и опускает валовую маржу до 50-60%. Underpricing в этой модели смертелен.
• Чистый outcome-pricing - миф. Harvey, Sierra, Intercom Fin, Glean - все работают в гибриде: база + usage или outcome поверх. 92% AI-компаний уже не на чистом per-seat.
• Средний слой исчезает между двумя полюсами. Сверху давят отраслевые платформы (Veeva, Procore, ServiceTitan) с собственным AI; снизу - управляемые среды исполнения от гиперскейлеров. Универсальный AI-агент сжимается между ними за 18 месяцев.
• Компаундирующая защита — в закрытой петле решение→исход. Доменная модель, воспроизводимые решающие правила и история фактических исходов накапливаются только изнутри операционной среды клиента. Горизонтальный конкурент воспроизводит их либо годами работы внутри той же операции, либо никак.

FAQ

Чем service-as-software отличается от обычного SaaS с AI-фичами? Единицей выставления счёта. SaaS берёт деньги за доступ к инструменту; service-as-software - за выполненный исход. Это переносит операционный риск на поставщика и анкорит цену против стоимости человеческого труда, а не против стоимости альтернативного программного обеспечения.

Можно ли запустить service-as-software без отказа от подписки? Да, и это безопаснее. Glean показал паттерн расширения: per-seat остаётся ядром, поверх него добавляются SKU за AI-возможности, потом - consumption-billing за агентные нагрузки, потом - отдельные модули за governance. Это даёт NDR 130%+ без слома существующих контрактов.

Где outcome-pricing не работает? Там, где исход неоднозначен, регулятор требует человеческого надзора или маржа исходной операции ниже $50 в час. Compression цены подтверждена в support, бронированиях, рутинных документах; не подтверждена в стратегических решениях, регулируемой медицине, сложных трансформациях.

Что должен накопить продукт за первые 12 месяцев, чтобы не быть заменимым? Три базовых слоя из обычной software-инженерии, но привязанные к конкретному клиенту: domain model (какими сущностями оперирует бизнес и как они связаны), business logic (исполнимые правила решений, эскалаций, ценообразования) и outcome history (история фактических исходов под каждым решением с контекстом момента). Порознь берётся любым SaaS-продуктом, вместе они воспроизводимы только внутри той же операции.

Что показывают публичные ROI-кейсы и что они скрывают?

За последние девять месяцев индустрия получила первый качественный набор измеримых результатов от платформ для агентной автоматизации. На странице клиентов Activepieces Alan заявляет о более чем 6 300 сохранённых часах в год и трёхстах с лишним рабочих сценариях; Funding Societies — о ста с лишним сценариях в восьми департаментах. На странице кейсов n8n Flow AI рапортует о сокращении исходящих касаний с 3–5 часов до менее минуты, Field Aerospace переводит подготовку коммерческого предложения из двух недель работы команды в 25 минут, Formula Bot уменьшает срок добавления нового коннектора с недели до полутора дней. Это не маркетинговые лозунги — реальные операторы согласились публиковать цифры с именами и должностями.

Если смотреть на эти кейсы не отдельно, а как на карту рынка, проступает другой узор. Все они решают одну задачу — ускоряют существующие горизонтальные процессы. И все выстраиваются в один и тот же ценовой и архитектурный класс. Потолок этого класса виден.

Где заканчивается стандартная среда исполнения и начинается отраслевой продукт

Различим три рабочих понятия, без которых разговор про слои размывается.

Стандартная среда исполнения агента — слой с унифицированными интерфейсами: цикл сессии, маршрутизация инструментов, память, изолированная песочница, разворачивание. К маю 2026 года он перестал быть инженерным проектом и стал готовым продуктом у всех крупных провайдеров. Anthropic в инженерном посте про управляемые агенты формулирует это прямо: предположения, зашитые в обвязку агента, устаревают вместе с моделями, и поэтому компания упаковывает оркестрацию в стабильные интерфейсы поверх сменяемого исполнения. The New Stack в разборе релиза описывает сдвиг от модели к модели плюс готовая оркестрация как продукту провайдера.

Отраслевой SaaS-продукт — другой полюс: продукт со своими экранами, отчётами, ролями, встроенными требованиями регулятора и многолетним операционным контекстом. Veeva для фармы, Procore для стройки, ServiceTitan для сервисного бизнеса. Veeva в продуктовой развёртке Vault AI описывает, как встраивает агентные сценарии прямо в отраслевые модули — это сигнал, что вертикальные игроки видят угрозу снизу и начинают двигаться навстречу.

Между этими двумя полюсами есть промежуточный слой, который в публичных кейсах почти не виден. Это уровень, на котором агентная система перестаёт быть «лучше Zapier» и становится способом, которым организация фактически работает: операционный слой бизнеса (operating layer). На карте маржи именно туда смещается ценность по мере того, как стандартная среда становится массовой.

Что Alan, Flow AI и Field Aerospace на самом деле сделали

Если разобрать публичные кейсы по слоям, получается следующая картина.

Alan развернул на Activepieces платформу для внутреннего обеспечения сотрудников. Цифры впечатляют, но вся работа происходит в горизонтальной плоскости: автоматизация HR-онбординга, синхронизация задач между корпоративными инструментами, эскалации в чатах. Это не отраслевая модель медицинского страхования — это родовая сантехника, которая ускоряет существующие процессы, но не переописывает их. Сама компания подчёркивает логику обеспечения: «300+ сценариев, 200+ внутренних авторов» означает, что цель была дать сотрудникам инструмент, а не построить специализированную операционную систему страхового продукта.

Flow AI — стартап в дистрибуции страховых продуктов. Их голосовые исходящие касания действительно дают радикальное сжатие времени: 3–5 часов превращаются в 60 секунд. Но если посмотреть, на чём построены касания, это связка из ElevenLabs, веб-хуков, Postgres, n8n и SMS/email-провайдеров. Качественная горизонтальная сборка. Слой, на котором Flow AI становится незаменим для брокеров — отраслевая модель оценки рисков, история взаимодействия с конкретными типами клиентов, политики комплаенса для разных юрисдикций — в публичной презентации не виден. Не потому что его нет, а потому что не он там измеряется.

Field Aerospace сократил подготовку коммерческого предложения с двух недель до 25 минут и снял около 30 000 долларов годовых затрат на программное обеспечение. Цифры серьёзные. Но это автоматизация документального процесса — извлечение, форматирование, сборка. Под этим слоем лежит специфика аэрокосмических контрактов: регуляторные требования, история ценообразования, специфическая структура спецификаций, партнёрские договорённости. Эта специфика в кейсе не видна. Видна только верхняя горизонтальная аппликация.

Formula Bot ускорил добавление нового коннектора с недели до полутора дней. Это операционная победа платформенной команды, не отраслевая защита. Если завтра OpenAI Connector Registry выпустит официальный SAP-коннектор с лучшей надёжностью, ценность собственной интеграционной полки начнёт оседать.

Все четыре кейса — честная работа с измеримым результатом. Но они отвечают на один вопрос: как ускорить существующие процессы. И не отвечают на другой: что становится защищённым активом за горизонтом 18 месяцев, когда стандартная среда исполнения станет массовой.

Три уровня защиты и куда смещается маржа

Полезно ввести явное разделение слоёв. На каждом из них живёт разный класс продукта и разный класс конкуренции.

Публичные кейсы живут в первом слое. Их экономия впечатляет, потому что сравнение идёт с ручным трудом и устаревшими инструментами; в этой системе координат любой грамотно собранный сценарий выглядит как прорыв. Но горизонт жизни этого преимущества короткий. Anthropic уже явно пишет, что предположения обвязки устаревают вместе с моделями, и сама же выпускает управляемую альтернативу. n8n и Activepieces встраивают MCP-серверы и конструктор агентов в ядро. То, что год назад требовало месяца сборки, через год будет ставиться из конфига.

Отраслевой SaaS — третий слой, куда нельзя зайти из горизонтального проекта без отраслевой команды, многолетнего опыта продаж и собственного продуктового цикла.

Операционный слой — средний слой, куда публичные кейсы не заходят: это требует отказа от логики «универсальное решение для всех» и согласия на меньший потенциальный рынок ради более глубокого контроля над одним конкретным процессом.

Откуда берётся накопительное преимущество

Операционный слой держится на трёх вещах, которые не упаковываются в управляемый продукт.

Первое — модель предметной области (domain world model). Это онтология с конкретными сущностями, их состояниями, валидными переходами и исключениями. Не «у вас есть документы про X», а «в этой организации сущность A может перейти в состояние B только если выполнены условия C, D, E, и сотрудник X не может одобрить переход без подтверждения от Y». Поисковые системы вроде Glean знают, что в компании есть документы. Они не знают, что партнёры определённого типа требуют иного порядка согласования, что обращения определённой категории клиентов требуют немедленной эскалации, а не стандартной очереди. Эта разница между корпусом документов и операционной моделью — фундаментальная.

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

Третье — следы решений (trajectory data). Закрытый цикл «решение → исход» в конкретном контексте. Не «лог действий», а связка между принятым решением и тем, что произошло через N дней: оплатил клиент или нет, прибыло вовремя или нет, привело к сделке или нет. Эту связку нельзя восстановить ретроспективно из логов: контекст момента уже потерян. Подробнее этот компонент мы разбирали в отдельной заметке про данные траекторий.

Все три компонента объединяет одно: их нельзя купить или упаковать в SDK — их можно только накопить изнутри конкретной операционной среды. Управляемый продукт по определению не может конкурировать на этом слое. О том, почему именно представление, а не модель, оказывается главным барьером переключения, мы писали в заметке про слой представления и вертикальную схему.

Почему публичные кейсы туда не идут

Структура стимулов объясняет это лучше, чем намерения игроков.

Activepieces и n8n — горизонтальные платформы по бизнес-модели. Им нужны кейсы, демонстрирующие универсальность: чем шире применимость, тем сильнее их позиционирование для расширения базы пользователей. Вертикальный операционный слой — анти-пример для такого позиционирования. Он показывает, что максимум ценности достигается, когда сборка делается под одну конкретную организацию или одну конкретную отрасль, а не как переиспользуемый шаблон.

Alan, Flow AI, Field Aerospace, Formula Bot оптимизируют под скорость отдачи: быстрые цифры для инвестиционного цикла. Горизонтальная автоматизация даёт этот срез; операционный слой требует месяцев работы внутри домена без яркого «до и после».

Наконец, провайдерская сторона рынка — Anthropic, OpenAI, AWS, Google — активно толкает управляемую обвязку как готовый продукт. К маю 2026 года стандартная среда исполнения стала массовым товаром у всех четырёх гиперскейлеров. Это значит, что публично видимая часть рынка дальше будет смещаться к ещё более горизонтальным кейсам, потому что именно там провайдерам выгодно показывать свои продукты. Операционный слой останется в тени публичной коммуникации, хотя именно туда уходит маржа. Эту разделительную линию между обвязкой и операционным слоем мы подробно разбирали в заметке про переход обвязки в массовый товар.

Как проверить, в каком слое живёт ваш продукт

Полезные тесты для двух разных аудиторий.

Для основателей: если обвязку можно заменить на Anthropic Managed Agents или OpenAI AgentKit за один спринт без потери ценности — продукт в массовом слое. Если при смене среды исполнения разрушается накопленная модель предметной области, политика решений и следы решений — продукт уже в операционном слое.

Второй тест: если завтра конкурент с большей командой и большим бюджетом захочет повторить продукт за 90 дней, что у него получится? Универсальный сценарий повторяется. Онтология предметной области конкретного клиента, накопленная за 12 месяцев работы внутри организации, не повторяется.

Для технических руководителей, которые оценивают AI-внедрения. Если поставщик показывает кейсы только класса «X часов сэкономлено в месяц», стоит уточнить, какой слой подрядчик построил поверх горизонтальной автоматизации. Часовая экономия — это эффект первого года; через 18 месяцев он начинает выравниваться по рынку. Глубина изменения процесса — это другая категория измерения. Temporal в документации по принципам исполнения процессов формулирует похожую мысль для инфраструктурного слоя: устойчивое состояние и долго живущие процессы становятся ценными там, где процесс действительно встроен в работу бизнеса, а не там, где автоматизирована отдельная задача.

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

Сигналы 2026 года

Три сигнала покажут, как развивается дифференциация между слоями.

Если управляемые обвязки от Anthropic, OpenAI и AWS дойдут до общедоступности с встроенными вертикальными шаблонами — это означает попытку провайдеров занять операционный слой сверху, через пресеты. Сценарий маловероятный в ближайшие 12 месяцев, потому что отраслевое знание не упаковывается в шаблон, но провайдерская сторона будет пробовать. На встречные движения вертикальных игроков указывает, например, продуктовая платформа Vault AI от Veeva — отраслевой SaaS не отдаёт операционный слой без боя.

Если на n8n и Activepieces появятся кейсы, где экономика измеряется не в часах, а в процентах улучшения отраслевого исхода — например, «точность решения X выросла на Y процентов за 6 месяцев» — это будет сигналом, что операционный слой начинает становиться публично видимым.

Если вертикальные SaaS-игроки уровня Veeva и Procore начнут публично анонсировать собственные среды исполнения агентов — это означает движение третьего слоя вниз, к операционному слою, и сжатие пространства для независимых вертикальных AI-продуктов. Похожую общую логику смещения ценности на стыке инфраструктуры и данных описывает материал a16z про большие технологические идеи 2025.

Главное

• Публичные кейсы AI-агентов дают честную экономию, но измеряют только горизонтальную плоскость: сокращение времени на существующие процессы.
• Между стандартной средой исполнения и отраслевым SaaS существует средний слой — операционный слой бизнеса, который держится на онтологии предметной области, исполнимой политике решений и следах решений.
• Этот слой нельзя упаковать в управляемый продукт: его компоненты создаются внутри конкретной организации и не воспроизводятся ретроспективно.
• Маржа в категории смещается именно туда по мере того, как стандартная среда становится готовым продуктом у всех крупных провайдеров.
• Тест: если продукт можно за спринт перенести на чужую управляемую среду без потери ценности, он живёт в массовом слое.

FAQ

Чем операционный слой отличается от отраслевого SaaS?

Отраслевой SaaS — это полноценный продукт отрасли со своими экранами, отчётами, ролями, машиной продаж и десятилетним циклом накопления отраслевой экспертизы. Операционный слой — это уровень, на котором агентная система становится способом, которым конкретная организация работает: онтология предметной области, политика решений и следы решений одной компании или одной узкой ниши. Отраслевой SaaS требует капитала и команды другого порядка; операционный слой строится небольшими специализированными командами и держится за счёт глубины внедрения, а не масштаба распространения.

Почему стандартная среда исполнения считается массовой, если стартапы вокруг неё растут?

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

Когда операционный слой не имеет смысла строить?

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

Сколько времени занимает построение операционного слоя?

По открытым отраслевым материалам первая устойчивая версия онтологии и явной политики решений появляется обычно в горизонте от полугода до года активной работы внутри домена. Следы решений — самостоятельная категория, требующая отдельной инженерной работы; их накопительный эффект проявляется после нескольких месяцев замкнутого цикла «решение → исход».

Как отличить кейс операционного слоя от хорошо упакованной горизонтальной сборки?

Главный маркер — что измеряется в результатах. Горизонтальная сборка измеряет сэкономленные часы и сокращение цикла существующего процесса. Операционный слой измеряет качество принимаемых решений в домене и устойчивость этого качества при смене модели или среды исполнения. Если кейс не показывает второй тип метрик, скорее всего, он живёт в горизонтальной плоскости.

Notion хранит то, что вы решили записать

В январе 2026 года Sentra привлекла $5 млн от a16z speedrun и Together Fund под заявку «организационная память», в феврале Glean поднял Series F при оценке $7,2 млрд с переименованием продукта из «корпоративного поиска» в «систему контекста», в октябре 2025-го Mem0 закрыл $24 млн Серии A под универсальный слой памяти для агентов. Три раунда подряд под одну категорию, которая ещё в 2024-м году в инвестиционных дек-ах называлась «ИИ-документация».

За этим стоит признание того, что центральная единица корпоративного знания меняется — с документа на запись о произошедшем. Notion хранит то, что вы решили записать. Агентная память хранит то, что произошло, даже если никто ничего не писал. Разница между этими режимами фиксации определяет, какая команда сможет поддерживать знание актуальным при росте, а какая — нет.

Что сломано в документе как примитиве знания

Документ — это снимок состояния, сделанный человеком в момент рефлексии. У этого примитива три встроенных дефекта, которые невидимы при размере команды до 10 человек и становятся фатальными при 50.

Первый дефект — временная мёртвая точка. Документ не знает, когда он перестал быть правдой. В Notion-странице «как мы делаем онбординг клиента» нет поля «действителен до». Решение об изменении процесса принимается в чате, фиксируется в звонке, иногда оседает в карточке задачи — но обновление документа требует отдельного волевого акта от того, кто помнит, что такая страница существует. Бенчмарк LongMemEval, опубликованный исследователями из университетов Альберты и Калифорнии Сан-Диего, формализовал эту проблему через 5 категорий провала памяти у языковых моделей (одна сессия, несколько сессий, обновление знания, рассуждение во времени, воздержание от ответа); обновление знания — категория, в которой система не умеет понять, что новый факт отменил старый, и в которой даже передовые модели показывали падение точности на 30+ процентных пунктов относительно более простых задач извлечения. Документ страдает тем же — но без диагностики.

Второй дефект — отсутствие трассировки от операции. Документ не знает, откуда он взялся. У страницы про процесс продаж нет ссылки на конкретные сделки, которые привели к её появлению. У описания архитектуры нет связи с коммитами, которые её реализовали. Знание, оторванное от операции, превращается в фольклор — оно правдиво ровно настолько, насколько правдиво помнит автор в момент написания.

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

Эти три дефекта не лечатся «лучшим Notion». Лучший Notion — это не быстрее редактор и не умнее ИИ-помощник; это переопределение того, что считается единицей знания. Если единица — документ, то улучшить можно только скорость его создания и поиска. Если единица — запись о произошедшем, то документ становится не источником, а проекцией.

Документ против агентной памяти: где проходит граница

Различие проходит не по одному параметру, а сразу по семи измерениям — и именно совокупность расхождений делает «Notion с AI» категориально другой системой, а не апгрейдом старой.

Каждая правая ячейка предполагает, что в системе уже есть слой, фиксирующий операцию; без него правый столбец нереализуем. Именно поэтому категория «слой памяти» (memory layer) отделилась от «ИИ-документации» в 2025–2026 годах — появились компоненты, без которых правый столбец нельзя собрать: временны́е графы, эпизодические блоки, разрешение сущностей через единые идентификаторы.

Трёхэтажная архитектура: что фактически собирается

Категория, которую инвестиционный рынок к маю 2026 года называет «мозгом компании» (company brain) или «корпоративным слоем памяти», стоит на трёх различимых слоях. Это не одна база и не три разных продукта — это три типа фиксации, каждый со своим горизонтом и своим способом записи.

Эпизодический слой — последовательность событий, которые произошли с участием системы или вокруг неё. Звонки, сообщения, действия агента, реакции клиента, статусы заказов. У каждого события есть отметка времени, актор и связь с предшествующим. Letta, наследник проекта MemGPT, реализует этот слой через блоки памяти — структурированные записи, которые агент создаёт в ходе работы и к которым возвращается в следующих сессиях. Sentra в своей публичной модели описывает это как «память взаимодействий»: «встречи, диалоги, сообщения». Эпизод — атом операционной памяти; он создаётся в момент события и не требует отдельного акта документирования.

Семантический слой — извлечённые из эпизодов устойчивые утверждения о мире. «Этот клиент платит на третий день после счёта», «эта команда эскалирует раньше, чем требует процесс», «этот тип возражений снимает кейс из соседней отрасли». Mem0 в своей технической документации отделяет семантическую память от эпизодической как архитектурный слой: один — журнал, другой — выводы. Принципиально, что семантический слой не пишется руками — он извлекается из эпизодического слоем над ним. Если завтра выясняется, что клиент платит уже не на третий, а на седьмой день, новый эпизод противоречит старому утверждению; задача памяти — пометить старое как недействительное и сформировать новое, а не молча затереть. Graphiti, открытый движок временно́го графа знаний, решает это через две метки времени — «действителен с» и «недействителен с», — где противоречие становится свойством системы, а не дефектом.

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

Эти три слоя складываются не в иерархию «черновик → чистовик», а в петлю. Эпизодический слой пишется автоматически в момент работы. Семантический извлекается из эпизодического и переписывается, когда новые эпизоды противоречат старым выводам. Структурированный обновляется, когда семантический достигает уровня надёжности, при котором утверждение можно показать наружу. Документ в этой схеме — не отсутствует, но перестаёт быть источником истины: он становится одной из возможных проекций структурированного слоя для конкретного читателя в конкретный момент.

Почему «лучший Notion» — это категориальная ошибка

Первый рефлекс команды при столкновении с этой архитектурой — встроить её в существующее представление о документе: «Notion с агентами», «ИИ-википедия, которая сама обновляется», «база знаний, которая запоминает диалоги». Все 3 формулировки описывают один продукт: документоцентричную систему с добавленным слоем автозаполнения.

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

Этот сдвиг виден на «единице правды». В документоцентричной команде вопрос «а как у нас устроен онбординг» закрывается ссылкой на страницу. В команде с памятью — агрегацией: «12 последних онбордингов, извлечённые из них устойчивые шаги, и те из них, что менялись за 6 недель». Первая система отвечает последней отредактированной версией. Вторая — выводом из того, что фактически делалось. Совпадают они только в идеальном мире; в реальном — расходятся уже через квартал.

Из этой же логики растёт и инвестиционный тезис рынка. Glean переименовал продукт из «корпоративного поиска» в «систему контекста» при оценке $7,2 млрд именно потому, что поиск по документам перестал быть достаточным ответом — нужна агрегация по операциям. Sentra зашла под тезисом «память участвует, а не ждёт» с раундом $5 млн. Mem0 на $24 млн Серии A продаёт «универсальный слой памяти», а не «лучшую корпоративную базу знаний». Все 3 формулировки — отказ от документа как первичной единицы.

Как это меняет архитектуру самой команды

Сдвиг от документа к памяти меняет и роли. В документоцентричной команде владелец знания отвечает за актуальность страниц и регулярные ревизии — роль, которая на 20-й странице перестаёт масштабироваться. В команде с памятью она распадается на две: владелец схемы решает, какие сущности живут в семантическом и структурированном слоях и как они связаны (работа раз в квартал, а не еженедельная редактура); владелец триггеров — при каких условиях семантический слой порождает уведомления и эскалации. Обе роли проектируют слой, а не наполняют его — наполнение делает работа.

Параллельно меняется онбординг. В документоцентричной команде новичка учат через страницы, устаревшие на квартал. В команде с памятью он получает доступ к эпизодическому слою домена за 6–12 месяцев и к актуальному семантическому слою: вместо «как мы делаем» он видит «как 200 раз делали». Устаревание знания на онбординге исчезает как класс.

И наконец, меняется природа решений. Sentra выделяет третий тип памяти — «память решений»: решения и договорённости с временной меткой, актором и связью с эпизодом, который к ним привёл. Этот слой заменяет жанр «решение по итогам встречи в Notion-странице»: решение становится записью, привязанной к породившей её ситуации, а не пунктом в странице, которую через полгода никто не открывает. По той же логике, по которой замкнутый цикл «решение → исход» становится единственным реальным защитным рвом для вертикальных ИИ-агентов, память решений становится активом ИИ-нативной команды: решения в связке с исходами не воспроизвести чтением документации.

Конкретные тесты для трёх типов читателей

Для основателя на стадии команды в 10–15 человек тест такой: возьмите 3 ключевых процесса — продажа, онбординг, эскалация инцидента — и спросите, откуда команда узнаёт, как они устроены. Если ответ «из страницы в Notion» и последнее обновление старше 6 недель при изменившемся процессе — документ и реальность уже расходятся. База из 50 операционных страниц требует 5–10 точечных обновлений в месяц при умеренной динамике; при ручном режиме доходят 1–2. Единственный способ закрыть разрыв при росте — перенести точку фиксации с документа на запись о произошедшем.

Для инженера, выбирающего проект, тест другой: посмотрите, как в продукте устроен слой памяти агентов. Если это «вектор плюс поиск по сходству» — это первая стадия зрелости, ещё без временно́й структуры. Если есть явные слои «эпизодический / семантический / структурированный» с двойными метками времени и сведением сущностей через единые идентификаторы из системы записи, продукт уже стоит на актуальной архитектуре. Разница между этими двумя состояниями — не косметическая; вторая система допускает изменение фактов о мире без переписывания истории, первая — нет.

Для руководителя, оценивающего внедрение ИИ, тест третий: спросите поставщика, какой результат внедрения остаётся у вас через год. «Обученный на ваших документах ассистент» — снимок состояния, начинающий устаревать с первого изменения процесса. «Трёхслойная память, накапливающаяся из вашей операционной активности» — растущий актив; тогда уместны вопросы про возможность выгрузки этой памяти и про владельца структурированного слоя — именно он ядро защиты от смены поставщика.

На что смотреть дальше

Категория «мозг компании» к маю 2026 года ещё не имеет общепринятой границы между горизонтальными платформами (Glean, Sentra, Microsoft Copilot) и вертикальными системами памяти, привязанными к домену. Но первая граница уже проходит по владению структурированным слоем. Если он принадлежит поставщику платформы, замена поставщика стирает бо́льшую часть накопленного знания; если заказчику — смена памяти становится инженерной задачей, а не катастрофой.

Вторая граница — между извлечением семантического слоя машиной и его курацией человеком. LongMemEval показал, что модели уверенно справляются с поиском, но проваливаются на 2 из 5 категорий — разрешении противоречий и понимании временно́го порядка. Пока этот разрыв не закрыт, семантический слой требует человеческого надзора над тем, что засчитано как новое устойчивое утверждение, а что — как шум.

Третья граница — выгрузка. Документоцентричная эра дала привычку, что знание принадлежит команде и переносится между инструментами в виде файлов. Память агента слабее переносима по построению — привязана к схеме, временно́й модели, структуре эпизодов. Появление стандартов выгрузки слоя памяти — или их отсутствие в ближайшие 12 месяцев — скажет, останется ли эпоха архитектурно открытой или закроется вокруг 1–2 доминирующих стеков.

Главное

• Документ как единица знания страдает 3 структурными дефектами: не знает, когда устарел, не связан с операцией, требует ручной записи. На команде до 10 человек это незаметно, при 50 — фатально.
• На его место приходит трёхэтажная память: эпизодический слой пишется автоматически, семантический извлекается из него, структурированный остаётся системой записи и аудита.
• «Лучший Notion» — категориальная ошибка. Это не улучшение документа, а замена единицы знания: со страницы, которую кто-то отредактировал, на запись о произошедшем.
• Сдвиг меняет роли: владельцы знания превращаются в проектировщиков схем и триггеров; онбординг идёт по эпизодам последних 6–12 месяцев, а не по устаревшим страницам.
• Главная архитектурная проверка — кому принадлежит структурированный слой. Если поставщику горизонтальной платформы — актив временный. Если заказчику — память остаётся за командой при смене стека.

FAQ

Документы исчезнут совсем? Нет. Они перестанут быть источником истины и станут проекцией структурированного слоя — рендером для конкретного читателя. Контракт, отчёт регулятору, описание продукта на сайте — всё это документы. Но генерируются из памяти, а не порождают её.

Это не то же, что ИИ-помощник в Notion? Нет. ИИ-помощник в документоцентричной системе ускоряет работу с документом — пишет, ищет, суммирует. Архитектура памяти меняет единицу: знание фиксируется в момент события, а не рефлексии. Помощник без смены единицы — электронная таблица с макросами там, где нужна реляционная БД: ускорение операций над неподходящим примитивом.

Когда такой переход оправдан для команды? Когда расхождение между актуальным процессом и его документированной версией начинает регулярно стоить решений — повторных вопросов на онбординге, дублирующих диалогов, ошибок в эскалациях. В командах до 10 человек это решается дисциплиной; от 30 — становится структурным: количество одновременных изменений превышает скорость их описания руками.

Это не то же, что корпоративный поиск вроде Glean? Близко, но не то. Корпоративный поиск строится поверх существующих документов и ускоряет их нахождение. Слой памяти фиксирует операцию напрямую и извлекает знание из неё. Сама Glean переименовала продукт в «систему контекста», признавая этот сдвиг.

Кому принадлежит память агента? Главный вопрос архитектурного выбора. Если структурированный слой живёт в собственной системе записи заказчика, память остаётся у него и переживает смену вендора. Если он живёт в SaaS-платформе вендора, замена платформы стирает большую часть актива.

Что уже можно купить, а что — нет

К апрелю 2026 года стек вертикального AI разделился на то, что покупается из коробки, и то, что не покупается ни за какие деньги. За последний квартал четыре крупнейших провайдера — Anthropic, OpenAI, Google и AWS — независимо выпустили managed agent harness как отдельные продукты — этот сдвиг рынка businessengineer.ai назвал «harness as the agentic moat» ещё в марте, а к маю продуктизация уже завершилась. То, что год назад требовало месяца инженерной работы, ставится из SDK за несколько часов. Параллельно появилась индустрия памяти для агентов: Mem0 закрыл Series A на $24 млн в октябре 2025 при оценке $150 млн, Graphiti накопил десятки тысяч звёзд на GitHub, LongMemEval (arXiv:2410.10813) стал стандартным академическим бенчмарком долговременной памяти агентов.

Если модель меняется за выходные, а слой памяти переносится за 2–4 недели, вопрос звучит прямо: что именно нельзя купить, синтезировать или воспроизвести? Не инфраструктура памяти. А данные, которые через эту инфраструктуру прошли.

Конкретнее — это один тип данных: записи закрытого цикла. Каждая такая запись — формула вот что решил агент / человек, вот что произошло в итоге — это контракт между действием и его измеримым следствием через N дней. Если сформулировать точно, пара решение → исход — это атомарная единица обучающего сигнала вертикального AI, состоящая из трёх связанных полей: контекст, в котором было принято решение; само действие (что сделал агент или человек); измеримое последствие через заданный промежуток времени. Эта же сущность называется trajectory data — структурированная пара контекста и фактического исхода, зафиксированная в момент реального действия и связанная во времени с последствием. В отличие от обычного лога, такая запись содержит не только сам факт, но и связь действия с измеримым результатом. Это единственный слой защиты, который нельзя восстановить задним числом — сколько бы денег на восстановление ни потратить.

Три уровня, три разных горизонта жизни

Вертикальный AI-продукт сегодня строится на трёх слоях. У каждого из них - разный срок жизни как конкурентного преимущества.

Первый слой — модель. Горизонт защиты: 12–18 месяцев. Пока вы используете одну фронтирную модель, конкурент использует другую; через год оба перейдут на следующее поколение, и разница исчезнет. Jason Lemkin из SaaStr формулирует это прямо: «AI is table stakes, prompts are portable, AI quality is not your moat» — то есть качество модели и переносимость промптов не создают устойчивого преимущества. Это знакомая логика технического преимущества, которое утекает вниз по стеку — её прошли реляционные базы данных, облачная инфраструктура, теперь проходят фронтирные модели. На модели устойчивость не строится.

Второй слой — схема данных (representation layer). Горизонт защиты: годы. Это онтология домена: какие сущности существуют, как они связаны, что считается статусом, кто имеет право эскалировать, какие исключения валидны. Подробно про этот слой — в предыдущей заметке про representation layer как источник стоимости переключения. Чужому провайдеру нужны месяцы на корректное описание домена и ещё месяцы на калибровку схемы под реальное поведение конкретного рынка.

Третий слой — данные траекторий (trajectory data). Горизонт защиты: невозможно воссоздать ретроспективно. Это не «история действий». Это закрытый цикл (closed loop) — замкнутая связь между решением в конкретном контексте и фактическим исходом, наблюдаемым через определённый промежуток времени. Решение либо привело к нужному результату, либо нет. Прогноз сбылся или не сбылся. Рекомендация была принята клиентом или отвергнута. Именно эти пары «решение → исход» становятся обучающим сигналом, который улучшает следующие решения системы в похожих ситуациях. Более умной моделью — это значит не модель с большим числом параметров, а система, у которой выше точность прогнозирования исхода в конкретном домене за счёт накопленных пар. Их нельзя синтезировать, восстановить из логов или купить.

Почему «нельзя воссоздать» — не метафора, а физическое ограничение

Данные траекторий создаются только в момент реального решения в реальном контексте. Ни ретроспективная разметка логов, ни синтетические данные, ни дообучение на общедоступных датасетах не воспроизводят этот слой. Причина: запись содержит не только сам факт решения, но и контекст момента — состояние системы, историю предшествующих взаимодействий, конкретные условия, сложившиеся к тому часу. Этот контекст начинает теряться уже через сутки: параллельные процессы успевают изменить состояние, а исход решения проявляется позже самого решения, и связать одно с другим по логам постфактум становится невозможно (arXiv:2507.05257).

Исследования памяти агентов подтверждают асимметрию количественно. MemoryAgentBench, представленный в работе Hu, Wang и McAuley «Evaluating Memory in LLM Agents via Incremental Multi-Turn Interactions», вводит четыре ключевых компетенции для систем с памятью: точный поиск, обучение во время использования, понимание длинных горизонтов и избирательное забывание. Авторы фиксируют, что ни один из проверенных подходов — от простого расширения контекста до retrieval-augmented generation и внешних модулей памяти — не закрывает все четыре компетенции одновременно. На LongMemEval (arXiv:2410.10813) разрыв в категории temporal reasoning между системами с накопленной долговременной историей и без неё авторы оценивают в десятки процентных пунктов — и этот разрыв не закрывается увеличением контекстного окна.

MEM1 (arXiv:2506.15841) идёт дальше: работа показывает, что системы, обученные на реальных траекториях решений, формируют принципиально другие внутренние представления задачи — не описательные, а оперативные. Из этого следует, что разрыв в качестве между провайдером с историей и провайдером без неё не просто существует — он увеличивается с каждым месяцем работы в одном домене.

Gong: прецедент монетизации

Рынок уже научился продавать запись траекторий как отдельный продукт — за пределами AI-агентов. Самый показательный пример — Gong.io.

Gong записывает каждый разговор отдела продаж, извлекает из него паттерны и связывает их с исходами сделок. Это и есть запись траекторий в чистом виде — только для sales-команды, а не для AI-агента. Модель продукта состоит из трёх обязательных строк прайса: платформенная подписка ($5 000–$50 000/год), per-user лицензия ($1 300–$1 600 на пользователя в год) и единовременное внедрение ($7 500–$65 000). Для команды из 10 человек первый год обходится примерно в $28 000, для 50 человек — около $106 000.

Причина, по которой рынок готов платить эти деньги, проста: Gong не продаёт «аналитику звонков». Gong продаёт накопленную историю «вот что говорилось на этом этапе сделки — вот чем сделка закончилась». Платформенная подписка отделена от лицензии на пользователя именно потому, что хранилище и доступ к историческим записям — это базовая ценность, не зависящая от размера команды. Внедрение стоит отдельно и дорого по той же причине: клиент платит за то, чтобы правильно поставить запись траекторий с первого дня, а не пытаться разметить логи задним числом, когда контекст уже потерян.

Та же логика работает в LLM-observability. Langfuse продаёт запись траекторий агента от $29 до $2 499/мес в зависимости от глубины ретенции данных. Braintrust — от $249/мес с отдельной строкой за хранение данных. Коммерческая логика общая: хранение и анализ траекторий — отдельная позиция прайс-листа, а не «инфраструктура внутри».

Вертикальный маховик против горизонтального «company brain»

К 2026 году оформилась отдельная категория горизонтальных «company brain» продуктов: корпоративная память для всей компании. Glean привлёк оценку в районе $7 млрд в раунде 2025 года. Y Combinator включил enterprise memory layer в Request for Startups последних батчей. Эта категория решает реальную задачу — поиск и связывание знаний внутри организации.

Но для вертикального AI у горизонтальных платформ есть структурное ограничение: они не накапливают данные траекторий в конкретном операционном домене. Возьмём поток обращений в службу поддержки SaaS-продукта. Горизонтальная платформа знает, что в компании есть документация по продукту и тикеты. Она не знает, какие решения о приоритизации, эскалации или закрытии тикета в каком контексте приводили к удержанию клиента, а какие — к отказу от подписки в течение следующих 90 дней. Эта связь между решением и исходом не накапливается автоматически — она требует явной фиксации в момент действия и привязки к измеримому событию через N дней.

Исторический прецедент — Veeva против Salesforce в фармацевтике. Veeva не победила лучшей CRM-системой. Она победила потому, что накопила domain-specific онтологию и историю реальных взаимодействий именно для pharma sales: паттерны контакта с врачами, регуляторные ограничения, специфику цикла одобрения препарата. Salesforce не воспроизвёл это через универсальную CRM не потому, что не мог собрать данные, а потому, что схема и контекст у Veeva уже были откалиброваны. Sanjay Srivastava в Forbes-эссе «The Moat Is Moving» формулирует тот же тезис в более узком виде: institutional regulation, deep ecosystem integration и, главное, «closed-loop data — operational evidence linking decisions to outcomes» в 2026 году становятся не маркетинговой «defensibility», а единственными слоями, которые провайдер модели физически не может упаковать в свой SDK.

Этот механизм — data network effects, описываемый в a16z-эссе «The Economic Case for Generative AI and Foundation Models» как одна из ключевых форм defensibility в эпоху foundation моделей: ценность компаундируется, когда больше использования системы создаёт лучшую калибровку, а лучшая калибровка привлекает больше использования.

Разрыв в стоимости между вертикальным маховиком и горизонтальной платформой здесь не косметический, а структурный. Совокупная стоимость владения горизонтальной enterprise-платформой уровня Glean для крупной компании, по публичным выкладкам аналитиков рынка корпоративного поиска, измеряется сотнями тысяч долларов в год. Вертикальный AI-контур, собранный поверх open-source инфраструктуры памяти и собственной онтологии домена, на сопоставимом периметре существенно дешевле. Эта ценовая разница — не конкурентный риск для вертикального игрока, а его структурная защита: горизонтальная платформа не может опуститься в эту цену, не обесценив свою же модель монетизации.

Что произойдёт, когда managed eval станет товаром?

Закономерный риск: OpenAI уже выпустил Evals API. Anthropic движется в ту же сторону. Если managed evaluation станет бесплатной инфраструктурой — не обесценивает ли это запись траекторий как таковую?

Нет — по той же причине, по которой Datadog существует рядом с бесплатным AWS CloudWatch. CloudWatch даёт сырые метрики; Datadog продаёт интерпретации в контексте конкретного стека и рабочего процесса. Gong существует рядом с Salesforce Einstein много лет по той же логике: Salesforce умеет анализировать структурированные данные CRM, но не воспроизводит специфику разговоров, которую Gong накопил в конкретных индустриях.

Почему это работает как порог, а не как движение

Накопление траекторий ведёт себя не линейно. До определённого объёма записей система ведёт себя как «лучший промпт» — её можно воспроизвести копией инструкции. После того, как система накопила заметный объём закрытых циклов в одном операционном контексте, «перенести знание» к конкуренту выписыванием промпта уже нельзя: ценность живёт в парах «решение → исход», в сезонных паттернах и в длинном хвосте исключений, которые нельзя выразить одной инструкцией. Конкуренту придётся накапливать это заново — в том же режиме реального времени, в том же домене, при тех же условиях.

Публичных бенчмарков, которые прямо транслируют размер trajectory корпуса в «проценты switching cost», пока нет — и это честнее признать. Но форма разрыва фиксируется количественно на смежных прокси. MemoryAgentBench (arXiv:2507.05257) показывает, что разрыв в качестве temporal reasoning между системами с накопленной историей и без неё измеряется десятками процентных пунктов на LongMemEval — и этот разрыв не закрывается ни ростом контекстного окна, ни сменой модели. Единственный фактор, который его закрывает, — накопление реальной истории в том же домене.

Без явного слоя записи траекторий — фиксации входа, решения и исхода — эти данные не накапливаются автоматически. Это инженерное решение, которое имеет смысл принимать на старте: вход (контекст), решение (что агент или человек сделал), исход (что произошло через N дней) — три поля в каждой записи. Ретроспективная разметка старых логов возможна, но контекст момента уже потерян, и качество таких данных принципиально ниже.

Что из этого следует

Четыре следствия для вертикального AI-продукта.

Первое. Архитектурное решение: запись траекторий должна быть явным слоем с первого дня, а не логом, который «потом разметим» (arXiv:2506.15841). Вход (контекст), решение (что агент или человек сделал), исход (что произошло через N дней) — три поля в каждой записи. Без этой структуры данные копятся, но не становятся обучающим сигналом.

Второе. Коммуникационное решение: клиент должен понимать, что именно компаундируется со временем. Не «мы поддерживаем AI-систему», а «за 6 месяцев система накопила N закрытых циклов в вашем домене, и это делает её точнее, чем любое новое решение с нуля». Gong продаёт ровно это сообщение: клиент платит не за записи звонков, а за то, что система с каждым месяцем точнее предсказывает исходы сделок, чем интуиция менеджера.

Третье. Стратегическое следствие: горизонт конкурентного преимущества зависит от того, как давно и насколько методично ведётся запись (arXiv:2507.05257). Провайдер, начавший фиксировать траектории год назад, имеет год структурного опережения. Этот разрыв не закрывается «лучшей моделью» — только временем работы в том же контексте. Оценка вертикального AI-продукта в этой логике строится не на технологическом стеке, а на глубине и длине накопленной истории.

Четвёртое. Конкурентное следствие: managed eval от OpenAI и Anthropic не уравнивает игровое поле — он смещает ценность дальше в сторону данных (Evals API). Когда инфраструктура записи доступна всем, выигрывает тот, кто начал записывать раньше и в правильном вертикальном контексте. Коммодитизация инструментов в зрелых рынках систематически усиливает преимущество тех, кто накопил содержание раньше — этот сдвиг ценности от инструмента к данным в его работе уже прошли инфраструктурный мониторинг (CloudWatch против Datadog) и CRM (Salesforce против Gong); сейчас он повторяется на уровне AI-агентов.

Главное

• Модель и слой памяти коммодитизируются на горизонте 12–18 месяцев — это базовое условие рынка, на котором приходится строить продукт.
• Схема данных (representation layer) держится годами. Необходимый, но не достаточный уровень защиты.
• Данные траекторий — единственный слой с физической невоспроизводимостью. Закрытые циклы «решение → исход» нельзя купить, синтезировать или воссоздать ретроспективно (arXiv:2506.15841).
• Поведение слоя нелинейно: до определённого объёма записей знание переносится копией промпта; после — нет, и конкуренту приходится накапливать заново в реальном времени.
• Рынок уже монетизирует этот слой: Gong (≈$28 000–$106 000/год на команду), Langfuse и Braintrust — отдельная позиция прайс-листа за хранение и анализ траекторий.
• Managed eval не убивает преимущество — он создаёт инфраструктуру записи. Ценность — в том, что именно записано и под какой домен откалибровано.

FAQ

Чем данные траекторий отличаются от обычных логов системы?

Лог фиксирует факт: агент ответил так-то в такое-то время. Запись траектории фиксирует замкнутый цикл: агент принял такое решение в таком контексте, и через N дней исход был таким. Разница принципиальная — лог описывает действие, запись траектории связывает действие с последствием. Эта связь и создаёт обучающий сигнал, который улучшает следующие решения в похожих ситуациях (arXiv:2506.15841).

Почему нельзя воссоздать данные траекторий задним числом — разве нельзя разметить старые логи?

Ретроспективная разметка работает для очевидных случаев, но не воспроизводит контекст момента решения. Временная метка, история предыдущих взаимодействий, состояние системы, параллельные события — всё это либо не сохранилось в логах, либо не было связано в структуру, пригодную для извлечения паттернов. MEM1 (arXiv:2506.15841) показывает, что внутренние представления модели, обученной на реальных траекториях, отличаются от представлений модели, обученной на синтетически восстановленных записях, — и этот разрыв не закрывается ростом объёма синтетики.

Горизонтальные платформы корпоративной памяти вроде Glean — разве они не решают ту же задачу?

Нет. Горизонтальная платформа знает, что в компании есть информация по домену, но не знает, какие решения в каком контексте приводили к каким исходам. Это разница между корпусом документов и историей действий, привязанных к последствиям. Горизонтальная платформа работает с первым; данные траекторий — это второе. Вертикальный AI-продукт с двенадцатью месяцами работы в домене и горизонтальная корпоративная память — разные категории, а не конкуренты.

Когда данные траекторий начинают создавать реальное конкурентное преимущество — с первого дня или нужно накопить порог?

Поведение нелинейно. До определённого объёма закрытых циклов в одном операционном домене знание системы можно перенести к конкуренту копией инструкции — switching cost практически нулевой. После — нет: ценность живёт в парах «решение → исход», в сезонных паттернах и в длинном хвосте исключений, которые нельзя выписать одной инструкцией. Конкурент в этой точке вынужден накапливать заново в режиме реального времени, в том же домене и при тех же условиях. Конкретный порог зависит от плотности решений и длины обратной связи в вертикали — публичных бенчмарков, переводящих размер корпуса траекторий в проценты switching cost, пока нет.

Как объяснить клиенту ценность данных траекторий, не раскрывая технических деталей?

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

В августе 2025 года United Rentals сообщила, что 76% её выручки в 2025 году пришло от клиентов, использующих digital-инструменты. В 2023 году этот показатель был 70%, в 2024-м — 73%. Шесть процентных пунктов в год при выручке около 16 млрд долларов — это не маркетинговый слайд, это фактический сдвиг операционной модели. Тот же отчёт фиксирует +22% online-выручки и +31% онлайн-платежей год к году, а ML-рекомендатор Smart Suggestions уже даёт −27% времени на подбор и заказ техники на пилотных аккаунтах (investors.unitedrentals.com).

В это же время большинство российских арендодателей спецтехники принимают заявки телефонным звонком, ведут партнёров в Excel и проверяют наличие машины ручным обзвоном. Это не оценка, это наблюдаемая реальность отрасли, в которой основной канал поиска подрядчика — Авито, а основной операционный софт — мессенджеры. Разрыв между двумя картинами — не «отставание из-за санкций» и не «русские не умеют в AI». Это окно, которое закроется в течение 18–24 месяцев — и закроется не само, а руками тех, кто решит занять вертикальный слой раньше остальных.

Что значит «AI у большой четвёрки» сейчас

Под большой четвёркой мирового rental-рынка понимаются United Rentals (≈$16 млрд выручки 2025), Sunbelt Rentals в составе Ashtead Group (≈$8 млрд+), Loxam (€2,47 млрд) и Herc Rentals (≈$3 млрд). У всех четырёх в 2024–2025 годах появился публично заявленный AI-контур, и архитектурно он устроен похоже.

United Rentals публикует Total Control как proprietary fleet management platform: web и mobile, заказ и возврат техники, разнесение затрат по объектам, управление инвойсами, расширенная телематика. Поверх этой поверхности в 2025 году добавлены три AI-функции: Smart Suggestions предсказывает следующий заказ клиента на основе истории, сезонности и характера объекта; Equipment Fit AR позволяет через камеру телефона разместить 3D-модель техники на стройплощадке и проверить, пройдёт ли она в узкое место; predictive maintenance закрывает поломки до их появления через ML на телематических данных.

Sunbelt идёт по более тяжёлому пути. В ноябре 2025 года компания расширила партнёрство с Trackunit и подключила к платформе IrisX более 20 000 единиц техники, включая аккумуляторные хранилища, солнечные модули и башенные осветительные мачты — то есть нетипичные для классического rental позиции. Поверх этого работает AI-driven customer portal с метриками утилизации и downtime, приложение True Fuel Costing и открытый Fleet API. На уровне группы это одна из пяти стратегических осей Sunbelt 4.0 — connectivity и data перестали быть «инициативой ИТ» и стали отдельным направлением P&L. Архитектурно за этим стоит не велосипед: Sunbelt США давно живёт на PTC ThingWorx как IoT-агрегаторе, нормализующем данные с разнородных OEM.

Loxam в финансовом отчёте 2025 года прямо заявляет: «вся цепочка процесса с клиентом теперь оцифрована — от заказа до управления контрактом онлайн, а deployment AI продвинулся, в особенности в predictive maintenance и fleet management». Herc Rentals продаёт ProControl с технологией M.A.C. — multi-user billing, geofencing, контроль доступа к технике, ETA-прогноз, mobile-first UX. В спонсорском материале Wired Herc формулирует это как «следующее поколение аренды техники в кармане у клиента» — и эта формулировка показывает, что для них мобильное приложение клиента уже не дифференциатор, а минимум.

Общий паттерн у всех четверых одинаковый. Никто не строит всё внутри: у каждого есть собственный customer-facing portal плюс интеграция с горизонтальными B2B-сетями — Trackunit и SmartEquip для парка и запчастей, ThingWorx как промышленный IoT-слой. То, что стоит дороже всего, — нормализация данных от десятков OEM и обвязка операционных процессов вокруг этой нормализации. Это и есть defensible часть. Модель и UX — заменимые.

Что в этой архитектуре делает вертикальный AI

Vertical AI — это операционный слой, в котором AI решает не общую задачу (написать текст, ответить на письмо), а конкретную последовательность шагов внутри одной отрасли, опираясь на её собственную модель сущностей, статусов и инвариантов. Для аренды спецтехники такой слой описывает, что считается заявкой, какой статус у партнёра, что значит «техника подтверждена», как переходят между состояниями документ и платёж. Это не «прикрутить чат-бот к сайту» — это построить диспетчерский контур с confidence scoring по парку и рейтингом по партнёрам, в который потом встраиваются языковые модели как исполнители, а не как продукт.

Большая четвёрка, по сути, уже построила такой слой и теперь докручивает в него AI. На фоне этого индустрия фиксирует базовое условие: по исследованию Quipli за 2025 год только 16% rental-операторов в США имеют полностью интегрированные системы, ещё 67% живут на частично интегрированных, а 50% по-прежнему вручную переносят данные между системами. Большая четвёрка — это исключение, а не среднее. Российский рынок аналогичный слой не построил пока ни на каком уровне — и здесь проходит развилка.

Российская картина: где мы сейчас и где пройдёт граница

Российский рынок аренды спецтехники структурно отличается от американского по нескольким измерениям, и большую часть этих различий нельзя проигнорировать. Мирового масштаба IoT-инфраструктуры в РФ нет: Trackunit-устройство стоит порядка 10–30 долларов в месяц на единицу, и для парка 200 машин это 200–600 тыс. рублей ежемесячно — годовая выручка одной единицы. OEM-производители тяжёлой техники не отдают CAN-данные на старых моделях. Retrofit-сенсоры стоят 50–200 тыс. рублей за единицу. Полноценный predictive maintenance на сенсорной телеметрии в SMB-rental в горизонте 2026–2028 годов нерентабелен; это не выбор, это арифметика.

Зато оцифрован соседний слой. ATI.SU (биржа грузоперевозок) ввела банковскую верификацию через Т-Бизнес, СберБизнес и Альфа-Бизнес, ML-детектор подозрительных аккаунтов и публичную «Карту грузов» с heatmap спроса по регионам (ati.su). ATI.SU занимает в грузоперевозках ту же позицию, в которой кто-то скоро окажется в аренде спецтехники: централизованная верификация контрагентов, репутационная база, операционная аналитика поверх. Это не гипотеза — это работающая модель в смежной нише.

Именно поэтому август 2025 года был ключевым для отрасли. Тогда «Контур.Диадок», Transbaza и «Авито Спецтехника» публично объявили интеграцию ЭДО прямо в платформу аренды. Цифры из релиза: 60% арендаторов на Авито Спецтехнике — юридические лица, число арендодателей выросло на 15% за 2024 год, документооборот ускорился в 10 раз, а по оценкам платформы автоматизация документов сберегает 2% бюджета строительной сметы (при том, что сама спецтехника — это около 20% бюджета стройки).

Сложение читается прямо: маркетплейс с трафиком и рейтингом, нишевая CRM с историей в учёте аренды спецтехники, инфраструктура ЭДО федерального масштаба. Этой связке не хватает двух элементов — диспетчерского AI и dynamic pricing — чтобы стать «Яндекс.Аренда спецтехники» де-факто. Оба элемента технически доступны: GigaChat 3 Pro и YandexGPT 4 закрывают LLM-слой, Яндекс Маршрутизация с 300+ параметрами и заявленными −30% логистических затрат закрывает route optimization, российские поставщики голосовых агентов — общение с водителями и партнёрами. Никто из big tech пока не запустил продукт целиком — но запретов нет, и это главное.

Цена входа и реальная экономика

Параллельно стало понятно, сколько стоит вертикальный AI на российских данных. Опубликованный на vc.ru разбор 50 кейсов внедрения GigaChat и YandexGPT даёт устойчивые цифры: средний бюджет внедрения — 75 тыс. рублей в месяц, окупаемость 3–6 месяцев, ROI 150–400% за полгода, доля провалов 23%. Простой Telegram-бот для приёма заявок — 15 тыс. рублей внедрение и 3 тыс. в месяц, экономит около 30 тыс. на зарплате оператора. Голосовой ассистент для входящих звонков — 120 тыс. внедрение и 25 тыс. в месяц, заменяет двоих администраторов из трёх. Это не «AI-революция», это бытовая операционная экономика, которая уже работает.

То же на международной стороне. По данным Quipli за 2025 год, 83% rental-операторов борются с дефицитом персонала, 67% теряют ресурсы на задачи, которые могла бы решить автоматизация, и только 16% имеют полностью интегрированные системы. Большая четвёрка двинулась в AI не из любви к технологиям, а потому что не хватает людей, и это единственный способ удержать утилизацию парка выше 30% по EBITDA-маржинальности. Российский рынок ровно в той же демографической ловушке.

Что это означает для трёх типов решений

Первое — для собственника rental-парка. Конкретный тест: посмотрите, какой процент входящих заявок попадает в CRM в течение 15 минут, и какой процент партнёров имеет хоть какой-то рейтинг или confidence-метрику. Если первый показатель ниже 40%, а второй ниже 30%, вы строите бизнес на интуиции диспетчера. Это работало в 2018 году, в 2026-м работает по инерции, к 2028 году не будет работать. Минимальный AI-контур — парсер заявок из чатов с автозаписью в CRM плюс бот первой линии — стоит 50–150 тыс. рублей разово и окупается за квартал. Дальше идёт диспетчерский слой с confidence по партнёрам и dynamic pricing v0 на правилах.

Второе — для руководителя направления в крупной компании, у которой rental — часть строительной или промышленной операции. Возможный тест: оцените, какой процент решений о выборе техники проходит через сравнение нескольких поставщиков. Если меньше 50% — вы не пользуетесь рынком, вы пользуетесь привычкой одного менеджера. К 2027 году платформенный слой (Авито + Transbaza + Диадок и преемники) сделает прозрачность default. Решение о подключении к этой экосистеме лучше принять до того, как она станет обязательной — переговорная позиция в двух случаях разная.

Третье — для инженера или продукт-менеджера, рассматривающего вертикальный AI как направление. Конкретный тест: можно ли описать модель сущностей, статусов и инвариантов выбранной отрасли в одном документе размером 5–10 страниц без внутренних противоречий. Если нет — представления нет, и значит модель будет встраиваться в чужой UX (как в случае с Авито). Если есть — есть шанс на собственный диспетчерский слой и собственную позицию в стеке. Большая четвёрка строила эти представления десятилетиями; российский SMB-rental не строил их никогда, и это одновременно недостаток и форточка возможностей. Подробнее о том, почему горизонтальные AI-решения проигрывают вертикальным в B2B: [[/2026/04/harness-commodity-operating-layer]].

Три сигнала, по которым видно скорость закрытия окна

Три сигнала, которые покажут, как закрывается окно. Первый — публичный запуск AI-чата или voice-агента на Авито Спецтехнике или внутри Transbaza, с привязкой к ЭДО. Это означает, что горизонтальная платформа закрыла customer-facing AI-слой и нишевый игрок остаётся снаружи. Второй — сделка между крупным rental-оператором (СтройТакси, Перевозка24) и одной из big tech (Яндекс или Сбер) о технологическом партнёрстве. Это означает консолидацию платформы и снижение независимой переговорной силы региональных арендодателей. Третий — появление публичного списка SMB-rental-компаний, опубликовавших собственный AI-контур (диспетчерский, dispatcher-mode, predictive «по симптомам»). Это означает, что окно ещё открыто, но конкуренция идёт уже не за концепцию, а за качество исполнения.

Большая четвёрка прошла развилку «строить вертикальный слой или быть поставщиком в чужом UX» примерно в 2018–2020 годах и выбрала первое. Российский рынок проходит её сейчас. Здесь нет отрицательного ответа — есть только разный возраст ответа, и более ранний всегда стоит дешевле.

Главное

• United Rentals в 2025 году получала 76% выручки от клиентов, использующих digital-инструменты, и эта доля растёт примерно на 6 процентных пунктов в год; AI-функции (Smart Suggestions, Equipment Fit AR, predictive maintenance) уже встроены в основной customer-facing продукт.
• Большая четвёрка строит двухслойную архитектуру: собственный customer-portal плюс интеграция с горизонтальными B2B-сетями (Trackunit, SmartEquip, ThingWorx). Никто не делает всё внутри — основная защищённая часть это нормализация данных и операционные процессы вокруг неё.
• На российском рынке аренды спецтехники связка «Авито Спецтехника + Transbaza + Контур.Диадок» с августа 2025 года уже закрыла маркетплейс, нишевую CRM и ЭДО. Не хватает диспетчерского AI и dynamic pricing — обе компоненты технически доступны, но пока никем не запущены.
• Окно для вертикального AI-слоя в российском rental сужается к 2027–2028 годам, после чего AI-чат, мобильное приложение клиента и автоматический ЭДО станут минимумом, а не дифференциатором. Компании, которые построят собственный диспетчерский слой раньше, сохранят прямой доступ к клиенту; остальные будут поставщиками техники в чужом UX.

FAQ

Кто такие «большая четвёрка» в мировой аренде спецтехники? United Rentals (США, ≈$16 млрд выручки), Sunbelt Rentals в составе Ashtead Group (UK, ≈$8 млрд+), Loxam (Франция, €2,47 млрд) и Herc Rentals (США, ≈$3 млрд). Это публичные операторы, которые в 2024–2025 годах публично заявили AI-функции в основных продуктах и публикуют операционные метрики этих функций.

Может ли United Rentals или Loxam выйти на российский рынок? В горизонте 2026–2028 годов — нет. Loxam фокусируется на Европе, MEA и Латинской Америке, United Rentals — на США, Канаде, Австралии и UK. Санкционный режим и капиталоёмкость входа делают прямое присутствие маловероятным. Угроза приходит не от них, а от локальных аналогов, которые копируют архитектуру.

Чем Vertical AI отличается от обычного чат-бота? Чат-бот — это интерфейс, способный отвечать на вопросы. Vertical AI — это операционный слой со своей моделью сущностей и статусов конкретной отрасли, в котором языковая модель работает как исполнитель шагов, а не как продукт. У чат-бота нет понятия «партнёр с confidence 0.7 и историей 12 месяцев». У вертикального слоя — есть, и именно это делает его трудно копируемым.

Что должен сделать средний rental-оператор в России в ближайшие 12 месяцев? Минимум — закрыть две вещи: автоматический парсинг входящих заявок из чатов и Авито в CRM с временем реакции до 15 минут, и базовый рейтинг партнёров с confidence-метрикой, которая обновляется по факту сделок. Это закрывается бюджетом 50–200 тыс. рублей разово и 5–25 тыс. рублей в месяц на сопровождение, окупается на горизонте квартала. Всё остальное — диспетчерский слой, dynamic pricing, predictive по симптомам — стоит начинать после того, как закрыт этот минимум.

Цифра, после которой остальное - следствия

За 23 месяца стоимость запуска моделей уровня GPT-3.5 упала с $20 до $0.07 за миллион токенов. Это сокращение в 280 раз (Stanford HAI AI Index 2025, через анализ Tobias Pfütze). Средняя цена корпоративного токена упала на 75% за один год - $10 → $2.50 в 2024-2025 (Ramp Velocity). Ведущие модели дешевеют со скоростью 5-10× в год; уровни возможностей, превратившиеся в товар, - на 40-900× в год (arXiv 2511.23455, ноябрь 2025). DeepSeek V3 стоит $0.14 за миллион входных токенов против $3.00 у GPT-4o - минус 95% при сопоставимом качестве на большинстве корпоративных задач (Silicon Canals).

Это не пузырь и не маркетинговая флуктуация. Это S-образная кривая (классическая траектория зрелости технологии - медленный старт, резкий рост, насыщение), которую видели облачные вычисления, жёсткие диски, оптоволокно и до них - десятки технологических волн. Исторически такие кривые разворачивались только при регуляторном вмешательстве или физическом лимите ресурсов; в работе моделей ни того, ни другого не просматривается. ИИ-студия, продающая «ИИ-интеграцию под клиента» в 2026 году по тем же правилам, по которым она продавала её в 2024-м, продаёт продукт, себестоимость которого через 18 месяцев упадёт ещё в несколько раз - а его конкуренция переедет этажом выше: туда, где сидят управляемые сервисы Bitrix24, RetailCRM и Yandex AI Studio.

Это не «рост рынка». Это обрыв превращения в товар - момент, когда продукт перестаёт различаться по бренду и его цена сходится к себестоимости. И механика у него ровно та же, что у веб-разработки в 2005 году и у SEO в 2015-м, - только сжатая в три раза по времени.

Не первый раз: веб-разработка, SEO, цифровой маркетинг

Каждое технологическое поколение проходит одну и ту же кривую: инновация → высокая маржа → инструментарий → платформы → гонка цен вниз для товарного слоя → выживают только специализированные ниши. Цикл одинаковый, разница - в скорости.

Каждая из предыдущих волн занимала пять-десять лет. ИИ-волна сжата до 24-36 месяцев по трём причинам: товаризация идёт не через open-source-копии, а через прямое снижение цен у самого провайдера; платформы исполнения (Bitrix24, RetailCRM, Yandex AI Studio) уже встроены в стек клиента; генеративные инструменты ускоряют сами агентства, и они конкурируют сами с собой.

Boutique Consulting Club описывает это как сжатие с двух сторон. Смысл их тезиса: ИИ обесценивает кодифицируемые задачи, а платформы исполнения двигаются вверх по цепочке, упаковывая лёгкий консалтинг в свои продукты (эссе Danilo Kreimer, основателя Boutique Consulting Club). Сверху давит платформенная упаковка, снизу - обнуление кодифицируемой работы. Их прогноз к 2035 году: кодифицируемая работа низкой сложности сохранит 10-20% человеческого присутствия, типичное беспорядочное внедрение - около 33%, стандартная стратегическая работа - 20-30%, сложные трансформации - около 50%. Сроки - 1-3 года для простых задач, 3-6 лет для среднего по сложности интеллектуального труда.

Параллельный сигнал из маркетингового сектора: Productive.io опросили 180+ агентств в ноябре 2025 - около трети уже получили запросы на «ИИ-скидку», ещё половина ждут такие запросы в ближайшие месяцы (Productive.io). Search Engine Land формулирует это короче: агентства внедряли ИИ ради экономии, но клиенты сделали то же самое - и теперь ожидания растут, бюджеты сжимаются, а ценность подвергается проверке (Search Engine Land, апрель 2026). Себестоимость падает быстрее, чем цена. Это финансовое определение сжатия.

Историческая параллель полезна для калибровки ожиданий. В 2005 году средняя цена корпоративного сайта в Москве была 150-500 тысяч рублей; к 2012 году WordPress + готовая тема + фрилансер закрывали тот же объём за 20-40 тысяч. Уцелели те, кто переехал в e-commerce-платформы для крупных ритейлеров и в продуктовый дизайн. Та же геометрия повторилась в SEO между 2010 и 2018: дешёвая оптимизация on-page ушла в $200-500, а специализированный legal или medical SEO со знанием нормативных требований закрепился на $10-15K в месяц. Средний слой исчез не из-за падения спроса, а потому, что спрос распался на два класса - самообслуживание и отраслевую экспертизу.

Что уже произошло в РФ - а не «может произойти»

Главная ошибка в обсуждении товаризации - говорить о ней в будущем времени. В русском B2B нижняя планка абонементного уровня уехала вниз уже сейчас.

Yandex AI Studio - это управляемая платформа Яндекса для сборки LLM-агентов поверх YandexGPT и внешних моделей без кода. Она в связке с SpeechKit покрывает четыре сценария применения, на которых живёт средняя ИИ-студия в РФ: квалификация лидов, контроль закрытий сделок, реактивация отказников, мониторинг скорости ответа по SLA. Стоимость для команды 10-15 менеджеров - 12 000-30 000 ₽/мес из коробки (vc.ru / Salekit, апрель 2026). Маркетплейс Bitrix24 содержит подборку ИИ-приложений и агентов от сторонних разработчиков - часть бесплатна, часть стоит 5-15 K ₽/мес как надстройка к основной подписке. RetailCRM штатно предлагает ИИ-агентов внутри тарифа, без отдельной интеграции.

В США тренд тот же: Salemwise приводит ориентир базовой ИИ-автоматизации для SMB - $500-5 000 единоразово плюс $49-500 в месяц. То есть в долларовом эквиваленте дешёвый абонемент уже сейчас стоит 4 000-40 000 ₽/мес.

Это меняет арифметику разговора с клиентом. До 2025 года ИИ-студия могла честно сказать: «то, что мы делаем, нельзя купить как продукт». В 2026-м у клиента уже открыта вкладка с маркетплейсом Bitrix24, и он видит там ИИ-помощника за 7 000 ₽/мес. Чтобы продать ту же базовую интеграцию по типичному студийному ориентиру (разбор бюджетов внедрения ИИ на vc.ru), нужно объяснять разницу, а разница больше не очевидна, потому что обвязка модели теперь товар («Когда обвязка становится товаром»).

Прогноз на 2027-2028, основанный на текущей траектории цен и платформенной активности:

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

Что не схлопывается под давлением товаризации?

Защитная геометрия. Из четырёх независимых источников за последний год - BVP AI Pricing Playbook, Pfütze, Euclid Ventures о защитном рве в отраслевом ИИ, Boutique Consulting Club - сходится один консенсус: после товаризации модели и обвязки остаются три источника отличия, и ни один из них не покупается у поставщика.

Контекст и качество данных. То, что компания накопила внутри себя за годы: исторические решения, паттерны клиентов, нормативный контекст, граничные случаи. BigDATAwire 2026 enterprise predictions формулируют это как «context capitalism» («капитализм контекста»): отличие смещается от доступа к модели к точности понимания реальных операций бизнеса. ИИ-студия не владеет этими данными, но может построить контур, который их захватывает и кодифицирует, - и тогда контур становится живым активом клиента, а не отчуждаемым артефактом.

Архитектура рабочего процесса. Где сидят контрольные точки управления, как результаты модели верифицируются до того, как они влияют на бизнес, какие триггеры эскалации, какие правила ценообразования, какие исключения допустимы. StackAI 2026 enterprise adoption называет это «repeatability - ability to deliver one governed workflow and replicate it 20 times» (повторяемость - способность выстроить один управляемый рабочий процесс и тиражировать его двадцать раз) и определяет как ключевой стратегический актив. Это не задача, которую решает Agent Builder. Это задача, которую решает человек, неделями сидящий внутри операции конкретной компании.

Доверие и ответственность за результат. Кто отвечает, если ИИ ошибся. Кто согласует с регулятором. Кто поддерживает культурные изменения. Boutique Consulting Club пишет об этом без эвфемизмов: уцелеет именно человеческая, неудобная часть - внутренняя политика, выстраивание доверия, тонкое искусство договариваться с теми, кто сам по себе.

Деталь, которую в дискуссиях о товаризации пропускают: средний слой схлопывается всегда, но оба полюса становятся жёстче. Товарный низ дешевеет быстрее, чем показывает публичный рынок; отраслевой верх дорожает быстрее, чем это видно снаружи. Та же динамика наблюдалась в SEO: к 2018 году дешёвая оптимизация on-page стоила $200-500, а специализированный legal SEO со знанием нормативных требований - $15 000+ в месяц. Разрыв вырос, не сжался.

Почему сближение возможностей моделей обнуляет «выбор стека» как продукт

Ещё один сигнал, который меняет правила воронки. На SWE-bench Verified - наиболее достоверном практическом ориентире для оценки моделей в задачах разработки в 2026 году - топ-5 моделей разделены 1.3 процентного пункта, что Smartscope называет «фактической ничьей». Сближение возможностей на уровне ведущих моделей означает, что выбор модели перестал быть стратегическим решением. Это просто выбор уровня: дороже-точнее или дешевле-почти-как.

Для агентств, которые строили часть своего авторитета на «мы знаем, какую модель брать под какую задачу», это плохая новость. Эта экспертиза обнуляется. Но домен и контекст - нет. Pfütze формулирует это так: каркас, контекст и обвязка агента определяют результат сильнее, чем интеллект самой модели. В 2024 году это было наблюдением. В 2026-м - это рабочая гипотеза для всей стратегии монетизации в B2B-ИИ.

Что это значит на практике для ИИ-студии в 2026

Логичный шаг - не переписывать страницу с ценами, а переписать определение того, что продаётся.

Первое: внедрение перестаёт быть «технической интеграцией» и становится «архитектурным аудитом и проектированием рабочих процессов». Тот же объём работы, но с другой формой ценности. Аудит - это не «подключим API», а «опишем, какие сущности первичны в вашей операции, где точки верификации, какие данные траекторий мы будем собирать с первого дня, как будет выглядеть слой представления через шесть месяцев». Это работа, которую Agent Builder не делает и не сделает - потому что Agent Builder не сидит внутри клиентской операции.

Второе: абонемент перестаёт быть «поддержкой агента» и становится «управлением ИИ-контуром с метриками результата». Здесь критичен сдвиг в формулировке SLA. Не «время ответа на тикеты» и не «процент бесперебойной работы агента», а измеримый бизнес-исход - время до контакта с лидом, конверсия на этапе квалификации, доля реактивированных отказников, потерянные заявки в неделю. То, что попадает в финансовую отчётность клиента, а не в дашборд интегратора. И, как часть того же абонемента, гибридный компонент - % от результата поверх базы. Это убивает позиционирование «мы такие же, как Yandex AI Studio, только дороже» и заменяет его на «мы берём деньги за результат, а не за инфраструктуру».

Третье - и это структурно важнее первых двух: отраслевой подход, а не универсальный. ИИ-студия, которая знает один-два рынка глубоко, не попадает в сжатие, потому что её защита - не код, а отраслевой контекст. Владельцы небольших операционных бизнесов в РФ не покупают «ИИ». Они покупают решения конкретных операционных болей: потерянные заявки, медленная диспетчеризация, потеря клиента после первого касания, ручная сверка по складу. Между «ИИ-агент» и «потерянная заявка» лежит пропасть, которую закрывает не модель, а человек, понимающий конкретный бизнес.

Boutique Consulting Club приводит ту же мысль в формате четырёх маршрутов выхода: либо ты уходишь в глубину (узкая отрасль), либо в ответственность за результат (берёшь обязательство по бизнес-метрике), либо в доверие (становишься частью команды клиента, а не подрядчиком), либо в собственные продукты (строишь продукт, не сервис). Все четыре маршрута имеют общее свойство - они не масштабируются за счёт SDK. Они масштабируются только за счёт человеческого контакта с конкретной операционной средой.

Что мы будем наблюдать

Несколько сигналов, которые покажут, в какую сторону рынок движется быстрее, чем ожидается.

Первый - публичные кейсы в маркетплейсах Bitrix24, RetailCRM, AmoCRM. Когда управляемый ИИ начнёт показывать измеримые результаты (не «внедрили ИИ», а «сократили время до первого контакта на 40%»), нижняя планка абонементного сегмента сдвинется ещё ниже - потому что у клиента появится ориентир, против которого он будет считать стоимость работы студии.

Второй - появление ценообразования по результату у заметных российских ИИ-студий. BVP AI Pricing Playbook фиксирует этот сдвиг в США с 2024-2025: контракты с оплатой по результату выросли с ~5% до ~15% выборки за 18 месяцев. Рынок РФ почти целиком живёт в оплате по часам и материалам или по схеме «внедрение плюс абонемент»; первый, кто публично закроет крупный контракт по схеме «процент от вынесенного в SLA бизнес-результата», задаст рамку, в которую остальные будут вынуждены войти.

Третий - поведение Bitrix24, RetailCRM и Yandex AI Studio в части отраслевых шаблонов. Если они начнут выпускать готовые шаблоны под конкретные ниши (стройка, медицина, ритейл), это сожмёт окно для универсальных агентств ещё на 6-9 месяцев. Если останутся на универсальных конструкторах - окно открыто чуть дольше.

Четвёртый - публичные данные по запросам на «ИИ-скидку». Productive.io уже зафиксировали тренд в США и Европе. Аналогичный замер в РФ появится в течение 2026 года, и его значение будет важнее, чем большинство инвесторских прогнозов.

Пятый - динамика зарплат внутри ИИ-студий. Если в 2026-2027 средняя ставка инженера среднего уровня по интеграции LLM начнёт расти медленнее общего IT-индекса в РФ, это сигнал, что бюджеты на универсальную интеграцию ужимаются на стороне клиента. Та же метрика срабатывала в SEO в 2014–2015 годах за 9–12 месяцев до того, как сжатие маржи стало очевидным в публичных финансовых отчётах агентств.

Что остаётся, когда обесценивающееся уходит вниз

Главный практический вывод не в том, что ИИ-студии умрут к 2027 году: параллель с веб-разработкой показывает, что большинство выживает при падении среднего чека в 7-10 раз. Важнее, что между 2026 и 2028 рынок проходит через перераспределение выручки, и пропорция «универсальное против отраслевого» инвертируется. Универсальная интеграция ИИ к CRM - основная масса бизнеса в 2024-м - к 2027 году станет товаром внутри Yandex AI Studio, Bitrix24 AI и RetailCRM, и маржа уйдёт в платформы. Отраслевой ИИ-контур с обязательствами по результату внутри одной отрасли, выглядевший узкой нишей в 2024-м, к 2027 году станет основной формой устойчивой маржи в секторе.

ИИ-студии, которые рассчитывали «делать всё для всех», в этой рамке теряют экономику. Выживают те, кто готов сидеть внутри одной операционной реальности достаточно долго, чтобы накопить контекст, который не помещается в API. Про экономику без внешнего капитала в такой модели мы писали отдельно - «Три клиента вместо раунда». Узкий рынок, который большинство сейчас называет ограничением, через 24 месяца окажется единственным местом, где осталась маржа.

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

Главное

• 280× за 23 месяца. Стоимость работы моделей уровня GPT-3.5 упала с $20 до $0.07 за миллион токенов. Это S-образная кривая, из которой нет разворота.
• Нижняя планка абонемента уже уехала. Yandex AI Studio, Bitrix24, RetailCRM закрывают базовые сценарии за 12-30 K ₽/мес - у клиента появился сравнительный ориентир, против которого он считает стоимость работы студии.
• Рынок раскалывается на два полюса. Товарный низ дешевеет быстрее, отраслевой верх дорожает. Средний слой - «ИИ-интеграция под ключ» - исчезает.
• Что уцелеет. Отраслевой верх с обязательствами по бизнес-результату, контекст и качество данных клиента, архитектура верифицируемых рабочих процессов, ответственность за бизнес-исход. Выбор модели и проектное внедрение - не уцелеют.

Частые вопросы

Правда ли, что этап внедрения ИИ-проектов исчезнет к 2027 году? Исчезнет не внедрение как таковое, а внедрение в нынешней форме «подключить LLM к CRM под ключ» за 150-350 K ₽. Под давлением управляемых платформ эта работа переводится в товарную нижнюю планку 30-80 K ₽. Премиальное внедрение сохранится только как «архитектурный аудит и проектирование рабочих процессов» внутри конкретной отрасли.

Чем абонемент в отраслевом верху отличается от «поддержки агента»? Формой SLA. Не «бесперебойная работа бота» и «время ответа на тикеты», а измеримый бизнес-исход: время до первого контакта с лидом, конверсия на квалификации, доля реактивированных отказников, потерянные заявки в неделю. Часть вознаграждения, привязанная к результату, - обязательный элемент защиты от сравнения с управляемыми платформами.

Можно ли выжить как универсальная ИИ-студия? Можно, но на порядок меньшей выручке и на рынке клиентов, которые сравнивают вас с Bitrix24 AI и Yandex AI Studio. Историческая параллель - агентства веб-разработки 2010-х, которые выжили как универсальные: их средний чек упал в 7-10 раз.

Применима ли эта логика к РФ в условиях 152-ФЗ и суверенизации стека? Да. Yandex AI Studio, GigaChat и RetailCRM решают вопрос локализации и соответствия регулированию внутри управляемой платформы - то есть суверенизация сама по себе ускоряет товаризацию, потому что выбивает у универсального интегратора один из сильных аргументов.

Что делать сейчас, если вы — средняя универсальная студия? Выбрать одну отрасль из тех, где уже есть 2–3 проекта. Закрыть в ней 1–2 операционных боли до измеримого результата. Переформулировать абонемент в обязательство по бизнес-результату. И в течение 12 месяцев накопить отраслевой контекст.

Команда из двух инженеров и одного оператора, ведущая трёх клиентов на ретейнере по 300–500 тыс. ₽ в месяц в одной вертикали, выходит на годовую выручку 10–18 млн ₽ с операционной маржой 55–65%. Та же команда, поднявшая seed-раунд $500K–1M на 15–20% долей, получает примерно тот же кэш на счёте, но другой набор обязательств: рост в 3–5 раз за 18 месяцев, найм, борд, отчётность. В 2025–2026 годах venture-фонды посеяли в B2B AI рекордные суммы — по данным Crunchbase на ранние стадии AI пришлась рекордная доля seed-капитала в США, — и обычная медианная дилюция на seed для B2B AI остаётся в коридоре 15–22%. Арифметика простая: при выходе $20M по сценарию ретейнер-модели основатели держат 100%, при том же выходе после двух раундов — около 45–55%. Чтобы оправдать второй сценарий, исход должен быть кратно больше первого, и желательно — реалистично кратно.

Где модель ретейнера переигрывает раунд

Главный аргумент в пользу bootstrapped-пути для вертикального B2B AI лежит не в идеологии, а в структуре издержек. Современный AI-стек 2026 года сместил инженерную плотность вниз, к платформам: harness, память, оркестрация, маршрутизация инструментов теперь продаются как managed-сервисы тремя крупнейшими провайдерами. Команда, которая ещё в 2023 году тратила полгода на собственный orchestration-слой, теперь собирает его за неделю. Это меняет сам смысл «масштабирования»: то, что венчурный фонд оплачивает как «инженерный найм», у вертикального игрока схлопывается в две лицензии и одного техлида.

При этом ретейнер 300–500 тыс. ₽ в месяц в нишевом сегменте перестал быть экзотикой. На смежных рынках — vertical SaaS, специализированные сервисы — устойчиво держится наблюдение, что узкая ниша платит премию 30–40% к универсальному продукту, потому что универсальный не закрывает граничные случаи. Jason Cohen, построивший за двадцать пять лет два «единорога» (один bootstrapped, один venture-funded), формулирует это в серии эссе про стратегию одной фразой: bootstrapping — это не отсутствие капитала, это другая теория роста, в которой клиент платит за компанию через выручку, а не через раунд. И в этой теории первая задача — не «найти продакт-маркет фит», а удерживать узкую нишу достаточно долго, чтобы отчуждаемые ноу-хау превратились в неотчуждаемое представление о вертикали.

Почему bootstrapping в B2B AI — стратегия, а не нехватка?

Стоит сразу разделить два понимания. Bootstrapping как нехватка — это «у нас не получилось поднять раунд, мы крутимся как можем». В этом прочтении ретейнер выглядит бедной альтернативой — вынужденной формой выживания без инвесторского ресурса. Bootstrapping как стратегия — это сознательный выбор: оптимизировать ожидаемую долю основателя в исходе, а не темп роста. Эти траектории различаются не объёмом выручки, а тем, какая переменная считается константой. Венчурная компания фиксирует темп и подбирает капитал; bootstrapped-команда фиксирует капитал и подбирает темп под устойчивые unit-economics.

Для B2B AI это различие усилено двумя факторами 2026 года. Первый — себестоимость инфраструктуры падает быстрее, чем растут потребности, так что capex-аргумент в пользу раунда («нам нужны деньги, чтобы построить продукт») у вертикальной команды слабый. Второй — exit multiples в B2B SaaS вернулись к 4–6× ARR на средних чеках, что делает арифметику долей решающей: выход $30M даёт основателю-100% в три раза больше, чем основателю-33% после трёх раундов. Эту арифметику любят прятать за разговорами про «мы строим что-то большое», но она железна.

Что меняет вертикальная ниша

Тезис «ретейнер сильнее раунда» работает не везде. Он работает там, где у клиента есть структурный switching cost к смене поставщика, а у поставщика — реалистичный путь его создать без масштабирования. Forbes в эссе The Moat Is Moving формулирует это сжато: в 2026 защитимыми остаются три слоя — институциональный регламент клиента, данные траекторий «вход → решение → исход» и глубокая интеграция в окружение. Все три слоя строятся через работу внутри клиента, не через найм.

Здесь важная деталь, которую обычно пропускают сторонники венчурной модели. Эти три слоя нельзя купить через найм быстрее, чем через работу. Команда из двадцати инженеров не построит world model вертикали быстрее, чем команда из двух — потому что узким местом является не инженерный труд, а доступ к реальным операциям клиента. Foundation Capital в эссе Service-as-Software описывает это как «кодификацию экспертизы»: продаётся не инструмент, а готовая работа, и качество готовой работы определяется глубиной погружения, а не размером команды.

Из этого следует операционная арифметика, которая редко звучит в инвестиционных дисках. Если три клиента в одной вертикали приносят 12–18 млн ₽ в год при марже 55–65%, и каждый следующий клиент в той же вертикали даёт компаундирующий эффект на discovery следующего, то предельная стоимость пятого клиента в воронке оказывается ниже, чем первого. Это — обратная сторона CAC-кривой, которой нет у компании, продающей универсальный продукт. У вертикального игрока CAC падает с глубиной ниши; у горизонтального — растёт.

Этот эффект перекликается с тезисом о том, что в 2026 году валентность харнесса и операционного слоя разошлась: инфраструктурный слой (managed orchestration, agent runtimes, vector storage) коммодитизировался, а операционный — представление клиента, его регламент и история решений — остался в руках того, кто работает внутри. Для бутстрап-команды это означает, что она играет на правильной стороне рынка: стоимость создаётся в работе с клиентом, а не в развороте платформы. Чем ближе команда к операциям клиента, тем сильнее её позиция. Капитал здесь не ускоряет работу — он либо переплачивает за ту же работу (больше людей на тот же клиент), либо пытается параллелизировать выход в новые вертикали раньше, чем рынок этого хочет. Первое размывает маржу, второе ломает глубину и откатывает команду к средним отраслевым показателям из венчурного сценария.

Арифметика дилюции и реалистичные исходы

Стандартный seed-раунд для B2B AI команды без revenue в 2025–2026 годах в Соединённых Штатах — это 15–22% дилюции по верхней границе. Если за seed следует Series A на 18–24% и затем поздние раунды плюс option pool, типовой основатель к моменту exit держит 25–40%. Harvard Business Review ещё в Six Myths About Venture Capitalists показал, что медианная доходность венчурного фонда в долгосрочном горизонте находится примерно на уровне публичного рынка; это значит, что распределение исходов сильно скошено: единицы возвращают фонд, остальные не возвращают. Для основателя это переводится в строгий язык: венчурный путь оправдан только если ваш ожидаемый исход кратно больше bootstrapped-исхода с поправкой на дилюцию.

Конкретно. Если bootstrapped-сценарий реалистично выводит на ARR 30–50 млн ₽ за три года при 100% доле, ожидаемая стоимость доли основателя при выходе — порядка 120–250 млн ₽. Чтобы венчурный сценарий обогнал, при доле 30% после раундов компания должна стоить 400–800 млн ₽. Это не невозможно, но это — статистический отлёт, не базовый сценарий, и в B2B AI 2026 года таких выходов в России единицы. Для большинства команд второй сценарий хуже первого по математическому ожиданию, и это вопрос арифметики, а не самооценки.

Отдельный аргумент — структура власти после раунда. Сообщество Indie Hackers последние три года систематически документирует обратную сторону венчурной сделки: сменяемость планов, давление на найм, разрыв между темпом роста, который требует фонд, и темпом, который выдерживают unit-economics. Bootstrapped-команда оптимизирует под одного клиента; venture-команда вынуждена оптимизировать под третий и пятый раунды, которых ещё нет. Эта разница в горизонте формирует, какие решения вообще можно принимать.

Как удерживать ретейнер дольше CFO-сезона

Ретейнер-модель работает только при ответе на вопрос «что будет на 6-й и на 12-й месяц». В B2B AI churn концентрируется в двух окнах: месяц 4–6 («wow wore off», champion leaving, внутренние команды клиента считают, что справятся сами) и месяц 7–12 (бюджетный пересмотр, AI-fatigue, накопленные подписки, давление CFO). На западных рынках бенчмарк здоровой компании — Harvey в legal AI: gross revenue retention 98%, net dollar retention 167% при firmwide adoption и более ста новых функций в квартал. На российском рынке таких бенчмарков пока нет, и это означает, что играют сильнее не те, кто занимается «развитием продукта», а те, кто строит switching cost внутри клиента.

Технически это сводится к трём слоям. Первый — workflow-замок: команда клиента ведёт работу через контур поставщика, не возвращаясь к старым таблицам и переписке. Второй — слой представления: какие сущности первичны, какие у них статусы, что считается дублем, что — исключением. Этот слой команда поставщика может выгружать как отдельный артефакт, и без него любая попытка перевести операции к конкуренту разрушает половину истории. Третий — траектории решений: закрытый цикл «вход → решение агента → исход через дни или недели». Эти данные нельзя восстановить копированием промпта, потому что они привязаны к конкретным операциям конкретного бизнеса.

Bootstrapped-команда в этой модели имеет неочевидное преимущество. Венчурный игрок вынужден агрессивно расширять воронку, ставит цели по логотипам и теряет внимание к глубине внутри каждого клиента. Команда, у которой клиент = 20–30% выручки, вынуждена делать обратное: каждое внедрение — это инвестиция в multi-year retention, и качество слоя представления у такого игрока выше по структурным причинам.

Тёплая сеть как канал, а не как недостаток

Стандартный аргумент против bootstrapped-модели звучит так: «без капитала вы не построите воронку». Это утверждение основано на предположении, что воронка строится через performance-маркетинг, а не через сеть. В B2B AI 2026 года это предположение чаще ложно, чем истинно. Реферальные лиды конвертируются в три–четыре раза выше, чем платный трафик; B2B-команды, заходящие через тёплый контакт, имеют существенно более короткий sales-цикл и существенно более высокий retention в первые шесть месяцев. Эту картину последовательно показывают и западные публикации, и наблюдения в нишевых российских вертикалях, где первый клиент чаще приходит через рекомендацию, чем через холодный контакт.

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

Что это значит для технического основателя сегодня

Для команды, выбирающей между поиском seed-инвестора и поиском второго клиента весной 2026, полезно прогнать четыре проверки. Первая — на чём вы держите тезис о росте. Если он держится на «нам нужно собрать команду из 15 человек, чтобы построить продукт», стоит честно ответить, какая часть этой команды в 2026 году заменяется managed-сервисами и одной лицензией. Вторая — кто платит за время. В bootstrapped-модели за время платит клиент, через ретейнер; в венчурной — фонд, через дилюцию. Это разные обязательства и разная свобода маневра.

Третья проверка — структура moat. Если ваш moat — это институциональный регламент клиента, данные траекторий и интеграция в его окружение, размер команды не делает moat быстрее. Он делает только дороже. Четвёртая — вероятность исхода. Bootstrapped-сценарий с 3–5 клиентами в одной вертикали через три года выходит на ARR, который реально продаваем стратегу или PE-фонду, и эта продажа возвращает основателю 100% доли. Венчурный сценарий требует исхода в три–шесть раз больше, чтобы окупить дилюцию. На большинстве рынков B2B AI в 2026 году этот множитель находится в области статистических хвостов.

Для рынка в целом это значит, что роль вертикальных AI-команд недооценена. Венчурный нарратив 2024–2025 годов сделал «горизонтальные платформы» главным жанром, в котором ходили деньги. К 2026 году видно, что значительная часть прикладной ценности AI создаётся не там. Jack Dorsey в акционерном письме Block написал в феврале 2026, что «инструменты интеллекта изменили, что значит строить и управлять компанией», и сократил 4 000 позиций. Это иллюстрация большего сдвига: компании больше платят за готовую работу, не за инструмент. Готовую работу делают вертикальные команды. Венчурный капитал на горизонтальном уровне работает плохо.

Стоит отметить, что эта логика не уникальна для AI. Jason Cohen в разборе product-market fit и в колонках по стратегии startup систематически показывает, что интересы фонда и интересы основателя оптимизируют разные функции полезности: фонд — распределение исходов по портфелю и «fat tail»-выбросы, основатель — ожидаемую долю в одном конкретном исходе своей компании. Эти функции совпадают только в узком коридоре hyper-growth-ставок, который в вертикальном B2B AI 2026 выпадает редко. Для основателя, оптимизирующего ожидаемую долю, рациональным является режим среднего роста, высокой маржи и отсутствия размывающего капитала. Ретейнер-модель в нише — довольно точный инструмент для именно этого режима.

Главное

• Для вертикальной B2B AI команды в 2026 году путь к 10–18 млн ₽ ARR через 3–5 ретейнер-клиентов даёт более высокую ожидаемую долю основателя в исходе, чем seed-раунд $500K–1M c дилюцией 15–22%, при сопоставимом кэше на счёте.
• Падение себестоимости harness-слоя (managed-сервисы Anthropic, OpenAI, Google, AWS) уничтожило capex-аргумент в пользу раунда: масштабирование команды больше не строит moat быстрее, чем работа внутри клиента.
• Switching cost в B2B AI создаётся в трёх слоях — workflow-замок, слой представления, траектории решений — и все три строятся через глубину, а не через найм.
• Bootstrapped-команда структурно лучше удерживает ретейнер: 20–30% выручки в одном клиенте создают давление на качество слоя представления, которого нет у венчурного конкурента.
• Тёплая сеть и реферальный канал в нишевых вертикалях обгоняют performance-маркетинг по конверсии и retention, что снимает главный аргумент против bootstrapped-модели — «нет денег на воронку».

FAQ

Когда раунд всё-таки имеет смысл? Когда продукт действительно горизонтальный, требует синхронного масштабирования инфраструктуры с ростом клиентской базы, и где скорость выхода на рынок критична из-за окна возможностей. В вертикальном B2B AI с retainer-моделью таких условий обычно нет.

Что если клиент уйдёт через 6 месяцев? Это самый болезненный риск ретейнер-модели и единственный, который нужно решать инженерно, а не финансово. Окно churn концентрируется в месяцах 4–6 и 7–12. Защита строится через интеграцию в ежедневный workflow клиента, накопление траекторий с первого дня и проактивный ROI-обзор за месяц до бюджетного пересмотра.

Можно ли вырасти за пределы 3–5 клиентов без раунда? Да, до 10–15 клиентов в одной вертикали при команде 4–6 человек — это устойчивый сценарий при марже выше 50% и реинвестировании в найм. Дальнейший рост требует либо прихода второго оператора (партнёра), либо осознанного перехода в платформенную модель — и тогда обсуждение раунда становится содержательным, потому что у компании уже есть данные траекторий и доказанный retention.

Как продать компанию из bootstrapped-модели? Стратегу или PE-фонду по мультипликатору 4–6× ARR. Главный фактор оценки — качество retention и глубина switching cost, а не темп роста. Компания с 25 млн ₽ ARR при net dollar retention 110%+ и gross revenue retention 90%+ продаётся лучше, чем компания с 50 млн ₽ ARR при тех же метриках на уровне 95% и 75% соответственно.

Что показывает расписание команды из трёх человек

В одной агентной команде, наблюдаемой с весны 2026, GitHub Issues открывают примерно раз в неделю. Расписание (crontab) смотрят каждый день. В нём 23 активные записи: проверка воронки в 9:00, ночной дайджест исследований в 02:00, проверка состояния агентов каждые два часа, еженедельный отчёт по базе знаний в понедельник в 7:30. Полный список покрывает примерно 80% работы, которая физически происходит в компании за неделю.

Доска задач у той же команды содержит шесть активных карточек. Из них три не двигаются больше двух недель. Это не проблема дисциплины и не «надо подтянуть процессы». Это структурный сдвиг: дискретные задачи перестали быть основной единицей операции. Основной единицей стало расписание.

Почему дорожная карта перестаёт отражать реальность

В классической компании дорожная карта — это карта работы. У каждого проекта есть начало, конец, владелец, определение готовности. Если хочется понять, чем занят бизнес, достаточно посмотреть в Jira: список карточек примерно равен списку текущей работы.

В компании на агентах эта карта систематически врёт в сторону недооценки. Большая часть операции выполняется не как набор тикетов, а как набор повторяющихся циклов, которые запускаются сами и завершаются сами. Никто не открывает карточку «прогнать дайджест исследований за вчера» — эту работу делает агент по расписанию. Никто не назначает владельца для «проверить здоровье воронки» — владелец это 0 9 * * *. Сторонний наблюдатель видит шесть карточек и делает неправильный вывод: «команда мало делает». А команда за то же время выполнила 140 запусков процедур, из которых 12 потребовали человеческого вмешательства.

Этот разрыв растёт по мере того, как управляемый контур исполнения (managed harness) становится стандартной частью стека. Платформы агентов — публичные материалы Anthropic Engineering, анонс OpenAI про новые инструменты для агентов, AWS Bedrock Agents — сводят стоимость запуска новой процедуры к одному файлу настроек. Это значит, что центр операционной массы быстро смещается от «человек делает задачу» к «расписание запускает агента, человек смотрит исключения». При таком распределении дорожная карта перестаёт быть основной картой работы — она становится картой исключений.

Похожий сдвиг уже случался в инженерии данных. dbt-core и Apache Airflow превратили аналитику из «возьмите тикет, напишите запрос» в «определите модель, она пересчитывается по расписанию». Граф зависимостей расписания (directed acyclic graph, DAG) стал документом, который точнее описывает работу команды данных, чем проект в Jira. Компания на агентах повторяет эту траекторию на уровне всей организации, не только аналитики.

Что меняется, когда работа становится расписанием?

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

Эта таблица не означает, что одна парадигма «лучше» другой. У них разные первичные объекты. В компании, где 80% работы — повторяющиеся циклы, описывать её через доску задач — то же самое, что описывать работу аналитической команды через тикеты «написать SQL»: формально можно, операционно — теряет половину сигнала.

Где живёт работа в компании на агентах

Если открыть условное расписание агентной команды, оно распадается на три слоя.

Первый слой — наблюдательные процедуры. Циклы, которые периодически снимают состояние мира: воронка, продажи за сутки, состояние клиентского контура, свежие сигналы из исследований, ошибки в продакшене. Они не производят решений, они производят структурированный снимок. Этот снимок потом потребляется либо человеком, либо следующей процедурой. У наблюдаемой команды на этот слой приходится примерно треть записей расписания.

Второй слой — решающие процедуры. Циклы, в которых агент применяет регламент (SOP): запускает повторный контакт, эскалирует зависшие тикеты, помечает устаревшие документы, переоценивает приоритеты задач. Это та работа, которая в классической компании размазана по людям и редко документируется явно. В агентной компании она кодифицирована — потому что иначе её не запустить по расписанию. Здесь живёт основной операционный слой компании, тот самый, про который мы писали в заметке про harness как товар: институциональный регламент перестаёт быть документом и становится исполняемой политикой.

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

Все три слоя имеют общее свойство: они описываются расписанием. Не «когда сделаем», а «когда запускается». Логика проекта «у задачи есть начало и конец» к ним применяется плохо. Их жизнь — это не движение от старта к финишу, а пульс. Поэтому расписание точнее описывает, что делает компания, чем дорожная карта.

Почему расписание — это политический документ

В классической компании главный политический документ — дорожная карта. Она отвечает на вопрос «что мы делаем в этом квартале» и согласовывается днями, потому что от неё зависит, что инвестор увидит на следующей встрече и что команда будет делать в понедельник. В компании на агентах главный политический документ — расписание.

Каждая запись в расписании — это явное утверждение: «эта работа достаточно важна, чтобы запускать её каждый день, час или неделю автоматически, даже если никто не просил». Добавление записи — это решение примерно того же веса, что найм человека: запись будет работать, потреблять ресурсы и производить выводы, пока её явно не выключат. Удаление записи — это решение примерно того же веса, что увольнение: что-то, что компания делала каждый день, перестаёт делаться, и последствия проявятся через недели.

Из этого следует операционная гигиена, которая в классической компании не нужна, а в агентной — критична. Каждая запись в расписании должна иметь явного владельца-человека, документированную цель, явный результат (куда пишется вывод) и явные условия деактивации. В наблюдаемой команде такой реестр живёт как отдельный документ; без него за полгода накапливается «долг расписания» — записи, про которые никто уже не помнит, зачем они нужны, но они продолжают что-то писать в файлы и иногда что-то ломать.

Переход от прототипов к продакшен-системам в индустрии агентов — это переход к надёжности и наблюдаемости, не к новым функциям. Применительно к агентам продакшен — это надёжное расписание плюс мониторинг исключений. Агентная организация делает то же самое на уровне организационного дизайна: расписание становится первоклассным объектом управления, а не служебной деталью.

Почему cron, а не очереди событий?

Резонный вопрос: если работа повторяется, почему не описать её как реактивную систему — очереди, события, вебхуки? Событийная архитектура отлично работает там, где есть внешний триггер: пришёл клиент, изменился документ, упал сервис. Но большая часть операционного слоя агентной компании запускается не от внешнего события, а от внутренней необходимости периодически проверять состояние мира. Никто не присылает вебхук «пора провести аудит базы знаний». Эти процедуры инициируются временем, а не данными.

Как отмечает Andrej Karpathy в публичных выступлениях про операционные особенности агентов:

«Большинство интересной работы агента — это не реакция на пользователя, а его собственный внутренний цикл размышления и проверки.» — Andrej Karpathy, ex-Director of AI, Tesla

Если этот цикл живёт в коде, его естественная форма — расписание. Очереди событий хороши как транспорт между процедурами, но не как замена самим процедурам. На практике агентный стек обычно сочетает обе модели: cron инициирует «такт сердца», очереди и долговечное исполнение платформы вроде Temporal обеспечивают надёжность отдельных шагов внутри. Расписание задаёт ритм; очереди — связность.

Журнал событий показывает, что произошло; расписание — что компания делает всегда.

Как отличить этот сдвиг от обычного DevOps?

Существует контраргумент: «запланированные задачи всегда были, это просто DevOps в новой обёртке». Контраргумент верен наполовину. Технически — ничего нового. Концептуально — отличие в статусе и составе того, что попадает в расписание.

В классическом девопс-сценарии в расписании живут служебные задачи: ротация логов, бэкап базы данных, проверки здоровья инфраструктуры. Это «системные функции», их пишут инженеры по надёжности, они редко обсуждаются на продуктовых синхронах. Процедура ничего не решает за бизнес; она поддерживает существование системы.

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

Эту разницу хорошо описывают практики наблюдаемости агентских систем. Как пишет Charity Majors в блоге Honeycomb, наблюдаемость нужна не за инфраструктурой, а за поведением системы — и в агентной операции это означает наблюдаемость за тем, что процедура реально делает с бизнесом, а не только за тем, что процесс не упал. Тот же сдвиг описан и в материалах Мартина Фаулера про эволюционную архитектуру и в практиках инженерии надёжности из Google SRE Book: когда поведение системы определяется не одним релизом, а постоянным фоном изменений, главным артефактом становится механизм этих изменений, а не их слепок.

Как говорит Charity Majors:

«Наблюдаемость нужна, чтобы задавать системе новые вопросы в продакшене, а не подтверждать заранее известные.» — Charity Majors, CTO, Honeycomb

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

Что это меняет для трёх типов читателей

Фаундер. Если на питче инвестор спрашивает «расскажите про дорожную карту», полезный второй ответ — «вот наше расписание». Не вместо, а вместе. Разговор сдвигается от будущих обещаний к тому, что компания делает каждый день уже сейчас и где живут точки контроля. Тестовый вопрос: можете ли вы за 60 секунд показать список из 10–20 процедур с явным владельцем и явным результатом? Если ответ «у нас всё в Jira» — компания операционно не агентная, что бы ни было написано на сайте.

Операционный руководитель. Главная управленческая работа в агентной компании — не приоритизация бэклога, а ревью расписания. Раз в две недели — пройти по расписанию или планировщику, отметить каждую запись как «оставляем», «удаляем», «меняем триггер», «передаём другому владельцу». Это занимает 30–60 минут и заменяет несколько часов планирования спринта. Тестовый вопрос: знаете ли вы, какая запись в расписании за последние два месяца ни разу не привела к человеческому действию? Если знаете — это либо ценная защита от ложноотрицательного, либо мёртвая процедура, которую пора удалять. Если не знаете — у вас нет наблюдаемости над собственной операцией.

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

На какие сигналы смотреть дальше

Несколько публичных индикаторов покажут, насколько сдвиг становится массовым. Первый — появление в основных инструментах управления проектами (Linear, Jira, Asana) явной поддержки «повторяющейся задачи агента» как отдельного типа сущности, наравне с тикетом и проектом. Когда станет встроенной концепцией, формализация «расписание как объект управления» закрепится. Второй — публичные кейсы компаний, которые ведут открытый список своих процедур как часть страницы «about/engineering». Это агентный эквивалент «we use Postgres and Kubernetes». Третий — рост MRR у инструментов класса оркестратор-для-агентов, заточенных не под конвейеры данных, а под рабочие потоки агентов.

Если эти сигналы придут в ближайшие 12 месяцев, операционный язык индустрии успеет перестроиться. Позже — фаундеры, которые уже строят компанию вокруг расписания, получат окно фор-старта. Главный вопрос один: что у вас в расписании завтра в 9 утра, и почему именно это.

Главное

• В компании на агентах основная единица работы — повторяющаяся процедура, а не дискретная задача. Дорожная карта отражает исключения; расписание отражает реальность.
• Расписание распадается на три слоя: наблюдательные, решающие, поддерживающие процедуры. Все три описываются расписанием, не сроками.
• Расписание — политический документ. Добавление записи — это решение масштаба найма; удаление — масштаба увольнения.
• Управленческая работа смещается от приоритизации бэклога к регулярному ревью расписания. Без этого появляется «долг расписания».
• Расписание точнее показывает, чем компания реально занимается каждый день, чем любая дорожная карта или доска спринта.

FAQ

Это значит, что управление проектами больше не нужно в агентной компании?

Нужно, но в другой форме. Проекты остаются для дискретных инициатив с началом и концом — запуск нового продукта, миграция, исследование вертикали. Просто проекты больше не описывают всю работу. Они описывают исключения над расписанием. Соотношение в наблюдаемых командах — примерно 20% работы в проектах, 80% в процедурах.

Что если бизнес по природе плохо ложится на расписание — например, консалтинг или редкие сделки?

Тогда часть работы остаётся в проектах, как и раньше. Но даже в таких бизнесах наблюдательный и поддерживающий слой обычно поддаётся логике расписания: ежедневный сбор сигналов о клиентах, еженедельный аудит воронки, ночная синхронизация CRM. Процедура не обязана охватывать ядро бизнеса, чтобы быть основным операционным артефактом — достаточно, чтобы она покрывала большую часть повторяющейся работы вокруг ядра.

Чем задача в расписании отличается от обычной запланированной задачи, которая и в классических компаниях есть?

Технически — ничем. Концептуально — статусом. В классической компании запланированные задачи — служебная деталь, спрятанная в DevOps. В агентной компании расписание поднято на уровень операционного артефакта: оно документировано, обсуждается на синхронах, имеет явных владельцев и реестр. Сдвиг — не в технологии, а в том, что считается «настоящей работой».

Как защититься от «долга расписания» — записей, которые никто не помнит, зачем нужны?

Минимум три практики: регулярное ревью расписания (раз в две недели достаточно), явный владелец и описание для каждой записи в едином реестре, и метрика «когда запись последний раз привела к действию». Записи, которые полгода ничего не запускали, — кандидаты на удаление. Это та же дисциплина, что в кокпите фаундера: операционный слой работает только если за ним есть петля проверки здоровья.

Можно ли называть компанию агентной, если у неё в расписании пять записей и команда из 50 человек?

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

Что отличает хорошую процедуру от плохой?

Хорошая процедура идемпотентна (можно безопасно перезапустить), имеет явный результат в наблюдаемое место (файл, дашборд, канал), имеет явный запасной вариант при ошибке (тихо в лог, не падает на пользователя) и имеет владельца-человека, который получит сигнал, если процедура начнёт врать. Плохая процедура — это скрипт, про который через три месяца невозможно ответить, что он делает и куда пишет результат.

Апрельский квартал, в котором провайдеры стали заменимы

8 апреля 2026 года Anthropic выпустил Managed Agents — managed execution loop, persistent memory через /memories, sandboxing и multi-agent orchestration. В тот же месяц OpenAI отгрузил AgentKit с визуальным Agent Builder, Connector Registry и встроенными Evals. Сбер на портале GigaChat API держит публичную тарификацию по пакетам токенов и три варианта развёртывания — облако, гибрид, on-prem. Yandex Cloud в Foundation Models собрал YandexGPT в одну линейку с Object Storage, Logging и managed-инфраструктурой.

Между этими четырьмя анонсами есть общая черта, которую обзоры обычно проходят мимо. Все четыре провайдера в 2026-м продают не модель, а стек: контракт API, managed orchestration, memory, observability. И как только стек становится частью продукта, цена ошибки выбора смещается с цены токена на стоимость переезда между стеками. Ровно поэтому сравнительные таблицы «GigaChat vs YandexGPT vs Claude» в 2026-м измеряют не то, что определяет экономику решения через год.

Дешевизна моноархитектуры — в долг

Базовый сценарий 2026-го у российской B2B-команды выглядит так. Команда выбирает одного провайдера — обычно по сочетанию цены, 152-ФЗ и удобства существующей инфраструктуры — и собирает на нём всё: парсинг входящих, классификацию, агентов с инструментами, summarisation. Это моноархитектура. Она экономит инженерные часы на старте: одна авторизация, один SDK, один формат tool calling, одна managed-память.

Контр-тезис: моноархитектура не дешевле — она дешевле в первый год. На втором году стоимость моноархитектуры — это стоимость миграции, и она конечна, измерима и обычно недооценена. Migration debt появляется не от плохого выбора, а от того, что любая моноархитектура жёстко связывает четыре независимых решения: формат структурированного вывода, протокол tool use, схему памяти и operations-контур. Когда хотя бы одно из четырёх перестаёт устраивать, переезжать приходится сразу всем стеком.

Альтернатива — роутер: внешний слой, который маршрутизирует запросы между провайдерами по типу нагрузки, чувствительности данных и стоимости. Роутер дороже в первый год — нужен evaluator-харнесс, единая schema domain-объектов, контракты между prompt-цепочкой и моделью. Но он линейно масштабирует решения второго года: смена одного провайдера меняет конфиг, а не архитектуру. В терминах предыдущей заметки про harness commodity, роутер — это та часть operating layer, которую provider-стеки в 2026-м начали поглощать, и которую командам выгодно не отдавать вверх по стеку без явного обмена.

Четыре стыка, на которых ломается моноархитектура

Чтобы увидеть, где конкретно моноархитектура накапливает долг, удобно смотреть не на «провайдеров вообще», а на стыки между подсистемами стека.

Structured output: формат входит в каждый prompt

OpenAI в Function Calling с 2023-го фиксирует контракт, при котором модель возвращает строго типизированный JSON по объявленной схеме. Anthropic в tool use реализует тот же контракт через tool_choice и явные input schemas. Это два формата, которые внешне делают одно и то же, но различаются в деталях: имена полей, форма передачи schema, поведение при несоответствии. На стороне Сбера механизм function calling в портале GigaChat API и сопровождающих технических разборах SberDevices на Хабре представлен своим интерфейсом; у Yandex — своим.

Команда, которая выбрала одного провайдера, кодирует именно его формат в каждый prompt и каждый валидатор. Через год, когда возникает сценарий с другим провайдером — например, reasoning-задача, где Claude даёт лучший результат на тех же примерах — миграция перетряхивает все места, где формат tool calling зашит. Это не «переписать промпты», это переписать тесты, евалуаторы, ретраи и логирование.

Команда с роутером изначально держит структурированный вывод как domain-объект, а формат провайдера — как адаптер; миграция меняет адаптер. Конкретно это значит, что в репозитории есть два уровня: типизированные классы доменных объектов (карточка клиента, событие, эскалация, статус) — независимые от провайдера, и тонкий слой провайдер-специфичного кода, который только переводит между этими классами и форматом конкретного API. На длинных горизонтах поддержка двух адаптеров обходится дешевле одного жёстко прошитого формата, потому что оба адаптера обязаны проходить один и тот же evaluator-харнесс.

Tool use: orchestration провайдера против внешнего роутера

Anthropic в инженерной заметке про Managed Agents формулирует суть managed-подхода: «self-evaluates and iterates until it reaches a result» — это описание execution loop, в котором провайдер берёт на себя оркестрацию и возвращает вызывающему коду только финальный результат. OpenAI в AgentKit даёт визуальный Agent Builder с Connector Registry и встроенными Evals. Это два разных способа упаковать одну и ту же задачу: длинная цепочка вызовов инструментов с возвратом контроля внешнему коду. Российские провайдеры в публичных материалах 2026-го тоже движутся в эту сторону, но с разной плотностью документации и разной зрелостью контракта на длинных горизонтах.

Команда, которая поверила, что «agent harness — это просто фича провайдера», и спроектировала flow внутри managed-конструкции, на втором году получает классическую vendor lock-in проблему. Смена провайдера здесь — это не «переключить ключ», это переписать саму форму orchestration: где живёт состояние, как оформлены retry, кто owns memory между шагами, как описан контракт инструмента. У каждого провайдера эти ответы разные, и в managed-продукте они зашиты в SDK, а не в коде команды.

Команда с внешним роутером — наоборот, держит orchestration снаружи, а провайдерский harness использует только там, где экономия на инфраструктуре оправдывает связанность. На практике это означает, что роутер берёт на себя три роли: классификатор запроса по типу нагрузки и чувствительности данных, владелец схемы domain-объектов и evaluator. Managed harness провайдера в такой архитектуре — один из исполнителей, не источник правды.

152-ФЗ как архитектурный, а не комплаенс-вопрос

Большинство обзоров обсуждают 152-ФЗ как фильтр между двумя множествами провайдеров: «российские можно, зарубежные нельзя для ПД». Это правда, но это не самый интересный уровень. Архитектурный уровень — что именно в стеке считается «обработкой ПД», и где проходит граница изоляции.

Документация GigaChat API предлагает три варианта развёртывания: облако Сбера, гибрид с данными на стороне клиента, on-prem. Yandex Cloud Foundation Models даёт data residency «в РФ» как умолчание. Команда, которая делает 152-ФЗ-чувствительный продукт на моноархитектуре одного из этих провайдеров, имплицитно принимает решение: весь продукт работает в одном комплаенс-периметре. На горизонте года это означает, что если в продукт добавляется задача, требующая reasoning-возможностей зарубежной модели — а такие задачи в 2026-м появляются регулярно — переезд требует разделить пайплайн на ПД-чувствительный и обезличенный, что архитектурно эквивалентно построению роутера задним числом, только в стрессе и под deadline.

Команда, которая с самого начала проектировала разделение по чувствительности данных как отдельную ось маршрутизации, ту же задачу решает добавлением ветки. 152-ФЗ перестаёт быть constraint на выбор провайдера и становится одним из measurable атрибутов запроса.

SLA и поведение под нагрузкой

У Anthropic и OpenAI публичные status-страницы и rate-limit-политики, описанные на уровне tier’ов. У GigaChat и Yandex Cloud публичная часть SLA на инференс LLM в 2026-м заметно беднее — корпоративные условия идут в индивидуальных договорах. Это не утверждение про качество, это утверждение про объём публичной информации, на которую может опираться внешний выбор.

Моноархитектура на любом из четырёх провайдеров делает SLA провайдера потолком SLA продукта. Если у провайдера падает регион или меняется rate-limit-политика, продукт деградирует синхронно, без степеней свободы. Роутер — наоборот, делает SLA продукта функцией политики маршрутизации: при деградации одного провайдера запросы уходят на резерв, latency p95 поднимается, но контур не останавливается. Цена этой устойчивости — поддерживать как минимум двух работающих провайдеров и единый evaluator-харнесс, на котором обе стороны проверяются на одинаковом наборе кейсов. Дешёвой эта устойчивость не бывает; вопрос в том, что обходится дороже — её отсутствие или её содержание.

На фоне этого Сбер в карточке GigaChat API пишет о ·«едином API для приложений и агентов», это сигнал: российские провайдеры движутся в ту же сторону. Как отмечают в блоге SberDevices, «функциональный вызов и инструменты — это не фича, а основной режим работы модели в production-контуре» — формулировка, которая почти дословно повторяет Anthropic и OpenAI. Одна и та же идея, реализованная четырьмя разными способами, и каждый из этих способов — будущая точка миграции.

Конкретные тесты для трёх ролей

Для CTO. Возьмите три задачи из текущего бэклога: одну со structured output, одну с tool use на 5+ шагов, одну с длинным контекстом. Зафиксируйте, в скольких местах кода и в скольких тестах прописан конкретный формат текущего провайдера — имена полей tool calling, формат сообщений, идентификаторы моделей. Если число таких мест превышает несколько десятков на одну задачу, у вас моноархитектура, и стоимость её замены через год — это столько же изменений, помноженное на число задач. Решение — не «срочно мигрировать», а вынести формат провайдера в адаптер и держать domain-объекты типизированными.

Для Head of Product. Запишите, какие фичи продукта зависят от поведенческих гарантий конкретного провайдера: структуры JSON, длины контекста, поведения tool calling на длинных горизонтах. Если таких фич больше трёх и все они сидят на одном провайдере, продукт зависит от его roadmap’а сильнее, чем от собственного. Тестовый сценарий: если завтра ваш текущий провайдер поднимет цену на 30% или удалит конкретную фичу — какие функции продукта перестают работать в течение недели. Это и есть продуктовая стоимость моноархитектуры, выраженная в feature-availability.

Для Tech Lead. Постройте один проект так, чтобы провайдер был заменим: единая schema domain-объектов, адаптеры под форматы провайдеров, evaluator-харнесс на 200–500 типичных кейсов с эталонными ответами. Это инвестиция в недели, а не в дни. Признак, что харнесс реальный, а не на бумаге: вы можете прогнать новую модель на нём за ночь и получить численный ответ — лучше, хуже, на каких подмножествах. Без такого харнесса любая дискуссия о смене провайдера ведётся в терминах ощущений, что само по себе — диагностика степени lock-in.

Что покажет 2026-й, и какие сигналы стоит фиксировать?

Тренд имеет несколько проверяемых сигналов. Первый — появление managed-роутеров в публичных продуктах: внешних сервисов, которые принимают единый API и сами решают, какому провайдеру отправить запрос. Если такие продукты выходят в GA, моноархитектура становится анахронизмом, а вопрос смещается на политику маршрутизации. Второй — публикация официальных кейсов перевода production-нагрузок между российскими и зарубежными провайдерами без потери качества. Такой кейс — публичное доказательство, что архитектурно стек уже переносим, и оценочная стоимость миграции из моноархитектуры в роутер становится прозрачной величиной. Третий, обратный, — появление команд, которые публично возвращаются с роутера на моноархитектуру, объясняя это операционной сложностью. Это будет означать, что граница применимости роутера выше, чем сейчас принято считать, и что для значительной части B2B-задач достаточно одного провайдера и грамотных адаптеров.

В любом сценарии вопрос «GigaChat или Claude» — не главный. Он выглядит как закупочный, но за ним стоит архитектурный, и именно архитектурный определяет, сколько будет стоить второй год.

Главное

• Сравнения LLM-провайдеров по цене и фичам в 2026-м воспроизводят ошибку обзоров BPM десять лет назад: они отвечают на закупочный вопрос вместо архитектурного.
• Реальная развилка — моноархитектура или роутер. Моноархитектура дешевле в первый год и дороже на втором за счёт стоимости миграции; роутер — наоборот.
• Стоимость моноархитектуры скрыта в четырёх стыках: формат structured output, протокол tool use на длинных цепочках, граница 152-ФЗ-изоляции, поведение под нагрузкой.
• Минимальная архитектура, которая делает провайдера заменимым: единая schema domain-объектов, адаптеры под форматы провайдеров, evaluator-харнесс на 200–500 кейсов.
• Сигналы 2026-го, на которые стоит смотреть: managed-роутеры в GA, публичные кейсы переноса production-нагрузок, обратные кейсы возврата на моноархитектуру.

FAQ

Чем моноархитектура отличается от vendor lock-in?

Моноархитектура — это осознанный выбор одного провайдера ради скорости в первый год; vendor lock-in — следствие того, что при этом выборе команда не выделила domain-слой, и формат провайдера разлился по всему коду. Можно иметь моноархитектуру без lock-in, если domain-объекты типизированы и evaluator-харнесс реальный — это и есть разница между рабочей сборкой и долгом. Тест: сколько мест в коде нужно изменить, чтобы поменять провайдера? <100 — нормальная моноархитектура. >1000 — lock-in.

Когда роутер — переинжиниринг?

Роутер переинжиниринг, когда в продукте меньше трёх разных типов запросов, нет 152-ФЗ-чувствительных данных и объём инференса ниже ~10 000 запросов в день. Для таких команд правильный путь — один провайдер плюс правильные адаптеры. Роутер окупается от двух и более дифференцирующих факторов: хотя бы две роли LLM в продукте, две зоны чувствительности данных, или два критерия SLA.

Как оценить стоимость миграции с моноархитектуры?

Подсчитайте три числа: (1) сколько prompt-шаблонов содержат провайдер-специфичный формат, (2) сколько тестов предполагают конкретные имена полей tool calling, (3) сколько мест в коде ссылаются на идентификаторы моделей напрямую. Сумма этих трёх чисел, умноженная на ~2 часа на каждое место (типичная оценка для рефакторинга с проверкой тестами), даёт оценку миграционного долга в инженер-часах. Часто получается 500–1500 часов на средний продукт — то есть 3–9 человеко-месяцев.

Что выбрать команде, которая стартует сегодня — моно или роутер?

Стартовать с моноархитектуры на одном из российских провайдеров (152-ФЗ требует РФ-инфраструктуры в большинстве B2B-сценариев), но сразу заложить три инвестиции: типизированные domain-классы (карточка клиента, событие, эскалация), адаптер-слой между ними и API провайдера, evaluator-харнесс на 50–100 кейсов. Это превращает будущий переход в роутер в добавление второго адаптера, а не пересборку. Стоимость этих трёх инвестиций при старте — 2–4 недели, экономия на горизонте 12 месяцев — порядок тех же 500–1500 часов.

Какие задачи в B2B РФ-стеке оправданно отдавать зарубежным моделям через роутер?

Reasoning-задачи на длинных горизонтах (планирование, decomposition сложных кейсов, анализ длинных документов) — у Claude и GPT-5.5 в 2026-м преимущество подтверждается на публичных бенчмарках. Чувствительность данных снижается обезличиванием на стороне роутера: запрос уходит в зарубежную модель без ПД, ответ применяется в РФ-контуре с ПД. Для классификации входящих, summarisation отчётов, генерации шаблонных писем — российские провайдеры в 2026-м конкурентоспособны и выгоднее по стоимости и латентности.

Какую цену обычно недооценивают?

Возьмём бюджет средней vertical-AI-компании, которая обслуживает auto-dealers или SaaS-поддержку: счёт за инференс к Anthropic или OpenAI — порядка $300–500 в месяц на одного активного клиента. Стоимость инженерной работы по описанию того, что в этом конкретном бизнесе считается лидом, какие у него валидные статусы, что считается дублем, кто имеет право пометить сделку как закрытую, — десятки тысяч долларов разовой работы плюс непрерывная доработка. Соотношение 1:100 в пользу схемы, не модели. И именно эта пропорция объясняет, почему вертикальные AI-продукты, проигрывающие на бенчмарках, выигрывают на удержании.

В предыдущей заметке мы констатировали факт: за один квартал четыре крупнейших провайдера схлопнули agent harness в managed-продукт, и сослались на три слоя, которые остались defensible: representation layer, trajectory data, institutional SOP. Эта заметка — глубокое погружение в первый. Мы утверждаем: стоимость переключения вертикального AI-провайдера прямо пропорциональна глубине интеграции representation layer в операционные процессы клиента, а не качеству модели, на которой он работает.

Что именно мы называем representation layer

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

Vertical schema — это representation layer, специализированный под конкретную отрасль: схема для auto-dealers фиксирует, что лид «горячий» при наличии тест-драйва, в SaaS-поддержке — при NPS-сигнале и определённой роли пользователя, в коммерческой недвижимости — при подписанной LOI. Универсальная схема CRM этих различий не делает; vertical schema их кодифицирует, потому что без них агент возвращает правдоподобную, но операционно неверную работу.

Здесь же мы можем зафиксировать ещё два понятия, которые в популярной прессе часто склеиваются. Data moat — это устойчивая разница между тем, что знает про домен ваш продукт, и тем, что знают конкуренты, при условии что разница не воспроизводится за разумные деньги и время извне. И switching cost — это совокупная цена для клиента покинуть текущего вендора: переписать интеграции, восстановить кодифицированные процессы, заново обучить людей и заново накопить операционную историю. У AI-продуктов основной вклад в switching cost даёт не контракт и не стоимость миграции данных, а именно потеря representation layer, которую невозможно «выгрузить в CSV».

Почему модель — заменимая часть стека

Бенчмарки последних восемнадцати месяцев показывают одну и ту же вещь: разрыв между frontier-моделями быстро схлопывается. Anthropic выпустил Managed Agents в апреле 2026 с persistent memory и self-evaluation; OpenAI в это же время отгрузил AgentKit с визуальным Agent Builder; AWS — Bedrock AgentCore с Runtime, Gateway, Memory как managed primitive. Любая команда, которая использует одну из этих платформ, может переключиться на другую за выходные, если речь идёт только об инференсе и harness.

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

Jerry Chen из Greylock в эссе «The New Moats: Why Systems of Intelligence Are the Next Defensible Business Model» формулирует это как «системы интеллекта»: в эпоху, когда сами модели становятся горизонтальным API, защита смещается в системы, которые накапливают уникальные данные, feedback loops и контекст их применения. Через пять лет тезис не устарел — изменилась только точность. Уникальные данные сами по себе не moat: их надо описать на языке, который понимает бизнес, и в формате, который понимает агент. Этот язык и есть representation layer.

Из чего реально состоит схема

На уровне артефактов representation layer — это четыре слоя, которые в зрелом продукте живут в репозитории и обновляются как код.

Первый — типы и сущности. JSON Schema или Pydantic-классы для основных объектов домена с явными атрибутами и связями. Например, в SaaS-поддержке: Account, User, Ticket, Conversation, Escalation, с типизированными ссылками между ними. Этот слой обычно выглядит дёшево — но именно его форма определяет, какие вопросы агент в принципе сможет задавать в данных.

Второй — конечные автоматы и инварианты. Граф валидных переходов состояний (new → triaged → in_progress → resolved → closed), правила, при которых переход допустим, и условия, при которых сущность не имеет права существовать. Без этого слоя агент способен сгенерировать «правдоподобный» исход, который на проверке окажется операционно невозможным — и это самая частая причина отказа vertical-AI-продуктов на ранних этапах.

Третий — события и trajectory hooks. Каждое значимое изменение состояния порождает событие с фиксированными actor, timestamp, before, after, reason. Этот слой непосредственно соединяется с тем, что мы в прошлой заметке называли trajectory data: без формализованной схемы событий замкнутая петля «вход → решение → исход» не собирается. Open-source memory-стек, такой как Graphiti или Letta, даёт хранилище для таких событий и temporal reasoning поверх них, но не даёт самой схемы — её всё равно проектирует команда.

Четвёртый — резолверы и валидаторы. Код, который превращает грязный вход реального мира — почту, чаты, формы, выгрузки — в сущности схемы и обратно. Это самая «грязная» часть representation layer и одновременно самая защищённая: чтобы её воспроизвести, конкурент должен не просто прочитать вашу схему, а заново пройти через все edge cases вашего домена.

Vendep в эссе «Forget the data moat, the workflow is your fortress in vertical SaaS» формулирует это резко: «moat — это не данные сами по себе, а то, как они вшиты в рабочий процесс». На уровне representation layer этот тезис конкретизируется: «вшиты в рабочий процесс» означает, что схема валидируется на каждом шаге, и любое расхождение между моделью и реальностью становится явным, а не молчаливым.

Где это уже работает

Зрелые vertical-SaaS-компании де-факто давно построили representation layer, просто не называли его так. Procore описывает строительный объект через типизированный набор RFI, submittals, change orders с явными статусами и инвариантами; ServiceTitan для home services формализует звонок, work order, наряд бригады и инвойс через типизированные сущности с явной историей переходов. На этом фундаменте AI-функции прирастают как естественное расширение, а не как отдельный продукт. Когда Foundation Capital в эссе «AI Leads a Service-as-Software Paradigm Shift» пишет про переход от продажи софта к продаже готовой работы, имплицитное условие этой модели — что «работа» формализована достаточно, чтобы её можно было поручить системе. Representation layer и есть инструмент такой формализации; без него service-as-software не выходит за пределы demo.

Обратный пример полезен не меньше. Forbes в марте 2026 описывал, как горизонтальные AI-«обёртки» над generic CRM теряют клиентов в пользу вертикальных продуктов с глубоким пониманием домена — несмотря на то, что качество моделей у обёрток часто выше. Причина прозаична: универсальная CRM-схема не различает реструктуризацию долга в B2B-кредитовании и продление подписки в SaaS, а вертикальный продукт различает, и его агент перестаёт делать абсурдные предложения. Это и есть видимая часть representation layer — она проявляется как «продукт просто понимает наш бизнес».

Что это значит на практике

Для фаундера AI-продукта. Тестовый вопрос для собственного продукта: если завтра OpenAI выпустит модель, которая на ваших задачах работает на 10% лучше, насколько изменится ваша экономика удержания? Если сильно — у вас, скорее всего, нет representation layer, у вас тонкая обёртка над API. Если почти не изменится — у вас есть слой, который компаундируется. Конкретный действие: перенесите одну центральную сущность вашего продукта (лид, тикет, ордер, контракт) из «свободно лежит в промптах и коде» в явную, версионированную схему с инвариантами. Через три месяца оцените, насколько чаще вы исправляете ошибки агента в коде валидаторов, а не в промптах. Этот сдвиг — самый ранний признак, что слой начал формироваться.

Для руководителя, выбирающего вендора. На discovery-встрече задайте один вопрос: «покажите, как у вас описана сущность X в нашем бизнесе». Если ответ — «мы передадим это в промпт модели», вы покупаете harness, и ваша зависимость от вендора будет нулевой, а ценность — кратковременной. Если ответ — «вот версионированная схема, вот инварианты, вот резолверы, вот политика изменений», вы покупаете operating layer, у которого есть и глубина, и аудит, и опционально перенос. Второй важный вопрос: «при расторжении контракта что я получу обратно — дамп таблиц или работающую копию representation layer на стандартных форматах». Ответ на второй вопрос отличает зрелого вендора от оппортуниста.

Для инженера, выбирающего, где работать. В команде, которая накапливает representation layer, ваша работа компаундируется: каждый новый клиент уточняет схему, каждый новый edge case добавляет валидатор, через два года вы один из немногих людей с реальным domain-driven understanding своей вертикали. В команде, которая занята прослойками поверх managed harness, через тот же срок вы — специалист по стеку, который провайдеры съели. На собеседовании смотрите, есть ли у команды отдельный артефакт «schema» или «ontology», кто им владеет, как часто он меняется. Если на этот вопрос команда не понимает, о чём вы спрашиваете, — это сигнал.

На что мы будем смотреть дальше

Если тезис верен, в течение ближайших 12–18 месяцев должны появиться три вещи. Первая — публичные стандарты для vertical schema по отдельным отраслям: не «общий JSON Schema», а конкретные онтологии для логистики, страхования, ритейла, согласованные между несколькими игроками. Сейчас этого нет, и каждый вендор изобретает свою. Вторая — рост сегмента ESB-подобных продуктов вокруг переноса representation layer между провайдерами, по аналогии с тем, как Open Banking стандартизировал API банков. Третья, самая важная — появление кейсов компаний, которые сменили модель и harness без потери operating-слоя: это будет публичным доказательством того, что слой действительно отделим и переносим. Если такие кейсы появятся, рынок vertical-AI окончательно перестанет конкурировать моделями.

Главное

• Representation layer — формальная схема сущностей, статусов и решений конкретного бизнеса — основной источник switching cost у вертикальных AI-продуктов; модель и harness заменимы, схема — нет.
• Слой состоит из четырёх артефактов: типы и сущности, конечные автоматы и инварианты, события и trajectory hooks, резолверы и валидаторы. Все четыре живут в репозитории и обновляются как код.
• Тестовый сигнал для продукта: если улучшение базовой модели не двигает удержание — у вас есть слой; если двигает сильно — вы продаёте обёртку.
• Для покупателя AI-продукта главный вопрос — не «какая там модель», а «как описаны сущности моего бизнеса и что я унесу при расторжении».
• В ближайшие полтора года индикатор зрелости рынка — появление публичных vertical-схем и переносимых operating-слоёв между вендорами.

FAQ

Можно ли сделать representation layer переносимым между провайдерами? Часть переносится, часть остаётся связанной с конкретной операцией. Схема, инварианты и валидаторы хранятся как код и не зависят от выбора модели. Переносимость ломается на двух стыках — на интеграциях с операционными системами клиента и на управляемой памяти провайдера, где формат событий и trajectory hooks часто проприетарен. Стандарт переноса появится не раньше, чем будет рыночное давление со стороны крупных покупателей.

Чем representation layer отличается от обычной схемы базы данных? Схема БД описывает форму хранения; representation layer описывает смысловой контракт между бизнесом и агентом. У него обязательно есть инварианты, конечные автоматы и резолверы — слои, которые в традиционной БД-разработке либо живут в коде приложения, либо отсутствуют вовсе. Кроме того, representation layer проектируется так, чтобы его читала и писала и модель, и человек, и валидатор — и расхождения между ними становились видимыми.

Почему vertical schema дороже модели?

Модель можно заменить через API-router или weekend migration, если surface вокруг неё стабилен. Vertical schema создаётся через discovery, интеграции, чистку грязных данных и десятки edge cases в операции клиента. Поэтому экономический вес смещается с inference bill на артефакты, которые описывают бизнес как исполняемую систему.

Когда representation layer не создаёт moat?

Он не создаёт moat, если схема остаётся generic и не получает данных из реального workflow. Таблица с сущностями без инвариантов, событий и валидаторов легко копируется конкурентом. Moat появляется только там, где 3-6 месяцев operation history превращают схему в набор проверенных правил и исключений.

Как измерить зрелость representation layer?

Минимальный тест: посчитать, сколько ошибок агента исправляется изменением схемы или валидатора, а не переписыванием промпта. Если через 90 дней большинство исправлений всё ещё живёт в prompt text, слой незрелый. Если изменения идут в типы, конечные автоматы, resolvers и trajectory hooks — representation layer начал компаундиться.

Сколько времени занимает первый рабочий слой?

Для узкого workflow первый production-grade slice обычно занимает 4-8 недель: 1-2 недели на entity discovery, 1-2 недели на dirty-data resolvers, 2-4 недели на валидаторы и trajectory hooks в реальной операции. Быстрее можно собрать demo, но demo не создаёт switching cost. Переключательные издержки появляются только после того, как схема пережила десятки реальных случаев и начала ловить ошибки до того, как их увидит человек.

На второй итерации слой обычно расширяют не шириной, а глубиной: добавляют 5-10 новых инвариантов, 2-3 события в trajectory log и один новый resolver для самого частого грязного входа. Это важнее, чем подключить ещё одну модель. Модель улучшает ответ; representation layer уменьшает число ситуаций, где неправильный ответ вообще возможен. В этом и состоит экономическая разница между API-обёрткой и operating layer.

Что изменилось за один квартал?

8 апреля 2026 Anthropic выпустил Managed Agents — управляемый цикл исполнения, постоянную память через интерфейс /memories, песочницу, мультиагентную оркестрацию, агентов, которые «self-evaluate and iterate until they reach a result». В публичном API beta header — managed-agents-2026-04-01 (Claude API docs). 22 апреля на Cloud Next Google переименовал Vertex AI в Gemini Enterprise Agent Platform — Agent Builder, Agents Gallery, A2A protocol, $750M партнёрский фонд. В тот же день AWS отгрузил управляемый harness (контур исполнения) в preview-режиме в Bedrock AgentCore — Runtime, Gateway, Identity, Memory, Observability как управляемые примитивы (AWS docs). OpenAI в это время добивал AgentKit — Agent Builder с визуальным холстом, реестром коннекторов, ChatKit, встроенными проверками и ограничениями (OpenAI).

За один квартал четыре крупнейших провайдера независимо схлопнули в managed-продукт тот самый слой, который ещё в марте называли «agentic moat» (businessengineer.ai). На рынке, который год назад продавал «настройку агента» за сотни тысяч рублей, теперь это npm install плюс конфиг в облачной консоли. Это не прогноз. Это то, что произошло.

Что сломалось у «AI-агентств» за один квартал

Бизнес-модель студии, продающей «AI-бота под клиента», держится на одной арифметике: harness (память, маршрутизация инструментов, оркестрация, проверки, ограничения) — это инженерный труд, который можно перепродать с маржой. Когда Anthropic берёт на себя цикл исполнения, OpenAI — реестр коннекторов, AWS — память и наблюдаемость, вся себестоимость, на которой строилась цена, испаряется. Не потому что заказчик стал умнее, а потому что у него теперь есть кнопка «Agent Builder» бесплатно или почти бесплатно.

Разговор в октябре 2025, который в растущем сообществе вокруг агентных стеков звучал как откровение — «модель — товар, harness определяет успех агентов» — за полгода устарел. Harness теперь тоже товар. И это меняет не одну строчку в P&L, а весь жанр: студия, которая продаёт «соберём вам агента», в 2026 — это студия, которая в 2018 продавала «настроим вам Kubernetes». Ещё работает, но потолок виден.

Производное следствие важнее самого факта. На воронке такой студии теперь стоит не «вам нужен бот?», а «вам нужен бот, или ваш CTO уже открыл AgentKit и собрал его за вечер?». В обоих случаях продаваемая ценность — не в harness. Она где-то ещё. Вопрос только в том, понимает ли студия, где именно, до того как закроется следующий квартал.

Что именно стало товаром

Имеет смысл смотреть не на «агентов» вообще, а на компоненты. Маршрутизация инструментов и function calling — нативная часть API всех четырёх провайдеров; это больше не код, это конфиг. Память краткосрочная и долгосрочная — управляемый интерфейс у Anthropic, AgentCore Memory у AWS, управляемый контекст у Google; кастомные RAG-конвейеры теряют ROI на глазах. Многошаговая оркестрация — Agent Builder у OpenAI, AgentCore Runtime у AWS, A2A protocol у Google (TNW). Проверки и самоверификация — OpenAI Evals с оценкой трасс, AgentCore Observability с записью сессий и воспроизведением. Ограничения и PII detection — открытый код у OpenAI, встроенные у Google, AgentCore Identity у AWS.

Стопка компонентов, которую год назад студия описывала клиенту как «наша архитектура», теперь почти полностью совпадает с прайс-листом Bedrock и таблицей возможностей AgentKit. Это и есть определение коммодитизации: универсальная форма, которую любой может купить за деньги, а не за время. Anthropic не случайно переименовал Claude Code SDK в Claude Agent SDK — это сигнал, что вся стопка теперь продукт, а не пример кода.

То, что не провалилось внутрь платформы, тоже понятно. Институциональное знание — то, как именно конкретная компания принимает решения, какие у неё граничные случаи, кто и когда эскалирует. Данные траекторий (trajectory data) — закрытый цикл «вход → решение агента → исход через N дней», который восстанавливается только через работу, не через промпт. Глубокая интеграция в окружение клиента — 1С, amoCRM, отраслевые API, legacy. Эти три слоя в Forbes-эссе Sanjay Srivastava названы non-absorbable не из стилистических соображений, а потому что их нельзя упаковать в SDK, не имея доступа внутрь компании клиента.

Три слоя, которые нельзя купить через npm

Названия здесь важны, потому что от их понимания зависит, чем компания будет заниматься следующие два года.

Слой представления (representation layer). Это то, как бизнес моделируется в данных. Какие сущности первичны — лид, актив, контрагент, событие. Какие у них статусы. Что считается дублем. Что считается просрочкой. У большинства компаний это знание не лежит в одном месте: оно размазано между CRM, табличкой в Google Sheets, головой менеджера и чатом в WhatsApp. Когда компания строит AI-контур, она впервые вынужденно фиксирует слой представления как явный, структурированный объект — вертикальную схему. И этот объект, в отличие от модели, не товар: его нельзя скачать с Hugging Face, потому что он точен ровно настолько, насколько точно описывает конкретную операционную реальность. Gartner прогнозирует, что через 2026 год 60% AI-проектов будут свёрнуты из-за недостаточного качества данных — именно потому что слой представления не формализован. Жанр такой работы ближе к тому, что Foundation Capital в эссе про service-as-software называет «кодификацией экспертизы», чем к традиционной разработке.

Данные траекторий (trajectory data). Закрытый цикл. Что агент сказал → что человек сделал → что произошло через час, день, неделю. Бенчмарки 2025–2026 (BEAM из UAlberta, MemoryAgentBench из UCSD, LongMemEval) показали, что окно контекста в 1M токенов не равно 1M-токенной памяти: модели деградируют именно на задачах разрешения противоречий, упорядочивания событий и обновления знания во времени. Это значит, что временная траектория — отдельная архитектурная задача, и open-source memory-стек (Graphiti, Letta, Cognee) её решает только частично: он даёт хранилище, но не данные. Данные появляются от того, что агент работает в реальной операции, а не на синтетике. Их нельзя восстановить задним числом без месяцев работы в том же контексте — это и есть структура издержек на смену поставщика.

Институциональный регламент (institutional SOP). Операционный плейбук компании, превращённый в исполняемую политику. Не «инструкция в Notion», а граф решений: триггеры повторного контакта, правила ценообразования, пороги эскалации, кто имеет право подписать скидку, какие исключения допустимы, какие нет. До AI это знание жило в людях. Когда оно становится частью контура агента, происходит смена носителя: регламент теперь не «как мы тут работаем», а артефакт, который компания владеет, версионирует и аудирует. Как формулирует Vendep в эссе про вертикальные рабочие потоки: forget the data moat, the workflow is your fortress — и это не маркетинг, это описание того, что именно остаётся, когда модель и harness уходят вниз по стеку.

Эти три слоя не покупаются через npm install. Их строят. Медленно, по одному клиенту, по одной вертикали. И их главное свойство — они компаундируются: каждое следующее внедрение делает следующий точнее.

Агентная компания как сборка этих слоёв

Эти три слоя — не дополнительные возможности поверх агента. Они — форма самой компании, которая их использует. Именно про это говорит Andrej Karpathy, когда называет LLM «kernel of a new operating system» в своём докладе 2023 года «Intro to Large Language Models» — где «LLM OS» выделен как отдельная глава. Именно про это Jack Dorsey написал в акционерном письме Block в феврале 2026: «Intelligence tools have changed what it means to build and run a company» — и срезал 4 000 позиций (40% штата), обосновав это напрямую как операционную перестройку под AI. И это же — основная мысль Foundation Capital про переход от SaaS к service-as-software: AI продаёт не инструмент, а готовую работу.

Пока этот паттерн собирают по частям, но не как целое. Описать его можно тремя сменами акцента.

Cron вместо проекта. В классической компании работа упакована в проекты — сущности с началом, концом, бюджетом и менеджером проекта. В агентной компании ключевая единица — повторяющийся цикл. Агент, который каждое утро в 9:00 проверяет состояние воронки и эскалирует то, что зависло. Агент, который раз в час пробегает по тикетам поддержки и помечает то, что требует человека. Cron-задачи — не вспомогательные скрипты, а основная операционная ткань. Проекты остаются для исключений; рутина живёт в расписании.

Память вместо документа. Документ оптимизирован под человека: его читают глазами, забывают, переписывают по поводу. У агента есть структурированная память — вертикальная схема плюс темпоральный граф знаний — которая обновляется непрерывно, держит valid_at и invalid_at, разрешает противоречия не «последний прав», а с историей. Продуктовая документация, инструкции для саппорта, описание процессов — всё, что в обычной компании живёт в Notion и устаревает за квартал, в агентной компании живёт как структурированная память, которая обновляется в момент выполнения работы.

Роль вместо штатной единицы. В классической компании единица найма — место. Junior support, middle sales, senior PM. В агентной компании единица — роль с явным контрактом: что роль делает, какие у неё входы и выходы, какие пути эскалации, какая память. Один человек может занимать несколько ролей. Часть ролей делают агенты. Часть — гибрид. Дорожная карта ролей похожа не на оргструктуру, а на список сервисов в Kubernetes: версии, зависимости, наблюдаемость.

Это не теория. Klarna, по собственному заявлению, заместил порядка 40% штата AI-системами. Salesforce сократил 4000 позиций под тем же предлогом. Sam Altman публично сделал ставку на появление в течение года первой компании-юникорна с одним человеком в штате. Это можно считать пиаром, но направление одно. И направление состоит не в том, что «AI помогает работать», а в том, что операционная единица другая: cron, память, роль.

Связка трёх слоёв — слой представления, данные траекторий, регламент — собирает этот другой тип компании в нечто, что можно строить. Не как метафору, а как архитектуру. Harness стал товаром → выживает не тот, кто продаёт агентов, а тот, кто строит операционный слой → агентная компания и есть тот операционный слой. Эта связка объясняет, почему рынок «AI-агентств» в 2026 раздваивается: на тех, кто всё ещё продаёт harness (и закрывается), и тех, кто продаёт операционную систему для конкретной вертикали (и масштабируется).

Что это значит для трёх типов читателей

Фаундер AI-проекта. Если ваш текущий продукт — это «обёртка над API провайдера, упрощающая сборку агента», у вас 6–12 месяцев. Это не угроза, это просто календарь: управляемый harness уже идёт в GA у трёх из четырёх крупных провайдеров. Действие — не «придумать что-то ещё», а посмотреть, какой из трёх слоёв (слой представления, данные траекторий, регламент) у вашего продукта и ваших клиентов уже накапливается без вашего участия, и переинвестировать туда. Если ни один не накапливается — это сигнал, что вы строите типовой harness, и пора пересобирать гипотезу. Конкретно: если вы не можете внятно описать, какой маховик данных запускается у вашего клиента в первые 30 дней работы продукта, — у вас нет соответствия продукт-рынок (product-market fit), у вас есть демо.

Руководитель компании, думающий про AI. Главная ошибка 2026 года — покупать «AI-бота» как изолированный SaaS, отдельно от своих процессов. Это эквивалент покупки CRM в 2010-х в надежде, что она «улучшит продажи»: сама по себе не улучшит. Покупать стоит операционный слой — поставщика, который интегрируется в ваш контур и помогает вам кодифицировать регламент, накопить данные траекторий и зафиксировать слой представления. Тестовый вопрос на discovery-встрече: «через 6 месяцев работы с вами что у меня есть, чего не было?». Если ответ — «у вас работает бот», это продавец harness. Если ответ — «у вас есть структурированный операционный слой, который вы можете аудировать, версионировать и при необходимости перенести на другого провайдера», — это поставщик другого жанра. Заодно проверьте контракт: фиксирует ли он провайдера. Если да — это не защитимая часть, это привязка, и при следующем шаге провайдеров вверх по стеку вы будете платить за это снова.

Инженер, выбирающий, где работать. Большая часть инженерных команд в AI-агентствах сейчас занята тем, что превращается в ETL-работу нового поколения: интеграция управляемых компонентов друг с другом плюс прослойки, которые не выживут до 2027. Это не плохая работа — но она не компаундируется. Команды, где компаундируется опыт, — это те, кто работает в одной вертикали достаточно глубоко, чтобы накапливать слой представления и данные траекторий. Признак: команда не описывает свою работу в терминах «мы интегрируем GPT/Claude», а в терминах «мы строим операционный слой для X». Если на собеседовании вам показывают архитектуру вокруг harness, а не вокруг домена — это команда, которая через год будет делать миграцию своего же стека на управляемый harness и думать, чем заняться. Если вокруг домена — у вас есть шанс проработать там пять лет и выйти с компетенцией, которой не будет ни у кого, кроме людей с этим же опытом.

На какие сигналы смотреть

Тренд имеет несколько проверяемых траекторий, по которым видно, ускоряется он или нет. Первая — появление управляемого harness агентов у не-западных провайдеров. GigaChat и YandexGPT в РФ, Qwen и Doubao в Китае. Если в течение Q3–Q4 2026 в их продуктах появляется визуальный конструктор агентов и управляемая память — это сигнал, что коммодитизация harness вышла на глобальный уровень и больше не зависит от географии. Вторая — появление маркетплейсов вертикальных шаблонов от провайдеров: «готовые наборы регламентов под ритейл, страхование, логистику». Если такие маркетплейсы открываются, нижний сегмент вертикального AI становится неустойчивым, и операционный слой как сервис должен сместиться вверх по среднему рынку. Третья, обратная — появление публичных кейсов компаний, которые ушли с управляемого harness обратно в собственный стек. Если такие кейсы будут — значит, либо managed-продукт упёрся в потолок применимости, либо стоимость выхода оказалась выше, чем казалось при подключении. Это интересный сигнал для всех, кто сейчас выбирает между «строить» и «купить».

В любом сценарии главный вопрос остаётся одним и тем же. Не «какого агента построить», а «какой операционный слой вокруг агентов мы собираем за следующие 24 месяца, и кому мы будем им владеть к 2028». Это вопрос о форме компании, не о технологии. Технология уже общая.

Главное

• Harness агентов (память, оркестрация, проверки, ограничения) стал товаром: Anthropic, OpenAI, Google, AWS выпустили managed-продукты за один квартал.
• Защитимыми остаются три слоя: слой представления (вертикальная схема данных), данные траекторий (закрытый цикл вход→решение→исход), институциональный регламент (политика компании как исполняемый граф решений).
• Агентная компания — это не метафора, а архитектура: cron вместо проекта, память вместо документа, роль вместо штатной единицы.
• Рынок AI-агентств раздваивается: те, кто продаёт harness — закрываются; те, кто строит операционный слой для вертикали — масштабируются.

FAQ

Что такое harness в контексте AI-агентов?

Harness — это контур исполнения вокруг модели: маршрутизация инструментов, память, песочница, оркестрация, проверки, ограничения и наблюдаемость. В 2025 этот слой ещё выглядел как инженерная дифференциация. В апреле 2026 четыре крупных провайдера вынесли его в managed-продукты, поэтому продавать один harness как главную защитимую часть стало слабой позицией.

Почему управляемый harness обесценивает AI-агентства за квартал?

Потому что он забирает себестоимость, на которой держалась цена агентства: сборку памяти, вызова инструментов, оркестрации и базовых проверок. Если клиент может получить 70-80% этого слоя в AgentKit, Managed Agents или AgentCore, агентство должно продавать не «бота», а кодификацию бизнеса. Иначе discovery-встреча превращается в простое сравнение поставщиков.

Чем слой представления отличается от обычной CRM-схемы данных?

CRM-схема хранит поля и статусы; слой представления фиксирует смысловой контракт бизнеса: какие сущности первичны, какие переходы валидны, что считается ошибкой, дублем или эскалацией. Для AI-агента это не справочник, а рабочий язык. Именно поэтому слой представления нельзя купить через SDK провайдера.

Данные траекторий — это просто логи или что-то ещё?

Нет. Лог фиксирует, что произошло в системе; данные траекторий связывают вход, решение агента, вмешательство человека и бизнес-исход через час, день или неделю. Эта петля нужна, чтобы учить регламент и валидаторы на реальной операции. Управляемая наблюдаемость даёт трассы, но не создаёт клиентскую историю исходов.

Как отличить настоящий операционный слой от обёртки над API?

Спросите, что останется у клиента через 6 месяцев, если модель и провайдер поменяются. У обёртки останется набор промптов и интеграций. У операционного слоя останутся вертикальная схема, история траекторий, исполняемый регламент, журнал аудита и понятный план переноса на другой слой инференса и harness.