El informe existe. La habitación no.

Recientemente, un agente de IA ha añadido seis elementos a nuestro propio tablero retro.

El primero decía: «Empiece por verificar antes de actuar: los errores de ejecución de los agentes representan el 38 % de los obstáculos (el doble que la siguiente causa); el coste recurrente radica en determinar una causa, realizar un push o reorientar el trabajo antes de comprobar el código en producción, los datos o el estado de la rama». Detrás de ello se encontraban las pruebas que respaldaban este patrón: errores de git/estado-de-rama durante el trabajo con agentes concurrentes en ocho sesiones y dos repositorios; comprobaciones parciales previas al push que interrumpieron la integración continua (CI) en cuatro sesiones, dos veces en un mismo repositorio el mismo día; una laguna en las simulaciones de pruebas que una sesión había señalado el día anterior, con la nota de que el documento de corrección nunca se redactó.

Hay dos aspectos de ese panel que merecen especial atención. En primer lugar, ninguna sesión de trabajo por sí sola habría clasificado ninguno de estos problemas como el más grave: cada caso se tomaba con indiferencia, suponía unos minutos perdidos, una molestia que alguien había sabido sortear. La clasificación solo existe de forma agregada, entre sesiones y personas. En segundo lugar, y lo que resulta más incómodo: los puntos más condenatorios no tenían nada que ver con el agente ni con el código. Se referían a nosotros: correcciones que habíamos acordado y no habíamos adoptado, el mismo estancamiento que se repetía sin que «se hubiera implementado ninguna corrección definitiva entre medias».

Un informe automatizado puede proporcionarle toda esta información. Lo que no puede hacer es conseguir que las personas responsables del proceso, de la documentación, del presupuesto para herramientas y de las prioridades se reúnan y decidan qué medidas tomar al respecto. El informe existe. La reunión, no. Este artículo trata precisamente de esa reunión.

Todos construyeron el circuito

Para mediados de 2026, «identificar qué ha fallado en el trabajo asistido por IA y transmitir esa información» se ha convertido en una práctica consensuada. Existe bajo al menos seis denominaciones, y todas ellas son adecuadas. El Feedback Flywheel de Rahul Garg aprovecha las dificultades surgidas durante las sesiones para elaborar documentos de orientación y medidas de protección. La «Compound Engineering» de Every hace que cada unidad de trabajo sirva de aprendizaje para la siguiente. Thoughtworks dota a los agentes de sensores; Addy Osmani denomina a esta disciplina Loop Engineering. Los proveedores de plataformas cierran el ciclo a escala de flota: la «memoria onírica» de OpenAI, la «curación de contexto» de Anthropic y el archivado automático de tickets de Factory Signals. El proyecto de código abierto de GitHub gh-aw, un marco para flujos de trabajo agenticos escrito en Markdown con lenguaje natural, es el que más se acerca a nuestro tema: sus flujos de trabajo de análisis de sesiones ya generan informes automatizados de análisis de sesiones. Un ejemplo público, el análisis automatizado de 50 sesiones de un solo día, señala una tasa de omisión del 24 % y una tasa de éxito del ejecutor del 33 % como «señales de fallo».

Si utiliza alguno de estos elementos, siga utilizándolos. Este artículo no propone sustituir ninguno de ellos. Sin embargo, clasifique los bucles según el nivel en el que se ejecutan y observe el patrón:

Un manual de estrategias para profesionales. Una configuración de sesión. Una memoria de plataforma. Una pila de observabilidad. Una flota de un proveedor.

Casi todos los ciclos en este ámbito son ciclos individuales: una persona y su agente, o un proveedor y su flota. El «flywheel» de Garg es el único diseño que apuesta por los artefactos compartidos por el equipo, y su lista de cadencia incluye una línea que casi nadie ha puesto en práctica: «En la retrospectiva: un punto del orden del día en la retrospectiva de sprint actual: ¿qué ha funcionado con la IA en este sprint?» Menciona el lugar y pasa a otro tema. El «dogfooding» de GitHub, por su parte, genera exactamente el informe de fricciones que una ceremonia de equipo desearía como aportación, y lo posiciona como observabilidad de ingeniería, y punto.

