OpenClaw Gateway

Hola, soy Alex de DEV STORIES DOT EU. OpenClaw Gateway, episodio 1 de 11. Estás lejos de tu escritorio, pero necesitas una code review rápida. Envías un mensaje desde tu móvil y, segundos después, recibes un análisis detallado, generado completamente por un servidor privado corriendo en tu máquina local. La arquitectura de Personal AI Gateway es lo que hace posible este setup completamente self-hosted. La mayoría de los chatbots de IA obligan a pasar tus datos personales por una capa de orquestación de terceros. Si quieres conectar una app de mensajería a un modelo de lenguaje, normalmente dependes de un servicio cloud para unir las APIs. Esto expone tus queries privadas e introduce latencia. La arquitectura de OpenClaw Gateway elimina el servicio intermediario ejecutando todo dentro de un único proceso self-hosted. Este proceso actúa como un puente dedicado. Se sitúa directamente entre tus apps de mensajería del día a día y tu runtime de IA elegido. Sigamos la ruta exacta de un mensaje para ver cómo fluye la lógica. Envías un code snippet desde tu móvil usando WhatsApp. En tu máquina local, el proceso del gateway ya está corriendo. Mantiene conexiones persistentes con tus apps de mensajería usando librerías específicas. Para WhatsApp, el gateway utiliza la librería Baileys para gestionar la conexión directa por socket. Para Telegram, se basa en el framework grammY. Cuando tu mensaje llega al servidor local, lo hace envuelto en una estructura de datos específica del protocolo. Un evento de WhatsApp tiene una forma de payload totalmente diferente a la de un evento de Telegram. El gateway parsea inmediatamente estos mensajes entrantes. Elimina los wrappers específicos de la plataforma, extrae el raw text y el identificador del remitente, y los empaqueta en un objeto interno estandarizado. Aquí está la clave. Para cuando tu mensaje llega al runtime de IA, el motor no sabe de dónde proviene el texto. El runtime opera de forma totalmente independiente de Baileys o grammY. Solo ve una request limpia y uniforme. La IA procesa tu code snippet, genera la review y devuelve una respuesta en texto plano al gateway. El gateway entonces invierte el flujo. Comprueba el marcador de origen adjunto a la request inicial. Si hiciste la pregunta por WhatsApp, el gateway formatea la respuesta de la IA en una estructura compatible con Baileys y la envía por el socket directamente a tu móvil. Si la request vino de Telegram, utiliza grammY para enviar la respuesta. Mantener todo esto dentro de un único proceso self-hosted reduce drásticamente la complejidad operativa. No necesitas hacer deploy de múltiples microservicios, configurar colas de mensajes ni exponer endpoints locales a webhooks externos solo para enrutar un texto. Una aplicación aislada gestiona los sockets de red, ejecuta la lógica de normalización e invoca el motor de IA. Como el gateway unifica múltiples canales internamente, el contexto de tu conversación se mantiene centralizado. Puedes empezar a hacer troubleshooting de un bug en Telegram mientras caminas, y hacer una pregunta de seguimiento más tarde en WhatsApp. El gateway asegura que el runtime de IA conserve el historial completo, independientemente de qué app móvil abras. La ventaja más importante de esta arquitectura es el control absoluto sobre tus inputs y outputs en cualquier interfaz de mensajería, completamente en tu propio hardware. Si disfrutas del podcast y quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon. Eso es todo por hoy. ¡Gracias por escuchar y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. OpenClaw Gateway, episodio 2 de 11. Tu bot de trabajo y tu bot asistente personal nunca deberían compartir las mismas memorias, pero levantar una instancia de servidor separada para cada nueva persona del bot es una pesadilla operativa. Esta es exactamente la tensión que resuelve el Multi-Agent Routing. Los oyentes suelen confundir este setup con una arquitectura SaaS multi-tenant. Vamos a aclararlo de inmediato. El Multi-Agent Routing no está diseñado para alojar bots dispares para miles de clientes externos. En su lugar, existe para organizar las distintas personas de un único propietario, o para enlazar chats de grupo específicos con bots específicos creados para un propósito, todos corriendo de manera eficiente bajo un mismo techo. Para que esto funcione, el sistema separa estrictamente dos conceptos. Tienes que entender la diferencia entre un account ID y un agent ID. El account ID es el humano. Es el identificador de la persona que envía el texto. El agent ID es el bot. Define la persona específica, el modelo y las instrucciones con las que está hablando el humano. Un único humano con un account ID hablará habitualmente con múltiples agent IDs diferentes a lo largo del día. En el OpenClaw Gateway, múltiples agentes aislados corren lado a lado. No compartes estados de memoria entre ellos. Cada agent ID tiene su propio workspace dedicado y su propio session store independiente. Cuando un mensaje entrante llega al Gateway, el sistema tiene que averiguar exactamente qué workspace aislado debe recibirlo. Lo hace usando reglas de routing conocidas como bindings. Los bindings son mappings deterministas. Miran los metadatos exactos adjuntos a un mensaje entrante y lo enrutan en consecuencia. Cada mensaje entrante lleva un payload de datos de conexión. Esto incluye el canal, como WhatsApp o Telegram. Incluye el account ID del remitente. También puede incluir un peer identifier, que podría dictar una sala de chat de grupo específica. Tú configuras los bindings para evaluar estos metadatos. Por ejemplo, puedes crear un binding que dicte que cualquier mensaje que llegue por el canal de WhatsApp se enrute directamente a un agent ID rápido y de uso diario. Este agente maneja tareas rápidas, listas de la compra o búsquedas web sencillas. En la misma configuración, estableces otro binding indicando que cualquier mensaje que llegue vía Telegram se enrute a un agent ID más potente corriendo un modelo más grande como Opus para trabajo profundo de código. El flujo lógico es sencillo. El Gateway recibe un mensaje de Telegram. Lee los metadatos del canal y tu account ID. Comprueba los bindings, encuentra la regla que coincide con Telegram y reenvía el payload al agent ID de Opus. El agente de Opus se despierta en su workspace aislado. Consulta su propio session store dedicado para recuperar el historial de la conversación. No tiene absolutamente ningún acceso a la lista de la compra que le acabas de enviar al agente de WhatsApp. Aquí está la clave. El Multi-Agent Routing convierte un único Gateway en una centralita determinista, usando los metadatos del canal y del usuario para garantizar que la persona correcta siempre atienda la request correcta sin contaminar nunca sus memorias. Como siempre, gracias por escuchar. Nos vemos en el próximo episodio.

