El mapa: bucles de retroalimentación de los agentes, herramientas y enfoques

TeamRetro se interesa por todos los ciclos de mejora continua que llevan a cabo los equipos; el trabajo asistido por IA es un nuevo ámbito que estamos analizando desde nuestra perspectiva retrospectiva. Esta página es el complemento de referencia de esta guía: todo el tema presentado de forma sistemática. Si prefiere comenzar por la historia, empiece por el inicio de la guía y luego vuelva aquí.

De qué trata esta página

Tres aspectos, por orden: el ciclo de vida que recorre cada problema desde su aparición hasta su resolución; los ciclos denominados que se han establecido en el sector para gestionar dicho ciclo de vida, clasificados según el nivel en el que opera cada uno; y los esquemas de clasificación que se utilizan para identificar qué ha fallado. Léalo de arriba abajo para identificar la situación de su equipo: qué etapas cubren ya sus herramientas, qué ciclo ya está ejecutando con otro nombre y qué vocabulario utilizaría para etiquetar los hallazgos. Todo lo que aquí se expone es independiente: nada de ello requiere que adopte nuestra práctica, nuestras etiquetas o nuestro producto.

El ciclo de vida: siete etapas, desde el conflicto hasta la solución

Cuando un agente que realiza un trabajo real se encuentra con un obstáculo (un documento que falta, una instrucción ambigua, una herramienta poco fiable), esa señal es efímera: el agente la sortea, la sesión finaliza y, en la siguiente sesión, se topa con el mismo obstáculo. Los patrones de fricción de Rahul Garg definen el coste de primer orden (el «bucle de frustración» de generar → revisar → no encaja → volver a generar); el ciclo de vida que se muestra a continuación ilustra el problema de segundo orden: qué debe suceder para que la fricción se resuelva al nivel adecuado. La brecha es cuantificable: alrededor del 90 % de los equipos registran los rastros de los agentes, pero solo entre el 37 % y el 52 % los evalúan de forma sistemática (LangChain, junio de 2026) —la mayoría de los equipos pueden observar la fricción; son muchos menos los que la convierten en soluciones—.

Escenario	La pregunta a la que responde	Opciones	Término profesional
0 · Alojamiento web	¿Dónde se ejecuta el agente?	CLI local · web · IDE · CI/sin interfaz gráfica · programado	—
1 · Detección	¿Cómo se percibe la fricción?	autocomprobación · revisión por parte de un agente secundario · corrección humana · telemetría	revisión de trazas, análisis de errores
2 · Instrumentación	¿Cómo sabe el agente que debe realizar el seguimiento?	habilidad · gancho · convención · control	—
3 · Grabación	¿Cómo se recoge y dónde?	memoria · almacén MCP · registros/rastros · tickets · confirmaciones etiquetadas	codificación abierta, memoria episódica
4 · La cosecha	¿Cómo se lleva a cabo la reunión más allá de una sola sesión?	minería de trazas frente a agregación de artefactos · barrido frente a evento · deduplicación	—
5 · Síntesis y selección de dianas	Registros sin procesar → patrones → ¿qué nivel de corrección?	agrupar + puntuar y, a continuación, ordenar por altitud	codificación axial, taxonomía de fallos
6 · Cerrar el ciclo	¿Ha servido la solución para reducir los problemas futuros?	evaluar la tendencia	Volante de inercia de retroalimentación, ingeniería de efecto multiplicador

Fase 0: Alojamiento

Todo lo que viene a continuación depende de dónde se ejecute el agente. Un agente CLI local deja un registro en el disco y puede escribir archivos en memoria; un agente de CI o sin interfaz gráfica puede ser efímero, y su único rastro será lo que haya registrado antes de que el contenedor dejara de funcionar; un agente web o de IDE conserva un historial del lado del servidor que se puede consultar, pero no analizar con «grep»; un agente programado se ejecuta sin supervisión humana. El entorno de alojamiento determina las opciones disponibles para todas las etapas posteriores: qué se puede observar, dónde puede persistir el estado y quién (o qué) puede revisarlo. La disyuntiva: una observabilidad local más completa frente a la reproducibilidad y el almacenamiento centralizado de las ejecuciones alojadas.

Fase 1: Detección