Lo más parecido a una excepción lo encontramos en Scrum.org, cuya serie sobre equipos híbridos incluye Cómo llevar a cabo la retrospectiva de sprint cuando la mitad de su equipo está formada por agentes de IA. Merece la pena leerlo, ya que aborda con seriedad la cuestión del lugar de celebración y la responde de forma diferente a como lo hacemos nosotros: su retrospectiva se convierte en una sesión de depuración basada en datos sobre las métricas de los agentes (frecuencia de reescritura de indicaciones, índices de desviación, consumo de tokens). Se trata de una perspectiva útil, y un equipo podría llevar a cabo ambas. Sin embargo, se centra en los agentes; el ciclo del que trata este artículo se centra en la colaboración: las causas en lugar de los síntomas, con soluciones dirigidas al nivel al que correspondan (el briefing, la documentación, el proceso, el material), y con los agentes aportando su propia visión del trabajo en lugar de aparecer como un panel de control.

La carencia no radica en la tecnología. Todos los componentes (captura, agregación, generación de informes) ya están disponibles en la actualidad. La carencia es de carácter práctico: casi nadie ha explicado qué hace el equipo, en conjunto, cuando llega el informe.

¿Qué es lo que realmente necesita una habitación?

La tendencia natural en este caso es aumentar el nivel de automatización: una mejor agrupación en clústeres, correcciones aplicadas automáticamente y un panel de control. Para una amplia categoría de hallazgos, ese enfoque es acertado, y los flujos de trabajo mencionados anteriormente lo llevan a cabo con eficacia. Sin embargo, enumere las decisiones que el informe plantea realmente y fíjese en su estructura:

• Mantener o eliminar. ¿Qué fricción recurrente supone un desperdicio y cuál es un control deliberado? El control de revisión que ralentiza al agente podría ser la correa que alguien ha elegido (un resumen de la ponencia de Armin Ronacher en AIE Europe: «la fricción es lo necesario… para dirigir»); Radar, de Thoughtworks, advierte ahora sobre la deuda cognitiva que supone eliminar demasiado. Eliminar un punto de control altera el riesgo de todos. Esa es, por definición, una decisión del equipo.
• Dónde se aplica la solución. Un patrón de fricción recurrente se resuelve en algún nivel: una nota personal, una indicación o habilidad, la configuración del entorno, la documentación, el propio material de trabajo, el proceso o en una fase anterior con un proveedor. Esos elementos tienen responsables, y los responsables son personas diferentes.
• Prioridad en el contexto de la agregación. Cinco minutos que cada persona dedica a tareas secundarias por sesión pasan desapercibidos para cada individuo, pero suponen un coste importante para el equipo en su conjunto. Tomar medidas al respecto (reescribir la plantilla compartida, modificar el proceso de admisión, elevar el asunto al proveedor) requiere un nivel de decisión que ningún individuo tiene por sí solo.
• La comprobación de la adopción. ¿Se ha adoptado realmente la corrección del ciclo anterior y ha desaparecido el problema? La frase más valiosa de nuestra propia junta fue precisamente esta: señalado ayer, nunca se implementó. Un bucle sin esta comprobación es como un volante de inercia que gira en el aire.

Ninguna de estas acciones es un cálculo. Todas ellas son negociaciones entre personas que controlan diferentes aspectos del funcionamiento del equipo. Los profesionales que trabajan en solitario integran legítimamente estas decisiones basándose en su intuición; los procesos de la flota generan legítimamente el subconjunto legible por la máquina a la velocidad de esta. Las versiones a escala de equipo requieren que las personas se reúnan en una sala con un vocabulario común y con la autoridad necesaria para reorientar la atención. Eso no es un proceso. Es una ceremonia.

¿Por qué una boda de estilo retro —o una ceremonia de carácter similar—?

Antes de entrar en materia, quiero dejar claro lo siguiente: nos dedicamos a la venta de software retrospectivo. Precisamente por eso, en esta sección se argumenta a partir de las propiedades del producto y no de la marca: le ruego que tenga en cuenta este matiz a la hora de valorar nuestra conclusión y que compruebe usted mismo dichas propiedades.

Las características que debe reunir el conjunto de decisiones: un espacio que sea recurrente (las fricciones menores y crónicas nunca dan lugar a una reunión puntual), en el que no se culpe a nadie por norma, que abarque a todos los responsables (deben estar presentes las personas encargadas de los procesos, la documentación, las herramientas y las prioridades), y basado en pruebas. Para la mayoría de los equipos, la retrospectiva de sprint es el lugar donde ya se dan esas cuatro características: no hay que defender ninguna nueva reunión en una «guerra de calendarios», y existe una convención de «ausencia de culpas» que es más importante de lo que parece, ya que el modo de fallo tentador en este caso es el análisis post mortem que culpa a los agentes, y la escuela de ingeniería de arneses rechaza explícitamente ese enfoque por defecto: el ingeniero culpa al modelo y lo archiva bajo «esperar a la próxima versión»; en su lugar, corríjase el arnés (Osmani, Agent Harness Engineering).

