Это изложение поста sam rhea, CIO Cloudflare, опубликованного в X 6 августа 2026 года. Не дословный перевод: я пересказываю ход мысли автора своими словами, короткие цитаты привожу в кавычках и добавляю собственные выводы. Оригинал — пост sam rhea в X.
Cloudflare рассказала, как за несколько месяцев собрала внутреннюю ИИ-платформу для всей компании и теперь открывает её наружу. Называется она Cloudflare OS. Интересна тут не сама платформа, а путь к ней: команда сначала выяснила, какую работу люди реально хотят отдать машине, и только потом построила инструмент.
Личный планировщик как способ мышления
Автор начинает издалека. В пятом классе школа выдала ему ежедневник: развёрнутая на две страницы неделя, колонки по дням, строки по урокам, внизу место для длинных проектов. В шестом классе поставщик задержал новую партию, и он собрал себе такой же в Excel. Не скопировал, а перестроил под то, как сам думает о работе.
Дальше — деталь, ради которой стоит держать эту историю в голове. Директор школы попросил чистую страницу самодельного планировщика и раздал копии остальным. Часть детей пользовалась спокойно, но другие подходили и спрашивали, что означают все эти сокращения и квадратики.
Личная система работы не переносится на другого человека простым копированием. Это и есть рамка, в которой Cloudflare строила свою платформу: не один универсальный инструмент для всех, а среда, где каждый собирает нужное себе.
Ошибка первого захода
Первая попытка выглядела логично: дать всем не-инженерам те же инструменты, что у разработчиков, только с дружелюбным интерфейсом. Инженер клонирует репозиторий, кладёт рядом файл контекста вроде AGENTS.md и направляет агента на задачу. Для остальной работы такая схема подходит плохо: там разовые результаты и десятки систем учёта вместо одного репозитория.
Результат автор описывает прямо: если дать всем среду, которая хорошо пишет код, вы получите гораздо больше кода, чем вам нужно. Компанию залило приложениями, собранными «на вайбе» и ищущими себе задачу.
Магический почтовый ящик
Тогда команда пошла с другого конца. Сотрудникам сказали: присылайте работу, которую не хотите делать, на «магический ИИ-бот по почте», он вернёт готовый результат. За ботом сидели живые люди и делали эту работу с помощью ИИ-инструментов.
Наблюдение автора здесь важнее самой механики. Люди неохотно отправляют в автоматическую систему свои идеи приложений, но охотно отправляют туда рутину, которая им надоела. Через сотни, а потом тысячи обращений команда собрала карту той самой рутины.
Запросы разбирали вручную, замечали повторяющиеся шаблоны, писали под них skill- и context-файлы, размечали подключения к данным и описывали, какие форматы результата нужны людям. Часть ответов после этого удалось автоматизировать.
Автор не романтизирует этот этап: обслуживать такую очередь было мучительно, и команда была сильно мотивирована её закрыть. Ручная работа продолжалась ровно до момента, когда набралось достаточно типовых «работ, которые надо сделать», чтобы дать людям готовый старт.
Это главный урок поста. Каталог автоматизации не проектируется в кабинете. Он собирается из реальных запросов, и какое-то время за него приходится платить ручным трудом.
Версия первая: браузер вместо ноутбука
Первый Cloudflare OS был простой средой в контейнере на инфраструктуре компании. Человек открывает браузер, проходит аутентификацию через Zero Trust и запускает те самые skill-файлы, накопленные на этапе почтового бота. Локальная настройка не нужна.
Эффект автор описывает через новичков в продажах: спустя несколько дней после выхода на работу они автоматизировали то, на что на прошлом месте ушли бы недели.
Второе следствие бытовое, но показательное: ноутбук можно закрыть и уйти за кофе, задача продолжит выполняться. Никто больше не ходит по офису с приоткрытым лэптопом.
Есть и аргумент от безопасности. Эфемерная облачная среда видит только те данные, которые человек в неё принёс, а не всё содержимое рабочего ноутбука, как это происходит при локальном запуске агента. У службы безопасности есть аудит и сетевой контроль, вплоть до фильтрации того, куда среда может ходить в интернете.
Справа в интерфейсе открывается панель с результатом работы скилла — техническим документом, презентацией, отчётом. Готовое можно сразу передать коллегам.
MCP-портал и доступ к системам учёта
Данные подключены через собственный MCP-портал. MCP (Model Context Protocol) — открытый стандарт, который описывает, как ИИ-инструмент подключается к системе учёта и узнаёт, какие данные и операции ему доступны. Права сессии в Cloudflare OS ограничены правами конкретного человека в конкретной системе.
Отдельное решение, которое стоит отметить отдельно: почти для каждой системы Cloudflare пишет собственную реализацию MCP-сервера, даже когда вендор даёт готовую. Это позволяет добавить свои ограничения, например лимиты запросов по роли или региону. Сервер живёт на serverless-платформе компании, поэтому стоимость поддержки близка к нулю.
Для российских и небольших команд буквальное повторение этой схемы избыточно. Полезна сама идея: между агентом и системой учёта стоит собственный слой, где вы задаёте правила доступа, а не полагаетесь на настройки чужого сервиса.
AI Gateway: аудит и деньги
Весь инференс идёт через AI Gateway. Компания фильтрует, логирует и аудирует обращения к моделям, а правила DLP из корпоративного шлюза переиспользуются, чтобы определённые датасеты вообще не уходили провайдеру.
Вторая функция шлюза — экономика. Не каждому пользователю нужен максимальный режим рассуждений у флагманской модели. Автор формулирует это без прикрас: компании не нужно, чтобы сотрудники тратили примерно 20 долларов на почасовую суммаризацию своего почтового ящика. Шлюз разводит задачи по моделям: автономные сценарии вроде запусков по расписанию уходят на более экономичные.
Версия вторая: ИИ как производитель инструментов
У первой версии обнаружилась структурная проблема. Каждый запуск скилла открывал прожорливую сессию инференса, хотя большая часть работы детерминирована: последовательность шагов, где рассуждение или человеческое решение нужны в двух-трёх точках.
Формулировку автора стоит запомнить: нам не так нужен ИИ как инструмент, как нужен ИИ в роли изготовителя инструментов.
Во второй версии человек описывает рабочий процесс словами, агент пишет код, который его выполняет, а дальше этот код запускается по требованию, по расписанию или по событию. Компания не строит один агент для всех, а даёт каждому возможность собрать изолированное по умолчанию приложение под себя.
Пример автор берёт из своей же зоны ответственности — служба поддержки внутренних пользователей с классической очередью тикетов. Раньше утренний разбор выглядел так: выгрузить CSV, загрузить в таблицы, построить графики, вручную открыть каждый ночной тикет. Долго и с дублированием данных за пределами системы учёта.
В первой версии платформы это стало скиллом поверх MCP-сервера тикет-системы. Безопаснее и меньше ручного труда, но каждое утро сжигались тысячи токенов на пересборку почти одинакового отчёта.
Во второй версии он описал нужные графики, агент написал для них код, а к данным подключился через сервис, который в Cloudflare называют gatekeeper. Тот держит на себе постоянные запросы к данным и сужает контекст приложения без ручного управления API-ключами.
Инференс при этом никуда не делся, он просто встроен точечно: в приложении есть кнопка «набросать ответ на тикет», ответ можно проверить и отправить. Когда агента отдают коллегам, те аутентифицируются своими правами через те же gatekeeper'ы, поэтому границы доступа к данным не размываются.
И финальная цифра, ради которой всё затевалось: открытие уже готового отчёта не стоит ни одного токена.
Как это внедряли
Отдельную ИИ-команду не нанимали. Нашли ранних энтузиастов в разных ролях и сделали их проводниками для коллег: руководитель продаж в Лондоне, solutions-инженер в Техасе, специалист по работе с инвесторами в Португалии. Плюс стажёры, встроенные в существующие команды с прямой задачей подтянуть коллег на новые инструменты.
Цифры компания приводит такие: платформой пользуются тысячи сотрудников каждую неделю, число активных пользователей растёт каждый рабочий день. За последний месяц в продажах, по оценке компании, сэкономлено больше 10 000 часов на планировании территорий и подготовке коммерческих предложений, а пользователи создали свыше 4 000 приложений и инструментов под конкретные задачи.
Это оценки самой Cloudflare в анонсе продукта, а не независимый аудит. Порядок величин интереснее точности: когда сборка инструмента занимает минуты, люди начинают делать её постоянно.
Что здесь применимо у вас
Я бы вынес из этой истории четыре вещи, не зависящие от масштаба Cloudflare.
- Начинайте со спроса, а не с платформы. Простой канал приёма задач в духе «пришлите то, что не хотите делать руками» даст вам список автоматизаций точнее любого воркшопа.
- Отделяйте детерминированное от вероятностного. Если процесс каждый раз одинаков, его должен выполнять код, а модель включается там, где нужны суждение или текст. Это одновременно вопрос стоимости и вопрос предсказуемости.
- Ставьте собственный слой между агентом и данными. Свой прокси или свой MCP-сервер дают вам права, лимиты и логи. Раздача API-ключей их не даёт.
- Считайте маршрутизацию моделей частью архитектуры. Одна модель на все задачи означает переплату на простых и потолок качества на сложных.
Основная мысль поста в том, что рабочие инструменты перестают быть продуктом, который кто-то выпускает раз в год. Они становятся тем, что человек описывает словами под свою задачу за один вечер. Тот самодельный планировщик в Excel из шестого класса — ровно тот же жест, только теперь его может повторить любой сотрудник, а не только тот, кто умеет верстать таблицы.
Следующий шаг
Хватит просить у ИИ результат. Стройте свои инструменты
Связанные материалы
- Статья: Как собрать свою первую команду ИИ-агентов
- Блог: Скиллы больше не дают преимущества: выигрывают циклы и графы
- База знаний: Контекст-инжиниринг — как собирать рабочий контекст для моделей нового поколения
Если вы думаете, с чего начать внутреннюю автоматизацию в компании, разговор обычно упирается не в выбор модели, а в границы доступа к данным и порядок приёма задач от сотрудников.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov