У каждой организации есть миссия — причина существования. Вместе с ней компании передают сотрудникам терминологию, процедуры, системы, стандарты и принятые способы работы. Люди берут этот контекст, добавляют собственный опыт и двигаются к общей цели.
Работа принимает разные формы: код, документы и презентации, отношения между людьми, результаты в физическом мире.
С кодом всё просто: он либо работает, либо не работает. Именно на этой обратной связи агенты последние пару лет учились писать код, который «работает» для разработчиков. Но что насчёт остальных сотрудников компании?
Дать такой же рычаг всей остальной организации — задача сложнее. Агентам нужно понимать контекст компании и иметь доступ к системам, которыми пользуются люди при выполнении своей работы. Этот контекст и доступ нужно превратить в результат, который двигает организацию к её миссии.
Для этого в Cloudflare создали Cloudflare OS — систему, которая даёт каждому сотруднику агента и рабочее пространство, выстроенное вокруг его компании: того, как она работает, что она знает, и систем, на которые она опирается.
В мае этого года первую версию Cloudflare OS получили все сотрудники Cloudflare. Тысячи людей в разных функциях, многие из них далеко от инженерии, ежедневно используют её для создания документов и презентаций, автоматизации повторяющихся задач и создания небольших приложений для визуализации данных.
Cloudflare OS также дала всем сотрудникам общую библиотеку контекста и навыков, собранную командами Cloudflare. Она фиксирует терминологию компании, процедуры и лучшие известные способы выполнения повторяющихся задач в виде инструкций, которым может следовать агент. Когда один человек находит лучший способ сделать что-то, этим способом может воспользоваться каждый.
Сегодня Cloudflare открывает исходный код новой версии Cloudflare OS. Развернуть её и подключить к внутренним системам может любая организация, сделав платформу своей.
Что показала работа с первой версией
Новая версия Cloudflare OS построена на опыте эксплуатации первой версии внутри компании — об этом пути подробно рассказывает CIO Cloudflare Сэм Ри (Sam Rhea) в своём блог-посте.
Первая версия строилась вокруг того, что отдельные люди работают с агентами в личных рабочих пространствах. Приложения были статичными, а не живым программным обеспечением, подключённым к внутренним системам, а большинство детерминированных по своей природе задач всё равно требовали повторного запуска навыка агента и расхода токенов модели.
Совместная работа обнажила более фундаментальную проблему. Доступ к MCP-серверу показывал, какие инструменты агент мог вызывать, но не то, какие именно ресурсы этот агент уже видел. Когда сотрудники начали делиться рабочими пространствами, приложениями и результатами, потребовалось гарантировать, что совместная работа не раскроет информацию тому, кому её видеть не положено.
Cloudflare OS пересобрали на новом фундаменте, чтобы решить эти проблемы. Безопасность должна быть частью самой платформы, а не тем, что каждый человек, создающий приложение или использующий агента, обязан реализовать правильно самостоятельно.
В результате получилась платформа, спроектированная так, чтобы принадлежать компании, которая её запускает. Интерфейсы можно настраивать под себя, подключать свои инструменты, добавлять навыки и контекст, отражающие принятые в организации способы работы.
Знакомство с Cloudflare OS
Cloudflare OS, как и многие другие AI-инструменты, начинается с диалога в браузере. Отличие в том, что каждый разговор опирается на контекст и навыки, которые собрала конкретная организация. Достаточно задать рабочему пространству цель — и оно сможет использовать эти знания вместе с инструментами и данными, которые компания уже применяет, чтобы этой цели достичь.

