Queremos que Orkas sea la base sobre la que funcione una empresa nativa de IA. Ese objetivo lleva directamente a una pregunta: ¿cómo colaboran varias personas y varios agentes en un mismo proyecto?
La respuesta es bastante distinta del trabajo en equipo al que estamos acostumbrados. Para entender por qué, conviene empezar por el origen de la colaboración entre personas. (Si buscas el recorrido paso a paso por el producto, consulta Proyectos compartidos: cómo trabajan juntos personas y agentes de IA en Orkas. Este artículo trata del razonamiento que hay detrás).
La colaboración humana se construyó en torno a dos límites humanos
Primero, las personas tenemos un ancho de banda y una memoria limitados. Solo podemos asimilar cierta cantidad de información a la vez y solo podemos recordar hasta cierto punto. Por eso los equipos necesitan comunicarse sin parar: compartir novedades, alinear objetivos, alinear el avance. Las reuniones semanales, las dailies, los informes diarios y semanales, el «¿hacemos un sync rápido?», el «tenemos que alinearnos»: todo eso compensa este límite.
Segundo, buena parte tiene que ocurrir cara a cara. En persona hay más canales que las palabras: el lenguaje corporal, el tono y la expresión también transmiten información. Cuando alguien dice «el plan me parece bien» al otro lado de la mesa, notas si lo dice en serio. Igual de importante: verse en persona genera confianza. Por eso tantos equipos en remoto siguen reuniéndose en persona de vez en cuando.
Qué cambia cuando se suman agentes
En un equipo de personas y agentes, la parte humana de la colaboración sigue importando. Pero trabajar con agentes es muy distinto de trabajar con personas. Los agentes tienen tres fortalezas claras y tres debilidades claras.
Tres fortalezas
Mucho ancho de banda y gran capacidad de ejecución. Sobre todo en tareas con objetivos claros y medibles. Y las tareas que los agentes pueden completar se están volviendo rápidamente más largas, difíciles y complejas. Al describir su propio agente de programación, Meta relata una tarea de optimización de kernels de GPU en la que el agente trabajó hasta 24 horas e hizo más de 1000 llamadas a herramientas (Meta). En octubre de 2026, Linus Torvalds publicó una serie de parches para el kernel de Linux cuyo código, programas de prueba y primer borrador del mensaje de commit escribió Claude Code; él hizo las mediciones en su propia máquina (LWN).
El conocimiento y las herramientas del mundo, de principio a fin y entre disciplinas. El preentrenamiento ya ha volcado el conocimiento del mundo en el modelo. Con las herramientas adecuadas, un agente puede llevar un trabajo de principio a fin, pasando por varias disciplinas: escribir el PRD → diseñar → desarrollar → probar → lanzar. Cuando ese mismo trabajo lo hacen personas, hacen falta producto, diseño, ingeniería y QA trabajando juntos, con otra ronda de alineación en cada traspaso.
Pocas debilidades humanas, y ninguna confianza que ganarse antes. Un agente no se cansa, no tiene días malos y no le da vergüenza hacer una pregunta básica. Un agente nuevo puede empezar en cuanto tiene el contexto del proyecto. No hay periodo de adaptación ni relación que construir primero.
Tres debilidades
Necesita un contexto limpio. Un contexto erróneo lo desvía. Nos ha pasado: un campo de nuestro panel de analítica decía que los datos «no se pueden vincular», cuando en realidad sí se podía; el propio campo estaba mal calculado. Dos agentes distintos leyeron esa línea y los dos abandonaron un análisis completo del recorrido de usuario. Una persona que viera esa conclusión preguntaría «¿esto sigue siendo correcto?». Un agente suele darla por buena sin más.
Le cuesta atribuir causas a largo plazo. Cuando varias variables influyen a la vez en el resultado, es fácil que culpe a la equivocada, y las personas tienen que corregirlo. Durante un tiempo, Google no indexaba algunas páginas nuevas de nuestro sitio. Un agente concluyó que «el sitio no tiene suficiente autoridad, así que Google no le dedica presupuesto de rastreo» y recomendó conseguir backlinks primero. Lo cuestionamos y lo comprobamos: la gran mayoría de las páginas del sitio ya estaban indexadas. Las pocas que no lo estaban parecían más bien temas demasiado alejados de la temática del sitio. El presupuesto de rastreo no tenía nada que ver, y conseguir backlinks habría sido un error.
Se adapta mal a un entorno que cambia, sobre todo cuando el cambio no está en sus datos de preentrenamiento. Una web recién rediseñada, una norma de una plataforma que acaba de cambiar, un producto que salió el mes pasado: una persona nota que «esto es distinto» y cambia de enfoque. Un agente a menudo sigue trabajando con lo que ya sabe y reintenta lo mismo una y otra vez.
Por qué las apps de chat no encajan
Las apps de chat se diseñaron para que trabajen personas con personas: los mensajes van pasando uno tras otro, las @menciones y las confirmaciones de lectura mantienen a todos sincronizados, y la información queda repartida entre canales. Ese diseño compensa justo los dos límites de antes. Las personas tenemos poco ancho de banda y poca memoria, así que no paramos de escribir y de alinearnos.
Para los agentes, ese molde no sirve:
- La charla informal, las discusiones sobre la marcha y los planes que luego se descartaron son, para un agente, ruido de contexto.
- Un agente no necesita ganarse la confianza conversando.
- Lo que un agente necesita de verdad es un contexto limpio y una tarea clara.
Así que la colaboración entre personas y agentes necesita un rediseño. Y a medida que los agentes sean más capaces, nuestra forma de colaborar también seguirá cambiando. En Orkas todavía lo estamos resolviendo.
Qué hace Orkas: conservar lo que no ha cambiado y rediseñar lo que sí
Nuestro enfoque es conservar las partes de la colaboración que no han cambiado y rediseñar las que sí. Abajo tienes un proyecto compartido en Orkas; las cuatro ideas corresponden a las cuatro zonas resaltadas.
1. Asignar, traspasar y revisar el trabajo: Pendientes
Esto existía mucho antes de los agentes, y lo seguimos necesitando. Por ahora, cada tarea de nuestros proyectos tiene un responsable humano, y una persona responde del resultado final.
En el producto funciona así. Cada tarea pendiente se asigna a una persona, y esa persona decide qué agente hace el trabajo. Solo el responsable puede iniciarla; el agente se ejecuta en el ordenador del propio responsable, con su modelo y sus créditos. Cuando termina, el agente pasa la tarea a Esperando confirmación en lugar de darla por completada él mismo. Solo está terminada cuando el responsable la ha revisado y ha hecho los cambios necesarios.
2. Compartir objetivos, antecedentes y contexto: Objetivos y reglas, Memoria
Aquí, personas y agentes comparten el mismo contexto, así que los datos clave siguen alineados.
Lo que hay en Objetivos y reglas y en Memoria se comparte en todas las conversaciones de este proyecto, y los agentes lo siguen siempre. Por ejemplo, pon en Objetivos y reglas una definición como «retención mensual = usuarios nuevos que vuelven el mes siguiente», y registra las decisiones clave en la memoria del proyecto. Cuando se incorpora un miembro nuevo con sus agentes, desde el primer día leen exactamente lo mismo.
3. Traspasar mediante archivos, mantener el proceso aparte
La Biblioteca del proyecto se sincroniza entre los miembros, y una tarea pendiente puede llevar cualquier archivo adjunto. El trabajo se entrega en forma de archivos, no de historial de chat.
Mantenemos aparte, a propósito, la mayor parte del proceso intermedio, para que no se convierta en ruido de contexto dañino para los agentes. Las pestañas bloqueadas Tareas y Automatización son solo tuyas. Un agente puede dar cientos de pasos y probar tres enfoques antes de producir un informe. Tu compañero recibe solo el informe; el proceso se queda en tus propias tareas y nunca acaba en el contexto de sus agentes.
4. Compartir agentes privados con el equipo
Los miembros pueden compartir sus agentes privados para que los use el resto del equipo. Estos agentes llevan consigo la experiencia y el criterio de calidad de su dueño. Compartirlos acelera a todos, y los problemas que la gente encuentra al usarlos pueden corregirse mediante la autoevolución, y eso amplía las capacidades de todo el proyecto.
Cuando se comparte un agente, Orkas empaqueta sus instrucciones de trabajo y sus habilidades, incluidas las que fue desarrollando por su cuenta mientras trabajaba. Su memoria y su historial de chat no se incluyen. Cuando la persona que lo compartió actualiza el agente, los miembros reciben la nueva versión automáticamente.
Un problema abierto y todavía incipiente
La colaboración entre personas y agentes está aún en una fase muy temprana, y las respuestas todavía no han convergido. A medida que los modelos mejoren, gran parte de lo que los agentes necesitan para colaborar pasará a los propios modelos.
Algunos modelos ya pueden hacerlo de forma nativa: ejecutar varios subagentes en paralelo para explorar un problema desde distintos ángulos, o planificar primero y después enviar subagentes a ejecutar el plan. Muse Spark Open, que Meta publicó con pesos abiertos en octubre de 2026, se describe como un modelo entrenado para dividir el trabajo, repartirlo entre subagentes y coordinarlos (blog de PyTorch).
Así que nuestra forma de colaborar cambiará a medida que mejoren los modelos. Las tareas pendientes, el contexto compartido, el traspaso mediante archivos y los agentes compartidos son nuestra respuesta para lo que los modelos pueden hacer hoy, no la forma definitiva.
Para cerrar
Hemos conservado lo que no ha cambiado: alguien es responsable del trabajo, alguien lo revisa, y los objetivos y el contexto siguen alineados. Hemos rediseñado lo que sí: traspasar mediante archivos, mantener el proceso aparte y convertir la experiencia y el gusto de cada persona en agentes que el equipo puede usar.
Seguimos explorando todo esto y nos encantaría intercambiar impresiones. Si diriges un equipo en el que personas y agentes trabajan juntos, pruébalo primero en un proyecto. Puedes descargar Orkas gratis para macOS y Windows.