Cloudflare OS: la plataforma agentic open source

Cuando vi el anuncio, lo primero que pensé fue: "otra más con un chatbot y conectores". Y es verdad que empieza igual que todos — abrís el browser, escribís un prompt, y del otro lado hay un agente. La diferencia es todo lo que viene después, y tiene nombre propio: Cloudflare OS, liberado como open source esta semana en el blog oficial de Cloudflare y disponible en GitHub. No es un wrapper de LLM. Es una plataforma agentic completa, diseñada para que tu empresa la adopte, la conecte a sus sistemas y la haga propia.

Si ya venís siguiendo el tema de agentes — y especialmente lo que cubrimos en mcp-2-0-stateless-cambio-de-juego-para-servidores sobre el nuevo Model Context Protocol — este anuncio es la otra mitad del rompecabezas: no solo cómo los agentes hablan con tus herramientas, sino dónde corren, qué pueden tocar y qué no.

La primera versión les dejó una lección

Cloudflare viene usando una versión interna de esta plataforma hace meses, y la publicaron ahora con cambios importantes. Su CIO, Sam Rhea, lo cuenta en detalle en su blog post, pero la versión corta es esta: la primera iteración se centraba en personas trabajando con agentes dentro de workspaces privados. Las apps eran estáticas, no software vivo conectado a los sistemas internos. Y los jobs que eran mayormente determinísticos obligaban a gastar tokens de modelo cuando en realidad no hacía falta un agente completo.

Pero la lección más fuerte vino cuando empezaron a compartir workspaces entre equipos. El problema no fue técnico al principio: Access al MCP server te dice qué tools puede invocar un agente, pero no te dice a qué recursos subyacentes tuvo acceso. Si alguien abre un workspace compartido, no hay forma de saber si ese workspace leyó una tabla financiera sensible, aunque la persona que lo abre no tenga permiso para ver esa tabla directamente. La gobernanza estaba afuera del protocolo.

Esa fue la decisión de diseño central de la nueva versión: la seguridad tiene que ser parte de la plataforma, no algo que cada persona o cada app implementa por su cuenta. Y eso cambió la arquitectura entera.

El principio rector: un agente en Cloudflare OS empieza sin acceso a nada. Todo lo que va a usar tiene que ser solicitado, concedido, y queda registrado para auditoría posterior. La credencial nunca llega al modelo.

Qué es Cloudflare OS hoy

La plataforma tiene tres pilares que se complementan, y entenderlos bien evita el error de tratarla como "otro Claude Cowork".

1. Workspaces de agente con contexto curado

Un workspace combina sesiones de agente, estado persistente, archivos generados, recursos accesibles y un runtime aislado donde el agente puede escribir y ejecutar código. La interacción es 100% desde el browser, no necesitás saber usar una terminal.

Lo importante es que cada workspace arranca con el contexto y las skills que tu equipo ya curó. Si alguien de tu equipo ya descubrió la mejor forma de hacer X, esa knowledge queda disponible para todos los demás workspaces sin tener que explicarle el proceso al modelo cada vez. Es la misma idea de un SKILL.md pero elevada a nivel organizacional.

Y el runtime donde corre el código que el agente escribe es aislado: server code corre en un Dynamic Worker con networking de salida deshabilitado, client code corre en un frame sandboxed en el browser. Ni el modelo ni el código generado pueden llegar a internet salvo a través de capabilities explícitamente provistas.

2. Gatekeepers: el nuevo modelo de gobernanza

Acá está la parte que más me gustó conceptualmente. Un Gatekeeper es un Worker específico del servicio que querés conectar, que se sienta entre Cloudflare OS y ese servicio externo. Entiende la API, los recursos, las operaciones posibles, y aplica la política de tu empresa antes de que el agente toque nada.

Pensalo así. Hoy, la forma default de darle acceso a un agente a tu GitHub es darle un token con permisos amplios. Un Gatekeeper te permite algo mucho más granular:

• Acceso a un solo repositorio, no a toda tu cuenta
• Lectura de issues pero no del código fuente
• Mascarar campos sensibles en las respuestas
• Rate limits por agente, por persona, por workspace
• Requerir approval humano antes de mergear un pull request

