Espaço de Trabalho de Agentes Gerenciado do Cloudflare OS Passa de Código Aberto para um Serviço com Lista de Espera

A Cloudflare abriu uma lista de espera para seu primeiro espaço de trabalho de agentes Cloudflare OS totalmente gerenciado, apenas um mês após lançar a plataforma subjacente como código aberto. A mudança transforma o Cloudflare OS de um projeto que as empresas precisam operar em um serviço que a Cloudflare pretende gerenciar para elas.

Isso parece uma edição hospedada convencional, mas a Cloudflare busca um papel mais amplo. Ela quer fornecer a cada funcionário um espaço de trabalho persistente que entenda os procedimentos da empresa e possa agir em sistemas aprovados. O espaço de trabalho pode pesquisar informações, criar documentos, modificar código e transformar tarefas repetidas em aplicações.

A pressão recai sobre Microsoft, Google e outros provedores de nuvem que já vendem plataformas de agentes empresariais. Seus produtos se beneficiam de posições consolidadas em suítes de escritório e contas de nuvem. A Cloudflare aposta que identidade, controles de rede, roteamento de modelos e execução isolada podem se tornar uma base igualmente importante para agentes no ambiente de trabalho.

Espaço de Trabalho de Agentes Gerenciado do Cloudflare OS Entra na Fase de Lista de Espera

A Cloudflare não está anunciando disponibilidade geral. Ela está testando se as empresas querem a plataforma de código aberto sem a carga operacional.

A Cloudflare anunciou a opção gerenciada em 1º de outubro de 2026. As organizações podem entrar em uma lista de espera, mas a empresa não forneceu uma data de lançamento, compromisso de nível de serviço, lista de disponibilidade regional ou termos comerciais.

A distinção importa porque a versão de código aberto já está disponível. As empresas podem implantá-la em suas próprias contas Cloudflare, personalizar sua interface e conectá-la a recursos internos. Elas também precisam configurar, operar, atualizar e proteger essa implantação.

Agora, a Cloudflare propõe uma divisão diferente de responsabilidades. Os clientes escolheriam usuários autorizados, contexto da empresa, competências organizacionais, sistemas conectados, um domínio personalizado e políticas de acesso relevantes. A Cloudflare cuidaria do trabalho restante de implantação e operação.

Segundo o anúncio da opção gerenciada, as organizações também selecionarão o AI Gateway usado por sua implantação. O AI Gateway fica entre o espaço de trabalho e os provedores de modelos, onde pode aplicar controles de roteamento, registro e políticas.

A Cloudflare afirma que milhares de organizações começaram a usar o Cloudflare OS durante o mês seguinte ao seu lançamento como código aberto. Esse número vem da Cloudflare e não recebeu verificação independente. A empresa não informou quantas implantações estão ativas, em caráter experimental ou sendo usadas em organizações inteiras.

Ainda assim, a lista de espera reflete uma lição concreta do lançamento de código aberto. Publicar código elimina barreiras de licenciamento e personalização, mas não elimina o trabalho de implantação. Uma empresa ainda precisa estabelecer regras de identidade, conectar sistemas, proteger credenciais, testar atualizações e investigar falhas.

O serviço gerenciado é a resposta da Cloudflare a essa lacuna de adoção. Ele oferece personalização às empresas sem exigir que cada cliente monte um processo operacional dedicado em torno da plataforma.

O momento também revela o mercado pretendido pela Cloudflare. O Cloudflare OS não está sendo posicionado apenas como um kit de desenvolvimento de agentes para equipes de software. A empresa descreve um espaço de trabalho para funcionários de vendas, finanças, suporte, operações e engenharia.

Uma reunião com cliente ilustra o escopo. Um funcionário poderia pedir a um agente que revisasse registros de contas, examinasse tickets de suporte, analisasse o uso do produto e preparasse uma apresentação. A tarefa atravessa vários sistemas e produz um resultado de trabalho editável, em vez de uma breve resposta de chat.

A Cloudflare também atualizou a plataforma durante seu primeiro mês. Agora, os usuários podem conectar repositórios GitHub e pedir aos agentes que inspecionem código, editem arquivos, criem commits ou abram pull requests. Essas funções levam o desenvolvimento de software para um produto inicialmente apresentado em torno de um trabalho de conhecimento mais amplo.

