¿Dónde debería aplicarse la solución?
Si se identifica cada caso de fricción del agente con su causa raíz, se indicará el ámbito (memoria, documentación, proceso o fase previa) en el que debe aplicarse la solución definitiva.
Dos equipos, la misma tensión, un cuarto diferente
Ambos equipos comienzan a registrar las dificultades a las que se enfrentan sus agentes de IA: las consultas ambiguas, la documentación obsoleta, las herramientas poco fiables y las repeticiones de tareas.
El primer equipo soluciona todo en el nivel más cercano. Cada inconveniente recurrente se convierte en un pequeño ajuste o en una nota para el futuro; cualquier asunto de mayor envergadura se convierte en otro párrafo del archivo de contexto. Tres meses después, sus agentes funcionan con instrucciones excesivamente extensas que nadie lee de principio a fin, y los problemas que realmente importaban (la plantilla de instrucciones que deja el alcance sin definir, la cuenta publicitaria cuya estructura complica cada sesión) siguen ahí, porque ningún ajuste rápido puede solucionarlos.
El segundo equipo formula una pregunta adicional por cada patrón: ¿dónde encaja realmente esta solución? El grupo «los agentes siguen adivinando cuál es nuestro público» se convierte en un cambio en la forma de plantear el trabajo: una solución de proceso, acordada en una sesión de equipo. El grupo «manual de procedimientos obsoleto» se convierte en una mejora en la documentación con un responsable. La «excentricidad puntual» se convierte en una nota de recordatorio y nada más. Tres meses después, sus archivos de instrucciones son más breves que cuando comenzaron, y las categorías de fricción que han solucionado muestran una tendencia a la baja.
La diferencia no radica en la disciplina a la hora de registrar los datos. Ambos equipos registraron los datos. La diferencia radica en una cuestión de enrutamiento que el primer equipo nunca se planteó.
La clave: los puntos de fricción a cierta altura
Cuando una sesión asistida por IA encuentra un obstáculo, la causa raíz apunta a un nivel en el que se encuentra la solución duradera. A ello lo denominamos la altitud de la solución; las altitudes disponibles van desde las efímeras hasta las estructurales:
memoria → habilidad/instrucciones → entorno y configuración → documentación → el propio material de trabajo → proceso/flujo de trabajo → producto o proveedor anterior
Identificar el problema convierte una queja en una solución que se puede abordar. «El agente se ha equivocado de nuevo con la estrategia de puja» es una queja. «La decisión sobre la estrategia de puja nunca se dejó por escrito en ningún lugar donde el agente pudiera encontrarla: se trata de una corrección en la documentación, y este es el manual de procedimientos en el que debe figurar» es una tarea con un objetivo concreto.
Calcular mal la «altitud» tiene dos consecuencias negativas. El subobjetivo —una nota privada en la memoria que, en realidad, es un documento del equipo que falta— implica que la fricción se repite para todos los que no sean usted: un «impuesto de recurrencia» para el resto del equipo. Las notas que ya han quedado aisladas de ese modo pueden recuperarse mediante una «cosecha de memoria» en todo el equipo. **Exceso de objetivos (una nueva habilidad para un caso puntual, otro párrafo en un archivo de contexto ya de por sí abultado) supone una carga de mantenimiento para el artefacto; el sector ha denominado con precisión estos antipatrones: proliferación de habilidades (de 16 a 48 habilidades en 15 días: «Añadir habilidades es fácil. … La gestión es lo difícil.») y la sobrecarga del archivo de contexto («un archivo de memoria que ha dejado de leerse», según esta nota de campo). Los proveedores han convergido en el mismo gradiente desde el extremo opuesto: restar importancia a la memoria efímera y promover el aprendizaje duradero mediante el control de versiones: Windsurf/Devin («escríbalo como una regla o añádalo a AGENTS.md… en lugar de confiar en memorias generadas automáticamente», documentación), OpenAI Codex («cuando Codex cometa el mismo error dos veces, pídale una análisis retrospectivo y actualice AGENTS.md», mejores prácticas), y la caducidad deliberada de 28 días de la memoria de Copilot.
Por lo tanto, en el sector se conocen ambos modos de fallo. Lo que ha faltado hasta ahora es un instrumento de enrutamiento.
Un vocabulario fijo que redirige
Nuestra propuesta de trabajo: asignar a cada problema de fricción exactamente una causa raíz, seleccionada de un vocabulario fijo de diez etiquetas distribuidas en cinco grupos: lo suficientemente reducido como para poder recordarlo, centrado en las causas más que en los síntomas, y deliberadamente independiente de herramientas y disciplinas:
- Resumen:
ambiguous-instruction,missing-context,incorrect-context,changed-requirements - Documentación:
missing-documentation,incorrect-documentation - Material de trabajo:
work-material-friction - Herramientas:
missing-access-or-tool,environment-friction - Agente:
agent-error
El grupo constituye la clave de enrutamiento. En el momento en que se etiqueta un hallazgo, ya está enrutado a medias:
| Dominante del grupo | La solución suele encontrarse en | Artefactos típicos |
|---|---|---|
| Sesión informativa | proceso (la forma en que se transmiten las instrucciones de trabajo) o una memoria persistente | plantilla de resumen, lista de comprobación para la reunión inicial, archivo de referencia |
| Documentación | documentos | README, manual de procedimientos/SOP, archivo de contexto, especificaciones |
| Material de trabajo | el propio material | código: la refactorización a la que la fricción sigue apuntando; no código: la reestructuración de la cuenta, el panel o la plantilla |
| Utillaje | environment/config, o en la fuente | ajustes, configuración de MCP, autorización de acceso, ticket de proveedor |
| Agente | indicación, habilidad o barrera de seguridad | edición de habilidades, hook, eval |
Una aclaración inicial: los grupos reciben su nombre en función de sus destinos de fijación, por lo que «la etiqueta determina parcialmente la fijación» es cierto por definición; se trata de una elección de diseño más que de un descubrimiento empírico. La afirmación empírica subyacente es que las etiquetas del momento de la captura son precisas y coherentes, que es precisamente lo que aún no hemos medido (más adelante se ofrece más información al respecto).
La tabla asigna a una corrección su primera dirección, y la recurrencia puede desplazarla. Cuando vuelve a surgir la fricción tras una corrección en la documentación o en el archivo de contexto, es probable que el texto no esté funcionando correctamente. Traslade la corrección a una barrera de seguridad: un gancho o una comprobación de integración continua (CI), que se mantenga independientemente de si alguien la lee o no. Se trata del mismo razonamiento que al elegir un desencadenador de captura: una regla de convención depende de que alguien la recuerde, mientras que un gancho no.
Tenga en cuenta lo que abarcawork-material-friction este concepto, ya que es ahí donde el vocabulario justifica su carácter independiente de la disciplina. En el código, se trata de la «deuda técnica»: ese módulo con el que todas las sesiones tropiezan. Fuera del código, es igual de real. Imagínese un equipo de marketing cuyo agente audita una cuenta de Google Ads que ha crecido de forma acumulativa: tres generaciones de convenciones de nomenclatura, campañas en pausa que nadie se atreve a eliminar, palabras clave duplicadas en grupos de anuncios que se solapan. En cada sesión, el agente dedica sus primeros minutos a reconstruir a qué campaña pertenece cada elemento, y cada recomendación viene acompañada de una advertencia. Ninguna solución rápida resuelve esto; ninguna nota de referencia lo soluciona para la siguiente persona. La etiqueta es work-material-friction, siempre emparejada con el material concreto al que hace referencia (esta cuenta), y la altitud es el material en sí mismo: la reestructuración hacia la que la fricción sigue apuntando. El mismo patrón se repite en hojas de cálculo enredadas, en el desorden de las plantillas de CMS y en las bibliotecas de macros de soporte; un bucle con forma de agente de programación no tiene dónde ubicar todo esto.
¿Por qué «fija» en lugar de «emergente»? Porque, para un equipo, la taxonomía es un instrumento de coordinación, no un ejercicio de clasificación. «La misma fricción a lo largo de ocho sesiones constituye un problema de proceso» solo tiene sentido si en las ocho sesiones se ha etiquetado de la misma manera; las afirmaciones sobre la distribución necesitan un denominador estable; y las líneas de tendencia («¿ha disminuido la fricción en las reuniones informativas desde que fijamos la plantilla del informe?») solo son válidas si una etiqueta significa lo mismo en marzo que en julio. Las categorías emergentes, en las que cada persona codifica las suyas propias, son la opción adecuada a nivel individual, pero en el contexto de un equipo varían según la persona, y nada se agrega sin un paso de conciliación del que nadie se hace responsable. Mantenemos en funcionamiento el motor de categorías emergentes en dos lugares: una nota con referencias empíricas debajo de cada etiqueta y una revisión periódica del vocabulario en la que las notas acumuladas someten a prueba las etiquetas. El vocabulario tiene versiones; está diseñado para cambiar en función de las pruebas, no para ser defendido.
Lo que ya existe, comparado con total sinceridad
No hemos inventado nosotros las taxonomías del fracaso, y las que ya existen cumplen bien su función.
MAST (arXiv 2503.13657) es la taxonomía fija de referencia: 14 modos de fallo en 3 categorías, derivados de 150 trazas examinadas por expertos y validados con un corpus de más de 1 600 casos, con una elevada concordancia entre anotadores (κ = 0,88). Clasifica cómo fallan los sistemas multiagente; está diseñada para la investigación y la evaluación comparativa, y es la más cercana a la nuestra en cuanto a disciplina, aunque difiere en su objeto: nosotros clasificamos por qué se produjo la fricción en la colaboración entre humanos y agentes.
La escuela del análisis de errores, la metodología de evaluación de Husain y Shankar (Preguntas frecuentes sobre evaluaciones, enero de 2026), defiende lo contrario a una lista fija: las categorías «deberían surgir de los patrones de fallo observados… y no de clasificaciones predeterminadas de consultas», y la lectura abierta de sus propios registros es «la actividad más importante en las evaluaciones». Creemos que tienen razón a escala individual y que la situación se invierte a escala de equipo, por las razones de agregación mencionadas anteriormente. Su disciplina de interpretación es fundamental en nuestra propuesta en cualquier caso; eso es precisamente lo que son las notas de evidencia.
En torno a estos ejes: la taxonomía de cuatro capas (Greyling, mayo de 2026) clasifica en qué capa de la pila se produjo el fallo, atribuyendo solo alrededor del 9,9 % de los fallos al razonamiento del modelo: la mayoría de los fallos son problemas del arnés (el arnés es el andamiaje que rodea al modelo), razón por la cual nuestra etiquetaagent-error es residual y se utiliza únicamente cuando las entradas eran adecuadas (la escuela de ingeniería de arneses rechaza explícitamente la tendencia a culpar al agente por defecto, centrándose en corregir el arnés en lugar del agente: Osmani, Agent Harness Engineering). TraceProbe clasifica las acciones de gestión de errores en los rastros. El «Feedback Flywheel» de Garg recopila cuatro tipos de señales en artefactos de equipo, el marco en el que se inscribe el nuestro: su contexto ≈ nuestros grupos de información y documentación; su «brazo de fallos» es lo que descompone nuestra taxonomía. «Factory Signals» clasifica los síntomas de las sesiones en tickets archivados automáticamente; «Braintrust Topics» es el producto resultante de la escuela emergente, que reorganiza diariamente sus trazas en nuevos grupos.
Dos interpretaciones objetivas de esa comparación. En primer lugar, la mayoría de ellas clasifican síntomas, capas o destinos; la nuestra clasifica causas, que es lo que convierte a la etiqueta en una clave de enrutamiento, y esa es la verdadera novedad que se alega, tal y como es. En segundo lugar, y lo más importante: MAST ha medido la fiabilidad del etiquetado y nosotros no. La fiabilidad interevaluador de nuestras diez etiquetas no se ha medido, y consideramos que eso es un requisito previo, no una nota al pie: el experimento (evaluadores independientes que etiquetan a ciegas las mismas entradas reales, con el grado de concordancia que se indique) se está llevando a cabo con entradas de nuestra propia prueba en vivo, tomando como referencia el κ = 0,88 de MAST. Hasta que se publiquen los resultados, esta taxonomía es una propuesta de trabajo con etiquetas versionadas, no un instrumento validado. Preferimos comunicárselo a usted antes de que lo descubra por sí mismo.
Asimismo, apoyamos todos los «loops» que ya están en funcionamiento: Loop Engineering, Compound Engineering, agent-retro, las retrospectivas de AGENTS.md, los sistemas de memoria de los proveedores y los informes de sesión automatizados. Manténganlos todos; nada de lo que aquí se propone los sustituye.
Por qué la altitud es una cuestión que atañe a todo el equipo
Esta es la carencia que comparten los ciclos existentes: casi todos ellos son individuales (un desarrollador y su agente, o un proveedor y su flota). Y las propias cifras del sector indican que el paso más costoso no es la supervisión: alrededor del 90 % de los equipos implementan trazas de agentes, pero solo entre el 37 % y el 52 % las evalúan de forma sistemática (LangChain State of Agent Engineering, junio de 2026). La capa que queda por explotar es la síntesis a nivel de equipo, y es precisamente ahí donde la perspectiva global empieza a cobrar importancia, por dos razones.
La agregación reajusta las prioridades. Lo que para una persona supone una molestia de diez minutos no es más que ruido; nadie se molesta en solucionarlo de forma racional. La misma etiqueta, repetida en ocho sesiones y entre cinco personas, supone uno de los mayores costes del equipo, y solo la visión agregada permite detectarlo. La agregación es también lo que aporta el vocabulario estandarizado: los recuentos solo cuadran si todos utilizan las mismas etiquetas.
Los niveles más altos son competencia del equipo. Una persona puede ajustar su propia memoria, indicaciones y configuración. Sin embargo, los cambios en los procesos, las decisiones discrecionales entre herramientas, el presupuesto para herramientas, las escalaciones a niveles superiores —es decir, los niveles en los que suele concentrarse la mayor fricción recurrente— son decisiones que ninguna persona puede tomar por sí sola. Esta es también la razón por la que creemos que la intervención humana en la síntesis sigue siendo necesaria, por muy buenos que sean los modelos: las soluciones se plasman en artefactos de los que los humanos son responsables y por los que responden: instrucciones, procesos, presupuestos y acuerdos de equipo. Se trata de una afirmación sobre la autoridad organizativa, no sobre la capacidad de los modelos. Y se trata de un puesto en el ciclo, no de una barrera en el proceso: los agentes deben detectar, registrar, agrupar y redactar con libertad; los seres humanos aportan el criterio de enrutamiento y asumen la responsabilidad.
Al revisar las aportaciones de las personas y los repositorios, también surgen lecciones que se contradicen entre sí. Es preferible sustituir en lugar de sobrescribir: la nueva lección se incorpora como una entrada con fecha que hace referencia a la anterior, y esta última sigue siendo legible, de modo que nadie vuelva a deducir silenciosamente la creencia errónea más adelante. Para elegir entre ellas, compruebe primero la procedencia (la evidencia de primera mano prevalece sobre una lección que solo se ha repetido) y, a continuación, la actualidad, consultando las marcas de tiempo reales. Si ninguna de las dos cosas lo resuelve, marque el par como «sin resolver» en lugar de imponer una opción ganadora. Compruebe también el ámbito de aplicación. Uno de nuestros repositorios contenía una lección que decía que nunca se debe crear un enlace simbólico a un «worktree»node_modules; otro indicaba que hay que crear dicho enlace o, de lo contrario, la compilación fallará. Cada una era cierta en su propio repositorio. Una solución compartida posteriormente, una copia con enlace físico, funcionó en ambos, por lo que la lección sobre el enlace simbólico quedó sustituida.
Si su equipo ya lleva a cabo una sesión de mejora continua, esto encaja perfectamente en ella: se presenta el panorama general de la fricción, el equipo se pregunta «¿dónde se aplica cada solución?», y cada patrón sale de allí con una prioridad y un responsable. No se trata de un ritual nuevo, sino simplemente de una retrospectiva con mejores datos de entrada. Los ingenieros de aprendizaje automático lo denominan «análisis de errores»; los equipos llaman a esta sesión «retrospectiva».
¿Qué nos haría cambiar de opinión?
Dado que se trata de un documento de debate, a continuación les exponemos aquellos aspectos sobre los que realmente tenemos dudas:
- Fiabilidad. Si el experimento de interevaluador pone de manifiesto una escasa concordancia, las reglas de delimitación (o las propias etiquetas) son erróneas, por lo que las revisaremos en el marco de la versión correspondiente, en lugar de defenderlas.
- Tamaño. El número de etiquetas, diez, es un valor heredado, no derivado. MAST tiene 14; Four-Layer, 4. Nuestra distribución de etiquetas tras un cuarto de las entradas reales es la prueba que lo confirma o lo modifica.
- Modos ausentes. La fricción entre agentes (pérdida de traspaso entre subagentes, fallos de coordinación) se clasifica actualmente en
environment-friction; los casos reales podrían requerir una categoría propia. - Ámbito de las revisiones que no se refieren al código. Definimos el ámbito de las revisiones en función de dónde se aplicarían las correcciones: el repositorio, en el caso de la mayor parte del trabajo de desarrollo; «cuenta», «espacio de trabajo» o «compromiso», fuera de él. Esos límites ajenos al código son propuestas que deseamos que se pongan a prueba con equipos reales.
- Viabilidad en el momento de la captura. ¿Pueden los equipos con mucha carga de trabajo etiquetar las causas en el momento, o debe realizarse el etiquetado durante la revisión? Los equipos que lo prueben resolverán esta cuestión más rápidamente que nuestras especulaciones.
Si ejecuta cualquier versión de este ciclo (categorías emergentes, un proceso de proveedores, una simple hoja de cálculo), nos gustaría saber en qué punto falla la tabla de enrutamiento. Especialmente si puede mostrarnos un patrón de fricción que no apunte en absoluto a una altitud: ai-discussion@teamretro.com.
Próximo capítulo: El informe existe. La sala no: por qué la asignación de las soluciones es una decisión del equipo y qué hace el equipo cuando llega el informe de fricciones. Parte de la guía de retrospectivas de los agentes de IA.