Sin embargo, la formulación más honesta de esta afirmación consiste en valorar a los rivales, en lugar de proclamar a un ganador:

• La planificación del sprint es la que tiene mayor peso en la sala, pero su orden del día está orientado al futuro y siempre está repleto; el análisis retrospectivo suele quedarse sin espacio en el tiempo dedicado a la planificación. La planificación es el momento en el que se programan las acciones acordadas, no donde se analizan los patrones.
• El análisis post mortem «impecable» cuenta con las normas adecuadas, pero se activa en el momento equivocado: se convoca para abordar los grandes fallos puntuales, nunca para el patrón de «cinco minutos y ocho personas en cada sprint», que es precisamente el patrón que solo la agregación puede detectar.
• Asíncrono — un informe y un sistema de seguimiento es la opción más económica y, para la mayoría de los elementos rutinarios, resulta suficiente. Lo que no puede hacer es tomar decisiones: la decisión de «mantener o eliminar» es una negociación, las disputas sobre el nivel de prioridad traspasan los límites de la responsabilidad de cada propietario, y la reordenación de prioridades requiere que los propietarios participen en la misma conversación.
• La alternativa nula —limitarse a hablar de IA en el modo retro, sin registros ni etiquetas— es gratuita, se adapta a la situación actual y, para un equipo pequeño con un uso moderado de los agentes, puede que sea realmente suficiente. Empiece por ahí. Lo que no permite es la comparabilidad entre sesiones, las tendencias o la comprobación de la adopción: una conversación que parte de cero cada vez. La práctica que se describe a continuación es lo que debe añadir cuando esa conversación se repita continuamente.

Así pues, la afirmación, con toda sinceridad: el «retro» —o su ceremonia actual de forma equivalente—. La revisión mensual de la campaña por parte del equipo de medios y la revisión de clasificación por parte del equipo de soporte son la misma ceremonia con nombres diferentes, y nada en esta práctica supone código: el registro de incidencias de una cuenta de publicidad enredada o de una biblioteca de plantillas incoherente se lee exactamente igual que el registro de incidencias de un repositorio heredado.

El agente presente en la sala: participante, nunca moderador

Si las pruebas proceden de agentes, ¿debería ser el agente quien se encargara de ello? No, y no principalmente por la razón que usted podría suponer.

La razón por la que esto falla: los modelos actuales no son fiables precisamente en este tipo de evaluaciones: los veredictos de los LLM varían ante entradas idénticas ~13,6 % de las veces, y en un estudio de producción de ocho semanas ~70 % de los fallos silenciosos de los agentes fueron detectados en primer lugar por una persona, y no mediante pruebas ni supervisión. Esto es cierto en la actualidad; los modelos mejoran.

La razón por la que esto no cambia: la facilitación y la toma de decisiones distribuyen la atención del equipo y modifican los artefactos de los que el equipo es responsable y ante los que debe rendir cuentas. Esa autoridad no se transfiere al modelo más competente de la sala, del mismo modo que tampoco se transfiere al ingeniero más competente de la sala. Se trata de un hecho organizativo, no de una falta de competencia.

Así pues, el agente participa tal y como lo haría el colaborador mejor informado. Aporta pruebas: sus registros de sesión, etiquetados y con indicación de los costes. Responde a las preguntas: a la pregunta «¿qué intentó realmente antes de aplicar la solución provisional?» se le da una respuesta respaldada por la transcripción. Redacta, pero nunca decide: las soluciones propuestas llegan con niveles de prioridad sugeridos; el equipo las modifica, reordena sus prioridades o las descarta. Y retoma las acciones aceptadas (la edición del documento, el cambio de configuración), ejecutándolas tras la ceremonia y sometiéndolas a una revisión habitual. La práctica investigadora tiene un nombre para esta división: en el marco ACE, el agente es el Reflector y un Curador consolida lo que se incluye en el manual de estrategias. Realizamos una adaptación deliberada: en ACE, el curador es un componente determinista; aquí, los curadores son el equipo.