A integração com o Google Workspace também foi ampliada. A Cloudflare afirma que os agentes podem pesquisar threads do Gmail, criar rascunhos, enviar mensagens e usar recursos conectados do Drive. Os administradores podem expor um Drive inteiro, uma pasta ou um documento individual.

O espaço de trabalho pode exportar documentos e dados como arquivos Excel, CSV, PDF, Markdown ou HTML. As exportações para Word e PowerPoint estão planejadas, mas não estavam disponíveis quando a Cloudflare publicou o anúncio.

Essas adições ampliam o trabalho que o produto pode atender. Elas também ampliam sua superfície de risco. Um agente que pode ler e-mails, acessar arquivos, alterar código e enviar mensagens precisa de controles mais rigorosos do que um chatbot que apenas redige texto.

Essa tensão leva diretamente ao principal argumento da Cloudflare. A empresa vende operações gerenciadas, mas sua alegação maior diz respeito ao acesso governado a dados empresariais.

O Produto Real É uma Camada de Execução Governada

O Cloudflare OS combina um espaço de trabalho voltado ao funcionário com uma infraestrutura que controla o que os agentes podem ver, executar, preservar e compartilhar.

Um espaço de trabalho armazena conversas, arquivos, resultados, permissões, tarefas e eventos agendados. Diferentemente de uma sessão de chat comum, ele pode preservar o estado depois que o usuário fecha o navegador. Essa persistência permite projetos que continuam ao longo de várias sessões.

A arquitetura de referência da Cloudflare posiciona Workers e o Agents SDK na camada de orquestração. Durable Objects mantêm o estado, enquanto Dynamic Workers e contêineres sandbox executam tarefas que exigem código.

O AI Gateway controla o acesso a modelos aprovados. Portais do Model Context Protocol conectam o espaço de trabalho a ferramentas empresariais. MCP é uma interface padrão por meio da qual agentes descobrem ferramentas disponíveis e invocam suas operações.

A arquitetura mantém o modelo separado das credenciais e da aplicação de políticas. Essa separação é importante porque um modelo de linguagem não deveria receber uma chave de API amplamente privilegiada sempre que precisar de dados da empresa.

A Cloudflare usa serviços chamados Gatekeepers entre o Cloudflare OS e sistemas externos. Cada Gatekeeper entende o serviço de destino, os recursos disponíveis, as operações permitidas e as políticas organizacionais relacionadas.

Um Gatekeeper do GitHub poderia expor um repositório sem expor uma conta inteira. Ele poderia permitir acesso a issues enquanto retém o código-fonte. Também poderia exigir aprovação humana antes que um agente faça merge de um pull request.

O agente vê uma interface de programação limitada, em vez da credencial subjacente. A Cloudflare afirma que as credenciais permanecem isoladas do código gerado. O código no servidor também é executado com acesso de rede de saída desativado, a menos que um administrador forneça uma capacidade aprovada.

Esse modelo começa sem acesso. Um agente ou aplicação gerada deve receber permissão para cada recurso que utiliza. Essa estrutura segue o princípio do menor privilégio, que limita uma identidade aos recursos necessários para sua tarefa atribuída.

A Cloudflare vai além ao rastrear os recursos que um agente observa. Se um agente lê um conjunto de dados restrito e cria um dashboard, o dashboard mantém uma relação com essa fonte.

Quando outro funcionário abre o resultado, os Gatekeepers podem verificar se esse funcionário pode acessar os recursos observados. O objetivo é impedir que resultados gerados contornem as permissões associadas aos dados originais.

Esse problema se tornou central para agentes empresariais. A autorização tradicional responde se um usuário pode abrir um arquivo ou consultar uma aplicação. Sistemas agênticos podem combinar informações de vários recursos e produzir um novo artefato.

O novo artefato pode conter fatos sensíveis sem manter os controles de acesso do sistema original. Um resumo, gráfico, aplicação ou rascunho de e-mail pode se tornar um caminho indireto em torno dos limites de dados.

