Se han incorporado agentes de IA a su equipo. Su ciclo de mejora no se ha percatado de ello.

Esta guía trata sobre cómo aplicar algo que los equipos ya conocen —el ciclo de mejora continua— a algo nuevo: el trabajo que su equipo realiza actualmente con agentes de IA. Nos dedicamos al desarrollo de software retrospectivo, por lo que este enfoque es el que mejor conocemos; el ciclo que describe funciona con cualquier herramienta y ceremonia que ya utilicen.

¿Prefiere leer primero la versión de 10 minutos? Empiece por la entrada de introducción rápida, recabar opiniones de los agentes de IA, y luego vuelva aquí para conocer el panorama completo.

El truco más antiguo del trabajo en equipo

Cada método que utiliza su equipo para mejorar es una variante de un mismo ciclo: realizar el trabajo, analizar cómo ha ido, introducir un cambio y comprobar si dicho cambio ha sido eficaz. Deming lo aplicó al sector manufacturero como «Planificar-Hacer-Verificar-Actuar»; Toyota lo convirtió en una cultura y lo denominó «kaizen»; el sector del software lo transformó en una ceremonia. La obra de Norm Kerth Project Retrospectives (2001) popularizó la retrospectiva entre los equipos de software, y el Manifiesto Ágil la estableció como un principio: «A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz y, a continuación, adapta y ajusta su comportamiento en consecuencia» (principio 12). Las reuniones de análisis posteriores sin culpar a nadie siguen el mismo ciclo para los incidentes; el balance de una campaña de un equipo de comunicación y la revisión de la clasificación de incidencias de un equipo de soporte lo llevan a cabo sin utilizar nunca la palabra «ágil».

El ciclo funciona gracias a una premisa: el trabajo genera datos sobre cómo debería cambiar el trabajo. Los equipos que recogen esos datos se potencian: cada ciclo mejora el siguiente. Los equipos que no lo hacen, se repiten.

Durante setenta años, las pruebas procedían de las personas. La gente se daba cuenta de la fricción, se quejaba durante la comida y lo planteaba en el retro. Los sensores del bucle eran humanos.

Un nuevo tipo de trabajador

En algún momento de los últimos dos años, su equipo comenzó a delegar trabajo real a un nuevo tipo de trabajador. Los agentes de IA ahora escriben y revisan código, auditan cuentas publicitarias, redactan respuestas de atención al cliente, elaboran informes y migran contenidos. Y este trabajador tiene un perfil peculiar: incansable, rápido, capaz… y carente de contexto. La descripción de Rahul Garg se ha convertido en la expresión habitual del sector: «Los asistentes de IA son como desarrolladores junior con energía infinita, pero sin contexto alguno», razón por la cual «el tiempo que se ahorra con el código generado por IA suele consumirse en el esfuerzo necesario para corregirlo» (Patrones para reducir la fricción en el desarrollo asistido por IA).

Ese coste de corrección es la fricción, y el trabajo de los agentes la genera constantemente: las instrucciones ambiguas que obligan a adivinar, el documento que no existía, la estructura de la cuenta que da problemas en cada sesión, la herramienta que se bloqueó, el requisito que cambió a mitad de la tarea. Nada de esto es nuevo: el trabajo humano genera la misma lista. Sin embargo, hay dos aspectos que sí son nuevos.

El nuevo empleado no se queja durante la hora de la comida. Un agente se encuentra con un obstáculo, lo sortea y sigue adelante. No llega a sentirse lo suficientemente frustrado como para plantear el problema en la reunión retrospectiva del viernes. La señal en la que siempre se ha basado su ciclo de mejora (una persona que presta atención a los roces hasta que una ceremonia los recoge) no se activa.

Y las pruebas se esfuman. Cuando finaliza la sesión, el contexto de la fricción desaparece con ella. En la siguiente sesión (otra persona, el mismo agente), se vuelve a topar con el mismo obstáculo desde cero. No se puede mejorar a partir de pruebas que nunca se han recopilado; el ciclo se agota silenciosamente, mientras que el trabajo parece estar bien.