Una de las asimetrías es la relacionada con la carga de trabajo. Todo lo que el agente introduce en la sala debe estar sin restricciones; un agente que necesite permiso para informar de problemas de fricción no informará de todos ellos. Todo lo que sale de la sala hacia aquello en lo que los agentes se basan posteriormente (memoria, archivos de contexto, configuración) se somete a una revisión ordinaria, ya que esa ruta de escritura constituye una superficie reconocida de contaminación y desviación (OWASP Agentic Top 10, ASI06). El procedimiento se sitúa exactamente en ese límite: entrada de pruebas sin restricciones, salida de escrituras restringidas.

Los quince minutos

Lo que, en realidad, proponemos que el equipo pruebe este sprint, con cada bucle que ya se ejecuta sin modificaciones:

1. Al finalizar cada sesión, el agente redacta una breve entrada retrospectiva sobre su propio trabajo: lo que ha salido bien, cada problema identificado con su causa raíz y el coste que ha supuesto, una propuesta de solución en forma de ticket y el nivel al que se dirige. Se registra junto con el trabajo, sin restricciones.
2. Antes de la reunión retrospectiva, las aportaciones realizadas desde la última sesión se sintetizan en un resumen de una página: temas recurrentes con mayor prevalencia, qué grupo de causas fundamentales predomina, si se han adoptado las soluciones propuestas anteriormente y las tres principales acciones recomendadas. El resumen sirve de base para el debate; no lo sustituye.
3. En la reunión de seguimiento (un punto del orden del día, no una nueva reunión): quince minutos dedicados a «¿qué ha funcionado con la IA en este ciclo y qué ha seguido siendo un problema?». Los responsables evaluarán las opciones: mantener o descartar, confirmar o reorientar las prioridades, y asignar responsables a las tres principales.
4. En el siguiente ciclo, la comprobación de cumplimiento del pliego de condiciones indica si la fricción se ha reducido realmente. Esa comprobación es la que convierte el informe en un bucle; además, fue ahí donde nuestra propia junta directiva nos descubrió.

Modos de fallo, denominados así para que pueda protegerse contra ellos: teatro retro (la ceremonia que se lleva a cabo ante el público: lectura breve, asentimientos con la cabeza, nada decidido; la regla de los «3 principales con sus responsables» existe precisamente para esto); culpa al agente (considerar que «el agente se equivocó» es la explicación en lugar de un residuo; la mayoría de los fallos se remontan al sistema de pruebas y a las entradas, no al razonamiento del modelo); expansión desmedida de la lista de deseos (veinte acciones, sin responsables); y el bucle que nunca se cierra (la falta de seguimiento: se aplican las correcciones, pero nadie comprueba la tendencia). Hemos redactado una completa guía práctica sobre cómo fracasan las ceremonias; todos los modos que en ella se recogen son aplicables también en este caso.

Lo que no estamos afirmando

No sustituye a ningún ciclo de trabajo de los proveedores: sus resultados son las entradas de esta ceremonia. No se trata de una nueva reunión. Tampoco es una ceremonia dirigida por IA; viniendo de una empresa cuyo producto son las retrospectivas, esta restricción es deliberada. No es necesario para un profesional que trabaja en solitario, cuyos ciclos se cierran correctamente de forma intuitiva. Y el objetivo no es la ausencia total de fricción: cierta fricción constituye la superficie de control, y el punto del orden del día existe para elegir, no para descartarlo de inmediato.

¿Qué nos haría cambiar de opinión?

Se trata de un documento de debate, por lo que a continuación se expone la parte falsable. Si los bucles de los proveedores generan un juicio auténtico que trascienda las herramientas y las personas, y no se limitan a simples actualizaciones de memoria en toda la flota, el margen de maniobra se reduce a una mera función de auditoría. Si los equipos que llevan a cabo la versión asíncrona «solo con resumen» muestran la misma tendencia a la reducción de la fricción que los equipos que tratan el punto del orden del día, esos quince minutos serán una farsa y así lo diremos. Y nuestra propia afirmación sobre el vocabulario etiquetado se basa en un experimento de fiabilidad entre evaluadores que estamos llevando a cabo actualmente con entradas reales, en lugar de afirmarlo de antemano. Preferimos publicar las cifras antes que el nivel de confianza.

Si su equipo lleva a cabo alguna de estas actividades (el punto del orden del día, la sesión asíncrona o cualquier ceremonia que se nos haya pasado por alto), nos gustaría saber cómo ha ido: ai-discussion@teamretro.com.

---

Siguiente capítulo: Cómo llevar a cabo la retrospectiva de colaboración con IA — guía para el moderador sobre los quince minutos: la plantilla, el formato de participación y las tarjetas de preguntas. Parte de la guía de retrospectivas de agentes de IA.