A abordagem da Cloudflare trata a proveniência das informações como parte da autorização. A plataforma tenta lembrar o que um agente viu e, em seguida, usar esse histórico ao determinar quem pode acessar seu trabalho.

Isso é mais do que uma estrutura de conectores. É uma tentativa de governar os dados depois que um agente os transformou.

A publicação de lançamento de código aberto explica por que a Cloudflare reconstruiu a plataforma em torno desse requisito. Sua primeira versão interna oferecia espaços de trabalho privados, mas a colaboração expôs riscos relacionados a aplicações e resultados compartilhados.

A Cloudflare concluiu que o acesso a uma ferramenta MCP não revelava todos os recursos subjacentes observados por meio dessa ferramenta. Por isso, adicionou controles que operam abaixo da interface do espaço de trabalho.

O design também separa o trabalho determinístico da inferência de modelos. Um agente pode transformar um procedimento recorrente em código e, depois, usar um modelo apenas onde o julgamento é necessário.

Considere um dashboard de suporte. O software pode recuperar contagens de tickets, agrupar registros e renderizar gráficos sem pedir a um modelo que repita essas etapas. Um modelo pode continuar disponível para classificar casos incomuns ou redigir respostas sugeridas.

Essa separação pode reduzir inferências desnecessárias e criar fluxos de trabalho mais previsíveis. Também torna o resultado mais fácil de inspecionar, porque o código padrão lida com operações repetíveis.

A Cloudflare afirma que suas próprias equipes usaram esse padrão para relatórios internos de tickets. Um agente criou uma aplicação conectada aos dados de tickets, enquanto os funcionários mantiveram autoridade de revisão sobre as respostas redigidas.

Esse continua sendo um exemplo relatado pela empresa, não um estudo independente de desempenho. Ainda assim, ele ilustra a progressão pretendida da plataforma: conversa, fluxo de trabalho reutilizável e aplicação persistente.

O repositório de código-fonte da empresa também traz um claro aviso de acesso antecipado. Ele descreve a versão dois como uma reescrita completa, com algumas arestas ainda a serem resolvidas. Esse aviso deve orientar qualquer avaliação do serviço gerenciado.

Uma implantação hospedada pode simplificar as operações, mas não pode tornar automaticamente um software inacabado adequado para fluxos de trabalho críticos. Os compradores precisam distinguir a gestão de infraestrutura da maturidade da aplicação.

Microsoft e Google Dominam os Aplicativos, Enquanto a Cloudflare Mira o Plano de Controle

O principal desafio da Cloudflare não é criar mais um agente. É superar rivais que já controlam onde os funcionários trabalham.

A Microsoft pode posicionar agentes dentro do Microsoft 365, Teams, SharePoint, Dynamics e Power Platform. O Google pode conectar agentes ao Workspace, Cloud, Drive, Gmail e à busca organizacional.

Essas posições reduzem o atrito de adoção. Os funcionários podem encontrar agentes em aplicações conhecidas, enquanto os administradores podem reutilizar controles existentes de identidade, conformidade e dados.

O plano de agentes empresariais da Microsoft abrange ferramentas low-code, runtimes gerenciados, conectores e serviços para desenvolvedores. O Copilot Studio atende equipes de negócios, enquanto o Microsoft Foundry atende desenvolvedores que criam sistemas mais personalizados.

O Google segue uma estratégia de plataforma semelhante. Seus produtos empresariais combinam interfaces para funcionários, acesso a modelos, busca, conectores, criação de agentes e administração centralizada.

A Cloudflare não possui uma grande suíte de produtividade. Ela não pode presumir que os funcionários já passem o dia em um editor de documentos, caixa de entrada, planilha ou aplicação de colaboração da Cloudflare.

Em vez disso, está posicionando o Cloudflare OS acima desses sistemas. O workspace se conecta às ferramentas existentes, enquanto a Cloudflare fornece execução, rede, aplicação de identidade e governança de modelos.

Esta é uma estratégia de plano de controle. Um plano de controle define políticas e coordena recursos, enquanto os aplicativos conectados permanecem como sistemas de registro.

