Retrospectivas de sesión: de las ejecuciones de agentes a las mejoras de la plataforma

Cada sesión de un agente genera señales sobre lo que le falta a tu plataforma de workspace: el alcance de una skill era demasiado amplio, un archivo de conocimiento estaba desactualizado, una especificación era ambigua o faltaba un hook de git. Hoy, la mayoría de esas señales se pierden en el chat.

Este artículo trata sobre un pipeline ligero que permite conservarlas: plantilla de retrospectiva → señal por sesión → triage semanal → ítem del backlog de plataforma → solución → comprobación de recurrencia. Esta disciplina toma parte de las retrospectivas ágiles y añade elementos nuevos: los fallos de los agentes dejan rastros que se pueden inspeccionar y que las retrospectivas humanas no ofrecen, pero también exigen honestidad sobre lo que realmente se puede medir.

Esta es la Parte 5 de la serie Agentic Workspaces. El artículo principal presentó una nota de session-retrospective de cuatro líneas como paso 7 del ciclo diario. Este artículo retoma el proceso después de escribir la nota: cómo convertirla en una mejora duradera de la plataforma.

Una nota sobre el tono: este es el artículo más editorial de la serie. La taxonomía de fallos es un vocabulario práctico, no una clasificación de investigación validada. No hay un estudio controlado de antes y después que demuestre que las retrospectivas del workspace reducen el costo de coordinación: hay mecanismos plausibles y herramientas incipientes que hacen posible medirlo. Ejecuta el ciclo y mide tus propias tasas de recurrencia. A lo largo del artículo, las afirmaciones se identifican como respaldadas por fuentes o inferencias.

Audiencia: ingenieros y arquitectos que ejecutan el ciclo, con una perspectiva de gobernanza y cadencia para PMs y scrum masters responsables del backlog de plataforma.

TL;DR

• Trata cada ejecución de un agente como un punto de datos. Una retrospectiva extrae la señal (qué falló, documentación desactualizada, una skill faltante o un ciclo inestable) y la canaliza al backlog de plataforma.
• Usa una plantilla estructurada (no texto libre) para poder agrupar patrones, y etiqueta cada fallo con una clase de una taxonomía pequeña.
• El pipeline solo se cierra si incluye una comprobación de recurrencia; de lo contrario, es un buzón de sugerencias.
• Canaliza las soluciones a través de artefactos de plataforma (skills, conocimiento, hooks), no de la memoria del agente: el aprendizaje de comportamiento entre sesiones no está resuelto arquitectónicamente a July 2026.
• Las métricas son difíciles. Empieza con la tasa de clases de fallos recurrentes (un simple conteo), añade las rondas de revisión y la tasa de retrabajo a partir de git/GitHub, y considera el resto como candidatas para instrumentar.
• Evita las retrospectivas de fachada: las condiciones previas son notas estructuradas + al menos una solución implementada + una comprobación de recurrencia.

Qué aprenderás aquí

• Por qué las ejecuciones de agentes difieren del trabajo humano en un sprint y qué se puede trasladar de las retrospectivas ágiles
• Una plantilla detallada de retrospectiva con una explicación campo por campo
• Una taxonomía de fallos de siete clases específica para plataformas de workspace
• El pipeline de la señal a la mejora, presentado como diagrama y cadencia
• Una tabla honesta de métricas que separa lo medible de lo aspiracional
• Qué pueden y qué no pueden hacer las herramientas de automatización de retrospectivas
• Modelos de gobernanza y cómo evitar las retrospectivas de fachada

Por qué las ejecuciones de agentes son diferentes

El trabajo humano en un sprint se revisa mediante resultados y conversaciones. Las ejecuciones de agentes añaden dos características:

1. El resultado binario de éxito o fallo oculta la señal. Dos sesiones pueden «tener éxito», aunque una haya requerido tres rondas de revisión e improvisado para compensar una skill faltante. La señal está en la forma y persistencia de la traza, no en el resultado.
2. Los fallos son arquitectónicos, no individuales. Cuando un agente tropieza con el orden de push de submódulos o con un runbook desactualizado, el problema se repetirá para cada agente hasta que cambie la plataforma. Darle indicaciones al agente no ayuda; corregir el hook sí.

