OpenClaw: la arquitectura de un agente que trabaja 24/7
Casi todos hemos hablado con un asistente de IA que nos contesta con mucha educación y luego no mueve un dedo. Te explica cómo ordenar el correo, pero el correo sigue ahí. OpenClaw parte de la idea contraria: un agente que vive en tu propia máquina, no se apaga y, además de responder, actúa.
Vamos a abrir el capó. Veremos cómo está construido, por qué puede trabajar las 24 horas y qué ha pasado con su seguridad, que merece capítulo propio. Por el camino separaremos lo confirmado de lo estimado y de lo que solo son expectativas.
Qué es OpenClaw y qué problema resuelve
OpenClaw es un agente de IA autónomo, de código abierto y autoalojado. Ejecuta tareas reales (leer y escribir ficheros, lanzar comandos, navegar, gestionar correo y calendario) y usa como interfaz las aplicaciones de mensajería de siempre. Su lema oficial es «The AI that really does things» («La IA que de verdad hace cosas»). (repositorio oficial, xCloud)
Algunos datos básicos, confirmados en las fuentes:
- Está bajo licencia MIT y lo creó el desarrollador austríaco Peter Steinberger. (LICENSE, Wikipedia)
- Está escrito en TypeScript, con componentes en Swift para las apps nativas. Corre sobre Node.js en la máquina o el servidor del propio usuario. (Wikipedia)
- El repositorio oficial declara que no tiene nivel de pago, servicio alojado ni token. Por defecto solo consulta una vez al día si hay una versión nueva. (repositorio oficial)
¿Qué problema resuelve? Un chat de solo texto responde, pero no recuerda ni ejecuta. OpenClaw convierte un modelo de lenguaje en un agente con estado («stateful»): enruta peticiones, conserva sesiones, recuerda información y usa herramientas. (Atlantic.Net)
Piensa en la diferencia entre preguntarle a alguien por mensaje «¿cómo se hace esto?» y tener a esa persona sentada en la mesa de al lado, con acceso a tu ordenador (y a tu confianza, que es la parte delicada).
Un apunte sobre su popularidad. Wikipedia recoge 247.000 estrellas y 47.700 forks en GitHub a 2 de marzo de 2026. Un proveedor de alojamiento externo, xCloud, habla de unas 394.000 estrellas a 1 de noviembre de 2026. Son datos de terceros, en evolución, así que tómalos como una foto de cada fecha y no como una cifra definitiva. (Wikipedia, xCloud)
El Gateway: el plano de control que no se apaga
La pieza central de la arquitectura es el Gateway. Es un único proceso de larga duración que concentra todas las superficies de mensajería: WhatsApp (vía Baileys), Telegram (vía grammY), Slack, Discord, Signal, iMessage y WebChat. La documentación lo describe como «el único lugar que abre una sesión de WhatsApp», de modo que hay un Gateway por host. (documentación: arquitectura)
Los clientes se conectan a él por WebSocket, por defecto en 127.0.0.1:18789. Esto vale para los clientes de plano de control (app de macOS, línea de comandos, interfaz web) y para los nodos (macOS, iOS, Android), que se declaran con role: node. (documentación: arquitectura)
Pensado así, el Gateway es la centralita de un edificio de oficinas. Los teléfonos (los clientes) van y vienen, pero la centralita siempre está encendida y sabe quién llama a quién.
Esa centralización tiene una ventaja práctica. Varias apps apuntan al mismo estado de sesión en el servidor, de modo que una conversación empezada en un cliente conserva su identidad cuando otro cliente autorizado se conecta. (Atlantic.Net) Por eso el mismo agente puede responderte en Telegram desde el escritorio y en WhatsApp desde el tren, sin un bot distinto por plataforma. (xCloud)
El bucle del agente: de un mensaje a una acción
Si el Gateway es la centralita, el bucle del agente es lo que ocurre cuando alguien descuelga. La documentación lo define como una ejecución serializada por sesión que convierte un mensaje en acciones y en una respuesta. Sus fases son: entrada, ensamblado de contexto, inferencia del modelo, ejecución de herramientas, transmisión y persistencia. (bucle del agente, agente)
Atlantic.Net lo expresa en un ciclo más legible: petición → enrutado → ensamblado de contexto → modelo → acción → observación → modelo → actualizar estado → respuesta. (Atlantic.Net)
Un ejemplo ilustrativo (no es un caso documentado, solo una forma de visualizarlo). Le escribes: «mira si el panel de producción está caído». El agente enruta tu mensaje a tu sesión y monta el contexto. El modelo decide abrir el navegador, la herramienta lo ejecuta y el agente observa el resultado: el despliegue falla. Con esa observación el modelo vuelve a razonar, anota lo ocurrido y te contesta. La palabra clave es observación: tras cada acción el modelo ve lo que pasó y decide el siguiente paso.
Quién es el agente: los ficheros de arranque
El prompt del sistema se alimenta con ficheros que el usuario puede leer y editar. (agente)
AGENTS.md: instrucciones y «memoria».SOUL.md: persona y límites.IDENTITY.md: nombre y tono.USER.md: perfil del usuario.BOOTSTRAP.md: ritual de primer arranque, que se borra al completarse.MEMORY.md: memoria a largo plazo, solo si existe.
Es una forma poco misteriosa de configurar a alguien: en lugar de un panel opaco, una carpeta de textos que puedes abrir con cualquier editor.
Sesión, persistencia y «compaction»
Las filas de sesión y las transcripciones se guardan en una base de datos SQLite por agente (~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite). Eso permite lecturas acotadas del historial, búsqueda, recuperación tras un reinicio y control de retención. (Atlantic.Net)
Cuando una conversación se alarga demasiado, entra la compaction. El runtime resume lo antiguo y conserva los mensajes recientes para no desbordar la ventana de contexto. (bucle del agente)
Memoria no es lo mismo que historial
Una distinción sutil y útil: el historial de sesión es lo que ocurrió en esta conversación, y la memoria es lo que debe seguir siendo útil después. (Atlantic.Net)
El ejemplo de la propia fuente lo deja claro. El fallo de despliegue de hoy es historial. La URL estable de producción es memoria de largo plazo. Mañana no necesitas recordar el fallo, pero sí dónde está producción.
El motor de memoria integrado indexa ficheros Markdown (MEMORY.md, USER.md, memory/*.md) en una base SQLite por agente. Ofrece búsqueda de texto completo (FTS5) y, si hay proveedor de embeddings, también búsqueda vectorial, es decir, una búsqueda híbrida. (Atlantic.Net)
Lo interesante del diseño es que la memoria son ficheros de texto. Si el agente «aprende» algo erróneo, puedes abrir el archivo y corregirlo.
El «24/7» de verdad: daemon, cron y heartbeat
Un agente que trabaja las 24 horas necesita, antes que nada, un proceso que no se apague. Esa es la idea central: el Gateway es un único proceso, así que necesita una máquina siempre encendida. Si cierras el portátil, el agente se queda en silencio. (xCloud)
Para que sobreviva a reinicios, el comando openclaw onboard --install-daemon instala el Gateway como servicio en segundo plano: launchd en macOS o systemd en Linux. Arranca solo al encender el equipo. (claw.so)
Dos relojes con funciones distintas
Encendido no significa activo. Para actuar sin que nadie le escriba, el agente tiene dos mecanismos. (automatización, claw.so)
- Automatizaciones (cron). Es el planificador integrado del Gateway. Persiste trabajos y despierta al agente en el momento exacto, ya sea con una expresión cron o con un disparo único. Crea registros de tarea.
- Heartbeat (latido). Es un monitor ambiental propiedad del sistema. Por defecto late cada 30 minutos (cada hora con OAuth de Anthropic, según una de las fuentes) y trabaja con el contexto completo de la sesión principal.
La metáfora del reloj despertador funciona bien. El cron es la alarma que programas a las 9:00 y suena exactamente a esa hora. El heartbeat es esa persona que cada rato levanta la vista y comprueba si hay algo que atender.
La documentación cita como ejemplos un informe diario a las 9:00, un recordatorio a los 20 minutos, un análisis semanal y la comprobación de la bandeja de entrada cada 30 minutos. (automatización) El resultado de un trabajo de cron puede entregarse a un canal de chat o a un webhook, o quedar en silencio. (cron jobs)
Skills y ClawHub: cómo se le añaden poderes
Una skill es una carpeta con un fichero SKILL.md que explica cómo y cuándo usar una herramienta. Sigue el formato abierto AgentSkills, así que es texto legible y no código oculto. La precedencia va de mayor a menor: workspace, proyecto, personal, gestionadas e incluidas. (xCloud, agente)
ClawHub es el registro público donde la comunidad comparte skills, que se instalan con openclaw skills install. (xCloud) Que ese registro sea público y abierto es una gran ventaja y también el origen de buena parte de los problemas de seguridad que vienen ahora.
Entre las capacidades documentadas están el navegador propio basado en Chromium (pestañas, lectura de páginas, clics, escritura, capturas y PDF) y, según el proveedor activo, el control de escritorio con ratón, teclado y ventanas. (Atlantic.Net) Es además agnóstico respecto al modelo: admite Claude, GPT, DeepSeek o Llama vía Ollama, entre otros. (xCloud)
Los usos que citan las fuentes incluyen administración personal (correo, calendario, recordatorios, resúmenes), briefings de investigación, tareas de desarrollo y DevOps (revisión de logs, salud del servidor) y automatización en pequeñas empresas. (xCloud, Wikipedia) Un caso descrito por un tercero es el de un servicio de atención al cliente: triaje en WhatsApp, Telegram o Discord, creación de tickets y escalado a humanos, con memoria persistente entre conversaciones. (OpenClaw Roadmap)
La cara B: seguridad, incidentes y controversia
Un agente que puede ejecutar comandos, leer tus ficheros y hablar con el exterior es útil. Esas mismas propiedades lo convierten en un objetivo atractivo. Lo que sigue son hechos documentados y reacciones de terceros, no una opinión de LedSolEo.
El diseño de seguridad por defecto
En una instalación normal el Gateway se enlaza a loopback. La mayoría de canales responden a un remitente desconocido con un código de emparejamiento en lugar de procesar su mensaje, y el acceso a grupos funciona con lista blanca. Existe además un comando de autoevaluación: openclaw security audit. (seguridad del Gateway)
El marco de análisis: la «trifecta letal»
IBM (análisis de su equipo X-Force) resume el riesgo en tres ingredientes que, juntos, son peligrosos: acceso profundo a datos locales privados, interacción con contenido externo no confiable y capacidad de comunicarse hacia fuera. (IBM X-Force) Es un análisis, no un incidente, pero explica por qué un agente así exige tanto cuidado.
Un hecho confirmado: CVE-2026-25253
El caso emblemático es CVE-2026-25253, una ejecución remota de código «de un clic» con una puntuación CVSS de 8.8. En términos didácticos, un enlace malicioso conseguía que la interfaz guardara una dirección de Gateway controlada por el atacante y filtrara el token de autenticación. Con ese token se podían desactivar las confirmaciones y el sandbox, y ejecutar comandos en milisegundos. Las fuentes indican que afectaba a versiones hasta la v2026.1.24-1 y que quedó corregido en la v2026.1.29. (depthfirst, Reco)
Cronología de incidentes de comienzos de 2026 (datos de terceros)
Según la cronología de Reco, que debe leerse como datos de terceros y no como cifras consolidadas (Reco):
- 27-29 de enero: la campaña «ClawHavoc» introdujo unos 335-341 skills maliciosos en ClawHub, en torno al 12 % de un registro de 2.857. Con nombres tan inocentes como «solana-wallet-tracker», instalaban keyloggers o «Atomic Stealer».
- 31 de enero: Censys detectó 21.639 instancias expuestas en internet, frente a unas 1.000 pocos días antes, con fugas de claves API y tokens OAuth.
- 31 de enero: una base de datos sin proteger de Moltbook expuso 35.000 correos y 1,5 millones de tokens de agente.
- 3 de febrero: divulgación pública de CVE-2026-25253 y de tres avisos de seguridad.
Reacciones de terceros
Según Wikipedia, un mantenedor advirtió en Discord que «si no sabes usar la línea de comandos, este proyecto es demasiado peligroso para usarlo con seguridad». El equipo de Cisco encontró una skill de terceros que exfiltraba datos sin avisar. Y en febrero de 2026 el CEO de Microsoft, Satya Nadella, comparó OpenClaw con un «virus». (Wikipedia)
En el plano institucional, y siempre según la misma fuente, en marzo de 2026 China restringió su uso en organismos estatales, empresas públicas y bancos por riesgos de seguridad: borrado de datos, fugas y consumo excesivo de energía. (Wikipedia)
La versión 2.0 también recibió críticas. The Register señaló que las sesiones compartidas carecen de límites de red y de sistema de ficheros, que los secretos no se cifran en reposo y que el sandbox no viene activado por defecto. (Wikipedia)
La lectura prudente es sencilla. Un agente autoalojado te da control, pero también te da la responsabilidad de configurarlo bien. Quien lo instale conviene que mantenga las versiones al día, revise las skills antes de instalarlas y no exponga el Gateway a internet sin proteger.
De Warelay a OpenClaw: historia y gobernanza
El nombre ha cambiado más veces que el de un grupo indie en sus primeros años. Según Wikipedia, se publicó en noviembre de 2025 como Warelay. Después fue Clawdbot (2 de enero de 2026), Moltbot (27 de enero, tras quejas de marca de Anthropic porque «Clawd» sonaba a «Claude») y, tres días más tarde, OpenClaw (30 de enero de 2026). (Wikipedia)
El 14-15 de febrero de 2026, Steinberger anunció que se incorporaba a OpenAI y que OpenClaw pasaría a una fundación sin ánimo de lucro independiente (OpenClaw Foundation, 501(c)(3)). La fundación sigue manteniendo el proyecto bajo licencia MIT. Lo confirman Reuters y el propio autor. (Reuters, steipete.me)
Según Wikipedia y el blog del proyecto, el 30 de agosto de 2026 se publicó OpenClaw 2.0, con instalación más rápida, interfaz rediseñada y sesiones en la nube compartidas. (Wikipedia, blog de OpenClaw)
Presente, tendencias y futuro
Conviene separar tres cosas.
Lo que existe hoy (documentado): un Gateway multicanal, un agente con estado (SQLite más memoria en Markdown), cron y heartbeat, control de navegador y equipo, skills y ClawHub, compatibilidad con varios modelos y licencia MIT. (documentación, xCloud)
Lo que se aprecia en el ecosistema (análisis, no hechos cerrados): un ecosistema de terceros con guías de despliegue y directorios de skills, adaptaciones a modelos chinos y a super-apps domésticas, y rivales empresariales como NanoClaw. Este último propone un modelo de ejecución en contenedores con menor superficie de ataque. (Wikipedia)
Lo que son escenarios, no promesas: agentes personales «para mi madre», que es el objetivo declarado por el autor al unirse a OpenAI. Más sesiones en la nube compartidas y una gobernanza de fundación consolidada. Son expectativas; hoy no hay nada que las dé por hechas. (steipete.me)
Por qué importa
Más allá del nombre y de la polémica, OpenClaw ilustra un modelo concreto: el agente como servicio propio y siempre encendido. Un proceso permanente, un estado persistente que se puede leer, dos relojes (cron y heartbeat) para actuar sin que se lo pidan, y una interfaz que es, simplemente, la mensajería que ya usas.
Ese diseño explica tanto su atractivo como sus riesgos. Un agente que vive siempre encendido, con acceso a tus datos y comunicación hacia fuera, necesita la disciplina de cualquier servidor que mantengas tú mismo. Quizá esa sea la lección más útil de este proyecto: la autonomía de un agente se parece mucho a la de cualquier empleado, y pide permisos medidos y revisiones.
Para ampliar información
Documentación oficial y repositorio:
- Arquitectura (Gateway): docs.openclaw.ai/architecture
- Bucle del agente: docs.openclaw.ai/concepts/agent-loop
- Agente, workspace y sesiones: docs.openclaw.ai/concepts/agent
- Automatización (cron y heartbeat): docs.openclaw.ai/automation/index
- Trabajos de cron: docs.openclaw.ai/automation/cron-jobs
- Seguridad del Gateway: docs.openclaw.ai/gateway/security
- Repositorio oficial: github.com/openclaw/openclaw
- Licencia MIT: github.com/openclaw/openclaw/blob/v2026.10.9/LICENSE
- Blog de OpenClaw sobre la 2.0: openclaw.ai/blog/openclaw-2-accidentally
Historia, gobernanza y contexto:
- Wikipedia: en.wikipedia.org/wiki/OpenClaw
- Reuters: www.reuters.com/business/openclaw-founder-steinberger-joins-openai-open-source-bot-becomes-foundation-2026-02-15
- Anuncio del autor: steipete.me/posts/2026/openclaw
Explicaciones y análisis de terceros:
- Atlantic.Net (arquitectura): www.atlantic.net/cloud-platform/openclaw-architecture
- xCloud (explicador): xcloud.host/what-is-openclaw
- claw.so (despliegue 24/7): claw.so/blog/run-openclaw-247
- OpenClaw Roadmap (caso de atención al cliente): openclawroadmap.com/use-cases-business-customer-support.php
Seguridad:
- depthfirst (CVE-2026-25253): depthfirst.com/post/1-click-rce-to-steal-your-moltbot-data-and-keys
- Reco (cronología de incidentes): www.reco.ai/blog/openclaw-the-ai-agent-security-crisis-unfolding-right-now
- IBM X-Force («trifecta letal»): www.ibm.com/think/x-force/what-openclaw-reveals-about-agentic-ai-security-risks
