Muchas personas, cuando piensan en compañeros de trabajo con IA, imaginan de entrada que deberían funcionar como un equipo, con un agente por rol. Uno para ingeniería, otro para marketing, otro que solo escribe entradas del blog.
Nosotros también lo construimos así. Okou te permitía crear muchos agentes en un workspace, cada uno con su propio nombre, avatar, Instrucciones y Workflows. En agosto incluso publicamos un artículo sobre cómo varios agentes se reparten el trabajo y se lo pasan entre sí. Nuestro propio workspace tenía unos cuantos. Lucas escribía las entradas del blog, Lisa llevaba la contabilidad, Iris se encargaba de la relación con inversores y yo tenía uno llamado Emily que clasificaba mi correo.
Pero la intuición del usuario es solo un punto de referencia. Antes de Notion, la gente daba por hecho que una herramienta de documentos necesitaba encabezados y pies de página.
El multiagente tampoco es una capacidad fundamental. Las capacidades fundamentales son las que todo producto de IA acabará necesitando: chatear, crear presentaciones y sitios web, manejar un ordenador. Tener varios agentes no está en esa lista.
Pensemos en Lucas, nuestro antiguo agente del blog. Más o menos un tercio de sus Instrucciones es la misma plantilla genérica que usa el Okou por defecto. El resto son tres procedimientos concretos: cómo publicar una entrada del blog en Strapi, cómo escribir las páginas de casos de uso de nuestra web y cómo preparar el informe diario de conversión de registros. Los 13 Workflows asociados a Lucas son públicos en el workspace. Ninguno pertenece solo a Lucas.
Así que la diferencia entre Lucas y el Okou por defecto se reduce a un nombre, un avatar y tres procedimientos que deberían haber sido Workflows. Esos procedimientos están encerrados dentro de Lucas. Si le pides al Okou por defecto que publique una entrada del blog, no tiene ninguna de esas reglas.
A medida que crecía el número de agentes, crecían también las combinaciones. Muchos agentes, muchos Workflows y muchas conversaciones interactúan entre sí, y cada combinación es lógica que nosotros tenemos que mantener y que los usuarios tienen que aprender. Nos topamos con preguntas a las que no sabíamos responder bien desde el punto de vista del usuario:
- ¿Por qué dos agentes no pueden compartir el mismo Workflow?
- ¿Por qué solo puedo hablar con Okou en Slack y no con mi propio agente privado? Si Lucas es una persona, debería poder hablarle desde cualquier sitio.
- ¿Por qué la memoria se comparte entre todos los agentes? Si cada agente es una persona, cada uno debería tener su propia memoria.
Todas tienen solución, pero cada una exige un trabajo de ingeniería considerable. Si se quedan sin resolver, el multiagente sigue siendo una experiencia a medias. Además, nos costaba encontrar un problema que solo pudieran resolver varios agentes. La queja que más oíamos era que había demasiados agentes que gestionar.
Así que decidimos que cada persona tenga un solo Okou. El modelo es más sencillo:
- Cada persona tiene un Okou por defecto.
- Tu Okou te pertenece y es privado.
- Tu Okou y el de un compañero no son el mismo agente.
- Tu Okou puede usar cualquier Workflow que alguien de tu organización haya marcado como Public.
Lo que antes colgaba de un agente ahora vive donde encaja mejor:
- Las Instrucciones son tuyas. Escribes un único conjunto y Okou lo sigue en la web, en Slack y en las automatizaciones.
- Los Workflows son del workspace. Cualquiera puede usar un Workflow Public que publique un compañero, y puedes copiarlo y hacerlo tuyo.
- Las cuentas conectadas son tuyas, así que ya no tienes que elegir qué agente obtiene acceso.
- Las conversaciones se agrupan en Proyectos, por cliente, proyecto o tema.
En este modelo, un agente es poco más que un conjunto de Instrucciones. Los tres procedimientos que hay dentro de Lucas deberían convertirse en Workflows que cualquiera pueda usar.
El multiagente es, en realidad, una práctica de gestión dentro de una organización, una forma de gestionar lo que puede hacer la IA. Cada organización tiene sus propios métodos de gestión, y no hay uno que sirva para todas. Un único agente se parece más a una herramienta, y las herramientas son más fáciles de entender y de adoptar. Lo que más necesitan los usuarios es sacar la tarea adelante. Después, una herramienta para hacerlo. Lo que menos necesitan es un método para hacerlo.
El equipo de Applied AI de Anthropic observó algo parecido en un artículo reciente sobre despliegues de agentes en empresas. En sus comparaciones entre varios despliegues, un único agente con Skills a menudo superaba en calidad a un diseño dividido en subagentes especializados, y muchas veces con menor coste y latencia por tarea. También escriben que «con demasiada frecuencia vemos empresas que dan a cada equipo o tipo de problema su propio subagente, y la arquitectura de agentes acaba convirtiéndose en una copia de su organigrama». Su artículo trata de arquitectura de agentes, no de diseño de producto, pero el razonamiento se puede trasladar.
Si miramos los productos de IA actuales, vemos cuatro modelos:
- Muchos agentes, muchas conversaciones. Así era Okou.
- Un agente, muchas conversaciones. Así funcionan ChatGPT, Codex y Claude Cowork.
- Un agente, una conversación. Así funciona Instinct.
- Muchos agentes, cada uno con una sola conversación. Así funciona Grok bot.
Nosotros teníamos la combinación más compleja, y no resolvía más problemas.
Sabemos que es un cambio que rompe con lo anterior. Dos cosas nos impidieron hacerlo antes: pedirte que aprendieras una nueva forma de trabajar, con un solo Okou y Workflows, y la falta de un camino claro para lo que ya habías construido. Este es ese camino:
- Tus conversaciones siguen ahí. Puedes encontrarlas en Proyectos, con la búsqueda y en sus enlaces originales.
- Si usabas distintos agentes para ordenar conversaciones, usa Proyectos. Mantener las conversaciones agrupadas por categoría era el principal motivo por el que mucha gente creaba agentes adicionales. Claude y ChatGPT resuelven esa misma necesidad con Proyectos.
- Si escribiste Instrucciones distintas para distintos agentes, guarda lo que tienen en común en tus Instrucciones personales y convierte los procedimientos específicos en Workflows.
Cuanto antes dejemos de construir abstracciones sobre varios agentes, mejor. Cuando abras Okou, ya no tendrás que decidir a qué agente preguntar. Dile a Okou lo que necesitas hacer y Okou se encarga del resto.