De la metodología ágil se pueden trasladar el ciclo Kaizen/PDCA de inspección y mejora, y la disciplina de convertir hallazgos en ítems del backlog. Lo que no se traslada tan fácilmente son los sprints de duración fija y las demos como puntos de control. Aquí la unidad es una sesión, no un incremento de dos semanas.

La plantilla de retrospectiva

La nota de cuatro líneas del artículo principal es el punto de partida. Esta es la versión más completa para cada sesión, inspirada en herramientas de retrospectiva de la comunidad (formatos Start/Stop/Continue, analizadores de fricción y causa raíz, y esquemas de retrospective_signal):

# session-retrospective/2026-07-08.md

## Session metadata
- Date: 2026-07-08
- Branch: feat/cdp-uuid-mapping
- Goal: Cross-repo UUID mapping (apps/api + apps/web)
- Outcome: Partial — API PR green, web PR blocked on review loop

## What worked
- get-knowledge surfaced ADR-002 (UUID format) before planning
- /opsx:propose scoped both submodule tasks correctly

## What failed
- pr-triage-fix-loop pushed the parent before the submodule PR merged
- Review ran 3 rounds; rounds 2 and 3 were the same lint issue

## Failure class (see taxonomy)
- git-ordering-error   (blocking)
- review-loop-churn    (high)

## Root cause inference (editorial)
- No pre-push hook enforces push.recurseSubmodules=check
- Lint runs only in CI, not locally before commit

## Platform backlog candidate
- [ ] Pre-push hook: push.recurseSubmodules=check → workspace-sync-submodules
- [ ] Add `npm run lint` to pr-triage-fix-loop before push

## Recurrence check
- Same git-ordering-error appeared 2026-06-24; not fixed → escalate this sprint

## Notes for next session
- Pin apps/api SHA before web work to avoid a pointer race

Campo por campo:

El campo de inferencia de causa raíz es el que exige honestidad: quien lo escribe está haciendo una suposición a partir de la evidencia. La señal está en la traza; la causa requiere criterio. Identifícala como inferencia para que nunca se confunda con un hecho medido.

Una taxonomía de fallos para ejecuciones de agentes en workspaces

Esta taxonomía es específica de plataformas de workspace: el fallo es una ausencia en la plataforma (skills, conocimiento, especificaciones, automatización), no un fallo de razonamiento del LLM. Es un vocabulario práctico derivado de herramientas de retrospectiva de la comunidad, no una taxonomía de investigación validada. Para una taxonomía validada de sistemas multiagente, consulta la investigación MAST que se presenta más adelante; esta tabla es intencionalmente más detallada en infraestructura y menos en razonamiento del modelo.

Estas clases corresponden a las mismas causas raíz que la tabla de problemas de la Parte 2 y los modos de fallo de flotas de la Parte 3. La diferencia está en el enfoque: esos artículos te explican cómo solucionar el fallo; aquí lo clasificas para que la solución llegue al backlog de plataforma, en lugar de repetirse manualmente.

Usa esto como vocabulario inicial y amplíalo para tu contexto. La clave es etiquetar de forma consistente para poder agrupar los patrones.

De la señal a la mejora: el pipeline

Agent session completes
        │
        ▼
 session-retrospective note (template)
        │
        ▼
   Is this failure new?
     ┌─────┴─────┐
     │ yes       │ no (seen before)
     ▼           ▼
  File in     Escalate priority
  backlog     on existing item
  (draft)          │
     └─────┬───────┘
           ▼
  Weekly triage (engineer + PM) → route to fix target:
     ├── skill update / new skill
     ├── knowledge patch or ADR
     ├── automation (hook, CI step)
     └── spec template improvement
           │
           ▼
   Fix merged → workspace updated
           │
           ▼
   Recurrence check over next N sessions
     └── class reappears? yes → deeper dig / no → resolved

El ritmo:

Daily   : per-session note (2–5 min), filed in the retro log
Weekly  : triage (15–20 min, engineer + PM) → ≥1 platform fix before next triage
Sprint  : review backlog health — are recurring failures decreasing? are fixes closing?

No todas las notas se convierten en un ticket. La decisión durante el triage es: ¿caso aislado o patrón? Los casos aislados se registran; los patrones reciben un ítem en el backlog con una persona responsable.