Hola, soy Alex de DEV STORIES DOT EU. OpenClaw Gateway, episodio 3 de 11. ¿Alguna vez has deseado poder escribir literalmente un alma para tu IA, quizás haciendo que responda exclusivamente como una langosta espacial gruñona? En OpenClaw, lograr ese nivel de control del personaje no requiere nada de código. Se hace completamente mediante texto plano, lo que nos lleva al workspace del agente y los system prompts. Un agente en OpenClaw se define por su workspace. Este workspace es simplemente un directorio de archivos que contiene un conjunto específico de archivos Markdown de bootstrap. En lugar de enterrar tu system prompt dentro de la lógica de la aplicación o en campos complejos de la base de datos, OpenClaw expone las instrucciones principales como documentos legibles y con control de versiones. Cuando la aplicación se ejecuta, OpenClaw lee estos archivos para construir el system prompt monolítico que guía al large language model. La construcción se basa en cuatro documentos principales. El primero es el archivo markdown agents. Este documento establece la identidad central, los objetivos principales y los límites operativos estrictos del agente. Piensa en ello como la descripción del puesto de trabajo base. Le dice al modelo qué se supone que debe lograr y qué temas debe evitar por completo. El segundo documento es el archivo markdown soul. Aquí es donde viven la personalidad, el tono y el estilo conversacional. Aquí es exactamente donde le indicas al modelo que actúe como una langosta espacial gruñona. Escribes instrucciones explícitas diciéndole al agente que se queje del gélido vacío del espacio, que use metáforas de crustáceos y que se muestre en general molesto por las preguntas de los humanos. Al aislar la personalidad de la lógica central, puedes cambiar el tono de tu agente sin poner en riesgo su fiabilidad funcional. El tercer componente es el archivo markdown tools. Este texto explica las capacidades externas disponibles para el agente. Describe qué funciones puede ejecutar el modelo, los parámetros requeridos para esas funciones y cómo interpretar lógicamente los resultados. Sirve de puente entre el razonamiento interno del modelo y tu codebase real. El último documento es el archivo markdown user. Este archivo inyecta contexto sobre la persona que interactúa con el agente. Puede contener preferencias del usuario, niveles de habilidad técnica o restricciones de la cuenta. Esto asegura que el agente adapte sus respuestas al humano específico al otro lado del chat, en lugar de ofrecer consejos genéricos. Aquí está la clave. OpenClaw toma el contenido de estos cuatro archivos y los concatena. Este string combinado se convierte en el system prompt final. El detalle crucial es que este prompt se inyecta en la context window en cada turno de la conversación. El modelo no lee estos archivos una sola vez en el startup y de alguna manera los guarda en un banco de memoria separado. Lee el bloque concatenado completo cada vez que el usuario envía un nuevo mensaje. Esta decisión arquitectónica dicta cómo debes escribir tus archivos del workspace. Como todo el texto del workspace se antepone a cada interacción, tu conteo de tokens se sumará de forma agresiva. Si escribes una historia de fondo de tres páginas en el archivo soul, pagas el coste de procesamiento de esas tres páginas cada vez que el usuario simplemente dice hola. Más importante aún, los system prompts grandes consumen los límites disponibles de la context window. Un workspace sobrecargado desplaza el historial real de la conversación, haciendo que el modelo olvide partes anteriores del chat mucho más rápido. Debes ser implacable al editar los documentos de tu workspace. Elimina las instrucciones redundantes. Usa un lenguaje preciso. Si una regla en el archivo agents nunca se ejecuta, bórrala. El system prompt no es un paso de configuración de una sola vez. Es un impuesto recurrente sobre tu context window y tu presupuesto de la API, que se paga en cada turno de la conversación. Mantenlo ligero, y tu agente se mantendrá enfocado. Gracias por escuchar. Cuidaos todos.