El agente y sus apps ven una API chica y tipada en TypeScript. El Gatekeeper se ocupa del OAuth, sostiene la credencial, enforcea la policy, registra qué se leyó, y media cualquier cosa con un side effect visible hacia afuera. La credencial está completamente aislada del agente y del código que genere.

// Lo que el agente ve: una API tipada, sin credenciales
const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open"
});

// env.PROJECT es una capability que representa permiso para usar
// un recurso específico bajo una policy específica.
// La credencial real nunca aparece en este código.

3. Apps personales, modificables, compartibles como documentos

El tercer pilar es el que más cambia la dinámica de equipo. En una suite de productividad tradicional, tenés un set fijo de aplicaciones: documentos, hojas, presentaciones. En Cloudflare OS, cada "archivo" puede ser su propia aplicación, escrita por un agente para una persona, un proyecto o un equipo.

Cuando le pedís a tu workspace que arme una app, el agente escribe dos cosas: client code que renderiza la UI en el browser, y server code que guarda estado e implementa la lógica. El server se carga bajo demanda como un Dynamic Worker y se instancia como un Durable Object Facet (features nuevos que Cloudflare construyó para este proyecto). El facet le da a la app su propia base SQLite, separada del runtime de Cloudflare OS que la maneja. Los Dynamic Workers usan V8 isolates livianos, así que cada app puede tener su propio runtime aislado sin necesidad de un container o un server dedicado dando vueltas.

El browser client habla con el server usando Cap'n Web, el sistema de RPC open source de Cloudflare basado en object-capabilities. Un método del server se puede llamar desde el client como una función normal de JavaScript:

// Desde el cliente: una llamada a un método del server
const issues = await app.listIssues({ status: "done" });

Y acá viene la parte especial: el agente también puede llamar al mismo método. Si vos podés construir una herramienta para hacer un trabajo, los agentes pueden usar tu herramienta para hacer ese trabajo cuando vos no estás. Es la misma idea de las tools de MCP pero con tu código interno como primera clase.

Compartir la app, o compartir cómo se construyó

Hay dos formas de compartir lo que armaste:

• Compartir la app permite que otra persona colabore en tiempo real usando el mismo estado.
• Compartir el blueprint permite que otra persona arme su propia copia. La copia tiene el código original, pero no tiene los datos SQLite, el historial de conversación, las credenciales ni los recursos conectados. Cada instancia arranca con estado y recursos independientes.

La consecuencia práctica es enorme: cuando compartís una app con tu equipo, ellos pueden modificarla ellos mismos con IA en lugar de tener que pedirte un feature y esperar a que vos lo implementes. Es la diferencia entre "el software que compraste" y "el software que podés cambiar".

El detalle de policy que cierra todo

Hay un caso de borde que a mí me parece el más importante, y que muchos diseños de agentes忽略an. Supongamos que un agente lee una tabla sensible de un data warehouse y la usa para producir un dashboard en vivo. Compartir el dashboard no puede ser una forma de compartir la tabla con gente que no tenía acceso directo a ella.

Cloudflare OS registra cada recurso que los agentes observan. Esas observaciones quedan adjuntas al agente y a su trabajo. Cuando otra persona intenta abrir el workspace, interactuar con el agente, o ver lo que produjo, los Gatekeepers verifican el acceso de esa persona a los recursos observados. Si la persona no tenía permiso para ver la tabla original, tampoco puede ver el dashboard derivado.

El mismo log de observaciones se usa para informar las políticas que deciden cuándo los agentes pueden hacer requests externos. Una lectura de datos sensibles puede impedir que el agente escriba a ciertas fuentes, invite nuevos colaboradores, pase trabajo a otro agente o haga un request de salida. Todo eso sin que la persona que usa el agente tenga que pensarlo: la plataforma lo maneja.

Modelos, costos y control

Cloudflare OS funciona con cualquier modelo. Cada llamada de inferencia pasa por Cloudflare AI Gateway, lo que le da a tu organización un solo lugar para decidir qué modelos están disponibles y qué modelo tiene que usar cada job. No todo necesita el modelo más caro: resumir tus emails no leídos cada mañana no se beneficia de un frontier model, y la Gateway te da el control para que los modelos caros solo se usen en el trabajo difícil.

