Team Topologies para equipos de personas y agentes: dónde encajan realmente los agentes

Por Victor Hoang · Actualizado el 22 de septiembre de 2026

Team Topologies es el marco de Matthew Skelton y Manuel Pais para organizar los equipos en torno a cuatro tipos (stream-aligned, enabling, complicated-subsystem y de plataforma) de modo que el trabajo fluya con la menor carga de coordinación posible. Aplicado a equipos donde un agente de IA realiza parte del trabajo, los mismos cuatro tipos siguen siendo válidos, pero cambian dos cosas: la carga cognitiva gana una categoría nueva (ser responsable de un resultado que usted no produjo personalmente) y la Ley de Conway ahora se aplica a un sistema donde parte del «equipo» que hace el trabajo es software, no solo personas. Esta es la mitad estructural de un cambio más amplio que se aborda en qué es el futuro del trabajo.

Datos clave

• Team Topologies define cuatro tipos fundamentales de equipo: stream-aligned (alineado con un flujo de valor de negocio), enabling (ayuda a un equipo stream-aligned a superar obstáculos y detecta capacidades faltantes), complicated-subsystem (se encarga del trabajo que exige conocimientos especializados profundos o matemáticos) y de plataforma (ofrece un producto interno atractivo que acelera a los equipos stream-aligned). Fuente: Team Topologies, "Key concepts and practices"
• El artículo de Melvin Conway de 1968 enunció la tesis original: «Cualquier organización que diseñe un sistema... producirá inevitablemente un diseño cuya estructura es una copia de la estructura de comunicación de la organización». También señaló que los posibles canales de comunicación en un grupo crecen aproximadamente con el cuadrado de su tamaño. Fuente: Melvin Conway, "How Do Committees Invent?" (Datamation, 1968)
• En la investigación DORA de 2025, el 90% de las organizaciones ha adoptado al menos una plataforma interna, y el informe halló una correlación directa entre la alta calidad de la plataforma y la capacidad de una organización para obtener valor de la adopción de la IA. Fuente: Google Cloud, announcing the 2025 DORA Report
• El Work Trend Index 2026 de Microsoft encontró que los factores organizacionales (cultura, apoyo de los gerentes y prácticas de talento) explican más del doble del impacto medido sobre los resultados de la IA que los factores individuales, e identificó a los profesionales «Frontier», trabajadores en quienes la capacidad individual y la preparación organizacional se refuerzan mutuamente, como aproximadamente el 19% de la fuerza laboral encuestada que usa IA. Fuente: Microsoft WorkLab, "2026 Work Trend Index"

Qué dice realmente Team Topologies

Skelton y Pais crearon Team Topologies para resolver un problema concreto: los organigramas suelen dibujarse en torno a líneas de reporte y no a cómo fluye realmente el trabajo, y ese desajuste se manifiesta en despliegues lentos, responsabilidades poco claras y equipos que no pueden entregar sin la aprobación de otros tres equipos. Su respuesta es organizarse en torno a exactamente cuatro tipos de equipo y ser deliberados sobre cómo interactúan esos equipos, en lugar de dejar que los patrones de interacción surjan por accidente.

Un equipo stream-aligned es responsable de un tramo de valor de negocio de principio a fin y está configurado para entregarlo con el mínimo de traspasos. Un equipo enabling existe para cerrar una brecha de capacidad en otro equipo, a propósito y de forma temporal, y retirarse una vez cerrada la brecha. Un equipo complicated-subsystem asume la pieza del sistema que realmente exige una experiencia profunda y acotada (el motor de pagos, el modelo de recomendación, el algoritmo de precios) para que los equipos stream-aligned no necesiten cada uno su propio especialista. Un equipo de plataforma construye el producto interno, la infraestructura compartida, las herramientas y la capacidad de autoservicio que permiten a los equipos stream-aligned avanzar rápido sin reinventar cinco veces las mismas tuberías.

Nada de ese vocabulario necesita cambiar para describir un equipo donde parte del «trabajo» lo hace un agente de IA en lugar de una persona. Lo que hay que añadir es una respuesta clara a dos preguntas para las que Skelton y Pais no estaban escribiendo: dónde se ubica realmente el trabajo del agente dentro de estos cuatro tipos y qué ocurre con la carga cognitiva cuando una persona es responsable de un resultado que no produjo personalmente.