Hola, soy Alex de DEV STORIES DOT EU. OpenClaw Gateway, episodio 4 de 11. Haces deploy de un nuevo chatbot en el workspace de tu empresa. Alice le pide que resuma sus notas de una reunión privada y, cinco minutos después, accidentalmente le cita esas notas a Bob. Tu agente acaba de filtrar datos porque trata a todos los usuarios del workspace como si fueran exactamente la misma persona. Para solucionar esto, necesitas entender el Session Management y el DM Isolation. Antes de arreglar esta superposición, tenemos que aclarar un malentendido muy común. Los ingenieros suelen confundir las session keys con los authentication tokens. No son lo mismo. Las session keys no son barreras de seguridad. Son simplemente routing selectors. Le dicen al sistema OpenClaw qué bloque del historial de conversación debe extraer de la base de datos e inyectar en el prompt. Si necesitas restringir quién puede hablar con tu agente, usas una autenticación en condiciones. Las session keys solo sirven para mantener el texto separado. Cada interacción con un agente de OpenClaw ocurre dentro de una sesión. La sesión guarda el historial de la conversación y el contexto activo a corto plazo. Por defecto, OpenClaw enruta todo el tráfico a través de una única session key compartida llamada main. Si ejecutas un script de terminal en local o un asistente personal solo para ti, este comportamiento por defecto funciona a la perfección. Todo tu contexto se mantiene en un único thread continuo. Pero si conectas ese mismo agente a una plataforma multiusuario, la configuración por defecto se rompe. Cada usuario que habla con el bot escribe exactamente en el mismo historial main. El agente lee el prompt de Alice, genera una respuesta y la guarda. Cuando Bob envía un mensaje diez segundos después, el agente lee el input de Bob junto con el input anterior de Alice. Aquí es donde la cosa se pone interesante. Puedes evitar esta superposición usando los ajustes de DM Isolation. Cuando configuras la integración con tu plataforma, cambias la estrategia de session routing de la opción por defecto a per-channel-peer. Cuando activas per-channel-peer, OpenClaw deja de enrutar el tráfico a la sesión main. En su lugar, genera una session key única de forma dinámica para cada mensaje entrante. Esto lo hace combinando el identificador de canal de la plataforma con el identificador de usuario. Ahora, cuando Alice le envía un mensaje al bot en un canal específico, OpenClaw crea una session key única para ella y para ese canal. Cuando Bob le envía un mensaje al bot, su identificador de usuario genera una session key completamente distinta. El sistema carga un state limpio y vacío para Bob. Sus contextos están totalmente aislados. Si Alice habla con el bot en un canal completamente distinto, también obtiene una sesión nueva allí. Estas sesiones no guardan el state para siempre. OpenClaw gestiona la limpieza de sesiones mediante dos eventos de lifecycle específicos. El primero es un idle reset. Si una sesión en particular no recibe mensajes nuevos durante un tiempo configurado, el sistema descarta el contexto. La próxima vez que el usuario envía un mensaje, empieza desde cero. El segundo mecanismo de limpieza es un hard daily reset. Independientemente de lo activa que sea una conversación, OpenClaw purga a la fuerza todos los contextos de sesión exactamente a las 4:00 de la mañana, hora del servidor. Este reset diario actúa como un paso de garbage collection automatizado. Asegura que se libere memoria y que las conversaciones largas no consuman silenciosamente cantidades masivas de context tokens a lo largo de semanas de uso. Cuando haces deploy de agentes en entornos grupales, nunca asumas que la plataforma se encarga de la separación de usuarios por ti. Mapear explícitamente tus session keys al user boundary correcto es la única forma de evitar context leaks accidentales. Eso es todo por este episodio. Gracias por escuchar, y sigue programando.