A abordagem cria vantagens potenciais para ambientes mistos. Muitas organizações usam aplicativos da Microsoft, serviços do Google, GitHub, Salesforce, bancos de dados internos e vários provedores de modelos. Em teoria, um workspace neutro pode abranger essas fronteiras.

O Cloudflare OS também permite que os clientes escolham os modelos acessados pelo AI Gateway. Esse design evita vincular a interface do workspace a uma única família de modelos, embora as integrações disponíveis e os termos do serviço gerenciado continuem pouco claros.

A arquitetura se alinha à posição já estabelecida da Cloudflare em redes corporativas e segurança de aplicativos. Os clientes talvez já usem o Cloudflare Access para entrada em aplicativos com reconhecimento de identidade ou o AI Gateway para controles de tráfego de modelos.

Para essas organizações, o Cloudflare OS pode estender uma camada de políticas já estabelecida aos agentes dos funcionários. O argumento comercial é mais forte quando o cliente já configurou os serviços ao redor.

No entanto, a neutralidade tem um custo. Microsoft e Google podem oferecer comportamentos nativos mais profundos dentro de suas próprias suítes. A Cloudflare precisa reproduzir ou mediar essas ações por meio de Gatekeepers e APIs externas.

Cada integração adiciona trabalho de manutenção. O comportamento das APIs muda, os fluxos de autenticação evoluem e as permissões empresariais variam entre tenants. A Cloudflare precisa manter essas conexões confiáveis se quiser que o produto gerenciado pareça um único workspace.

A plataforma também precisa competir com infraestrutura gerenciada de agentes oferecida por provedores de nuvem. O runtime AgentCore da Amazon gerencia escalabilidade, tratamento de sessões, infraestrutura e isolamento para agentes implantados.

O AgentCore se concentra mais diretamente na execução de aplicações de agentes, enquanto o Cloudflare OS inclui uma interface para funcionários e ferramentas para produzir trabalho persistente. Os produtos se sobrepõem na camada de execução gerenciada, mesmo quando suas experiências de usuário diferem.

Essa concorrência mostra como o mercado está se dividindo em várias camadas. Provedores de modelos fornecem sistemas de raciocínio. Plataformas de nuvem executam agentes. Suítes de produtividade oferecem superfícies para usuários. Serviços de integração conectam ferramentas empresariais.

A Cloudflare está tentando reunir várias camadas sem possuir os aplicativos subjacentes. Sua diferenciação depende de saber se a governança e a execução entre sistemas superam a conveniência de agentes nativos de suítes.

Isso torna o contexto de aquisição decisivo. Uma empresa padronizada no Microsoft 365 pode preferir seu ambiente administrativo existente. Uma organização com sistemas heterogêneos pode atribuir mais valor a um workspace neutro em relação a modelos e aplicativos.

Os desenvolvedores enfrentam uma escolha semelhante. Podem criar agentes separados para trabalhos individuais ou oferecer aos funcionários um workspace compartilhado que possa criar ferramentas à medida que surgem necessidades.

O modelo de workspace pode reduzir a fragmentação. Os funcionários mantêm um único histórico de agentes, um conjunto de capacidades aprovadas e uma biblioteca de habilidades organizacionais. As equipes podem compartilhar procedimentos em vez de recriar prompts para cada tarefa.

Ele também pode concentrar riscos. Um único workspace conectado a muitos sistemas torna-se uma fronteira de segurança importante. Um erro de configuração ou uma integração defeituosa pode afetar vários fluxos de trabalho em vez de um único agente restrito.

Essa troca explica por que a edição gerenciada importa. A Cloudflare está pedindo aos clientes que confiem a ela a operação de um workspace que atravessa sistemas sensíveis, e não apenas a hospedagem de uma interface web.

As Operações Gerenciadas Não Resolvem o Problema de Confiança

A lista de espera elimina parte do trabalho de implantação, mas a Cloudflare ainda não apresentou evidências suficientes para resolver questões de segurança, confiabilidade e adoção.

A primeira incerteza diz respeito à maturidade do produto. O Cloudflare OS continua sendo um software de acesso antecipado e código aberto, e o serviço gerenciado não tem data de disponibilidade anunciada.