La carga cognitiva siempre fue la verdadera restricción

Team Topologies trata el tamaño y el alcance del equipo como consecuencias de una sola variable: la carga cognitiva, el esfuerzo mental total que un equipo puede sostener antes de que se degraden tanto la calidad como la velocidad. Un equipo stream-aligned al que se le encarga una quinta responsabilidad sin relación no se vuelve más capaz, se vuelve más lento y descuidado en las cinco. Por eso el marco insiste en responsabilidades de equipo acotadas y bien delimitadas, no amplias.

Los agentes cambian lo que llena ese presupuesto sin reducir necesariamente el total. Un equipo que antes dedicaba su carga cognitiva a producir un entregable ahora dedica una parte a especificar la tarea con la precisión suficiente para que un agente la intente y otra parte a verificar un resultado que parece seguro sea o no correcto. De ejecutor a orquestador aborda este cambio al nivel del puesto de una persona. A nivel de equipo, el mismo cambio significa que la carga cognitiva de un equipo tiene una nueva partida: la carga de responsabilidad, el costo continuo de ser responsable de una decisión o de un artefacto que generó un agente y no un compañero. Si se ignora esa partida al dimensionar un equipo, se obtiene un equipo stream-aligned que parece escaso de personal en el papel y que en silencio se ahoga en resultados de agentes sin revisar.

Dónde se ubican los agentes en cada tipo de equipo

La respuesta honesta es que los agentes no crean un quinto tipo de equipo. Cambian la composición interna y la carga de interacción de los cuatro que ya existen.

Equipos stream-aligned: el agente trabaja dentro del flujo, una persona sigue siendo responsable del resultado

Aquí es donde se concentra hoy la mayor parte del uso de agentes, y debería seguir siendo lo predeterminado. Un agente redacta el código, el texto de la campaña, la respuesta de soporte o el análisis de primera pasada, y una persona con nombre en el equipo sigue siendo responsable de lo que se entrega. El alcance del equipo no cambia; cambia su división interna del trabajo. Hay que vigilar la deriva del alcance en la dirección contraria: un equipo stream-aligned que empieza en silencio a construir y mantener su propia infraestructura de agentes (bibliotecas de prompts, arneses de evaluación, conectores de herramientas) además de su trabajo de producto real ha asumido un segundo trabajo, sin límites, que no pidió. Es el patrón de aumentación, no automatización funcionando como se espera, hasta que el trabajo de infraestructura supera el presupuesto cognitivo del equipo.

Equipos enabling: los agentes aceleran la transferencia de habilidades, pero no la hacen automática

Skelton y Pais diseñaron los equipos enabling para ser temporales por naturaleza: existen para cerrar una brecha de capacidad específica y se disuelven o pasan a otra cosa una vez cerrada. En un contexto de personas y agentes, este es el equipo que enseña a otros equipos stream-aligned a redactar un brief de agente utilizable, a fijar un listón de evaluación y a detectar una respuesta verosímil pero equivocada antes de que se entregue. La tentación es dejar que un equipo enabling se convierta en silencio en una plataforma permanente en la sombra, que hace el trabajo en lugar de transferir la habilidad. Eso frustra el propósito y esconde la carga cognitiva real dentro de un equipo que nadie contrasta con el marco.

Equipos complicated-subsystem: el especialista rara vez es reemplazado, se extiende su alcance

Un equipo complicated-subsystem existe porque alguna pieza del sistema exige realmente una experiencia profunda y difícil de distribuir. Los agentes encajan mal como responsables de ese subsistema, precisamente porque la razón de ser del equipo es que allí los errores son costosos y difíciles de detectar sin el conocimiento especializado. Donde los agentes ayudan es en el alcance: un especialista que revisa diez primeras pasadas redactadas por IA de un cambio al modelo de precios hace un uso distinto, y a menudo mejor, de una experiencia escasa que ese mismo especialista construyendo a mano los diez desde cero. Eso es human-in-the-loop funcionando como se espera: el especialista sigue siendo el control final, no un sello automático. La dotación del equipo de subsistema podría reducirse o su producción podría crecer, pero su límite de responsabilidad y su estándar de verificación no deberían moverse.

