¿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 nivel (memoria, documentación, proceso o fase previa) en el que debe aplicarse la solución definitiva.
Dos equipos, la misma tensión, un barrio 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 un párrafo más 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 dificulta 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 asignado. La «anomalía 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 los registraron. La diferencia radica en una cuestión de ruta que el primer equipo nunca se planteó.
La clave: los puntos de fricción a gran 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 al que pertenece» 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, sustituye a un documento del equipo que falta— implica que la fricción se repite para todos los que no son usted: un «impuesto de recurrencia» para el resto del equipo. La sobredefinición 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 la parte 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», buenas prácticas), 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 dirige
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 el código original | 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, no 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).
work-material-frictionTenga en cuenta lo quework-material-frictionabarca 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. Imagine 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 su primer rato a reconstruir qué campaña es dueña de qué, 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 «deuda técnica», siempre asociada al 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 da 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 briefing?») 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 decisión acertada 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 cuenta con 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 1600 casos, con una elevada concordancia entre los anotadores (κ = 0,88). Clasifica cómo fallan los sistemas multiagente; ha sido diseñada para la investigación y la evaluación comparativa —es la más cercana a la nuestra en cuanto a disciplina, aunque difiere en su objeto de estudio: 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 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 nuestraagent-erroretiqueta 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: hay que arreglar el arnés, no al agente: Osmani, Agent Harness Engineering). TraceProbe clasifica las acciones de gestión de errores en los rastros. Garg’s Feedback Flywheel recopila cuatro tipos de señales en artefactos de equipo, el marco en el que se inscribe el nuestro: su contexto ≈ nuestros grupos de briefing y documentación; su «rama 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 la materialización de la escuela emergente, que reagrupa sus trazas a diario.
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 —eso 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 lo hemos hecho. 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 su cuenta.
También apoyamos todos los procesos que ya están en marcha: 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 menciona los sustituye.
Por qué la altitud es una cuestión que compete a todo el equipo
Esta es la carencia que comparten esos 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 registran los rastros de los agentes, pero solo entre el 37 % y el 52 % los evalúan de forma sistemática (LangChain State of Agent Engineering, junio de 2026). La capa que queda sin cubrir 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 es 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 fijo: 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 y las escalaciones a niveles superiores —esos 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 seguirá 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 deben responder: 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 elaborar borradores con total libertad; los seres humanos aportan el criterio de enrutamiento y asumen la responsabilidad.
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 se asigna a un nivel de prioridad y a un responsable. No se trata de un ritual nuevo, sino de una retrospectiva con mejores aportaciones. 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 exponemos aquellos aspectos sobre los que realmente tenemos dudas:
- Fiabilidad. Si el experimento de interevaluadores 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 utiliza 14; Four-Layer, 4. Nuestra distribución de etiquetas tras un cuarto de las entradas reales constituye 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 del lugar donde se aplicarían las correcciones: el repositorio para 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 utiliza cualquier versión de este ciclo (categorías emergentes, un proceso de proveedores o 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 correcciones 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 agentes de IA.