Cuatro canales, rara vez exclusivos. La autodetección (el agente reconoce sus propios reintentos y retrocesos) es la opción más económica, pero también la más sesgada: el agente no sabe lo que desconoce. La revisión por parte de un agente secundario, en la que un agente independiente lee la transcripción a posteriori, es más objetiva, pero requiere una segunda revisión. La corrección humana es la señal de mayor calidad y sigue siendo la predominante: un estudio de producción de ocho semanas reveló que alrededor del 70 % de los fallos silenciosos fueron detectados en primer lugar por un ser humano que percibió que algo no encajaba (arXiv 2606.14589). La telemetría (tasas de error de las herramientas, denegaciones de permisos, recuentos de bucles) es automática, pero superficial: sabe qué ocurre, no por qué. Las configuraciones más sólidas se basan en la triangulación: la telemetría señala dónde buscar, y una ronda de revisión explica el motivo.

Fase 2: Instrumentación

Un agente no registrará fricción a menos que algo la provoque. Las opciones, según el grado en que dependan de la memoria del modelo, son: una habilidad (un procedimiento explícito y portátil que se invoca en un punto de parada: claro, pero debe activarse realmente), un gancho (que se activa automáticamente al inicio o al final de la sesión: fiable, pero poco preciso), una convención (una instrucción en un archivo de contexto: sin infraestructura, basada en la confianza) o un comando (activado por el usuario: deliberado, pero dependiente de la intervención humana). Esta es la etapa que con mayor frecuencia se omite, y es la razón por la que tanta fricción pasa desapercibida: nadie le indicó al agente que prestara atención.

Fase 3: Grabación

Dos preguntas: qué contiene un buen registro y dónde se almacena. Un registro útil incluye referencias a pruebas (qué ocurrió, cuánto costó), lleva una etiqueta procedente de un vocabulario fijo para que los registros sean comparables posteriormente y concluye con una propuesta de paso siguiente. En cuanto a dónde se almacena, cada opción presenta una disyuntiva real: archivos de memoria (duraderos y de fácil acceso, pero privados y con una estructura poco definida), un almacén MCP (compartido y consultable, pero que requiere un servidor), registros/rastros (automáticos y completos, pero la señal queda sepultada entre el ruido), tickets (pasos a seguir y visibles para el equipo, pero pesados por cada elemento) o commits y PR etiquetados, por ejemplo, unawork-material-frictionetiqueta que vincula la fricción al cambio exacto, aunque solo cuando el trabajo se integra en el control de versiones. Nada de esto es específico del código: el registro de una cuenta de un equipo de medios o el historial anotado de una cola de asistencia técnica también son sustratos de registro. Una advertencia que se aplica a cualquier sustrato en el que los agentes se basen posteriormente: la memoria escrita por los agentes constituye una superficie de ataque y deriva identificada (OWASP Agentic Top 10, ASI06), lo que justifica la necesidad de que las escrituras estén respaldadas por pruebas y revisadas.

Fase 4: Cosecha

La fricción en una sola sesión es ruido; la misma fricción a lo largo de ocho sesiones constituye un problema de proceso. La elección estratégica es entre la minería de trazas (releer las transcripciones sin procesar: completa, pero costosa y con un alto impacto en la privacidad) y la agregación de artefactos (analizar los registros redactados deliberadamente: económica, pero cuya eficacia depende de la disciplina de la Etapa 3); los procesos reales combinan ambas. A continuación, la cadencia (un barrido programado frente a la recopilación al final de la sesión) y la labor poco glamurosa de la deduplicación: la misma fricción expresada de cinco formas diferentes por cinco personas debe reducirse a un único patrón con un recuento fiel. La recolección es donde surge el valor, ya que la agregación es lo que reajusta las prioridades: una molestia de cinco minutos que nadie solucionaría de forma individual supone, en conjunto, un coste prioritario para el equipo.

Etapa 5: Síntesis y selección de dianas

Dos pasos. Agrupar y puntuar: agrupar los resultados en patrones, ordenados por frecuencia × coste; para eso sirven los esquemas de clasificación que se indican a continuación. Fijar el nivel adecuado: dirigir cada patrón al nivel correcto de solución, desde lo efímero hasta lo estructural (memoria → habilidad/indicación → entorno y configuración → documentación → el propio material de trabajo → proceso → herramienta o proveedor de nivel superior). Si se queda corto (una nota privada en la memoria para lo que en realidad es un documento del equipo que falta), la fricción se repite para todos los demás; si se excede (una nueva habilidad para un caso aislado), se sobrecarga un artefacto hasta el punto de que deja de leerse. El sector convergió de forma independiente en el mismo enfoque: restar importancia a la memoria efímera, potenciar el aprendizaje duradero mediante el control de versiones — La documentación de Windsurf/Devin recomienda convertir las lecciones recurrentes en reglas o en AGENTS.md (el archivo de instrucciones permanentes que leen los agentes) en lugar de depender de la memoria automática, la guía Codex de OpenAI afirma que el caso de «cometer el mismo error dos veces» merece una actualización de AGENTS.md, y la memoria de Copilot caduca a los 28 días por diseño: la memoria no ascendida debe desaparecer. Hay una conclusión sintética que es fácil pasar por alto: no toda la fricción es un desperdicio. Parte de ella constituye la superficie de control: «la fricción es lo que se necesita… para dirigir» (un resumen de la ponencia de Ronacher en AIE Europe), por lo que la clasificación incluye decidir si se mantiene o se elimina, no solo si se corrige.