Cloudflare OS объединяет три составляющие:
- Рабочее пространство агента, опирающееся на контекст и навыки, которые собрала компания, с изолированной средой выполнения, где агенты могут писать и запускать код.
- Новую модель безопасности и управления доступом для безопасного доступа к внутренним данным и сервисам.
- Платформу для персональных, изменяемых приложений, которые люди могут создавать, передавать друг другу и продолжать дорабатывать.
То, что начиналось как разговор, может превратиться в документ, приложение или рабочий процесс, который продолжает выполнять работу самостоятельно.
Рабочее пространство агента для всех сотрудников компании
Рабочие пространства агентов рассчитаны на использование любым сотрудником организации. Взаимодействие происходит через браузер, поэтому не требуется быть разработчиком или уметь работать с терминалом.
Рабочее пространство объединяет агентские сессии, постоянное состояние, результаты и файлы, доступ к ресурсам и изолированную среду выполнения, где агент может писать и запускать код.
Оно поставляется вместе с собранными контекстом и навыками, которые команда или компания уже накопила. Больше не нужно каждый раз изобретать колесо для одной и той же задачи — если кто-то в команде нашёл лучший способ сделать что-то, выигрывают все. Людям больше не нужно объяснять модели одни и те же процессы, терминологию и лучшие практики каждый раз при старте новой задачи.
Вот несколько примеров того, что можно делать:
Исследовать вопросы и задавать их
Рабочему пространству можно поручить исследовать тему, используя контекст компании и доступные ему ресурсы. Агент может писать код для поиска, фильтрации, объединения и анализа информации, вместо того чтобы загружать целиком весь набор данных в контекстное окно модели.
Создавать документы, презентации и таблицы
Рабочее пространство может превратить результаты исследования в документ, презентацию или таблицу, которую можно продолжать редактировать. Эти результаты не обязательно должны быть статичными файлами: они могут оставаться связанными с живыми данными, обновляться при изменении источников и при этом экспортироваться в привычные форматы или сервисы, например Google Drive.
Создавать совместные, подключённые приложения для команды
Когда документа или таблицы недостаточно, агент может собрать приложение с собственным интерфейсом, логикой и состоянием. Такое приложение может использовать подключённые ресурсы компании и поддерживать одновременную работу нескольких людей.
Запускать детерминированные рабочие процессы
Не каждой задаче нужна полноценная агентская сессия. Многие задачи — это известная последовательность шагов, где судейское решение модели требуется лишь в одном-двух местах. Рабочее пространство может превратить такие задачи в преимущественно детерминированные workflow, используя код для предсказуемых шагов и модель — только там, где она действительно нужна. Workflow можно запускать по требованию, по расписанию или при возникновении события в подключённой системе.
Cloudflare OS предоставляет агентам и приложениям управляемый доступ к системам записи через Gatekeeper (подробнее об этом — в разделе о безопасности ниже). Платформа также поддерживает уже существующие MCP-серверы (Model Context Protocol), которые организация уже использует, через MCP Server Portals.
Новая модель безопасности и управления доступом к внутренним данным и сервисам
Когда сотрудники начинают экспериментировать с AI на работе, один из первых запросов — получить API-ключи к корпоративным системам. Это логично: AI мало полезен на работе, если у него нет доступа к системам, которыми люди пользуются для своих задач.
Но выдавать API-ключи людям и агентам напрямую — опасная практика, которая плохо масштабируется. Ключи часто дают широкий, долгоживущий доступ, который трудно ограничить, безопасно передать другим и проверить постфактум.
MCP даёт агентам более безопасный способ работать с такими системами. MCP-сервер может хранить учётные данные и предоставлять заранее определённый набор инструментов, вместо того чтобы передавать ключ агенту напрямую. Но контроль над тем, какие инструменты агент может вызывать, — это только первый шаг. Сам по себе MCP не показывает, какие именно ресурсы агент уже наблюдал. Агент может объединить информацию из разных систем, отправить её куда-то с менее строгими ограничениями или показать её через приложения и результаты людям, которым доступ к исходным ресурсам не разрешён. Авторизация должна учитывать, куда данные могут попасть дальше.
Агенты начинают без каких-либо прав доступа
Cloudflare Access контролирует, кто может войти в Cloudflare OS. Внутри платформы каждый агент и каждое приложение по умолчанию не имеет доступа ни к чему. Агент может запросить доступ к конкретному ресурсу, а администратор — разрешить или отклонить запрос. Сгенерированный код получает этот ресурс как типизированную привязку (binding):
const issues = await env.PROJECT.listIssues({
teamId: "ENG",
state: "open",
});
env.PROJECT — это capability (объект-полномочие), представляющий разрешение использовать конкретный ресурс в рамках конкретной политики. Учётные данные остаются полностью изолированными от агента и любого сгенерированного кода.
Серверный код выполняется в Dynamic Worker с отключённой глобальной исходящей сетью. Клиентский код выполняется в изолированном (sandboxed) фрейме в браузере. Ни тот, ни другой не могут обратиться в интернет иначе, чем через явно предоставленные capabilities.
Gatekeeper управляет ресурсами и действиями
Gatekeeper — это специфичный для конкретного сервиса Worker, который находится между Cloudflare OS и внешним сервисом. Он понимает API сервиса, его ресурсы и операции, которые с ними можно выполнять.
Давать агенту доступ ко всему аккаунту GitHub целиком, скорее всего, слишком широкое разрешение. Gatekeeper может выдать доступ к одному конкретному репозиторию, разрешить читать issues, но не исходный код, скрывать отдельные поля, применять лимиты запросов и требовать подтверждения перед merge pull request.
Агент и его приложения видят только небольшой TypeScript API. Gatekeeper сам обрабатывает OAuth, хранит учётные данные, применяет политики, фиксирует, что было прочитано, и опосредует любое действие с внешне видимым побочным эффектом.