Cada request queda atribuido a la persona, equipo o workspace que la hizo. Los administradores pueden ver a dónde se va el spend de inferencia, setear presupuestos y rate limits, y decidir qué pasa cuando se llega a un límite. Es el tipo de control que una empresa mediana necesita y que hoy tiene que implementar a mano con wrappers sobre las APIs de cada proveedor.

Open source para que sea tuyo

Lo que me parece más relevante del anuncio: Cloudflare OS es open source desde el día uno. El repositorio en GitHub tiene el core, y hay un segundo repositorio de deployment que consume el core sin patchearlo, providing un lugar para configuración, UI custom, integraciones internas, analytics y pipelines de deployment.

El deployment interno de Cloudflare refleja los sistemas, la terminología, las policies y la forma de trabajar de Cloudflare. El tuyo debería reflejar la tuya. La idea es que la plataforma sea personalizable — podés cambiar la interfaz, agregar Gatekeepers internos, construir features específicas de tu organización sin tocar el core.

Y si querés acelerar el rollout, los partners estratégicos de Cloudflare (Presidio y Happy Cog) ofrecen paquetes de implementación que incluyen curaduría de skills y contexto institucional, construcción de interfaces custom, conexión a sistemas internos vía Gatekeepers y MCP Server Portals, y configuración de los controles de seguridad, modelos y costos. No es obligatorio — podés arrancar vos solo con el repo — pero el camino paid existe y es razonable para empresas sin un equipo de plataforma dedicado.

Por qué importa más allá del hype

Cada semana aparece un anuncio de plataforma agentic nueva. La mayoría son wrappers sobre un modelo con un nombre marketinero. Cloudflare OS me parece diferente por tres razones concretas, no por el press release.

Primero, el modelo de seguridad es estructural, no opt-in. Si querés que tu agente pueda tocar producción, la plataforma no te deja hacerlo a menos que la policy esté escrita y aplicada. No es una feature que activa el usuario proactivo; es el default. Para empresas medianas con equipos de seguridad reales, eso cambia la conversación de "¿podemos usar agentes?" a "¿qué Gatekeepers necesitamos?".

Segundo, el código de la app y el código del agente son la misma cosa. Cuando construís una tool, el agente la puede usar. No hay un proceso de "exportar la app, hacer un MCP server, hostearlo, registrarlo". Tu función de JavaScript es directamente invocable por el agente, con el mismo sistema de capabilities. Para un developer, eso es una cantidad enorme de fricción que desaparece.

Tercero, las observaciones son la policy. En vez de mantener una lista de "este agente puede acceder a estos recursos", el sistema registra lo que efectivamente vio y propaga esa restricción a cualquier output derivado. Es la única forma sensata de hacer data lineage en un mundo donde los agentes generan derivados automáticamente. Si trabajaste con DLP o con data governance, sabés lo que eso significa.

Cómo arrancar

Si querés probarlo hoy, el camino corto es:

1. Clonar el repo de Cloudflare OS y el repo de ejemplo de deployment.
2. Configurar tu cuenta de Cloudflare con tus propias Access policies, AI Gateway configuration, y los Gatekeepers a los sistemas que querés exponer.
3. Customizar la interfaz, las skills, y el contexto institucional para que refleje cómo trabaja tu equipo.
4. Desplegar y empezar a iterar.

El post oficial en el blog de Cloudflare tiene todos los links y un demo. Si te interesa la parte más técnica de cómo encaja con el ecosistema MCP, te recomiendo releer mcp-2-0-stateless-cambio-de-juego-para-servidores después — Cloudflare OS expone tus MCP servers existentes a través de MCP Server Portals, así que no tenés que reescribir nada de lo que ya tengas.

Lo que sigue, según Cloudflare: traer Cloudflare OS al dashboard como producto completamente managed, agregar containers para workflows de desarrollo, y llevar los workspaces a Slack y otras herramientas de chat. El open source de hoy es el piso, no el techo. Vale la pena mirarlo de cerca.