Etapa 6: Cerrar el ciclo

La prueba definitiva de todo el ciclo de vida: ¿tiende a disminuir ese tipo de fricción a lo largo de las sesiones posteriores? Una corrección que se registra pero nunca se implementa, o que se implementa pero no cambia nada, no es más que una farsa. Esta es la condición del Feedback Flywheel de Garg y la premisa de la ingeniería compuesta: cada corrección facilita la siguiente unidad de trabajo, siempre que el ciclo se cierre realmente.

Los bucles con nombre, por nivel operativo

El sector ha adoptado este ciclo de vida con al menos media docena de denominaciones diferentes. Todas ellas son válidas; nada de lo que aparece en esta página sustituye a ninguna de ellas. El único criterio de clasificación que se aplica en esta tabla es el nivel al que opera cada bucle — y lo que hay que tener en cuenta una vez ordenada:

Bucle	Se celebra en	Cierra el ciclo mediante
Ingeniería de bucles / Ingeniería compuesta	un profesional	normas personales, indicaciones, guías de actuación
agent-retro	una sesión	modificaciones de configuración o de habilidades por sesión a partir de la transcripción
Sensores de ingeniería de arneses (Thoughtworks)	el armazón de un código base (la estructura que rodea el modelo)	integrar los instrumentos de retroalimentación nativos (pruebas, linters, integración continua) en el ciclo del agente
Soñar (Anthropic, OpenAI)	la memoria de una plataforma	Minería en tiempo de inactividad del historial de sesiones para obtener diferencias de memoria por intervalos, en toda la flota
Motor LangSmith / Temas de Braintrust	una pila de observabilidad	agrupar los fallos de producción en incidencias, redactar solicitudes de incorporación de cambios (PR) y evaluaciones
Señales de fábrica	una plataforma única para agentes	detección de patrones de problemas en las sesiones y creación automática de tickets
Información sobre la sesión de gh-aw (GitHub)	las sesiones de una plataforma	informes automatizados de análisis de sesiones a lo largo de las ejecuciones del flujo de trabajo de los agentes (ejemplo de 50 sesiones)
Flywheel de retroalimentación (Garg)	los artefactos de un equipo	recopilar las lecciones aprendidas en documentos de configuración, comandos, guías de procedimientos y medidas de seguridad

Vuelva a leer la columna central: un profesional, una sesión, una plataforma, una pila. Casi todos los ciclos en este ámbito se desarrollan de forma individual o a nivel de flota: una persona y su agente, o un proveedor y toda su base de instalaciones. Solo el «flywheel» de Garg abarca al equipo, y su lista de cadencia menciona el ámbito (un punto del orden del día en la retrospectiva de sprint existente) sin ponerlo en práctica. Esa es nuestra interpretación del tema, y es el único punto en el que se pone de manifiesto el enfoque propio de esta guía: el nivel de equipo es la capa abierta —muchas personas, muchos agentes, más de una herramienta, con los responsables de las correcciones en la misma conversación—. Si está ejecutando alguno de los bucles anteriores, continúe haciéndolo; la capa del equipo consume sus resultados, no compite con ellos.

Los sistemas de clasificación

Para agrupar los puntos de fricción se necesitan categorías, y los marcos de referencia de cada ámbito clasifican aspectos distintos; no son tanto rivales como herramientas orientadas a cuestiones diferentes:

Esquema	Qué clasifica	Forma	Fiabilidad / origen
MAST	cómo fallan los sistemas multiagente	14 modos / 3 categorías	150 trazas revisadas por expertos, validadas sobre más de 1 600; coeficiente κ entre anotadores = 0,88
Escuela del análisis de errores (Husain/Shankar)	sea cual sea lo que revelen sus propias huellas	de carácter abierto; las categorías surgen de sus datos	una metodología, no un conjunto fijo; la lectura de sus trazas es «la actividad más importante en las evaluaciones»
Cuatro capas (Greyling)	¿En qué capa de la pila se ha producido el fallo?	4 capas	síntesis de los informes de fallos sobre el terreno; aproximadamente el 9,9 % de los fallos se atribuyen al razonamiento del modelo
TraceProbe	Acciones de gestión de errores en los rastros	9 acciones	análisis automatizado de trazas
Señales de fábrica	qué síntoma de fricción se observa en una sesión	7 tipos de señales	sesiones de codificación de agentes de producción
Nuestro vocabulario sobre las causas fundamentales	por qué se produjo ese conflicto en la colaboración	10 etiquetas / 5 grupos; cada grupo codifica la altitud fija	sesiones de trabajo, tanto de desarrollo como de otras áreas; la fiabilidad entre evaluadores aún no se ha medido: el experimento está en curso y el vocabulario cuenta con versiones y es revisable