Политика следует за тем, что видел агент
Контролировать только первоначальное чтение недостаточно. Представим случай: агент читает конфиденциальную таблицу в хранилище данных и на её основе строит живую панель (дашборд). Совместный доступ к этой панели не должен стать способом раскрыть исходную таблицу людям, которым доступ к ней напрямую закрыт.
Cloudflare OS фиксирует каждый ресурс, который наблюдали агенты. Эти наблюдения остаются привязанными к агенту и его работе. Когда другой человек пытается открыть рабочее пространство, взаимодействовать с агентом или посмотреть на то, что он произвёл, Gatekeeper проверяет права этого человека на доступ к наблюдаемым ресурсам.

Тот же журнал наблюдений используется для политик, определяющих, когда агенту разрешено делать внешние запросы. Чтение конфиденциальных данных может запретить агенту записывать данные в определённые источники, приглашать новых участников для совместной работы, передавать задачу другому агенту или делать исходящий запрос.
Людям, которые используют агентов или создают приложения, не нужно самостоятельно заботиться о том, чтобы не допустить подобных ошибок — теперь этим занимается платформа.
Платформа для создания и передачи персональных, изменяемых приложений
Большинство офисных пакетов дают фиксированный набор приложений: документы, таблицы, презентации. В Cloudflare OS каждый «файл» может быть собственным приложением, написанным агентом для конкретного человека, проекта или команды.
Это не прототипы, которые нужно экспортировать и разворачивать где-то ещё. Каждое такое приложение — полноценное full-stack приложение с клиентским кодом, серверным кодом, API и постоянным (durable) состоянием. По умолчанию приложения приватны, но их можно передавать другим, как документы.
Каждое приложение — это Worker
Когда рабочему пространству поручают создать приложение, агент пишет две части:
- Клиентский код, который отображает интерфейс приложения в браузере
- Серверный код, который хранит состояние и реализует поведение приложения
Сервер загружается по требованию как Dynamic Worker и инстанцируется как Durable Object Facet (обе эти возможности были созданы специально для этого проекта). Facet даёт приложению собственную базу данных SQLite, отдельную от среды выполнения самой Cloudflare OS, которая ей управляет. Dynamic Workers используют лёгкие изоляты V8, поэтому у каждого приложения может быть собственная изолированная среда выполнения без необходимости держать выделенный сервер или контейнер.