Uma lista de espera pode medir o interesse antes que a Cloudflare se comprometa com capacidade e recursos de suporte. Ela também significa que os compradores ainda não podem avaliar um contrato final, limite de serviço ou modelo operacional.

A Cloudflare não publicou detalhes do serviço gerenciado que cubram residência de dados, políticas de backup, resposta a incidentes, cronogramas de atualização, objetivos de recuperação ou integrações compatíveis. Esses detalhes importarão mais do que a conveniência de instalação.

A segunda incerteza diz respeito à precisão da autorização. Rastrear recursos observados é uma resposta cuidadosa ao vazamento de dados, mas as permissões empresariais reais são complexas.

As regras de acesso podem depender de função, localização, projeto, postura do dispositivo, campos de registros, retenções legais ou exceções temporárias. Um Gatekeeper deve interpretar corretamente essas restrições tanto durante a leitura quanto no compartilhamento.

Aplicativos gerados adicionam outra camada. Um aplicativo pode preservar dados, transformar campos, armazenar resultados em cache e aceitar entradas de vários usuários. A aplicação de políticas precisa sobreviver a todas essas transições.

A Cloudflare afirma que os Gatekeepers registram observações e verificam o acesso quando o trabalho é compartilhado. Testes independentes ainda não estabeleceram como esse modelo lida com cada transformação, revogação ou inferência indireta.

A revogação merece atenção especial. Se um funcionário perde acesso a uma fonte depois que um agente cria uma saída, o sistema precisa decidir se esse funcionário pode manter o material derivado.

Os administradores também precisarão de registros de auditoria compreensíveis. Um log que mostra que um agente chamou uma ferramenta é insuficiente se os investigadores não conseguem determinar quais registros influenciaram uma saída.

A terceira incerteza diz respeito ao código gerado. O Cloudflare OS permite que agentes escrevam e executem software em ambientes isolados. O isolamento reduz a exposição, mas o código gerado ainda pode conter erros de lógica.

Um fluxo de trabalho pode selecionar os registros errados, aplicar incorretamente um filtro, enviar um relatório incompleto ou executar uma ação não intencional. Essas falhas podem ocorrer sem escapar do sandbox.

Os controles de aprovação podem limitar efeitos colaterais prejudiciais. Eles também podem criar trabalho constante de revisão se cada ação relevante precisar de confirmação humana.

As organizações precisarão de diferentes níveis de autonomia para tarefas distintas. Ler um documento aprovado apresenta menos risco do que enviar e-mail, alterar código-fonte ou atualizar o registro de um cliente.

A quarta incerteza diz respeito à profundidade das integrações. A Cloudflare destaca GitHub e Google Workspace, mas a maioria das empresas depende de muitos outros sistemas. Um workspace gerenciado só se torna útil quando seus conectores correspondem ao trabalho real.

Conectar um sistema não basta. A integração precisa compreender permissões granulares, manter uma autenticação estável, lidar com falhas e expor ações de uma forma que os agentes possam usar com segurança.

A quinta incerteza diz respeito à adoção. Dar um agente a cada funcionário não garante que eles reformularão seu trabalho em torno dele.

Os trabalhadores precisam de habilidades organizacionais confiáveis, exemplos claros, práticas de revisão e suporte. As equipes também precisam concordar sobre quais resultados exigem verificação.

A Cloudflare afirma que milhares de seus funcionários usam a plataforma interna e que as equipes criaram milhares de ferramentas. Esses números demonstram atividade interna, mas continuam sendo estimativas da empresa em seu próprio ambiente.

Os funcionários da Cloudflare também têm acesso incomum às pessoas que desenvolvem o produto. Clientes externos podem enfrentar condições diferentes de integração, suporte, conformidade e gestão de mudanças.

Uma implantação gerenciada pode reduzir o trabalho de infraestrutura. Ela não pode organizar o conhecimento da empresa, resolver procedimentos pouco claros ou decidir quais fluxos de trabalho merecem automação.

As organizações devem tratar essa preparação como um projeto de gestão do conhecimento. Uma base de conhecimento de equipe confiável precisa de responsabilidade definida, regras de acesso, material atualizado e processos para corrigir orientações desatualizadas.