Equipos de plataforma: por qué un equipo interno de plataforma de IA aparece casi de inmediato

Es el tipo de equipo que se expande más rápido en cuanto más de dos o tres equipos stream-aligned empiezan a usar agentes de forma independiente. Si se los deja solos, cada equipo tiende a resolver por separado los mismos problemas: qué modelo invocar, cómo manejar credenciales y límites de costo, cómo registrar lo que hizo un agente con fines de auditoría, cómo conectarlo de forma segura a datos y herramientas internos. La investigación DORA de 2025 encontró que este patrón no es exclusivo de la IA: el 90% de las organizaciones ya había adoptado al menos una plataforma interna por esta razón, y la calidad de la plataforma predecía directamente si la adopción de la IA se convertía en una mejora real del desempeño o en un esfuerzo disperso y duplicado.

Un equipo interno de plataforma de IA se forma por la misma razón que se forma un equipo de plataforma compartida de DevOps: construir las tuberías una vez, bien, y ofrecerlas como capacidad de autoservicio supera a que cada equipo stream-aligned construya las suyas. Lo que suele tener a su cargo: conexiones compartidas con proveedores de modelos, una capa de interoperabilidad basada en MCP para que los agentes lleguen a las herramientas y datos internos de forma coherente y no mediante cinco integraciones puntuales, barreras de protección de costo y uso, y un estándar compartido de evaluación y registro para que nadie reinvente desde cero el «¿cómo sabemos que este resultado es suficientemente bueno?». También es el responsable natural de todo lo que implique varios agentes coordinándose en una tarea, el tipo de infraestructura compartida y de alto riesgo que ningún equipo stream-aligned debería asumir por sí solo. Rework lo trata igual en el lado del producto: estandarizar los workflows orientados a agentes y la interoperabilidad MCP es territorio de Work Ops, porque esa infraestructura no debería vivir duplicada dentro de cada equipo que la toca.

La Ley de Conway cuando parte del equipo es software

La observación original de Conway de 1968 trataba de personas: una organización que diseña un sistema tiende a producir un diseño que refleja su propia estructura de comunicación, porque las interfaces entre módulos terminan coincidiendo con las interfaces entre los equipos que los construyeron. También señaló algo menos citado pero igual de útil: el número de posibles canales de comunicación en un grupo crece aproximadamente con el cuadrado de su tamaño, que es justamente la razón por la que los grupos grandes y poco coordinados producen diseños dispersos y mal integrados.

Esa lógica no deja de aplicarse cuando un agente hace parte del trabajo. Las conexiones de herramientas y los límites de acceso de un agente son en sí mismos una interfaz, estructuralmente igual al límite de API entre dos equipos humanos. Si cinco equipos stream-aligned arman cada uno su propia versión de «un agente que puede leer el CRM y redactar un correo», se obtienen cinco integraciones ligeramente distintas, cinco modos de fallo y cinco lugares donde una revisión de seguridad tiene que comprobar por separado. Es la Ley de Conway cumpliéndose exactamente como se predijo, con el acceso a herramientas de un agente en lugar de un canal de comunicación.

La jugada útil aquí es la misma que Team Topologies toma de la idea original de Conway: la maniobra inversa de Conway, que consiste en dar forma deliberadamente a la estructura organizacional que se quiere para obtener la arquitectura de sistema que se quiere, en lugar de descubrir la arquitectura por accidente cuando el organigrama ya está fijado. Si el objetivo es una forma coherente y auditable de que los agentes se conecten a los sistemas internos, la organización tiene que trazar un límite claro (normalmente el equipo de plataforma) que sea responsable de esa interfaz, en lugar de dejar que cinco equipos stream-aligned la reinventen por separado y llamar «flexibilidad» al desorden resultante.

Cuatro patrones de equipo para el trabajo de personas y agentes

Ninguno es una prescripción para copiar al pie de la letra. Son formas reconocibles, y la mayoría de las organizaciones ejecutará más de una a la vez, en distintas etapas de madurez.