Клиент в браузере обращается к серверу через Cap'n Web — открытую систему удалённого вызова процедур (RPC) на основе объектных capabilities от Cloudflare. Серверный метод можно вызывать из клиента как обычную функцию JavaScript:
const issues = await app.listIssues({
status: "done",
});
Особенность в том, что тот же самый метод может вызвать и агент.
Значит, если можно создать инструмент, чтобы выполнять работу самому, тем же инструментом сможет воспользоваться агент, когда пользователя нет рядом.
Передать приложение или передать способ его создания
В Cloudflare OS приложением можно поделиться двумя способами:
- Передача самого приложения позволяет другим людям совместно работать в реальном времени с тем же состоянием.
- Передача blueprint (шаблона) приложения позволяет другим создать собственную копию этого приложения.

Приложение, созданное из blueprint, содержит код исходного приложения. Но оно не содержит его данных SQLite, истории переписки, учётных данных или подключённых ресурсов. Каждое новое приложение начинает работу с независимым состоянием и собственными ресурсами.
Это значит, что при передаче приложений команде коллеги могут сами модифицировать их с помощью AI, не подавая заявку на новую функцию и не назначая её на автора приложения.
Любая модель — и контроль над её стоимостью
Cloudflare OS можно использовать с любой моделью. Каждый вызов инференса проходит через Cloudflare AI Gateway, что даёт организации единую точку, где решается, какие модели доступны и какая модель должна обрабатывать каждую конкретную задачу.

Не каждой задаче нужна самая дорогая модель. Вряд ли есть смысл запускать самую дорогую флагманскую модель для того, чтобы каждое утро подытоживать непрочитанные письма. AI Gateway даёт контроль, необходимый для того, чтобы дорогие модели использовались только для действительно сложной работы.
Каждый запрос привязан к конкретному человеку, команде или рабочему пространству, которое его сделало. Администраторы видят, куда уходят расходы на инференс, могут устанавливать бюджеты и лимиты запросов, а также определять, что происходит при достижении лимита.
Открытый исходный код — чтобы платформа стала вашей
Cloudflare OS доступна уже сегодня как проект с открытым исходным кодом. Репозиторий находится на GitHub — cloudflare-os. Платформу можно развернуть в собственном аккаунте Cloudflare и использовать свои политики Access, конфигурацию AI Gateway, данные и интеграции.
Внутреннее развёртывание Cloudflare отражает системы, терминологию, политики и способы работы самой Cloudflare. Развёртывание любой другой компании должно отражать её собственную организацию.
Cloudflare OS спроектирована так, чтобы можно было настраивать интерфейс, добавлять внутренние Gatekeeper и создавать специфичные для организации функции без изменения ядра продукта.
Публикуются два репозитория: ядро Cloudflare OS и пример развёртывания, основанный на том, как платформа работает внутри самой Cloudflare. Репозиторий развёртывания использует ядро без внесения в него патчей, предоставляя отдельное место для конфигурации, кастомного UI, внутренних интеграций, аналитики и пайплайнов деплоя.
Совместно с партнёрами
Исходный код — это только отправная точка. Контекст, навыки, workflow, внутренние системы и политики — вот что делает Cloudflare OS по-настоящему полезной для конкретной организации.
Стратегические партнёры Cloudflare — Presidio и Happy Cog — помогут настроить Cloudflare OS под то, как работает конкретная организация, и внедрить платформу для всех сотрудников.
Партнёры могут помочь собрать общие навыки и институциональный контекст, создать кастомные интерфейсы, подключить внутренние системы через Gatekeeper и MCP Server Portals, а также настроить контроль безопасности, моделей и расходов.
В результате получается собственная, брендированная версия Cloudflare OS, подключённая к внутренним системам компании, работающая на Cloudflare и выстроенная под то, как реально работают её сотрудники.
Начало работы
Cloudflare OS доступна уже сегодня на GitHub. Можно изучить исходный код, попробовать демо или развернуть платформу в собственном аккаунте Cloudflare за несколько минут с помощью стартового репозитория.
Развитие платформы продолжается: Cloudflare работает над тем, чтобы принести Cloudflare OS в панель управления Cloudflare как полностью управляемый продукт, добавить контейнеры для рабочих процессов разработки и интегрировать рабочие пространства в Slack и другие чат-инструменты.
Связаться с командой Cloudflare для обсуждения можно через эту форму.