Así pues, esta es la situación, expresada sin rodeos: una parte cada vez mayor del trabajo de su equipo genera ahora datos de mejora que su ciclo de mejora nunca estuvo diseñado para recopilar.

El equipo se dio cuenta y reconstruyó el bucle por su cuenta

Las personas más cercanas al ámbito del trabajo de los agentes se dieron cuenta de ello desde el principio y, a mediados de 2026, «detectar la fricción de los agentes y retroalimentarla» se ha convertido en una práctica consensuada que recibe al menos media docena de denominaciones: el Feedback Flywheel de Garg, la Compound Engineering de Every, la Loop Engineering de Osmani, la ingeniería de arneses con sensores de Thoughtworks, los bucles de memoria a escala de flota de los proveedores de plataformas («dreaming» de OpenAI, Factory Signals) y gh-aw de GitHub, cuyos flujos de trabajo de análisis de sesiones ya generan informes automatizados de análisis de sesiones. Incluso los proveedores recurren a este término retro: las directrices de Codex de OpenAI indican: «cuando Codex cometa el mismo error dos veces, pídale que realice una retrospectiva y actualice AGENTS.md» (mejores prácticas).

Estos bucles son útiles. Si su equipo utiliza alguno de ellos, manténgalo; todo lo que se explica en esta guía se basa en ellos, en lugar de sustituirlos. No obstante, tenga en cuenta dos carencias.

En primer lugar, la brecha en la práctica: observar no equivale a mejorar. Alrededor del 90 % de los equipos implementan el seguimiento de sus agentes; sin embargo, solo entre el 37 % y el 52 % evalúan de forma sistemática los datos que recogen (LangChain, junio de 2026). La mayoría de los equipos disponen del panel de control. Son, sin embargo, mucho menos los que cuentan con el ciclo de mejora.

En segundo lugar, la brecha de forma: casi todos los ciclos del sector se desarrollan de forma aislada. Un profesional que ajusta su propio manual de estrategias, una plataforma que gestiona la memoria de su flota, una pila de observabilidad que agrupa sus propios rastros. Setenta años de mejora continua demuestran que la sinergia se produce en el equipo: allí donde reside la visión global, donde se reevalúan las prioridades y donde los procesos, la documentación y los presupuestos tienen responsables. Esa capa es precisamente la pieza que nadie ha reconstruido. Los informes existen; pero aún no se ha reservado la sala.

La anatomía del bucle

Cuando su equipo decida poner esto en marcha, el proceso tiene más elementos que intervienen de lo que parece a primera vista. El recorrido que debe superar un solo elemento de fricción:

Escenario	La pregunta
Alojamiento web	¿Dónde se ejecuta el agente y qué permite observar?
Detección	¿Cómo se detecta la fricción? (Autodetección, un agente de revisión, telemetría y corrección humana, que sigue siendo el sensor predominante: ~el 70 % de los fallos silenciosos son detectados en primer lugar por una persona)
Instrumentación	¿Qué es lo que hace que el agente lo registre? (Nadie registra los problemas que no se le ha indicado que busque)
Grabación	¿Qué datos contiene un registro útil y dónde se almacena?
La cosecha	¿Cómo se recopilan los registros de tantas sesiones y de tantas personas?
Síntesis	¿Qué patrones son importantes y a qué nivel corresponde cada corrección?
Cerrar el ciclo	¿La solución redujo realmente la fricción, o fue solo una puesta en escena?

Hay tres aspectos que marcan la diferencia entre un «loop» y un diario, y a cada uno de ellos se le dedica un capítulo propio en esta guía:

• Registros, no impresiones. Una entrada útil describe el momento, señala una causa principal a partir de un pequeño vocabulario fijo y propone una solución del tamaño de un ticket. Las etiquetas fijas son las que permiten agrupar las entradas: «la documentación era confusa» no se puede contabilizar; en cambio, ochomissing-documentationentradas sí se pueden contabilizar. (Capítulo: Cómo es un buen registro de fricción)
• La cuestión de la jerarquía. Cada patrón recurrente se soluciona en algún nivel: una nota de memoria, una indicación, la configuración, la documentación, el propio material de trabajo, el proceso o en una fase anterior con un proveedor. Si se aplica la solución en un nivel demasiado bajo, el problema se repetirá para todos los demás; si se hace en un nivel demasiado alto, se sobrecargará un artefacto que nadie lee. (Capítulo: ¿Dónde debe aplicarse la corrección?)
• La toma de decisiones en una sala. Parte de la fricción es deliberada: la fase de revisión que alguien eligió como punto de control (un resumen de la ponencia de Ronacher en AIE Europe: «la fricción es lo que se necesita… para dirigir»; Thoughtworks advierte ahora de la deuda cognitiva que supone un trabajo de los agentes con una falta excesiva de fricción). Las decisiones de «mantener o eliminar», las prioridades y las correcciones que afectan a varios responsables son negociaciones, no cálculos: requieren que los responsables de las correcciones participen en una misma conversación. (Capítulo: El informe existe. La sala no.)

Hacia dónde se dirige la historia

La lista de cadencia de Garg para el «flywheel» incluye una línea que casi parece un reto: «un punto del orden del día en la retrospectiva de sprint actual: ¿qué ha funcionado con la IA en este sprint?» (martinfowler.com). Ese es el hilo conductor de esta guía. No se trata de una ceremonia nueva, ni de una dirigida por la IA, sino del ciclo de mejora en el que su equipo ya confía, ampliado para incluir al miembro más reciente del equipo, con el agente como participante: este aporta las pruebas, redacta las soluciones y responde a las preguntas; el equipo se reserva el criterio, ya que las correcciones se plasman en procesos, documentos y presupuestos de los que las personas son responsables y por los que deben rendir cuentas.

Y partamos de una base realista: si su equipo se limita a añadir el punto al orden del día y a debatirlo (sin actas ni etiquetas), eso ya es mejor que el silencio, y para un uso moderado de la herramienta puede ser suficiente. El resto de esta guía recoge lo que debe añadir cuando esa conversación se repita una y otra vez.

Los capítulos

1. Esta página: por qué el trabajo asistido por IA necesita el proceso que su equipo ya lleva a cabo.
2. El mapa: bucles de retroalimentación de los agentes, herramientas y enfoques: el marco de referencia que abarca el ciclo de vida de la fricción, los bucles específicos que se han desarrollado en este campo y los esquemas de clasificación en uso. Empiece por aquí si su enfoque es de arriba abajo.
3. Cómo debe ser un buen registro de fricciones: la captura en el momento, las etiquetas de las causas fundamentales, las reglas de «nunca registrar».
4. ¿Dónde debería aplicarse la corrección? El problema de la altitud y la tabla de enrutamiento.
5. El informe existe. La sala no. Por qué la síntesis es una ceremonia de equipo, con un precio competitivo frente a sus rivales.
6. Cómo llevar a cabo la sesión retrospectiva de colaboración con IA: la guía para el moderador, con el punto del orden del día de 15 minutos, la plantilla y las tarjetas de preguntas.
7. Empiece en diez minutos: ai-session-retro y ai-retro-brief, los extremos de captura y síntesis del bucle, listos para instalar.

¿Prefiere la versión resumida? Dos entradas relacionadas en el blog: la guía de inicio rápido, recabar opiniones de los agentes de IA, y el relato de la primera vez que lo pusimos en práctica nosotros mismos, nuestros compañeros de equipo de IA se unieron a nuestra retrospectiva.

Preferimos que se discuta con nosotros a que se nos dé la razón de forma educada: cada capítulo termina con lo que nos haría cambiar de opinión.