Queremos que Orkas sea la base sobre la que funcione una empresa nativa de IA. Ese objetivo lleva directo 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 sobre el razonamiento detrás).
La colaboración humana se construyó alrededor de 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 tienen que comunicarse todo el tiempo: compartir novedades, alinear objetivos, alinear avances. Las reuniones semanales, las dailies, los reportes diarios y semanales, el “¿nos ponemos al día rápido?”, el “hay que alinearnos”: todo eso compensa este límite.
Segundo, buena parte tiene que pasar 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 se ve bien” del otro lado de la mesa, te das cuenta de si lo dice en serio. Igual de importante: verse en persona genera confianza. Por eso tantos equipos remotos siguen reuniéndose en persona cada cierto tiempo.
Qué cambia cuando se suman agentes
En un equipo de personas y agentes, el lado humano 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 reporta 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 punta a punta y entre disciplinas. El preentrenamiento ya condensó el conocimiento del mundo en el modelo. Con las herramientas adecuadas, un agente puede llevar un trabajo de punta a punta, atravesando varias disciplinas: escribir el PRD → diseñar → desarrollar → probar → lanzar. Cuando ese mismo trabajo lo hacen personas, se necesita que producto, diseño, ingeniería y QA trabajen juntos, con otra ronda de alineación en cada entrega.
Pocas debilidades humanas, y ninguna confianza que ganarse antes. Un agente no se cansa, no tiene días malos y no le da pena 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 equivocado lo saca de rumbo. Nos pasó a nosotros: un campo de nuestro tablero 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 del usuario. Una persona que viera esa conclusión preguntaría “¿esto sigue siendo correcto?”. Un agente normalmente la toma tal cual.
Le cuesta atribuir causas a largo plazo. Cuando varias variables influyen al mismo tiempo 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 asigna presupuesto de rastreo” y recomendó conseguir backlinks primero. Lo cuestionamos y lo revisamos: 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 lo que trata el 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. Un sitio web recién rediseñado, una regla de una plataforma que acaba de cambiar, un producto que se lanzó el mes pasado: una persona nota que “esto es diferente” y cambia de enfoque. Un agente muchas veces sigue trabajando con lo que ya sabe y vuelve a intentar lo mismo una y otra vez.
Por qué las apps de chat no funcionan aquí
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 justamente los dos límites anteriores. Las personas tenemos poco ancho de banda y poca memoria, así que seguimos escribiendo y alineándonos sin parar.
Para los agentes, ese formato no sirve:
- La charla casual, las discusiones sobre la marcha y los planes que después se descartaron son, para un agente, ruido de contexto.
- Un agente no necesita ganarse la confianza conversando.
- Lo que un agente realmente necesita es un contexto limpio y una tarea clara.
Por eso la colaboración entre personas y agentes necesita un rediseño. Y a medida que los agentes sean más capaces, la forma en que colaboramos también va a seguir cambiando. En Orkas todavía lo estamos resolviendo.
Qué hace Orkas: conservar lo que no cambió y rediseñar lo que sí
Nuestro enfoque es conservar las partes de la colaboración que no cambiaron y rediseñar las que sí. Abajo ves un proyecto compartido en Orkas; las cuatro ideas corresponden a las cuatro áreas resaltadas.
1. Asignar, entregar 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 por el resultado final.
En el producto funciona así. Cada pendiente se asigna a una persona, y esa persona decide qué agente hace el trabajo. Solo el responsable puede iniciar el pendiente; el agente corre en la computadora del propio responsable, con su modelo y sus créditos. Cuando termina, el agente pasa el pendiente a Esperando confirmación en lugar de marcarlo como completado por su cuenta. Solo se da por terminado cuando el responsable lo revisa y hace 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 se mantienen alineados.
Lo que está en Objetivos y reglas y en Memoria se comparte en todas las conversaciones de este proyecto, y los agentes lo siguen cada vez. Por ejemplo, pon en Objetivos y reglas una definición como “retención mensual = usuarios nuevos que regresan el mes siguiente”, y registra las decisiones clave en la memoria del proyecto. Cuando se suma un miembro nuevo con sus agentes, desde el primer día leen exactamente lo mismo.
3. Entregar mediante archivos, mantener el proceso aparte
La Biblioteca del proyecto se sincroniza entre los miembros, y un pendiente puede llevar cualquier archivo adjunto. El trabajo se entrega como archivos, no como historial de chat.
A propósito, mantenemos aparte 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 reporte. Tu colega recibe solo el reporte; el proceso se queda en tus propias tareas y nunca termina 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 la experiencia y el criterio de calidad de su dueño. Compartirlos hace que todos avancen más rápido, y los problemas que la gente encuentra al usarlos se pueden corregir 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 en sus inicios
La colaboración entre personas y agentes todavía está en una etapa muy temprana, y las respuestas aún no convergen. A medida que los modelos mejoren, gran parte de lo que los agentes necesitan para colaborar va a pasar a los propios modelos.
Algunos modelos ya pueden hacerlo de forma nativa: correr 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 la forma en que colaboramos va a cambiar a medida que mejoren los modelos. Los pendientes, el contexto compartido, la entrega mediante archivos y los agentes compartidos son nuestra respuesta para lo que los modelos pueden hacer hoy, no la forma definitiva.
Para terminar
Conservamos lo que no cambió: alguien es responsable del trabajo, alguien lo revisa, y los objetivos y el contexto se mantienen alineados. Rediseñamos lo que sí: entregar 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 gustaría intercambiar ideas. Si lideras un equipo donde personas y agentes trabajan juntos, pruébalo primero en un proyecto. Puedes descargar Orkas gratis para macOS y Windows.