Un diagnóstico útil: si no puede decir en cuál de estas cuatro formas se ubica hoy una pieza determinada de trabajo con agentes, eso suele ser el verdadero problema, no el modelo que usa ni el prompt que alguien escribió.

Señales de que su topología no se ha puesto al día

Algunos síntomas aparecen de forma fiable en las organizaciones que añadieron agentes a sus workflows sin revisar la estructura de los equipos:

• Duplicación silenciosa. Varios equipos stream-aligned han construido cada uno su propia versión de la misma capacidad de agente, porque no existe un equipo de plataforma que la ofrezca una sola vez. Es el patrón de Conway fragmentado descrito arriba, y suele aflorar primero como un hallazgo de revisión de seguridad que descubre cinco maneras distintas en que los agentes tocan la misma base de datos de clientes.
• Carga de responsabilidad invisible. El plan de dotación de un equipo sigue reflejando «cuánto trabajo puede producir este equipo», sin contabilizar el tiempo que ahora se dedica a verificar el resultado de los agentes. Es la versión a nivel de equipo de la paradoja de la productividad de la IA: la actividad sube mientras el rendimiento confiable no se mueve como sugieren las métricas de actividad.
• Un equipo enabling que nunca se va. Una transferencia temporal de habilidades se ha convertido en silencio en un equipo que hace el trabajo con agentes para todos los demás, lo que frustra el sentido de un equipo enabling y esconde una necesidad real de personal dentro de un equipo que nadie contrasta con su alcance real.
• Un límite de subsistema cruzado. Alguien ajeno al equipo especialista empezó a usar un agente para generar resultados en un dominio que antes requería la aprobación del equipo de subsistema, y nadie actualizó quién es realmente responsable del resultado.

Cómo empezar a aplicarlo

El orden importa menos que hacerlo de forma deliberada en lugar de dejar que ocurra por accidente:

1. Ubique los equipos actuales en los cuatro tipos, con honestidad, no con aspiraciones. La mayoría de las organizaciones descubre que ya hay trabajo informal de plataforma dentro de dos o tres equipos stream-aligned, sin etiquetar y sin coordinar.
2. Pregunte dónde se ha desplazado la carga de responsabilidad, y contrástelo con la dotación real. Si el tiempo de verificación ha crecido y la dotación no, la carga cognitiva real de ese equipo es mayor de lo que sugiere su organigrama.
3. Decida, a propósito, cuándo vale la pena crear un equipo de plataforma. El hallazgo de DORA de que la calidad de la plataforma predice el retorno organizacional de la IA es una buena prueba de sentido común: la duplicación visible entre equipos suele significar que la inversión se paga sola.
4. Dé a los equipos enabling una condición de salida antes de empezar. Defina de antemano qué significa «la brecha está cerrada», para que el equipo tenga un punto natural de disolución en lugar de convertirse en una función permanente y sin contabilizar.
5. Proteja de forma explícita el límite del complicated-subsystem. Deje por escrito qué decisiones siguen requiriendo la aprobación del equipo especialista sin importar qué generó el primer borrador, y trate saltarse ese límite como un incidente, no como una ganancia de eficiencia.

Nada de esto es una reorganización de una sola vez. El propio planteamiento de Microsoft sobre el rol de «agent boss» y la frontier firm trata la estructura de personas y agentes como una cuestión operativa continua, no como un diagrama dibujado una vez y archivado, y construir una cultura preparada para la IA es lo que evita que vuelva a las viejas costumbres en un trimestre. Los equipos de personas y agentes ya cubren el lado de las normas y la confianza de este cambio, cómo construyen las personas relaciones de trabajo con los agentes día a día. Esta es la mitad estructural del mismo problema, y las dos solo funcionan si alguien se hace realmente cargo de la decisión de diseño organizacional en lugar de que cada equipo improvise su propia respuesta.

Un organigrama que no se vuelve a dibujar después de que aparecen los agentes no es neutral. La duplicación, el tiempo de verificación sin contabilizar y la responsabilidad poco clara ocurren de todos modos, en silencio, dentro de la estructura que existiera antes de que alguien pensara en plantear la pregunta a propósito.