Hola, soy Alex de DEV STORIES DOT EU. OpenClaw Gateway, episodio 5 de 11. Las ventanas de contexto de la IA no son infinitas, pero tu conversación a menudo necesita serlo. Cuando una sesión larga llega al límite, la solución habitual es empezar a descartar los mensajes antiguos por completo, lo que provoca que el agente olvide repentinamente pasos de configuración cruciales. Gestionar los límites de contexto con Compaction resuelve esto al fusionar elegantemente los chats antiguos en resúmenes concisos antes de que se supere el límite. Antes de ver el funcionamiento, no lo confundas con el session pruning. El session pruning es una operación independiente que solo elimina el exceso de tool results. Compaction opera directamente sobre el historial principal de la conversación. Piensa en una sesión de programación larga. El agente lleva una hora generando boilerplate, leyendo archivos locales y depurando errores de lógica. Cada interacción suma al conteo de tokens. Si el sistema alcanza el hard limit del modelo de lenguaje subyacente, la API rechaza la request y la sesión crashea. Necesitas una forma de recuperar espacio sin romper la lógica del asistente. OpenClaw gestiona esto a través del Context Engine. El Context Engine administra todo el flujo de mensajes entre el usuario y el modelo. Dentro de este motor, hay un punto específico del lifecycle llamado compact. Esta fase actúa como una válvula de seguridad automática para el context overflow. El motor monitoriza activamente el uso de tokens de la conversación actual. Tú defines un umbral máximo de tokens en tu configuración. Mientras la conversación se mantenga por debajo de este umbral, los mensajes pasan con normalidad. Cuando el conteo de tokens se acerca al límite, el motor lanza automáticamente un memory flush a través del punto del lifecycle compact. Cuando se lanza el flush, el sistema divide el historial de mensajes en dos secciones. Separa los mensajes más recientes de los mensajes históricos más antiguos. Los mensajes recientes permanecen completamente intactos. El motor conserva la redacción exacta del intercambio inmediato para que el agente no pierda su hilo de pensamiento actual ni la sintaxis exacta de la función en la que estás trabajando activamente. Aquí está la clave. Los mensajes más antiguos no se descartan. En su lugar, se redirigen a un proceso de resumen secundario. Este proceso lee la mayor parte de la conversación inicial y la condensa en un breve texto de resumen. Este texto captura los objetivos originales, las decisiones arquitectónicas tomadas al principio y cualquier regla establecida, eliminando el relleno conversacional y las iteraciones obsoletas del código. Luego, el motor reestructura la memoria activa. Reemplaza el gran bloque de mensajes antiguos en bruto por este único bloque de resumen. El prompt recién estructurado contiene primero el bloque de resumen, seguido de los mensajes recientes tal cual. El conteo total de tokens cae drásticamente. El agente sigue entendiendo el contexto histórico al leer el resumen, y puede continuar ejecutando la tarea activa leyendo los mensajes recientes. La conversación continúa sin problemas y sin ninguna intervención manual. La gestión eficaz del contexto no consiste en conservar cada palabra exacta que escribiste, sino en comprimir sistemáticamente el pasado para que el agente tenga el máximo espacio para razonar sobre el presente. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. OpenClaw Gateway, episodio 6 de 11. Meter una IA en un workspace compartido de Slack con acceso a la terminal suena a incidente de seguridad garantizado, a menos que definas estrictamente quién tiene permiso para decirle qué hacer. Hoy hablamos de seguridad y límites de confianza. La regla fundamental del OpenClaw Gateway es que funciona bajo un modelo de confianza de asistente personal. Muchos desarrolladores asumen que los gateways de IA vienen con autorización compleja a nivel de usuario integrada. OpenClaw no. OpenClaw no está diseñado para aislamiento multi-tenant hostil. No intenta separar de forma segura a usuarios maliciosos entre sí en una única instancia compartida. En su lugar, todo el Gateway actúa como un único límite que representa a un operador de confianza. El sistema asume que cualquiera que pueda comunicarse con el Gateway está autorizado para actuar en nombre del propietario. Piénsalo como una workstation desbloqueada. Si tu instancia de OpenClaw está configurada con una herramienta que modifica la infraestructura, cualquiera que pueda hablar con esa instancia puede lanzar esa modificación. El propio modelo de IA no tiene el concepto de roles de usuario ni access tokens. Solo ve un stream de texto entrante. Esto nos lleva al grave riesgo de los canales compartidos. Si conectas tu Gateway a un grupo público de Telegram o a un canal de Slack de un equipo grande, todos y cada uno de los usuarios de ese canal están ahora dentro de tu límite de confianza. La IA trata cada mensaje que lee como una instrucción válida. Si un usuario externo escribe un ataque de prompt injection en el chat, está secuestrando la autoridad delegada de las herramientas de tu bot. El Gateway no puede distinguir entre tú pidiendo el estado del sistema y un atacante engañando al modelo para ejecutar un shell script destructivo. La autoridad es del bot, pero el control es de quien proporciona el prompt. Si tienes una conexión expuesta, como un bot de Telegram, tienes que blindarla. Primero, desactiva las herramientas con privilegios elevados para ese perfil específico del Gateway. No le des a un bot de acceso público acceso a tu sistema de archivos local ni a APIs internas sensibles. Mantén su conjunto de herramientas limitado a acciones de solo lectura o inofensivas. Segundo, restringe la capa de comunicación. Configura la conexión para que solo acepte mensajes directos de usuarios emparejados específicos, ignorando por completo los chats de grupo y a los desconocidos. Al limitar quién puede introducir texto y qué herramientas puede ejecutar el bot, aseguras el límite. Para verificar que no te has dejado ninguna puerta abierta, usa la utilidad de línea de comandos integrada. Ejecuta el comando openclaw security audit. Esta herramienta escanea la configuración activa de tu Gateway y comprueba dos riesgos principales. Primero, comprueba tu exposición de red. Te avisará si tu instancia está escuchando en interfaces públicas en lugar de estar vinculada de forma segura a localhost. Segundo, marca las herramientas permisivas. La auditoría te alertará si tienes capacidades de alto riesgo, como la ejecución de código arbitrario, habilitadas al mismo tiempo que integraciones de chat público. Aquí está la clave. El límite de la seguridad de tu sistema es exactamente el límite de quién puede enviar texto a tus modelos. Si no puedes limitar la audiencia, tienes que limitar las herramientas. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. OpenClaw Gateway, episodio 7 de 11. Darle a un modelo de IA acceso raw a la línea de comandos suena a vía rápida para cargarte el sistema. Pero, ¿y si el agente pudiera ejecutar automáticamente comandos inofensivos de parseo de datos, pidiéndote permiso explícitamente antes de tocar nada destructivo? La Exec Tool y los Runtime Approvals gestionan exactamente este equilibrio. La Exec Tool permite que un agente de OpenClaw ejecute comandos de shell para interactuar con el sistema. Cuando el agente decide que necesita ejecutar un comando, apunta directamente a la máquina host o a un contenedor sandbox designado. Usar un contenedor sandbox limita el radio de impacto de la ejecución general. Sin embargo, a veces el agente necesita de verdad interactuar con tu file system local, leer tus logs locales o iniciar procesos locales. Ejecutar comandos en el host es muy potente, que es exactamente el motivo por el que existe el modelo de autorización. OpenClaw utiliza un sistema de autorización de dos niveles para que mantengas el control sin ralentizar innecesariamente al agente. El primer nivel se basa en safe bins. Son binarios específicos que añades explícitamente a una whitelist como inofensivos, como jq para parsear JSON o grep para buscar texto. Si el agente llama a un comando que solo usa estos safe bins, el Gateway lo ejecuta inmediatamente. No hay prompts, y el agente mantiene su ritmo. El segundo nivel atrapa todo lo demás. Si el agente intenta una ejecución completa de shell o prueba a usar un binario que no está en la safe list, el Gateway intercepta la petición. Detiene al agente y activa el sistema de Runtime Approvals. Aparece un prompt en la UI de tu Gateway o en tu companion app. Puedes revisar el string exacto del comando que el agente quiere ejecutar. Si lo apruebas, el Gateway ejecuta el comando y devuelve el output al agente. Si lo rechazas, el comando nunca se ejecuta. En su lugar, el agente recibe un error de ejecución denegada, y tiene que buscar otra forma de proceder o pedirte aclaraciones. Esta es la clave de cómo funciona esto en la práctica. Pongamos que el agente necesita analizar un archivo de log enorme. Llama a grep para extraer los errores. Eso se ejecuta al instante. Luego, necesita compilar el proyecto, así que intenta ejecutar npm run build como un proceso en background. El Gateway detiene al agente y le hace un ping a tu companion app. Lees el comando, ves que tiene sentido y le das a aprobar. La build empieza en background. Más tarde, el agente decide hacer limpieza intentando borrar un archivo source. El Gateway te vuelve a hacer ping. Deniegas la petición. Tu archivo se queda intacto, y el agente aprende que no tiene permiso para esa acción. Hay una estricta restricción de seguridad que debes conocer al ejecutar en el host. El Gateway rechaza explícitamente cualquier intento de sobrescribir la variable de entorno path. Esto evita el hijacking. Sin este bloqueo, un prompt malicioso podría engañar al agente para redefinir el path, provocando que un nombre de safe bin como grep ejecute un script destructivo oculto en una carpeta diferente. Como el path está bloqueado, la lista de safe bins sigue siendo absoluta. El verdadero poder de la Exec Tool no es solo que la IA pueda ejecutar comandos, sino que el modelo de seguridad por niveles obliga a meter a un humano en el loop solo cuando hay mucho en juego, dejando al agente completamente autónomo para el trabajo rutinario. Si quieres ayudar a que el programa siga adelante, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. OpenClaw Gateway, episodio 8 de 11. Quieres que tu agente manipule imágenes usando una herramienta de línea de comandos. Normalmente, esto implica escribir wrappers de Python, definir schemas y esperar que el modelo de lenguaje entienda los parámetros. Pero en realidad no necesitas código para enseñarle a una IA una nueva capacidad. Solo necesitas un archivo de texto. Hoy nos centramos en enseñar a los agentes con Skills en OpenClaw. Una Skill en OpenClaw es esencialmente un manual de instrucciones. Es un archivo de texto plano llamado SKILL punto md, formateado según el estándar AgentSkills. No es un binario compilado ni un script de Python. Es un documento Markdown que le indica al agente exactamente cómo orquestar las herramientas existentes. Dentro de este archivo, escribes instrucciones paso a paso. Defines el propósito de la Skill, las herramientas que usa y la secuencia de acciones que el agente debe realizar. Si estás creando una Skill de procesamiento de imágenes llamada image-lab, tu archivo SKILL punto md explicará cómo formatear los argumentos de línea de comandos para redimensionar o recortar una imagen. El agente lee este archivo y traduce tus instrucciones en inglés a ejecuciones precisas de línea de comandos. Una Skill es inútil si la herramienta subyacente falta en el sistema. OpenClaw evita fallos aquí usando load-time gating. Esto te permite definir requisitos previos para que tu agente nunca intente usar software que no esté instalado. Lo gestionas declarando los requisitos en la configuración de la Skill. Para la Skill image-lab, es posible que necesites un gestor de paquetes específico para ejecutar los comandos. Lo especificas mediante la propiedad requires punto bins, indicando el nombre del ejecutable, como uv. También puedes requerir variables de entorno específicas mediante la propiedad requires punto env, que garantiza que haya una clave API o una ruta de configuración presente antes de que se active la Skill. Cuando OpenClaw se inicia, evalúa estos gates. Comprueba el entorno local en busca del binario uv y cualquier variable solicitada. Si faltan, OpenClaw omite la Skill silenciosamente. El sistema no crasheará y el agente no alucinará comandos no soportados. Simplemente opera sin las capacidades de image-lab. Aquí está la clave. OpenClaw necesita entregar estas Skills válidas al modelo de lenguaje de manera eficiente. Toma todas las Skills que pasaron las comprobaciones de tiempo de carga y las compila en una lista XML compacta. Este bloque XML se inyecta directamente en el system prompt del agente. Los modelos de lenguaje están altamente optimizados para parsear etiquetas XML. Al formatear el manual de instrucciones de esta manera, el agente separa limpiamente su persona principal de la lógica estricta y paso a paso definida en tus Skills. No tienes que escribir cada Skill tú mismo. OpenClaw se integra con ClawHub, el registro oficial de Skills creadas por la comunidad. Si necesitas que tu agente opere una base de datos o utilidad cloud específica, puedes buscar en ClawHub e instalar una Skill existente. Se descarga en tu entorno, pasa por las mismas comprobaciones de tiempo de carga y se inyecta automáticamente en el system prompt. El aspecto más valioso de la arquitectura de Skills es desacoplar la capacidad del código. Puedes reconfigurar por completo la forma en que tu agente resuelve problemas complejos de varios pasos simplemente editando un archivo Markdown, sin modificar nunca la lógica de tu aplicación ni compilar una nueva build. Gracias por pasar unos minutos conmigo. Hasta la próxima, que te vaya bien.

