Openbot: compañeros IA con ordenador propio

Trabajo a diario con agentes. Claude Code me escribe código, lo revisa y lo despliega desde la terminal, y hasta le he dedicado algún post. Pero todos comparten una limitación de fondo: viven en mi ordenador, con mi sesión, mis credenciales y mis permisos. Cuando el agente actúa, actúa como yo. Y a medida que crece lo que les delegamos, eso pasa de detalle a problema de diseño.

Por eso me hizo levantar la vista el anuncio del 19 de agosto: CopilotKit —los creadores del protocolo AG-UI— publicó Openbot, un proyecto open source cuya premisa cabe en una frase: compañeros de trabajo IA donde cada bot tiene un ordenador propio, separado del tuyo.

Aviso honesto: no lo he desplegado todavía. Esto es análisis del anuncio y lectura del repo; la experiencia de uso, si llega, será otro post.

Qué propone Openbot

El eslogan del repo es «AI coworkers you can hand real work to, and actually trust with the access»: compañeros IA a los que pasarles trabajo real y confiarles el acceso de verdad. La palabra que importa es coworker, porque define la arquitectura entera:

Cada bot tiene su propio ordenador. Un navegador Chromium real con sus propios logins (no los tuyos), sus ficheros aislados y solo las herramientas que le concedas.
Agnóstico de agente. Openbot no trae agente propio: acepta cualquier endpoint AG-UI, sea LangGraph, CrewAI, Pydantic AI, Google ADK, el Claude Agent SDK o tu harness escrito a mano. Sin reescribir nada.
Un gateway por el que pasa todo. Cada acción se decide antes de ejecutarse y se registra después. Enseguida vuelvo sobre esto: es la parte que más me interesa.

Por dentro: TypeScript sobre Bun, Docker, PostgreSQL, API en Hono, frontend en React. Licencia MIT; se levanta con un docker run y un .env.

Atai Barkai, CEO de CopilotKit, lo presentó como «an open source Grok Bot that works with ANY agent harness»: la alternativa abierta a los bots-empleado que los grandes venden como servicio cerrado. El repo ronda las 2.600 estrellas a los cinco días, con la etiqueta v0.0.1 bien visible.

De autocompletar a compañero con ordenador propio

Un asistente en el editor, por bueno que sea, es una extensión de ti. Mi Claude Code usa mis claves SSH, mi configuración de git, mis sesiones abiertas. Si mete la pata, la mete con mi identidad, y distinguir en un log qué hice yo y qué hizo él es arqueología.

El salto conceptual de Openbot es darle al agente una identidad separada. El bot tiene su navegador con sus cuentas y sus ficheros. Le das de alta como a un empleado: estas credenciales, estas herramientas, nada más. Y si mañana lo "despides" —borras el contenedor—, sus accesos mueren con él y el registro de lo que hizo se queda contigo.

La idea no es nueva —llevamos años dando cuentas de servicio a los procesos—, pero nunca la había visto aplicada así, y en open source, a agentes que usan un navegador como una persona.

La parte que me interesa: el gateway

Lo que me hizo leerme el repo entero no es el robot con su mesa; es la frase del README sobre el gateway: «there is no path that acts without the record existing first». No existe un camino que actúe sin que el registro exista primero.

El flujo de cada acción: el bot pide ejecutar una herramienta, el gateway evalúa las políticas —reglas CEL que pueden inspeccionar el nombre de la herramienta, la URL de la página, la ruta del fichero o el bot concreto—, escribe la entrada de auditoría y solo entonces ejecuta. O rechaza, citando la regla exacta que lo impide. Y el diseño declarado es fail-closed: el deny se evalúa antes que el allow, y una política ausente no permite nada.

Otro detalle bien pensado: los traspasos humano-agente. Cuando el bot topa con un muro de login o un 2FA, pide ayuda y una persona toma el control del navegador; ese traspaso también queda registrado (control tomado, control devuelto). El momento más delicado —un humano metiendo credenciales en la máquina del bot— no escapa del registro.

Es, hasta donde yo sé, la primera respuesta seria en open source al problema de fondo de esta ola: cómo confiar acceso real a un agente. Hasta ahora había dos opciones: vértigo asumido (permisos amplios y a rezar) o sandbox total (tan aislado que no sirve para trabajo real). Openbot propone la tercera: acceso real, pero enumerado, concedido pieza a pieza y auditado sin excepciones.

El escepticismo sano

Ahora, los pies en el suelo: esto es una v0.0.1 alpha con cinco días de vida. Los autores lo escriben sin rodeos: «expect rough edges and bugs, and expect things to move». Y los bordes no son teóricos: el modo por defecto va sin autenticación, hay huecos de autorización reconocidos en los issues y se han señalado escenarios donde la evaluación de políticas puede fallar en abierto; justo lo contrario de lo que promete el diseño. Para un producto cuyo argumento central es el control, eso descarta hoy cualquier uso con credenciales reales. Ellos mismos lo desaconsejan.

Y un asterisco que no sorprenderá a quien me lea: el código es MIT y la auditoría y las credenciales viven en tu PostgreSQL, pero los hilos de conversación dependen de CopilotKit Intelligence, el servicio en la nube del fabricante, necesario para arrancar. No es pecado —los servidores se pagan—, pero digámoslo claro: hoy, el «self-hosted» de Openbot lleva cordón umbilical. Si el proyecto va en serio con la palabra open, ese es el hueco a cerrar; o el que la comunidad cerrará por ellos, que para eso es MIT.

Para qué lo probaría (y para qué todavía no)

Lo probaría ya, en sandbox y con cuentas desechables:

Tareas repetitivas de navegador sin API: vigilar portales de proveedores, descargar facturas de paneles diseñados en 2009, rellenar el mismo formulario cada mes.
Un bot de solo lectura contra paneles internos, para recopilar datos e informes.
Aprender el modelo de políticas: escribir reglas CEL contra un bot enjaulado me parece la mejor manera de entender qué significa "darle herramientas" a un agente.

Y lo que todavía no, ni de broma: credenciales de producción, correo, banca, nada que roce datos de clientes, ningún flujo sin supervisión. La regla es la de siempre: no importa lo que el agente sabe hacer, importa cuánto cuesta su peor error. Con una alpha de cinco días, esa cuenta sale sola.

Conclusión

La dirección me parece la correcta: los agentes van a dejar de ser autocompletadores con ínfulas para convertirse en procesos con identidad propia, y entonces la pregunta importante no será si les damos acceso, sino cómo se concede, se delimita y se registra ese acceso. Openbot pone esa pregunta en el centro de la arquitectura y la responde en un repo MIT que puedes leer, no en un PDF de marketing.

El estado, en cambio, es el que es: una alpha con agujeros conocidos y una dependencia de nube que desentona con el discurso. Mi plan: estrella en el repo, un despliegue en una máquina sacrificable, y paciencia. Si el experimento da para contarlo, habrá segunda parte.