Después de OpenClaw, ¿por qué la mayoría de la gente todavía siente que falta algo?

Escritura: DeepThink Circle

¿Alguna vez te has preguntado por qué OpenClaw es tan popular, pero después de usarlo realmente, la mayoría siente que—es muy inteligente, pero todavía le falta algo?

No es que el modelo no sea lo suficientemente potente, ni que las funciones sean insuficientes. Es que resuelve el problema de “pensar”, pero no el de “hacer”.

Le dices que ejecute una tarea, y corre en la terminal, escribe en el IDE, razona en el cuadro de diálogo. Pero entre “decisión tomada” y “completado real”, hay un trecho—cambiar ventanas, buscar en el sistema, copiar y pegar, hacer clic en confirmar—y ese trecho todavía lo recorres tú.

Esto no es un fallo de diseño de OpenClaw, sino un problema estructural que enfrenta actualmente todo el ecosistema de AI Agents: la capa de percepción y razonamiento ya está bastante madura, pero la capa de ejecución está casi vacía.

La variable subestimada

En los últimos dos años, la discusión sobre infraestructura de IA se centró en dos direcciones:

Primero, la capacidad del modelo—tamaño de parámetros, velocidad de inferencia, ventana de contexto—los avances en esta línea son evidentes.

Segundo, el marco de los Agents—LangChain, AutoGPT, OpenClaw, que representan la capacidad de orquestación y programación de tareas—también recibe mucha inversión.

Pero hay una variable que casi nadie está abordando sistemáticamente: la infraestructura de ejecución en el nivel de estación de trabajo.

¿Qué es la infraestructura de ejecución en ese nivel?

Simplemente, aquello que permite que el Agent realmente “tenga manos” en tu entorno de trabajo específico—no en un sandbox, no en su propio contenedor, sino en tu pantalla real, con tus herramientas reales, en tu sistema real.

¿Por qué es difícil esto?

Porque la complejidad del entorno laboral real supera con creces cualquier simulación en sandbox. Muchas empresas operan sistemas heredados sin API, muchos flujos de trabajo cruzan cinco o seis herramientas diferentes, y el contexto de muchas tareas está disperso en varias ventanas, sin interfaces estandarizadas que puedan ser llamadas.

Esta complejidad no se puede resolver solo con modelos más inteligentes. Requiere una capacidad de percepción y ejecución más profunda—ver la pantalla real, entender el estado entre ventanas, manipular directamente el ratón y el teclado.

Este es precisamente el cuello de botella real para la implementación de los Agents, y la variable que la mayoría subestima sistemáticamente cuando discuten sobre AI Agents.

¿Qué hace Violoop?

Recientemente, un proyecto llamado Violoop llamó mi atención.

Es un hardware de IA nativo con pantalla táctil en la mesa, que se conecta a la computadora vía HDMI y Type-C, soportando tanto Mac como Windows. Desde fuera, parece discreto. Pero lo que hace, apunta exactamente a esa variable subestimada.

Recopila tres tipos de datos: flujo de video (percepción visual global de la pantalla), API del sistema (señales del estado del sistema operativo), permisos HID (control básico del ratón y teclado). Estas tres capas juntas conforman un runtime de percepción-razonamiento-ejecución a nivel de estación de trabajo.

Lo más importante es su modo de trabajo: no es un ejecutor pasivo que espera instrucciones, sino un runtime activo que percibe continuamente el estado del trabajo y decide cuándo intervenir.

Observa qué ventana estás cambiando, cuánto tiempo permaneces en una página, en qué ritmo avanza la tarea—y luego decide si debe actuar o no. Este diseño, en esencia, es muy diferente del modo “respuesta pasiva” de todas las herramientas de IA actuales.

Valor estructural de la capa de ejecución

Quiero profundizar un poco en por qué la ausencia de la capa de ejecución es un problema estructural, no solo una brecha funcional.

La estructura de la cadena de herramientas de AI Agents puede entenderse así:

Capa de modelos: responsable del razonamiento, ya bastante madura.

Capa de marco: encargada de la orquestación de tareas, en rápida convergencia.

Capa de herramientas: para mejorar en escenarios específicos, altamente homogénea.

Capa de ejecución: responsable de percepción a nivel de estación y ejecución cruzada de herramientas, casi vacía.

La falta de esta capa no solo hace que el uso del Agent sea “menos bueno”. El problema más profundo es que las capacidades del Agent están artificialmente limitadas por el contenedor de contexto.

Por ejemplo, la capacidad de Cursor se limita a IDEs. La de Claude Code, al terminal. Dentro de sus contenedores, son muy poderosos, pero fuera de ellos, no saben ni pueden responder a lo que sucede.

Esto significa que, en esencia, los AI Agents siguen siendo una forma de “mejora local”—potencian tu capacidad en una herramienta específica, pero no en todo tu flujo de trabajo.

Para que un Agent realmente se implemente, necesita percepción y ejecución que atraviesen estos límites de contenedor. Se requiere un sistema de IA en ejecución que pueda ver el panorama completo y manipularlo.

Aquí es donde entra Violoop.

Decisiones de diseño que merecen reflexión profunda

En la arquitectura de Violoop, hay varias decisiones de diseño que, en mi opinión, no son solo opciones funcionales, sino reflejos de una comprensión profunda del problema.

Modo de aprendizaje por grabación de pantalla: respuesta positiva a la “realidad sin API”