Hola, soy Alex de DEV STORIES DOT EU. OpenClaw Gateway, episodio 9 de 11. Tu agente está intentando extraer datos de una página web, pero no se limita a parsear raw HTML. Necesita renderizar un dashboard dinámico de React, hacer clic en un botón y esperar a que se cargue un chart. Tienes que darle al agente una interfaz web completamente funcional, pero bajo ningún concepto quieres que te toque tus pestañas abiertas ni que secuestre tu ratón. La Managed Browser Tool se encarga exactamente de esto. Esta herramienta le da a tu agente la capacidad de hacer clic, escribir, navegar y capturar visualmente exactamente lo que vería un humano. Ejecuta un entorno de navegador real para interactuar con aplicaciones con client-side rendering, saltándose las limitaciones de las simples requests HTTP. Para mantener tu espacio de trabajo seguro, la Managed Browser Tool utiliza diferentes perfiles operativos. El perfil por defecto es el perfil openclaw aislado. Cuando el agente utiliza este perfil, la herramienta levanta una instancia de Chromium completamente separada y dedicada. Tiene sus propias cookies, su propio local storage y su propio historial en blanco. El agente navega en su propio navegador dedicado. Puede rellenar formularios y navegar por menús sin tocar para nada tu sesión personal de Chrome. Sin embargo, hay veces que un agente necesita acceso a herramientas internas donde ya estás autenticado. Para esto, la herramienta ofrece el user profile. En lugar de arrancar desde cero, el user profile se acopla a tu sesión de Chrome existente, donde ya has hecho login. Se conecta mediante el DevTools Protocol a través del Model Context Protocol. Esto permite que el agente aproveche tus login tokens activos para esa tarea específica sin que tengas que pasarle credenciales directamente a la IA. Aquí está la clave. Darle a un agente de IA un navegador automatizado dentro de tu entorno introduce riesgos de seguridad inmediatos. Para mitigar esto, el control de la Managed Browser Tool es estrictamente loopback-only. El agente se comunica con el navegador únicamente a través de la interfaz loopback local. Más importante aún, cada request de navegación está protegida por la política de Server-Side Request Forgery. Esta política asegura que el agente no pueda usar su instancia del navegador como proxy para escanear en silencio los puertos de tu red local o llamar a servicios internos no autorizados. Piensa en el escenario del dashboard de React. Primero, el agente lanza un comando para abrir el navegador usando el perfil aislado por defecto. Navega a la URL del dashboard y espera activamente a que los componentes JavaScript se monten y el DOM se estabilice. A continuación, localiza el elemento específico del chart usando un selector CSS y dispara un evento click para expandir la vista. Finalmente, lanza un comando de screenshot. El navegador captura el frame renderizado y devuelve el buffer de imagen directamente al gateway. Darle un navegador a un agente nunca debería significar entregarle las llaves de tu red interna o de tu sesión personal de Chrome. La Managed Browser Tool mantiene al agente muy capaz, pero estrictamente contenido. Eso es todo por este episodio. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. OpenClaw Gateway, episodio 10 de 11. Le pides a tu IA que haga scraping de una web compleja o que procese miles de líneas de log, y luego te quedas ahí parado. Te quedas mirando un spinner durante diez minutos, sin poder hacer otra pregunta hasta que termine la tarea. Para solucionar este problema bloqueante, usas subagentes efímeros. Un subagente efímero es un worker temporal y aislado que se ejecuta en background. En lugar de hacer el cómputo pesado él mismo, tu agente de chat principal delega el trabajo. Lo hace usando una tool del sistema específica llamada sessions spawn. Cuando el agente principal se encuentra con una tarea masiva, lanza esta tool. Le pasa un prompt claro, los archivos de contexto necesarios y las instrucciones específicas para el trabajo. Esta acción crea una sesión de chat completamente nueva e invisible que se ejecuta totalmente en background. Como esta sesión está aislada, tu agente principal queda libre de inmediato. Puedes seguir hablando con tu asistente principal, hacer preguntas que no tengan nada que ver o asignar más tareas mientras el subagente procesa los datos pesados fuera de tu vista. Veamos un escenario concreto. Metes un log de errores de servidor enorme en tu chat principal y pides una auditoría de seguridad. Procesar ese log línea por línea con tu LLM principal más potente lleva mucho tiempo y quema un montón de tokens caros. En su lugar, tu agente principal delega el trabajo. Aquí está la clave. Al llamar a sessions spawn, el agente principal puede especificar un modelo completamente distinto para la tarea en background. Puede asignarle un LLM más barato y rápido al subagente. Este worker en background usa el modelo más rápido para procesar a toda velocidad el análisis repetitivo de logs. El agente principal se mantiene responsive usando el modelo inteligente, mientras que el subagente hace el trabajo pesado usando el modelo rápido. Cuando el subagente por fin termina de parsear esos logs, necesita una forma de devolver los datos. Lo hace anunciando su resultado final hacia arriba en la chain. El subagente coge su resumen compilado e inyecta un mensaje directamente de vuelta en el chat solicitante original. Simplemente ves aparecer un nuevo mensaje del subagente con tu análisis de logs terminado, listo para que tú y el agente principal lo discutáis. Esta arquitectura se conoce como el patrón orchestrator, y se basa en reglas sobre el nesting depth. El escenario que acabamos de ver es nesting depth uno. El usuario habla con el agente principal, y el agente principal hace spawn de un subagente. OpenClaw también soporta nesting depth dos. En un escenario de depth dos, tu subagente de parseo de logs podría encontrarse con un payload fuertemente codificado en los logs. Entonces puede hacer spawn de su propio subagente solo para decodificar ese payload específico. Ese agente de segundo nivel decodifica el texto, se lo pasa de vuelta al primer subagente, que luego completa el análisis de logs y reporta hacia arriba a tu chat principal. El sistema capa esto estrictamente a un depth de dos. Este hard limit evita bucles recursivos descontrolados donde los agentes hacen spawn continuamente de otros agentes para siempre, agotando tus recursos de compute. Los subagentes efímeros cambian fundamentalmente cómo interactúas con una interfaz de prompt. Dejas de tratar a tu LLM como un único thread bloqueado y empiezas a tratarlo como un gestor de tareas asíncrono. Eso es todo por este episodio. ¡Nos vemos en la próxima!