O Cloudflare OS depende de contexto selecionado e habilidades reutilizáveis. Se essas entradas entrarem em conflito ou se tornarem obsoletas, o agente poderá executar o procedimento errado com mais eficiência.

O serviço gerenciado, portanto, precisa provar duas coisas. A Cloudflare deve operar a plataforma técnica de forma confiável, enquanto os clientes devem manter a camada organizacional que fornece aos agentes instruções úteis.

Nenhuma dessas responsabilidades desaparece com alguns cliques de implantação.

Três Sinais Mostrarão se o Cloudflare OS Pode se Tornar Infraestrutura Empresarial

A próxima etapa depende de detalhes do serviço, evidências em produção e provas de que o modelo de governança da Cloudflare funciona fora da própria organização.

O primeiro sinal é uma versão gerenciada com definição clara. A Cloudflare precisa publicar disponibilidade, regiões compatíveis, cobertura de integrações, controles administrativos e limites de responsabilidade.

Um lançamento sem esses detalhes enfraqueceria o argumento de infraestrutura. Um modelo operacional documentado o fortaleceria, especialmente para equipes de segurança e conformidade que avaliam o uso de longo prazo.

Os compradores devem buscar respostas claras sobre localização dos dados, roteamento de modelos, logs, backups, tratamento de incidentes, atualizações e isolamento entre tenants. Também devem examinar como as implantações gerenciadas diferem das instalações operadas pelos clientes.

O segundo sinal é a adoção independente em produção. A declaração da Cloudflare sobre milhares de organizações descreve interesse inicial, mas não revela uso sustentado.

Evidências mais fortes incluiriam clientes identificados, fluxos de trabalho definidos, escala de implantação, feedback de administradores e taxas de erro medidas. Estudos de caso devem explicar como as organizações lidaram com permissões e revisão humana.

A profundidade de uso importa mais do que o tamanho da lista de espera. Um piloto que cria apresentações de exemplo tem um significado diferente de um workspace conectado a sistemas operacionais.

A Cloudflare também deve distinguir usuários ativos de usuários registrados. O valor da plataforma depende de trabalho repetido, aplicativos reutilizáveis e habilidades organizacionais compartilhadas.

O terceiro sinal é como Microsoft, Google e Amazon respondem ao modelo de workspace. Seus produtos já cobrem muitas das capacidades ao redor, e cada uma pode fechar lacunas por meio de integração mais estreita.

Se as principais plataformas adicionarem proveniência mais forte entre sistemas e habilidades organizacionais portáteis, a distinção de governança da Cloudflare diminuirá. Se permanecerem centradas em suas próprias suítes, a posição neutra da Cloudflare se tornará mais valiosa.

A Cloudflare também precisa mostrar que suas versões de código aberto e gerenciada podem avançar juntas. O código aberto atrai personalização e escrutínio, enquanto um serviço hospedado cria pressão por estabilidade.

Essa combinação pode se tornar uma vantagem se os clientes puderem inspecionar a plataforma, controlar integrações e alternar entre modelos operacionais. Ela se torna uma desvantagem se as versões mudarem rápido demais para que as empresas possam validá-las.

O workspace de agentes gerenciado do Cloudflare OS é, portanto, mais do que um anúncio de hospedagem. Ele testa se as empresas querem um ambiente governado onde os funcionários possam pesquisar, criar, programar e automatizar em sistemas existentes.

A Cloudflare apresentou uma arquitetura crível para esse ambiente. Ainda não apresentou um produto gerenciado concluído nem evidências independentes de que o modelo funcione em empresas variadas.

As organizações que consideram a lista de espera devem começar com fluxos de trabalho restritos e reversíveis. Devem identificar os dados necessários, as ações permitidas, os pontos de aprovação humana e a responsabilidade pelas habilidades organizacionais.

A pergunta mais útil não é se cada funcionário deve receber um agente. É se um workspace governado pode substituir com segurança uma coleção crescente de experimentos desconectados com agentes.

A Cloudflare agora precisa provar que operações gerenciadas, acesso granular e produtos de trabalho persistentes podem responder a essa pergunta em produção.