La razón para canalizar las soluciones a través de artefactos de plataforma, en lugar de la memoria del agente, es estructural. Un issue de Claude Code (#51735, abierto a July 2026) documenta que los agentes repiten errores idénticos entre sesiones: las correcciones hechas en la sesión N no cambian el comportamiento en la sesión N+1, incluso cuando están documentadas en un archivo que el agente lee. Por eso, la solución duradera es un hook, una skill o una modificación del conocimiento —algo que la plataforma haga cumplir—, no una nota que le pida al agente que lo recuerde.

Métricas: cómo saber si el workspace está mejorando

Esta es la sección en la que hay que ser honestos. La tabla separa lo que tiene una vía clara de medición de lo que es plausible, pero difícil de medir.

Salvedad general: una evaluación rigurosa requiere herramientas específicas o infraestructura para experimentos controlados (consulta De la intuición a las métricas). La mayoría de los equipos no contará con eso desde el primer día. Vía práctica: empieza con la tasa de clases de fallos recurrentes a partir de las notas, añade las rondas de revisión y la tasa de retrabajo a partir de git/GitHub, e instrumenta el resto más adelante. No afirmes que hay una mejora hasta que al menos dos soluciones de plataforma hayan reducido de forma medible una clase que antes era recurrente.

Automatización parcial: retrospectivas a partir de logs

Un pequeño ecosistema de herramientas analiza transcripciones de sesiones de agentes (JSONL de Claude Code / Codex CLI) para calificar las sesiones, detectar antipatrones y sugerir cambios de configuración. Algunas exponen su análisis como herramientas MCP para que un agente pueda autoanalizarse al inicio de la sesión; otras leen el historial de git y las métricas de calidad del código para producir informes estructurados con sugerencias de actualización de CLAUDE.md. Un hallazgo reportado por al menos una de estas herramientas (agentsesh): las calificaciones del proceso pueden estar correlacionadas negativamente con la entrega; las sesiones con alta «calidad de proceso» a veces entregan menos. Ese es el argumento para medir resultados (commits, pruebas, eventos de bloqueo, retrabajo), no ceremonias.

Lo que estas herramientas no pueden hacer:

• Resolver el aprendizaje de comportamiento entre sesiones: la brecha estructural descrita antes. Por eso el pipeline canaliza las señales hacia artefactos de plataforma.
• Reemplazar el criterio humano sobre en qué fallos vale la pena invertir.
• Cubrir todos los harnesses: la mayoría son específicos de Claude Code / Codex a July 2026.

Recomendación práctica: empieza con notas manuales. Añade un analizador automatizado una vez que exista el hábito de escribirlas y conozcas tus clases de fallos. Las herramientas de retrospectiva expuestas mediante MCP son las más fáciles de integrar: el agente reflexiona al inicio de la sesión en lugar de requerir un paso humano por separado.

Gobernanza: quién es responsable del backlog de plataforma

Los frameworks ágiles a escala ya resolvieron el problema de «quién se encarga de la mejora sistémica». En Scrum@Scale, un equipo dedicado es responsable del backlog de mejora sistémica y tiene autoridad para programarlo. En SAFe, las historias de mejora entran en el backlog del equipo y compiten por capacidad junto con las funcionalidades, lo que permite que realmente se lleven a cabo. El principio aplicable: trata las mejoras de plataforma como ítems de primera clase del backlog, con responsables y fechas de entrega, no como notas aspiracionales.

Aplicado a un workspace (adaptación editorial):

Para PMs y scrum masters: ustedes son responsables de la cadencia y la priorización, no de escribir las notas. Faciliten el triage semanal, decidan qué ítems de plataforma reciben capacidad del sprint frente al trabajo en funcionalidades y sigan una cifra a lo largo del tiempo: la tasa de clases de fallos recurrentes. Si no muestra una tendencia descendente, el ciclo es una puesta en escena.

Cómo evitar las retrospectivas de fachada. Los rituales sin condiciones previas se convierten en una puesta en escena. Estas son las condiciones:

1. La nota de retrospectiva está estructurada, de modo que se pueden agrupar los patrones.
2. Al menos una solución de plataforma se ha implementado a partir de una nota; de lo contrario, es un buzón de sugerencias.
3. La comprobación de recurrencia forma parte de la plantilla; sin ella, el ciclo nunca se cierra.

El antipatrón: una reunión semanal sin backlog, sin responsable y sin comprobación de recurrencia, donde se comentan las fricciones de cada sesión y luego se olvidan.

Lista para empezar

1. Adopta la plantilla estructurada de retrospectiva; guarda las notas en un directorio dedicado retro-log/ en la raíz del workspace (mantenlas fuera de .knowledge/, que es para ADRs y runbooks duraderos: las notas de sesión tienen una vida corta, según la estructura de la Parte 1).
2. Empieza a etiquetar los fallos con la taxonomía de siete clases (amplíala según sea necesario).
3. Añade un triage semanal de 15–20 min con una persona responsable designada.
4. Comprométete a implementar una solución de plataforma antes del siguiente triage.
5. Añade una comprobación de recurrencia a cada nota; escala las repeticiones.
6. Una vez consolidado el hábito, añade un analizador automatizado de transcripciones y empieza a contar la tasa de clases de fallos recurrentes.

Conclusión

La ejecución de un agente no es solo un diff: es una forma de explorar qué le falta a tu plataforma. Captura esa señal en una nota estructurada, etiquétala, revísala en el triage semanal y canaliza la solución hacia una skill, un hook o una modificación del conocimiento que la plataforma haga cumplir. Mantén las métricas honestas: primero cuenta los fallos recurrentes, demuestra que las soluciones los reducen y resiste la puesta en escena de retrospectivas que nunca entregan nada. De esta manera, el workspace mejora de forma medible cada semana y esa mejora se acumula en todas las sesiones futuras de agentes.

Con esto se cierra el arco actual de la serie Agentic Workspaces: sincronizar, fundamentar, especificar, implementar, revisar, hacer triage, aprender y ahora mejorar la plataforma que ejecuta todo el proceso.

Fuentes

Consultadas el July 8, 2026. Este tema se basa en la experiencia; las fuentes combinan materiales primarios y secundarios y están identificadas.

• MAST: «¿Por qué fallan los sistemas multiagente basados en LLM?» — arXiv:2503.13657 (taxonomía de fallos validada; 2025)
• Conjunto de datos de telemetría de producción de la comunidad que aplica MAST (informal, sin revisión por pares) — github.com/hugomn/mast-taxonomy-production-telemetry
• «Entender el comportamiento de los agentes de código» — arXiv:2511.00197 (2025)
• Rituales Agentic-Agile (condiciones previas, cuándo resultan contraproducentes) — agentpatterns.ai (2026)
• Calificación de sesiones de agentsesh (resultados por encima del proceso) — pypi.org/project/agentsesh
• Skills de retrospectiva: giannimassi/agent-retro, pmgledhill102/claude-retros
• Brecha de aprendizaje entre sesiones — issue #51735 de Claude Code (July 2026)
• Tasa de retrabajo de DORA (5.ª métrica) — Guía de DORA de Swarmia
• Guía Scrum@Scale v2.1 (backlog de mejora sistémica) — scrumatscale.com
• Mejora continua de SAFe — agility-at-scale.com

Inferencia editorial (explícitamente no validada): la taxonomía de siete clases de fallos del workspace; la adaptación de modelos de gobernanza ágil a las cadencias de retrospectiva del workspace; la afirmación de que las señales se canalizan mejor a través de artefactos de plataforma que de la memoria del agente (respaldada por la brecha de aprendizaje entre sesiones, pero el mecanismo de reducción es una inferencia); la actualidad del conocimiento como métrica indirecta. Trata todo esto como patrones que debes validar en tu propio equipo.

Artículos relacionados de esta serie:

• Parte 1: Agentic Workspaces: submódulos, skills, conocimiento y entrega guiada por especificaciones
• Parte 2: Los submódulos como contrato de dependencias — donde encontrarás soluciones para git-ordering-error
• Parte 3: Ejecutar Agentic Workspaces en la nube a escala — soluciones para fallos a escala de flota
• Parte 4: Trazar, hacer triage y depurar: herramientas MCP para Agentic Workspaces
• Relacionado: Audita tu flujo de trabajo diario con agentes de IA
• Relacionado: Cómo crear un registro de skills para tu empresa