Hola, soy Alex de DEV STORIES DOT EU. OpenClaw Gateway, episodio 11 de 11. Un verdadero asistente no se queda inactivo esperando a que escribas un comando. Revisa proactivamente tus sistemas y te avisa cuando algo realmente necesita tu atención. Pasar de un loop reactivo de prompt y respuesta a un agente autodirigido requiere mecanismos específicos de scheduling y ejecución. Esto nos lleva a los workflows de automatización proactiva. OpenClaw gestiona la automatización basada en el tiempo mediante dos mecanismos distintos. El primero es el Heartbeat. El segundo es Cron. Los ingenieros suelen confundirlos porque ambos disparan acciones automáticamente en función del tiempo, pero tienen roles arquitectónicos completamente diferentes en cuanto al state y al aislamiento de la sesión. El Heartbeat es un loop periódico que se ejecuta continuamente dentro de tu sesión principal activa. Está diseñado para comprobaciones rutinarias y continuas donde tu contexto actual importa. Aquí está la clave. Como el Heartbeat opera dentro de tu sesión actual, tiene acceso directo a tu interfaz activa. Piensa en un escenario en el que quieres monitorizar tu bandeja de entrada en busca de mensajes urgentes. Configuras un Heartbeat para que ejecute una comprobación cada treinta minutos. Si detecta un correo electrónico crítico, el Heartbeat puede hacer un push inmediatamente de una alerta en lenguaje natural directo a tu stream de conversación activo. Funciona como un background thread continuo, vinculado a tu state de usuario actual, lo que permite interrupciones inmediatas y contextuales. Cron funciona de forma completamente diferente. Está diseñado para jobs programados y precisos que requieren un aislamiento total. Si quieres que el sistema compile un informe matutino completo a partir de diversas fuentes de datos exactamente a las seis de la mañana, usas Cron. Cuando un schedule de Cron se dispara, OpenClaw no utiliza tu chat activo. En su lugar, levanta una background session completamente aislada. Hace un pull de los datos necesarios, procesa la carga analítica pesada de forma silenciosa, y trackea todo el job internamente como una Background Task. Esto significa que el procesamiento pesado no contamina la context window de tu chat de escritorio activo. Una vez que el job termina, el informe final se almacena y queda listo para que lo recuperes cuando hagas login. El Heartbeat comparte el state contigo, mientras que Cron se ejecuta en modo headless y aislado. Los triggers basados en tiempo son solo una parte del workflow. OpenClaw se apoya en Hooks y Standing Orders como herramientas complementarias para completar el loop de automatización. Mientras que Heartbeat y Cron dictan cuándo ocurre una acción basándose en el reloj, los Hooks gestionan los triggers externos, orientados a eventos. Un Hook expone un endpoint de escucha al que pueden llamar sistemas externos. Si un log crítico del servidor indica un fallo, un sistema externo puede hacer una llamada a un Hook de OpenClaw, despertando al asistente para que analice el error inmediatamente sin esperar al siguiente pulso programado del Heartbeat. Las Standing Orders proporcionan las reglas operativas persistentes para todas estas ejecuciones autónomas. Cuando ese job de Cron aislado se despierta a las seis de la mañana, no hay ningún usuario presente para guiar su output. Las Standing Orders definen el formato exacto, la profundidad analítica y las reglas de prioridad que el asistente debe seguir mientras trabaja de forma completamente independiente. Al combinar Heartbeats periódicos para la monitorización activa, jobs de Cron aislados para tareas programadas pesadas, y Standing Orders persistentes para gobernar el comportamiento no guiado, cambias fundamentalmente la naturaleza de la aplicación. Dejas de construir una simple interfaz de chat y empiezas a hacer el deploy de un verdadero asistente autónomo. Dado que este es el último episodio de nuestra serie sobre OpenClaw, te animo encarecidamente a que explores la documentación oficial, pruebes a configurar estas background tasks de forma práctica, o visites devstories dot eu para sugerir temas para nuestra próxima serie. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.