agent-errorDos notas de lectura. En primer lugar, los ejes difieren realmente: los esquemas de síntomas (las señales de Factory) le indican que una sesión ha salido mal; los esquemas de capas (Four-Layer) le indican en qué parte de la pila; un vocabulario de causas le explica el motivo, lo que permite que una etiqueta dirija parcialmente su propia solución (unwork-material-frictionhallazgo apunta al material en sí —deuda técnica en el código, o una cuenta, un tablero o una plantilla enredados fuera de él—; una etiqueta de informe apunta al proceso). En segundo lugar, la tensión entre lo universal y lo emergente es real: las taxonomías fijas aportan comparabilidad y fiabilidad medible en el etiquetado (el κ = 0,88 de MAST es el punto de referencia), mientras que las categorías emergentes se ajustan a su distribución real de fallos. Un término medio viable consiste en mantener un pequeño vocabulario fijo para la agregación, con notas de evidencia de código abierto debajo de cada etiqueta. Y una advertencia que todo el campo se ha ganado: las etiquetas de tipo «-style» deben ser el caso residual, no el predeterminado. La escuela de ingeniería de arneses rechaza explícitamente ese reflejo, en el que el ingeniero culpa al modelo y lo archiva bajo la categoría «esperar a la próxima versión»; en su lugar, se debe corregir el arnés (Osmani, Agent Harness Engineering). El análisis de cuatro capas atribuye solo alrededor del 9,9 % de los fallos al razonamiento del modelo.

Localícese

Un breve diagnóstico. Repase las etapas y marque lo que ya tiene:

• Dispone de registros o logs de sesión (herramientas de observabilidad, JSONL en disco, historial del lado del servidor) → La detección y el registro están cubiertos. Las cifras de LangChain indican que la mayoría de los equipos se detienen aquí.
• Algo le recuerda al agente que debe registrar los problemas (una habilidad, un gancho de interrupción, una convención de los archivos de contexto) → La instrumentación está cubierta; si no hay nada que lo haga, esa suele ser la primera solución más económica.
• Actualiza los archivos AGENTS.md y CLAUDE.md cuando algo se repita → está realizando la síntesis a nivel individual, el patrón del «mismo error dos veces» del Codex.
• Su plataforma se encarga de organizar sus recuerdos (consolidación al estilo «Dreaming», memoria «Copilot») → Recopilación y síntesis a nivel de flota, dentro de dicha plataforma.
• Su pila de observabilidad agrupa los fallos y las soluciones preliminares (Engine, Topics, Signals) → síntesis a nivel de pila, para el tráfico que detecta dicha pila.
• Alguien revisa periódicamente las sesiones, las personas y las herramientas, y los responsables de las soluciones toman una decisión conjunta → Recopilación y síntesis a nivel de equipo. Esta es la fila que la mayoría de los equipos dejan en blanco.

Según nuestra observación, la laguna más habitual es esa última fila: la visión global que abarca todas las herramientas y personas, y las decisiones que de ella se derivan: mantener o descartar, a qué nivel, y qué prioridad tiene. Tenga en cuenta la cuestión del alcance de la revisión que esto conlleva: ¿qué trabajo debe incluirse en un grupo concreto para un debate? ¿El repositorio, el producto, la cuenta publicitaria, la bandeja de entrada de asistencia técnica o la interacción con el cliente? Defina el alcance en función de dónde se aplicarían las correcciones, y asegúrese de que los casos no relacionados con el código se tramiten con la misma naturalidad que los relacionados con el código.

El resto de esta guía aborda cada uno de los niveles por separado: el capítulo introductorio presenta la historia de forma narrativa; los capítulos posteriores tratan sobre cómo captar la fricción en el momento, la recopilación de información a lo largo de las sesiones, la decisión de altitud y cómo es en la práctica un espacio a nivel de equipo. Empiece por donde tenga la fila en blanco.

Próximo capítulo: Cómo debe ser un buen registro de fricciones — la captura en el momento, las etiquetas de causas fundamentales y las reglas de «nunca registrar».