Muchos equipos tienen necesidades que no llegan a justificar una aplicación: un comparador para revisar propuestas, un registro de decisiones o un inventario que solo hará falta durante una migración. Suelen resolverse con lo que ya hay a mano. Construir algo propio obliga a decidir dónde se aloja, cómo se guardan los datos y quién puede entrar. A veces ese trabajo alrededor pesa más que la herramienta.
En Cuando el software dura lo mismo que el problema hablábamos de aplicaciones que se generan para una tarea concreta. Pero escribir el código es solo una parte: hace falta un sitio donde funcionen, conserven lo que hacemos y puedan compartirse. Cloudflare OS propone ese sitio. En Codin lo hemos desplegado para explorar qué se puede hacer con él.
Un entorno de trabajo que también puedes modificar
Cloudflare OS es un proyecto abierto de Cloudflare que reúne agentes de IA, pequeñas aplicaciones y acceso controlado a servicios externos. Se utiliza desde el navegador y puede desplegarse en una instalación propia.
La comparación que propone Cloudflare ayuda a entenderlo: imagina una suite de oficina donde cada archivo pudiera ser una aplicación a medida. En lugar de elegir siempre entre documento, hoja de cálculo o presentación, podrías crear una herramienta con los campos, las vistas y las acciones que necesitas. OS llama gadgets a esas aplicaciones, que puedes adaptar y compartir.
La diferencia se aprecia con algo sencillo. Supongamos que queremos comparar propuestas de varios proveedores. Una tabla recoge los datos, pero quizá también necesitamos marcar dudas, conservar la explicación de cada valoración y mostrar solo las diferencias relevantes. Una aplicación propia permitiría reunir ese recorrido en una misma pantalla. El interés de OS está en ofrecer un entorno común para construir herramientas así, sin preparar una infraestructura distinta para cada una.
Ejemplo ilustrativoDe una idea a una herramienta
Conversación
Quiero comparar tres propuestas de proveedores: plazo, alcance y soporte.
Preparo un comparador con una columna por propuesta y una fila por criterio.
Añade las condiciones de cada una y deja filtrar por soporte incluido.
Describe: la petición parte de una tarea concreta. Basta con explicar qué hay que comparar y con qué criterios.
Construye: el asistente propone una primera versión del gadget. Aquí es un esquema con tres proveedores ficticios, plazos y alcance.
Adapta: durante la revisión aparece una necesidad nueva. La herramienta suma una fila de condiciones y un filtro que deja en segundo plano la propuesta sin soporte incluido.
De pedir una herramienta a trabajar con ella
El asistente integrado permite describir un gadget y pedir cambios sobre él. La conversación puede continuar cuando la primera versión ya existe: añadir una vista, cambiar cómo se presenta un resultado o incorporar una acción. El código de la herramienta queda disponible para seguir modificándolo.
Esto cambia la relación con una aplicación pequeña. Volviendo al comparador, descubrir a mitad de la revisión que falta registrar una condición del proveedor podría dar lugar a un cambio en la herramienta. Ya no tendríamos que encajar toda la tarea en las posibilidades de la primera pantalla. Naturalmente, habría que comprobar que ese cambio conserva los datos y hace lo que esperamos.
En OS, la conversación y la aplicación conviven en el mismo espacio. A la izquierda queda el encargo y su historial; a la derecha podemos usar el gadget, abrir sus archivos o revisar los servicios que tiene conectados. Estas son las tres vistas de nuestra instalación:
Capturas realesUn gadget, tres formas de trabajar
1 · El encargo permanece a la vista. En este caso: un CRM con pipeline, seguimiento y oportunidades de Radar. Debajo queda registrado que se aceptaron los cambios.
2 · La aplicación se usa al lado. La pestaña App abre el gadget: se puede consultar el tablero y trabajar con sus datos sin salir del espacio.
1 · Los archivos están accesibles. Code reúne la interfaz y la lógica del gadget. Podemos pasar de la aplicación a su implementación en una pestaña.
2 · Las reglas se pueden revisar. Aquí se ven las etapas del CRM y el contexto que utiliza. La conversación sigue al lado mientras inspeccionamos el código.
1 · Los recursos del gadget tienen su propio panel. Connections muestra el modelo disponible y el nombre con que lo usa el código: LUNA. Esa conexión permite pedir un análisis desde el CRM.
El CRM nos sirvió para probar ese recorrido con información pública importada desde Codin Radar. Es una primera versión, con importación manual, pero reúne una aplicación que conserva sus datos, código que podemos modificar y una conexión a IA para analizar oportunidades.
El ejemplo también separa dos usos de la IA. Uno ayuda a escribir la herramienta; otro realiza una tarea dentro de ella. Guardar una nota o cambiar una etapa sigue siendo software convencional. La aplicación no necesita que un modelo vuelva a imaginarla cada vez que alguien la usa.
Construir con las herramientas que ya usas
En nuestra prueba escribimos el gadget con Codex, desde nuestro entorno habitual, y lo instalamos mediante la API de OS. Esa API utiliza Cap’n Web, una biblioteca de Cloudflare para llamar a funciones remotas desde JavaScript. El proceso consistía en cambiar el código, revisarlo y enviar la nueva versión.
Esta posibilidad nos parece especialmente útil para equipos técnicos. Podemos conservar el editor, el modelo y la forma de revisar código con los que ya trabajamos. OS queda como el lugar donde la aplicación se ejecuta y mantiene sus datos, aunque la construcción ocurra fuera de su asistente.
También permite repartir el trabajo. Alguien puede plantear lo que necesita y revisar la interfaz; otra persona puede ocuparse de las partes que requieren más cuidado. La conversación ayuda a concretar la herramienta y el código sigue estando ahí cuando hace falta entender o corregir su comportamiento.
Compartir una herramienta o reutilizar su diseño
OS distingue entre acceso para usar y para construir. Quien recibe el primero trabaja con la aplicación y sus funciones; quien recibe el segundo también puede modificar el código. Usar no significa únicamente leer: un gadget puede permitir registrar información o pedir un análisis sin conceder acceso a su desarrollo.
Hay otra forma de compartir que resulta igual de interesante: los blueprints. Son plantillas de aplicaciones completas. Permiten que otra persona cree su propia copia del gadget con almacenamiento y conexiones propios, sin llevarse el historial, los datos guardados o las credenciales de la instancia original.
La diferencia es práctica. Un equipo podría trabajar junto en el mismo inventario de una migración. Otro podría reutilizar su diseño para una migración distinta, con sus propios sistemas y responsables. En el primer caso comparten el trabajo; en el segundo, una herramienta que les ahorra empezar desde cero.
Ejemplo ilustrativoCompartir el trabajo o el diseño
Lucíamisma instanciainstancia original
Migración Norte
- Servidor de correo Lucía: revisar DNS
- Base de clientes Andrés: exportada
- VPN de oficina Lucía: pendiente
Andrésmisma instanciacopia nueva
Migración Norte
- Servidor de correo Lucía: revisar DNS
- Base de clientes Andrés: exportada
- VPN de oficina Lucía: pendiente
Migración Sur
- Portal de proveedores Andrés: pedir acceso
- Almacén de ficheros
- Impresoras de planta Andrés: inventariar
Trabajar juntos: las dos personas abren la misma herramienta y ven los mismos datos, así que lo que anota una aparece para la otra. Con acceso para usar pueden registrar información; cambiar el código requiere acceso para construir.
Crear una copia: un blueprint describe la aplicación completa y permite crear otra instancia con su propio almacenamiento y conexiones. Se reutiliza el diseño; el historial, los datos y las credenciales del original no pasan a la copia.
Las conexiones externas también tienen su lugar en la propuesta. OS utiliza Gatekeepers, componentes que median el acceso de agentes y gadgets a recursos concretos. Eso requiere configurar las integraciones correspondientes: desplegar OS no conecta automáticamente todos los sistemas de la empresa.
Qué merece tener su propia herramienta
Cloudflare presenta OS como un proyecto todavía en desarrollo. Nuestra experiencia también es temprana: hemos probado una aplicación, no medido un cambio en la productividad del equipo. Y una herramienta propia sigue necesitando mantenimiento; un producto consolidado puede resolver mejor un proceso que depende de muchas integraciones o necesita soporte continuo.
Aun así, merece la pena mirar ese espacio de tareas pequeñas que las herramientas genéricas cubren solo a medias. Un revisor de propuestas puede acompañar un proceso recurrente. Un inventario de migración quizá solo tenga sentido durante unas semanas. Ambos necesitan una interfaz, unas reglas y datos que se conserven, aunque su duración sea distinta.
Lo que queremos seguir explorando en Cloudflare OS es esa posibilidad: tener preparado el lugar donde esas herramientas pueden vivir. Si cada una exige arrancar un proyecto entero, muchas ni se plantean. Si parte del trabajo ya está resuelto, la pregunta puede acercarse más a la tarea: qué necesitamos hacer y qué aplicación nos ayudaría a hacerlo.
