En mi última conferencia quise poner una idea sobre la mesa con total claridad: el problema no es el hype alrededor de los agentes de IA. El verdadero problema es quedarse mirando el hype mientras otros ya están construyendo sistemas que trabajan, responden, ejecutan tareas y generan valor real.
Por eso titulé esta charla OpenClaw: del hype a la práctica. Mi intención no era vender una fantasía futurista ni repetir el discurso de siempre sobre agentes autónomos. Quise mostrar algo mucho más útil: cómo diseñar, desplegar y operar agentes de IA que sí puedan vivir en producción con criterios concretos de costo, arquitectura, identidad, seguridad y ejecución.
Del ruido mediático a una arquitectura operativa
Hoy vivimos en un mercado saturado de promesas. Por un lado están los titulares que presentan a los agentes como si fueran magia. Por el otro, están los equipos que necesitan sistemas estables, predecibles, baratos y gobernables.
Esa tensión fue el punto de partida de mi charla.
Mi tesis es simple: un agente no debe entenderse como una demo bonita ni como un truco de marketing. Un agente útil debe entenderse como una infraestructura operativa.
En la presentación lo expliqué con una arquitectura muy sencilla de visualizar:
- VPS en la nube como espacio operativo
- OpenClaw como framework
- LLM como motor de razonamiento
- Telegram como interfaz conversacional
Lo importante aquí no es la herramienta específica, sino el cambio de mentalidad. Cuando una persona entiende esta separación, deja de pensar en “un bot” y empieza a pensar en un sistema que puede vivir 24/7, recibir instrucciones, ejecutar acciones y evolucionar con nuevas capacidades.
Empezar bien no significa empezar complejo
Uno de los mensajes más importantes que quise dejar es que no se necesita hardware costoso ni una infraestructura absurda para comenzar con agentes.
Mi recomendación es empezar en la nube, con una complejidad mínima y con disponibilidad permanente. Eso obliga a tomar mejores decisiones desde el primer día: aislar entornos, reducir superficie de ataque, controlar credenciales y definir fronteras de confianza.
Ese enfoque coincide con la propia documentación de OpenClaw, donde se recomienda separar entornos y límites de confianza cuando existen usuarios o credenciales con distintos niveles de riesgo, en vez de asumir que todo debe convivir en un solo espacio compartido. OpenClaw Security
La identidad del agente también se diseña
Otro punto que trabajé mucho en la conferencia fue la identidad.
Creo que una de las ideas más subestimadas en el mundo de los agentes es pensar que todo se resuelve solo con código. No es así. Un agente también se redacta, se orienta y se entrena desde el lenguaje.
Archivos como SOUL.md, IDENTITY.md y USER.md permiten definir:
- el tono del agente,
- su rol,
- sus prioridades,
- el contexto del usuario,
- y la forma en que debe tomar decisiones.
Para mí, esa capa es lo que transforma al agente en algo más cercano a un colaborador operativo que a un simple asistente reactivo. No basta con darle herramientas; también hay que definir cómo piensa, qué considera importante y cómo responde cuando la realidad no es perfecta.
Skills: enseñar tareas, no solo conectar funciones
También dediqué una parte importante de la charla a explicar las skills de una forma menos abstracta.
Mi manera de verlo es muy simple: una skill no es solo una integración técnica. Una skill es una instrucción empaquetada que le enseña al agente a ejecutar una tarea concreta, casi como cuando entrenamos a una persona nueva dentro de un equipo.
Eso hace toda la diferencia, porque nos obliga a pensar menos en features aisladas y más en capacidades operativas reutilizables.
La documentación oficial de OpenClaw lo aterriza muy bien: las skills funcionan como unidades instruccionales empaquetadas en carpetas con SKILL.md, y pueden cargarse o filtrarse según configuración, entorno o allowlists. OpenClaw Skills
El valor real no está en reemplazar humanos
En esta conferencia también quise mover la conversación hacia un lugar más honesto.
No me interesa vender la narrativa del reemplazo humano. Me interesa hablar de ampliación de capacidad operativa.
Cuando una persona o un equipo incorpora agentes bien diseñados, no está “desapareciendo trabajo humano”. Lo que está haciendo es absorber trabajo repetitivo, delegar ejecución y liberar tiempo para decisiones estratégicas, creatividad, dirección y criterio.
Esa es la razón por la que en la charla insisto en que hoy una sola persona, con pocos dólares al mes y una buena arquitectura de agentes, puede alcanzar una capacidad operativa que antes exigía equipos mucho más grandes.
No porque la IA sea magia, sino porque la automatización bien gobernada multiplica enfoque.
Del agente individual a un sistema distribuido
Uno de los momentos más importantes de la presentación fue mostrar la arquitectura distribuida del Dragons Team.
Ahí ya no estamos hablando de “qué es un agente”, sino de cómo construir un sistema multiagente con especialización por contexto, orquestación centralizada, costos controlados e inferencia híbrida.
En este modelo:
- Nia opera como orquestador principal
- Majisto se enfoca en infraestructura y automatización de bajo consumo
- Astra se especializa en señales, scraping y síntesis
Lo valioso de esta topología no es solo que funcione, sino que cada nodo tiene una responsabilidad clara y una carga cognitiva proporcional a su rol. Eso hace posible combinar nube e inferencia local sin disparar costos ni perder gobernanza.
Costos bajos, decisiones inteligentes
Otra idea central de la charla fue desmontar el mito de que trabajar con agentes exige presupuestos enormes.
Cuando el procesamiento pesado se deriva solo donde realmente hace falta, y los nodos periféricos operan con APIs ligeras o funciones delimitadas, el costo operativo puede mantenerse sorprendentemente bajo.
Ese punto fue clave para demostrar que la conversación sobre agentes ya no es un lujo de laboratorio. Es una posibilidad real para creadores, developers, startups y equipos pequeños que quieren construir sistemas útiles sin hipotecar su operación.
Seguridad: donde la conversación se vuelve seria
Si hubo un segundo acto en mi conferencia, fue este: la seguridad.
En el momento en que conectamos un LLM al mundo real mediante herramientas, APIs, filesystem o ejecución de comandos, dejamos de hablar solo de generación de texto. Empezamos a operar una superficie de riesgo completamente nueva.
Por eso insistí en que las aplicaciones con LLM no pueden protegerse únicamente con controles tradicionales. Riesgos como la prompt injection directa o indirecta, el abuso de herramientas y la escalación de privilegios ya están documentados por OWASP como amenazas centrales para agentes y aplicaciones basadas en LLM. OWASP Prompt Injection Prevention OWASP AI Agent Security
Mi propuesta de defensa en profundidad se organiza en varias capas:
- arquitectura y aislamiento,
- identidad y accesos,
- ejecución y red,
- amenazas de contenido,
- visibilidad operativa.
Ese enfoque también se alinea con el marco del NIST para IA generativa, donde la gestión del riesgo no se limita al modelo sino que cubre gobernanza, operación, monitoreo, controles técnicos y contexto de uso. NIST AI RMF
Tres principios que considero no negociables
Si tuviera que resumir la parte más madura de la conferencia, la dejaría en tres principios.
1. Mínimo privilegio y separación de entornos
Un agente compartido, con demasiados accesos y sin fronteras claras, es una mala idea.
Por eso defiendo contenedores, gateways separados, usuarios dedicados del sistema y credenciales segmentadas. La seguridad real empieza cuando dejamos de asumir que todo puede convivir en el mismo espacio sin consecuencias.
2. La aprobación humana no reemplaza el sandboxing
Pedir confirmación al usuario no es suficiente.
Ese es uno de los errores de diseño más comunes en sistemas agentic: creer que un clic de aprobación compensa una mala arquitectura de aislamiento. No lo hace. El control real está en el host, el sistema operativo, la red, los permisos y las herramientas expuestas.
3. Todo input externo debe tratarse como potencialmente malicioso
Una página web, un correo, un archivo adjunto o un bloque de texto pueden contener instrucciones ocultas o maliciosas que alteren el comportamiento del agente.
Por eso insisto en no confiar ciegamente en contenido externo, mantener protecciones activas y redactar secretos en logs y trazas. La seguridad de agentes no es un tema teórico; es una disciplina operativa.
Por qué esta charla importa ahora
Lo que quise construir con esta conferencia fue un puente.
Un puente entre el entusiasmo y la implementación. Un puente entre el agente individual y la arquitectura distribuida. Un puente entre la promesa de productividad y la responsabilidad de operar IA con seguridad.
Creo que ahí está la relevancia real de esta conversación. Los agentes ya no son solo una curiosidad de laboratorio ni una demo para redes sociales. Se están convirtiendo en una nueva capa operativa del software.
Y si vamos a construir esa capa, tenemos que hacerlo bien: con identidad, con skills, con topologías pensadas para el mundo real, con costos sostenibles y con principios serios de seguridad.
Mi conclusión
Para mí, OpenClaw: del hype a la práctica no trata únicamente sobre OpenClaw.
Trata sobre una forma de pensar la IA aplicada con más criterio y menos espectáculo.
Trata sobre dejar de consumir el futuro como narrativa y empezar a operarlo como arquitectura.
Ese fue el mensaje de mi conferencia, y sigue siendo el mensaje que más me interesa defender: los agentes de IA no valen por parecer inteligentes. Valen cuando son útiles, gobernables, escalables y seguros.