Cloudflare OS łatwo skrytykować za nazwę: to nie jest klasyczny system operacyjny. Mimo to premiera jest ważna, bo wskazuje następny problem adopcji AI w firmach: nie wystarczą lepsze chatboty. Potrzebne są zarządzane workspace’y, w których agenci czytają kontekst firmy, budują małe aplikacje, proszą o uprawnienia, zostawiają audyt i kontrolują koszty modeli.

Firmowy workspace AI z izolowanymi aplikacjami, Gatekeepers, akceptacjami i sejfami danych

Cloudflare ogłosił Cloudflare OS 5 sierpnia o 13:00 UTC jako otwartą platformę dla agents, apps and work. Firma twierdzi, że od maja 2026 tysiące pracowników używa wczesnej wersji do dokumentów, slajdów, powtarzalnych zadań i małych aplikacji. Publicznie dostępne są cloudflare-os i cloudflare-os-starter; główne repo miało przy sprawdzeniu około 3,900 stars, 270 forks, licencję Apache-2.0 i świeże commity.

Dyskusja na Hacker News — około 561 points i 270 comments — pokazała zainteresowanie i obawy: czy to naprawdę OS, lock-in Cloudflare, koszt Workers, bezpieczeństwo, porównanie do Sandstorm i ryzyko chaosu jak w SharePoint.

Dlaczego chatbot nie wystarczy

Chatbot pomaga, dopóki praca jest pytaniem i odpowiedzią. Workflows wymagają stanu, uprawnień i skutków. Sales ops potrzebuje CRM, finance tabel i definicji, support ticketów i approvals. Wklejanie kontekstu do czatu albo przekazanie szerokiego API tokenu to nie architektura.

Warstwa enterprise AI powinna być workspace’em: company context, skills, documents, generated apps, connected systems, logs, access control and budgets. Agent staje się runtime’em do pracy wewnętrznej, a nie tylko oknem czatu.

Propozycja Cloudflare

Cloudflare opisuje trzy elementy. Pierwszy to agent workspace z kontekstem i shared skills. Drugi to security/governance: agenci zaczynają bez dostępu, dostają konkretne capabilities przez Gatekeepers, a credentials są izolowane od generated code. Cloudflare mówi, że server code działa w Dynamic Worker z global outbound networking disabled, a client code w sandboxed browser frame.

Trzeci element to personal modifiable apps. Aplikacje są private by default, można je udostępniać jak dokumenty i jako blueprints bez SQLite data, conversation history, credentials czy connected resources. Ważne nie jest tylko “AI writes code”, ale to, że aplikacja ma wąski sandbox.

Gatekeepers są sednem

Gatekeeper to Worker między agentem a usługą. Zamiast szerokiego API key agent dostaje wąską możliwość: przeczytać tabelę, utworzyć ticket, streścić folder, poprosić o approval. Gatekeeper może maskować pola, limitować wywołania, wymagać akceptacji i logować, co agent zobaczył.

To zmienia pytanie z “czy agent ma Salesforce?” na “jaka akcja, na jakich danych, pod czyją tożsamością, z jakim limitem i logiem?”. To właściwy kierunek. Ale źle napisany Gatekeeper będzie po prostu kolejnym nadmiernym connectorem.

Policy musi iść za danymi

Cloudflare podkreśla, że policy follows what the agent observed. Jeśli agent czyta sensitive table i robi dashboard, udostępnienie dashboardu nie powinno omijać uprawnień tabeli. Summary z prywatnego dokumentu nie staje się publiczne tylko dlatego, że jest nowym tekstem.

Derived artefacts to jeden z głównych problemów enterprise AI: streszczenia, wykresy, mini-apps i code mogą zdradzać źródła. Observation logs nie rozwiązują wszystkiego, ale pomagają odpowiedzieć, co agent czytał, kto to zlecił, jaki model użyto i gdzie trafił output.

Dobre pilotaże

Najlepsze starty są nudne: weekly sales summaries z approved CRM fields, support dashboards, data cleaning, internal FAQ, incident review templates, procurement tables i małe reporting apps. Zacznij od jednego lub dwóch Gatekeepers, read-only by default, strict logs, małej grupy użytkowników, budżetu i human approval dla write actions.

Ryzyka

Lock-in jest realny. Projekt jest open source na Apache-2.0, ale mocno opiera się o Workers, Dynamic Workers, Durable Objects, Access i AI Gateway. Dla klientów Cloudflare może to być sensowny trade-off; to nie pełna przenośność.

Koszty mogą zaskoczyć. AI Gateway daje attribution, budgets i rate limits, ale agenci potrafią generować dużo model calls. Potrzebne są hard budgets, per-user attribution i anomaly alerts.

Najbardziej przyziemny problem to app sprawl: dziesiątki personal apps stają się ważne, ale nikt nie ma ownership, versioning ani retirement. Bez zasad lifecycle dostajemy szybszy problem SharePoint.

Jak oceniać

Pytaj, co agent może czytać domyślnie. Bezpieczna odpowiedź: nic. Czy outbound networking jest wyłączony? Czy read-only i side effects są osobnymi capabilities? Czy approval wymusza infrastruktura, a nie prompt? Czy credentials są scoped i krótkie? Czy logs nadają się do audytu? Czy generated apps mają owners, wersje i proces wycofania?

Microsoft, Google, OpenAI, Anthropic, Retool, Appsmith, Zapier, n8n, Dify i Langflow celują w tę samą warstwę workflow. Cloudflare wyróżnia się infrastrukturą i Zero Trust. Pytanie nie brzmi, czy Cloudflare OS to prawdziwy OS. Pytanie brzmi, czy firma umie ustalić operating rules dla agentów, zanim ludzie oprą na nich realną pracę.