Se han incorporado agentes de IA a su equipo. Su ciclo de mejora aún 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. Desarrollamos software para retrospectivas, por lo que este enfoque es el que mejor conocemos; el ciclo que describe funciona con cualquier herramienta y ceremonia que ya tengan.

¿Prefiere leer primero la versión resumida 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 introdujo en el ámbito de la fabricación 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 Project Retrospectives (2001), de Norm Kerth, 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 culpas 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 jamás 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, competente 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 noveles con energía infinita, pero sin ningún contexto», razón por la cual «el tiempo que se ahorra gracias al código generado por la 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. Hay dos aspectos nuevos al respecto.

El nuevo empleado no se queja durante la comida. Un agente se topa con un obstáculo, lo sortea y sigue adelante. No llega a frustrarse lo suficiente 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 reunión 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 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 de estilo retro: la guía de Codex de OpenAI reza: «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 bucles 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 suma de esfuerzos 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é es lo que 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: aproximadamente el 70 % de los fallos silenciosos son detectados en primer lugar por una persona)
Instrumentación	¿Qué hace que el agente lo registre? (Nadie registra los problemas que no se le ha indicado que busque)
Grabación	¿Qué contiene un registro útil y dónde se encuentra?
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 farsa?

Hay tres disciplinas que marcan la diferencia entre un «loop» y un diario, y a cada una de ellas 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, sí se pueden contabilizar ocho entradasmissing-documentation. (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 a un nivel demasiado bajo, el problema se repetirá para todos los demás; si se hace a un nivel demasiado alto, se sobrecarga un artefacto que nadie lee. (Capítulo: ¿Dónde debe aplicarse la corrección?)
• El criterio en una sala. Parte de la fricción es deliberada: el punto de control que alguien eligió como punto de revisión (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). Decidir si mantener o eliminar, establecer prioridades y las correcciones que implican 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 es casi 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: es el 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 ciclo de trabajo 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 identificados que se han desarrollado en este campo y los esquemas de clasificación en uso. Comience 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 y 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, cuyo precio se compara con el de sus competidores.
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 breve? 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 reunión retrospectiva.

Preguntas frecuentes

¿Es necesario que los agentes de IA cuenten con su propia retrospectiva independiente?

No. El enfoque que se propone en esta guía amplía el ciclo de mejora que su equipo ya lleva a cabo, a menudo como un único punto del orden del día en la retropectiva existente, en lugar de añadir una nueva ceremonia. El agente participa aportando pruebas y proponiendo soluciones; el equipo es quien toma la decisión.

¿Por qué no se detectan los roces con los agentes de IA en las retrospectivas habituales?

Hay dos razones. Los agentes no se quejan: cuando se topan con un obstáculo, lo sortean y siguen adelante, por lo que nadie lleva el problema a la sesión posterior. Y las pruebas se desvanecen: cuando termina la sesión, el contexto de la fricción desaparece con ella, de modo que la siguiente sesión se enfrenta al mismo obstáculo desde cero.

Ya registramos los historiales de nuestros agentes. ¿No es eso suficiente?

La mera observación no supone una mejora. Alrededor del 90 % de los equipos implementan la monitorización de los rastros de sus agentes, pero solo entre el 37 % y el 52 % evalúa de forma sistemática la información que recogen. Los rastros son materia prima; el ciclo requiere disciplina en la recopilación, síntesis y un foro a nivel de equipo en el que los responsables de las correcciones tomen decisiones de forma conjunta.

¿Debería ser la propia IA la encargada de llevar a cabo la retrospectiva?

No. El agente es un participante: aporta las pruebas, elabora las soluciones y responde a las preguntas. El equipo es quien toma las decisiones, ya que las soluciones se incorporan a procesos, documentos y presupuestos de los que las personas son responsables y ante los que deben rendir cuentas.

¿Cuál es la versión mínima viable de esta práctica?

Añada un punto al orden del día de su retrospectiva habitual (¿qué ha funcionado con la IA en este ciclo?) y coméntenlo. Sin registros, sin etiquetas. Eso ya es mejor que el silencio y, para un uso moderado de los agentes, puede ser suficiente. El resto de la guía se refiere a lo que debe añadir cuando esa conversación se repita una y otra vez.

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.