Muchas empresas aún operan sistemas heredados sin ninguna API. No es un problema de deuda técnica, sino una restricción real—estos sistemas no desaparecerán a corto plazo ni abrirán interfaces de repente.

El modo de aprendizaje por grabación de pantalla de Violoop, que usa aprendizaje reforzado para construir modelos de estructura de tareas, en lugar de grabar y reproducir coordenadas fijas. La decisión detrás de esto es: el entorno laboral real es dinámico, cualquier automatización basada en rutas fijas fallará cuando la UI cambie. Solo entendiendo la intención de la tarea, se puede mantener alta estabilidad en cambios.

Esta decisión es correcta, y también la causa fundamental por la que las herramientas tradicionales de RPA enfrentan límites en escalabilidad.

División entre el lado del dispositivo y la nube: respuesta a costos de inferencia y límites de privacidad

El procesamiento multimodal de alta frecuencia (percepción de pantalla, comprensión visual, filtrado de datos sensibles) se realiza en chips locales, mientras que la inferencia compleja se hace en la nube.

Esta división resuelve dos problemas: primero, el costo—la inferencia multimodal es la principal fuente de gastos en ejecución de Agents, y la localización puede reducir significativamente el costo por ejecución; segundo, la privacidad—los datos sensibles se filtran antes de subir a la nube, cumpliendo con las políticas de datos empresariales.

Más importante aún, esta arquitectura permite que Violoop esté en modo de espera 24/7—combinando Wake-on-LAN, puede despertar automáticamente la máquina en horarios específicos, ejecutar tareas y volver a dormir. Esto es imposible para un Agent solo software.

Aislamiento de permisos a nivel hardware: respuesta a los riesgos de ejecución autónoma

Un chip de seguridad independiente se encarga de la revisión de permisos, aislado físicamente del chip principal. Operaciones de alto riesgo deben pasar por un proceso de confirmación hardware, sin posibilidad de ser bypassed por software, y si se desconecta físicamente, todo se detiene.

Este diseño me llamó mucho la atención porque demuestra que el equipo entiende claramente los riesgos de la “ejecución autónoma”: no basta con prompts y prompts del sistema para mantener el control, sino que se necesita una restricción rígida en tiempo de ejecución. Solo quienes han desplegado Agents en entornos productivos pueden tener esa percepción.

¿Por qué surge esto ahora?

Una pregunta interesante: la falta de una capa de ejecución no es un problema nuevo, ¿por qué proyectos como Violoop aparecen ahora?

Mi juicio es que varias condiciones han madurado simultáneamente en los últimos tiempos:

Primero, la capacidad de inferencia multimodal en el borde ya alcanza niveles en tiempo real para procesar señales visuales de pantalla. Hardware anterior no podía hacer esto.

Segundo, la capacidad de comprensión de tareas de los grandes modelos es suficientemente fuerte, haciendo factible “entender la intención de la tarea” en lugar de solo “grabar secuencias de operación”. Esto es la base para que el modo de aprendizaje por grabación funcione.

Tercero, la ola de popularidad de OpenClaw ha expuesto la carencia en la capa de ejecución, haciendo visible la demanda del mercado en esa dirección.

El madurar conjunto de estos tres factores abre una ventana que antes no existía.

El equipo de Violoop también respalda esta percepción: el CEO Jaylen He es un emprendedor en serie, que llevó su equipo a YC; el CTO King Zhu, con formación en MIT EECS, completó su grado en 3.5 años, con experiencia en Microsoft Xbox, HoloLens, Surface, y desde 2023 ha desplegado en empresas Fortune 500. No es un equipo que empezó a hacer hardware de IA solo porque OpenClaw se volvió popular, sino que ya venían validando esa dirección antes de que la tendencia explotara.

Además, Violoop ha cerrado dos rondas de financiamiento en un mes, la segunda desde el primer encuentro hasta la firma en una semana, y la tercera ya está en proceso—lo que indica que los inversores también reconocen el potencial de esta línea.

Señal verdaderamente relevante

El producto lanzará su campaña de crowdfunding en Kickstarter en abril. Aún no está en producción en masa, y muchas capacidades deben ser validadas en entornos reales. Los límites de generalización del modo de aprendizaje por grabación, la sostenibilidad a largo plazo del sistema Skill, la estabilidad del hardware en producción—son preguntas que requieren tiempo y datos de usuarios reales para responder.

Pero hay algo que ya puedo afirmar con certeza:

La capa de ejecución es una infraestructura que el ecosistema de Agents debe completar en los próximos dos o tres años. No porque un producto haya sido exitoso, sino porque sin esa capa, toda la inversión en percepción y razonamiento no se traducirá en mejoras reales en la eficiencia del trabajo cotidiano.

Este lugar, tarde o temprano, será ocupado.

El problema actual no es “si la capa de ejecución es importante”, sino “quién, cómo y cuándo hacerlo”.

Violoop es uno de los pocos proyectos que, en esta línea, ha pensado en los problemas con claridad y ha diseñado una arquitectura con su propio juicio.

El éxito de OpenClaw ha mostrado el potencial de los Agents. Pero el verdadero punto de inflexión en su implementación probablemente no será cuando salga un nuevo modelo, sino cuando se complete la infraestructura de la capa de ejecución.

Eso es, en realidad, la señal más importante detrás de toda esta ola de entusiasmo.