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 vuelva después.

De qué trata esta página

Tres aspectos, por orden: el ciclo de vida que recorre un único problema desde su aparición hasta su resolución; los ciclos denominados que se han establecido en el sector para gestionar ese ciclo de vida, ordenados según el nivel en el que opera cada uno; y los esquemas de clasificación que se utilizan para nombrar lo que 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 adoptar nuestra práctica, nuestras etiquetas ni 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 convierta en una solución al nivel adecuado. La brecha es cuantificable: aproximadamente el 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	n/a
1 · Detección	¿Cómo se percibe la fricción?	autocorrecció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 · orden	n/a
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	n/a
5 · Síntesis y selección de dianas	Datos brutos → 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 roces en el futuro?	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 CI o sin interfaz gráfica puede ser efímero, y su único rastro es lo que haya registrado antes de que el contenedor dejara de funcionar; un agente web o 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 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 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 en qué medida dependan de que el modelo lo recuerde: una habilidad (un procedimiento explícito y portátil que se invoca en un punto de parada: claro, pero debe activarse realmente), un gancho (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 una persona: 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 queda sin registrar: nadie le indicó al agente que prestara atención.

Fase 3: Grabación

Dos preguntas: qué contiene un buen registro y dónde se encuentra. 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 a seguir. En cuanto a dónde se almacena, cada opción presenta una disyuntiva real: archivos de memoria (duraderos y de bajo esfuerzo, pero privados y con una estructura poco definida), un almacén MCP (compartido y consultable, pero requiere un servidor), registros o 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, p. ej., una etiquetawork-material-friction 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 desviación 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 el análisis de trazas (revisar de nuevo las transcripciones sin procesar: completo, pero costoso y con un alto impacto en la privacidad) y la agregación de artefactos (revisar los registros redactados deliberadamente: económico, pero tan eficaz como la disciplina de la Etapa 3); los procesos reales combinan ambos. A continuación, la cadencia (un barrido programado frente a la recopilación al final de cada 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 recopilació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. Agrupación y puntuación: agrupe 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 puntual), se sobrecarga un artefacto hasta el punto de que deja de leerse. El sector convergió de forma independiente en el mismo gradiente: restar importancia a la memoria efímera, potenciar el aprendizaje duradero mediante el control de versiones. Los documentos de Windsurf/Devin recomiendan convertir las lecciones recurrentes en reglas o en AGENTS.md (el archivo de instrucciones permanentes que leen los agentes) en lugar de confiar en la memoria automática; la guía Codex de OpenAI afirma que cometer el mismo error dos veces justifica una actualización de AGENTS.md, y la memoria de Copilot caduca a los 28 días por diseño: la memoria no promovida 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 selecció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 en el 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 y 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 instrumentos de retroalimentación nativos (pruebas, linters, CI) 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)
Volante de retroalimentación (Garg)	los artefactos de un equipo	recopilar las lecciones aprendidas en documentos de configuración inicial, 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 se dirige 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 en más de 1 600; κ 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	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 produjo 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 registros de seguimiento	9 acciones	análisis automatizado de trazas
Señales de fábrica	qué síntoma de fricción presenta 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; el 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

Dos 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 porqué, lo cual es lo que permite que una etiqueta dirija parcialmente su propia solución (un hallazgowork-material-friction apunta al material en sí mismo: deuda técnica en el código, o una cuenta, un tablero o una plantilla enredados fuera de él; una etiqueta de sesión informativa 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 listón 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 agent-error«-style» deben ser lo residual, no lo 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 un ~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 historiales 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 nada de ello ocurre, esa suele ser la primera solución más económica.
• Actualiza los archivos AGENTS.md y CLAUDE.md cuando se repita algo → está realizando la síntesis a nivel individual, el patrón del «mismo error dos veces» del Códice.
• 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 propuestas de solución (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 ello 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, la interacción con el cliente? Defina el alcance en función de dónde se aplicarían las correcciones, de modo que los casos ajenos al código se canalicen 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 una fila en blanco.

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