Lo que aprendí de OpenClaw y lo que OpenClaw aprendió de mí

Empecé pensando principalmente en capacidades. La experiencia me llevó a otro lugar: cuanto más puede hacer un asistente, más importante resulta decidir qué debe hacer, qué debe preguntarnos y cuándo tiene que detenerse.

Durante los últimos años nos hemos acostumbrado a una relación bastante sencilla con la inteligencia artificial.

Preguntamos algo, recibimos una respuesta, la evaluamos y decidimos qué hacer después.

Pero estamos entrando en otra etapa.

Los asistentes pueden utilizar herramientas, recuperar información, conservar contexto, encadenar pasos y, en algunos casos, ejecutar acciones.

Eso cambia la pregunta.

Ya no basta con saber si una inteligencia artificial es capaz.

También necesitamos decidir qué autonomía queremos darle.

Lo he descubierto trabajando durante meses con OpenClaw, un sistema que he ido configurando como asistente personal.

Al principio quería conseguir que hiciera más cosas.

Con el tiempo descubrí que esa no era la parte verdaderamente difícil.

Mi primera mirada era bastante previsible.

Conectar herramientas. Dar acceso controlado a información. Utilizar WhatsApp como canal de conversación. Incorporar Rabbit R1 como otra forma de interacción. Conservar contexto entre conversaciones.

La idea parecía sencilla: construir un asistente cada vez más capaz.

• ¿Qué puede hacer sin preguntarme?
• ¿Cuándo debe detenerse?
• ¿Qué debe recordar?
• ¿Qué ocurre cuando encuentra información contradictoria?
• ¿Cómo distinguir una propuesta de una acción realmente ejecutada?

Estas preguntas terminaron siendo más importantes que muchas decisiones técnicas.

Porque existe una diferencia considerable entre una inteligencia artificial que nos ayuda a pensar y otra a la que empezamos a delegar acciones.

La primera necesita buenas respuestas.

La segunda necesita además límites, permisos y criterios de parada.

A través de instrucciones, documentación, configuraciones, memoria y conversaciones, el sistema ha ido incorporando algunas reglas de mi forma de trabajar.

Proponer no es aprobar. Aprobar no es ejecutar.

Una prueba que ha funcionado una vez no se convierte automáticamente en una solución estable.

Una acción irreversible merece más precaución que una prueba que podemos deshacer.

Prefiero un cambio pequeño, verificable y reversible antes que una arquitectura más espectacular pero difícil de comprender.

Cuando algo falla, quiero entender primero qué capa ha fallado antes de empezar a borrar, reinstalar o reconstruir.

Estas reglas parecen instrucciones para una máquina.

En realidad son también una descripción de mi propio criterio.

Y ahí apareció algo que no esperaba.

Muchas decisiones cotidianas funcionan de forma implícita.

Sabemos cuándo queremos revisar algo, cuándo preferimos detenernos o cuándo una acción nos parece demasiado arriesgada.

Pero una máquina necesita fronteras más claras.

• ¿Qué significa exactamente que algo está aprobado?
• ¿Cuándo una prueba deja de ser experimental?
• ¿Qué debe documentarse?
• ¿Qué puede automatizarse?
• ¿Qué merece supervisión humana?
• ¿Cuándo un error debe detener el proceso?
• ¿Cuándo continuar deja de ser progreso?

Al intentar trasladar esas reglas al asistente descubrí que algunas tampoco estaban completamente formuladas en mi cabeza.

Intentar enseñar a una inteligencia artificial cómo quiero trabajar me ha obligado primero a comprender mejor cómo trabajo yo.

El proceso tampoco ha sido limpio.

Ha habido actualizaciones, incompatibilidades, canales que dejaron de responder, configuraciones que hubo que revisar, pruebas fallidas y decisiones que finalmente preferimos no ejecutar.

Todo eso puede parecer fricción técnica. Pero también contiene información.

Un error revela una dependencia que no habíamos visto.

Una actualización muestra cuánto entendemos realmente de aquello que tenemos funcionando.

Una copia de seguridad deja de ser una rutina cuando sabemos exactamente qué estamos protegiendo.

