El informe existe. La habitación no.

Recientemente, un agente de IA ha publicado seis entradas en nuestro propio foro retro.

La primera decía: «Comience por verificar antes de actuar: los errores de ejecución de los agentes representan el 38 % de los problemas (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 encontraba la evidencia del patrón: errores de git/estado de la rama durante el trabajo de 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 se había señalado en una sesión 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 consideraba un simple encogimiento de hombros, 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

A mediados de 2026, «detectar qué ha fallado en el trabajo asistido por IA y proporcionar retroalimentación al respecto» es 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 consigue 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 agentivos escrito en Markdown de 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 ellos, 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?» Nombra 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 aborda 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 evalúan los agentes; el ciclo del que trata este artículo evalúa la colaboración: las causas en lugar de los síntomas, con soluciones dirigidas al nivel al que pertenezcan (el resumen, la documentación, el proceso, el material), y los agentes aportan 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, de forma conjunta, cuando llega el informe.

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

Lo más natural en este caso es automatizar aún más: una mejor agrupación en clústeres, correcciones aplicadas automáticamente y un panel de control. Para una amplia categoría de hallazgos, eso es correcto, y los procesos mencionados anteriormente lo hacen bien. Pero 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 a cierta altura: 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 pasa por alto en cada 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 último ciclo y ha desaparecido la fricción? La frase más valiosa de nuestra propia junta fue precisamente esta: señalado ayer, nunca se escribió. 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 flujos de trabajo de Fleet generan legítimamente el subconjunto legible por máquina a la velocidad de la máquina. 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 reasignar 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 interpretar 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 pequeñas fricciones 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 a cargo de los procesos, la documentación, las herramientas y las prioridades), y basada 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 es una nueva reunión que haya que defender en una «guerra de agendas», y una convención «sin culpar a nadie» 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 objetiva de esta afirmación se limita a valorar a los rivales, en lugar de proclamar a un ganador:

• La planificación del sprint es la que tiene mayor autoridad en la sala, pero su orden del día está orientado al futuro y siempre está repleto; la evaluación retrospectiva, al tener que caber en un espacio de planificación, suele quedarse sin tiempo. La planificación es el momento en el que se programan las acciones aprobadas, no donde se analizan los patrones.
• El análisis post mortem «impecable» cuenta con las normas adecuadas, pero con un desencadenante erróneo: 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 permite detectar.
• Asíncrono (un informe más un sistema de seguimiento) es la opción más económica y, para la mayoría de los asuntos rutinarios, resulta suficiente. Lo que no puede hacer es encargarse de la toma de decisiones: la decisión de «mantener o eliminar» es una negociación, las disputas sobre el nivel de prioridad traspasan los límites de las responsabilidades 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 retro, sin registros ni etiquetas) es gratuita, se adapta a la situación actual y, para un equipo pequeño con un uso reducido 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 constantemente.

Así pues, la afirmación, expresada con toda sinceridad: la ceremonia 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 fricciones de una cuenta de publicidad enredada o de una biblioteca de plantillas incoherente se lee exactamente igual que el registro de fricciones 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 se desvanece: los modelos actuales no son fiables precisamente en este tipo de valoraciones: 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 ~el 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 hoy en día; 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 capacidad.

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 preguntas: a la pregunta «¿qué intentó realmente antes de aplicar la solución provisional?» se responde con una respuesta respaldada por la transcripción. Redacta, pero nunca decide: las soluciones propuestas llegan con niveles de prioridad sugeridos; el equipo las modifica, les reasigna 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 investigativa 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 se refiere a la carga de trabajo. Todo lo que el agente introduce en la sala debe estar sin restricciones, ya que un agente que necesite permiso para informar de problemas de fricción tiende a subestimar la información. 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 control, salida de escrituras con control.

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 va dirigida. Se registra junto con el trabajo, sin restricciones.
2. Antes de la reunión retrospectiva, las aportaciones realizadas desde la última vez 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 anteriores y las tres medidas recomendadas principales. 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. Y fue precisamente ahí donde nuestra propia junta directiva nos pilló.

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 del 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); proliferación 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 los puntos de partida 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 esta es la parte falsable. Si los bucles de los proveedores generan un juicio auténtico que trascienda las herramientas y las personas, y no se limiten 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 aplican 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 versión de esto (el punto del orden del día, el resumen asíncrono o una ceremonia que se nos haya pasado por alto), nos gustaría saber qué ha ocurrido: ai-discussion@teamretro.com.

---

Siguiente capítulo: Cómo llevar a cabo la retrospectiva de colaboración en 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.