
Cloudflare lança OS open-source de produtividade com agentes no Workers
O que é o Cloudflare OS
A Cloudflare abriu o código-fonte do Cloudflare OS, um "sistema operacional" de produtividade com IA desenvolvido originalmente para uso interno, no qual boa parte da força de trabalho da empresa - de engenharia a vendas - já usa diariamente. O termo "sistema operacional" é usado em dois sentidos: como ambiente para a empresa usar IA com segurança (de modo que o time de segurança "possa dormir tranquilo") e como plataforma que gerencia cargas de trabalho de IA, análogo ao que um SO tradicional faz com processos. O projeto está no GitHub sob licença Apache-2.0, com cerca de 10,9 mil estrelas.
A versão publicada é a v2, uma reescrita completa sobre uma nova fundação. Em agosto de 2026, o estado é de "early access": muito capaz, mas ainda com muitas arestas. É possível rodar localmente com pnpm (via wrangler e workerd) ou fazer deploy para a própria conta Cloudflare.
Três pilares
O sistema oferece: uma interface de chat com agentes pré-carregados com conhecimento sobre como a empresa opera; desenvolvimento sandboxado de aplicativos, em que agentes criam "gadgets" (pequenos apps pessoais) que podem ser compartilhados com segurança; e uma camada de segurança chamada Gatekeepers, que aplica guardrails a agentes e apps para que usuários não técnicos possam usar a plataforma livremente sem riscos.
Gadgets: software por usuário, não SaaS
A abordagem rompe com 25 anos de arquitetura de nuvem e SaaS. Ao criar uma apresentação, por exemplo, o sistema gera uma instância privada do software de slides só para o usuário, isolada em sandbox separada. Isso traz dois efeitos: um bug de segurança no app de slides não vaza os dados do usuário, e é seguro modificar o código - basta pedir ao agente para adicionar a funcionalidade que falta. Segundo a Cloudflare, quando qualquer usuário consegue pedir a um agente as features de que precisa, o modelo centralizado de software deixa de fazer sentido.
Gatekeepers: segurança por capacidades
Gatekeepers são descritos como "MCP servers turbinados". Ao apresentar um agente ou Gadget a um recurso externo, um Gatekeeper é criado para mediar o acesso: fornece uma API limpa via Cap'n Web, trata autorização (por exemplo, via OAuth), restringe o acesso ao recurso específico pretendido, registra toda ação e oferece aprovação humana para ações com efeitos colaterais.
A inovação apontada está no human-in-the-loop: em vez de exigir aprovação síncrona (que faz o agente parar e esperar, levando usuários a recorrer ao auto-approve ou ao --dangerously-skip-permissions), o Gatekeeper simula o resultado localmente, deixa o agente continuar e enfileirar ações, e entrega resultados simulados. O usuário aprova ou rejeita as ações em lote depois, quando for conveniente. Cada Gatekeeper é implementado como um Worker separado; há Gatekeepers prontos para GitHub, Google, Cloudflare, Supabase, Notion, Confluence, e-mail, Home Assistant, Slack, Spotify e ZoomInfo.
Analogia com um sistema operacional
A analogia não é só marketing: o workshop-backend funciona como kernel, os Gatekeepers equivalem a drivers, o workshop-front é o shell, Gadgets são processos e Blueprints, executáveis. Uma diferença dos SOs tradicionais é o tratamento de agentes de IA: eles não podem ser tratados apenas como usuários, pois precisam prestar contas a um humano e ter permissões próprias e restritas. O modelo de segurança ideal, segundo o projeto, é baseado em capacidades, não em listas de controle de acesso.
Construído sobre Workers
O Cloudflare OS usa Workers, com destaque para Durable Objects, Dynamic Workers e Facets - cada workspace é um Durable Object, cada Gadget roda em um Facet de Dynamic Worker. Recursos como Dynamic Workers e Facets foram adicionados ao runtime especificamente para suportar o projeto. Como o workerd é open source, o OS pode rodar inteiramente em servidores próprios, embora a documentação para esse cenário ainda esteja em desenvolvimento.
Funcionalidades e colaboração
O agente de codificação é multiuso e opera em "Code Mode": executa tarefas escrevendo e executando trechos de código na hora. Suporta vários provedores de LLM e modelos self-hosted, e a plataforma afirma que, pela integração estreita, o agente costuma performar melhor e com menos tokens que um agente de propósito geral. Todo app criado ganha automaticamente uma API amigável a agentes, porque cliente e servidor de um Gadget precisam se comunicar via Cap'n Web RPC - não é preciso montar um servidor MCP.
Há multiplayer em tempo real (viabilizado por Durable Objects) e Blueprints, que permitem compartilhar o código de um Gadget para que outros criem cópias próprias - mais parecido com apps de celular e PC do que com software hospedado. Isso elimina a necessidade de manter um serviço online e permite que cada usuário adapte o software com IA em vez de pedir funcionalidades ao desenvolvedor.
Acesso e contribuições
Por padrão, agentes e Gadgets não têm acesso a nada: é preciso "apresentar" cada recurso explicitamente, por link ou interface - o oposto da configuração prévia de MCP servers, que dá acesso amplo e ambiente ao agente. O cliente roda em iframe sandboxado e o servidor em Dynamic Worker sem acesso à internet, comunicando-se apenas via bindings designados.
Quanto a contribuições externas, o projeto não as busca neste momento: a justificativa é que, com a IA, escrever código virou a parte fácil, e o difícil é revisar e manter a coerência. PRs pequenos e verificados são aceitos; PRs de baixo valor ou longos serão fechados. Entre as dependências destacadas estão Pi (pi-agent-core), CodeMirror, isomorphic-git e Vite.