Y una automatización que falla recuerda por qué necesitamos poder volver atrás.

En varias ocasiones, el comportamiento más inteligente ha consistido precisamente en detenerse.

No ejecutar todavía. No actualizar todavía. No corregir antes de comprender.

A veces un buen sistema no es el que hace más.

Es el que sabe cuándo no debe continuar.

Existe una tentación bastante natural cuando una automatización empieza a funcionar: añadir otra herramienta, otro permiso, otra integración, otro flujo.

Pero un asistente puede tener muchas herramientas y ser peor sistema. Puede conservar mucha información y generar más ruido. Puede automatizar muchas acciones y aumentar nuestra dependencia. Puede parecer extraordinariamente inteligente y seguir siendo imprevisible.

Con el tiempo he ido llegando a otra medida de calidad:

La capacidad impresiona; la previsibilidad genera confianza.

Y cuando una inteligencia artificial empieza a intervenir en tareas reales, la confianza importa bastante más que una demostración espectacular.

Para mí, un asistente útil debe mantener una relación razonable entre cinco elementos:

capacidad, memoria, contexto, permisos y criterio.

Si una de esas capas crece sin las otras, el sistema empieza a desequilibrarse.

En mi caso, puedo conversar con Nexo desde WhatsApp o desde Rabbit R1.

Ya no estoy necesariamente abriendo una aplicación y empezando desde cero.

Entro en una conversación donde existen contexto anterior, determinadas reglas y una historia de decisiones.

Durante años hemos organizado nuestra vida digital alrededor de aplicaciones: una aplicación para cada función. Abrir, utilizar, cerrar.

Los asistentes persistentes empiezan a introducir otra lógica: una capa de inteligencia que puede atravesar distintas herramientas y situaciones.

Eso puede reducir mucha fricción. Pero también plantea una obligación nueva.

Cuanto más natural resulta la tecnología, más importante es comprender qué sabe, qué recuerda, qué puede hacer y dónde terminan sus permisos.

La comodidad no debería volver invisible la arquitectura.

A veces utilizamos la imagen de Jarvis para describir el futuro de los asistentes personales. Es una metáfora atractiva, pero no expresa exactamente lo que busco.

No quiero una inteligencia artificial que tome el control de mi vida.

Tampoco quiero automatizar todo aquello que técnicamente sea posible automatizar.

Quiero algo bastante menos espectacular: un sistema que conozca suficiente contexto como para no obligarme a explicar lo mismo una y otra vez.

Que reduzca fricción. Que conserve continuidad. Que pueda ejecutar determinadas acciones y pregunte antes de ejecutar otras.

Que distinga lo que sabe de lo que supone.

Y que no confunda una intención con una acción ya realizada.

No quiero delegar mi criterio. Quiero evitar tener que reconstruir constantemente el contexto sobre el que aplico ese criterio.

Eso cambia bastante la forma de pensar un asistente personal.

Estas preguntas no resuelven todos los problemas de los agentes.

Pero obligan a colocar el criterio antes que la fascinación técnica.

OpenClaw ha ido incorporando mis preferencias, mis reglas y parte de la arquitectura con la que organizo mi trabajo.

Yo he aprendido algo distinto.

Construir un asistente personal no consiste simplemente en conectar un modelo de inteligencia artificial con herramientas.

Consiste en diseñar una relación entre capacidad y responsabilidad.

Entre memoria y privacidad. Entre autonomía y supervisión. Entre continuidad y control.

Y esa arquitectura termina diciendo bastante sobre la persona que la construye.

Porque para decidir qué quiero que una máquina haga por mí tengo que decidir primero qué quiero seguir decidiendo yo.

Para establecer qué puede recordar tengo que pensar qué merece continuidad.

Para decidir cuándo debe preguntarme tengo que reconocer dónde sitúo mi responsabilidad.

Y para enseñarle mis límites tengo que haberlos entendido primero.

Empecé este proyecto intentando conseguir que una inteligencia artificial me conociera mejor.

He terminado descubriendo que, para lograrlo, primero tenía que explicarme mejor a mí mismo.