Cómo es un buen historial de fricción

¿Por qué registros y no recuerdos?

La fricción en una sola sesión es ruido. Esa misma fricción a lo largo de ocho sesiones constituye un patrón que su equipo puede corregir, pero solo si esas ocho sesiones han dejado registros que realmente puedan analizar juntos: coherentes (con el mismo esquema, para que sean comparables) y veraces (observaciones respaldadas por pruebas, no meras impresiones).

Ninguna de las dos cosas ocurre de forma predeterminada. El momento en que se produce la fricción es el momento en el que se dispone de la máxima información al respecto: la línea concreta obsoleta del manual de procedimientos, el parámetro exacto que el informe dejó sin especificar. Esa información se desvanece rápidamente. El agente normaliza su propia solución alternativa en unas pocas iteraciones y, al final de la sesión, la señal ha desaparecido a menos que alguien la haya anotado; cualquier cosa que un subagente descubra «se desvanece en el momento en que la devuelve» (Hindsight, mayo de 2026). Este capítulo trata sobre el hecho de anotar.

Cómo se percibe la fricción

Antes de que se pueda grabar algo, hay que percibirlo. Son cuatro canales, y cada uno capta cosas diferentes:

El agente se da cuenta de que está teniendo dificultades. Bucles de reintento, retroceso, relectura del mismo archivo o nueva consulta de la misma vista analítica, una suposición impuesta por una laguna en el informe. Las plataformas de producción han convergido esencialmente en esta lista de señales de comportamiento (Factory Signals, enero de 2026). El canal más económico, con dos límites evidentes: no detecta lo que no está presente (se percibe un bucle de reintentos; un documento que nunca ha existido no genera ninguna señal) y la autoobservación supera al autodiagnóstico: los modelos localizan mal sus propios errores de agencia incluso en trazas seleccionadas (~11 %, TRAIL). Por lo tanto, la tarea durante la sesión consiste en observar los síntomas y citar pruebas, sin aferrarse rígidamente al diagnóstico.

Un segundo agente revisa la transcripción. Un revisor independiente detecta lo que el agente que realizó el trabajo había normalizado. Es más objetivo; supone una segunda revisión y conlleva sus propios errores de interpretación.

Una persona corrige al agente. Sigue siendo el sensor predominante: un estudio de producción de ocho semanas reveló que aproximadamente el 70 % de los fallos silenciosos de los agentes fueron detectados en primer lugar por una persona que notó que algo no iba bien, y no mediante pruebas unitarias, comprobaciones de estado o auditorías de gobernanza (arXiv 2606.14589). Cada corrección —ya sea un «no, lo que quería decir era…» de un revisor o una parte interesada que vuelve a explicar el resumen durante la auditoría— señala exactamente en qué punto el contexto se desvió de la intención, y el agente puede captarlo en el momento sin ningún coste adicional para el proceso.

Telemetría. Índices de error de las herramientas, denegaciones de permisos, recuentos de bucles, duraciones prolongadas. Automática e imparcial, pero superficial: sabe que ha ocurrido algo, pero no por qué.

Las configuraciones más eficaces se basan en un enfoque triangular: la telemetría indica dónde hay que buscar, una revisión explica por qué y la corrección humana resuelve aquellos problemas que ninguna señal automática puede detectar. Sea cual sea la combinación que utilice, lo que debe quedar en pie debe ser siempre lo mismo: un récord.

¿Qué es lo que lleva al agente a registrarlo?

Un agente no registrará una fricción que nadie le haya indicado que busque. La mayor parte de la fricción no queda registrada, no porque no se haya detectado, sino porque no se ha producido ningún evento que haya activado su captura. Existen cuatro mecanismos, que se diferencian principalmente en lo que garantiza su activación:

• Una habilidad: un procedimiento escrito y versionado que el agente ejecuta al finalizar la sesión. Incluye el esquema y las reglas de honestidad, por lo que su activación es coherente: el mismo procedimiento funciona tanto en una refactorización como en una revisión de una cuenta publicitaria. Punto débil: su invocación es probabilística; puede que nunca se active sin que se detecte.
• Un «hook»: el propio arnés activa o recuerda (una inyección al inicio de la sesión, un disparador al final de la sesión). Es determinista (la única opción que no depende de que nadie recuerde nada), pero poco preciso (también se activa en las sesiones de dos minutos) y está limitado a una plataforma concreta.
• Una línea de convención: una instrucción permanente en el archivo de contexto del ámbito, o en su equivalente no relacionado con el código, un paso del procedimiento operativo estándar (SOP) del equipo: «Finalice cada sesión significativa asistida por IA registrando los problemas surgidos». No requiere infraestructura alguna, pero se basa por completo en que el modelo respete una línea entre muchas, y su eficacia decae a medida que el archivo crece; el modo de fallo identificado es el archivo de memoria que ha «dejado de leerse» (nota de campo sobre antipatrones).
• Un comando: una orden introducida manualmente/retroal final de una rama de funcionalidades o de un turno de clasificación. Es deliberada y se ejecuta en el momento preciso; el eslabón débil es la memoria humana.

Estos elementos se combinan; organícelos por capas. Un desencadenante determinista (un «hook» o un paso del procedimiento operativo estándar [SOP] al final del turno), una carga útil procedimental (la habilidad) y una línea de convención que defina la práctica como una norma: elija al menos un desencadenante; dos es mejor. Incluso los proveedores han llegado a la misma conclusión: las directrices de Codex de OpenAI indican: «cuando Codex cometa el mismo error dos veces, pídale una análisis retrospectivo y actualice el archivo AGENTS.md» (buenas prácticas).

Los elementos que caracterizan una buena introducción

Un registro es el contrato entre la sesión que detectó la fricción y todo lo que viene a continuación: la calidad de la síntesis viene determinada por la calidad del registro. Cuatro elementos fundamentales:

1. Un momento respaldado por pruebas, con su coste correspondiente. Qué ocurrió, cuándo y la consecuencia observable, con suficiente detalle como para que alguien que no hubiera estado presente en la sesión pudiera actuar en consecuencia. Por «coste» se entiende trabajo repetido, tiempo perdido o resultados erróneos; un registro sin coste no puede clasificarse posteriormente. El coste estimado por el agente es aproximado: indíquelo tal cual(est.), en lugar de fingir precisión.

2. Exactamente una etiqueta de causa raíz de un vocabulario fijo de diez etiquetas. Los vocabularios fijos permiten una etiquetación fiable (MAST alcanzó un κ = 0,88 en 14 modos de fallo; véase arXiv 2503.13657); las categorías de formato libre varían según la persona y dejan de poder agregarse. Las diez:

• ambiguous-instruction: la pregunta dejaba sin precisar un parámetro clave (público, alcance, definición, periodo de tiempo) y obligaba a hacer una suposición
• missing-context: un hecho conocido por el equipo, pero que no se ha comunicado
• incorrect-context: la información facilitada era errónea
• missing-documentation: falta algún documento que debería existir (no hay README, especificaciones, manual de procedimientos ni procedimiento operativo estándar)
• incorrect-documentation: existe un documento, pero está desactualizado o contiene errores, y se ha tomado como referencia
• work-material-friction: el material con el que se estaba trabajando ralentizaba el proceso o propiciaba la aparición de errores: deuda técnica o una estructura confusa en el código; una cuenta, un cuadro de mando, una hoja de cálculo o una plantilla desordenados fuera de ese contexto (indique siempre el material concreto)
• missing-access-or-tool: no se disponía de un conector, un permiso o una herramienta necesarios
• agent-error: un error del propio agente (una suposición errónea, información desactualizada, un error que él mismo haya provocado)
• changed-requirements: los requisitos cambiaron a mitad de la sesión y hubo que volver a realizar el trabajo
• environment-friction: fallos en las herramientas, tiempos de espera agotados, problemas con el entorno de pruebas o con la plataforma

Una etiqueta por hallazgo garantiza la veracidad de las distribuciones: elija la que mejor se ajuste, tenga en cuenta las contradicciones en las pruebas y nunca invente una etiqueta a mitad de la entrada. Tres reglas límite realizan la mayor parte del trabajo de desambiguación. La prueba de conocibilidad por el agente: ¿era posible encontrar el hecho en cualquier lugar en el que el agente pudiera buscar razonablemente? Si no se encontró en ningún lugar donde debiera estar → missing-documentation; si se facilitó solo más tarde, por una persona → missing-context. El error del agente es el residuo: utilícelo únicamente cuando los datos de entrada fueran adecuados y el agente aún así cometiera un error; si el error se debe a un dato de entrada erróneo, etiquete dicho dato. Y ambigüedad frente a cambio: si la aclaración reveló lo que siempre se quiso decir, se trata de ambiguous-instruction; si el objetivo cambió realmente, se trata de changed-requirements.

3. Una solución del tamaño de un ticket, en la que se especifique su «altitud». La «altitud» es el nivel al que se dirige la solución: memoria, competencia, entorno, documentación, el propio material, proceso o fase previa. Un registro de fricción sin una solución asociada es una queja.

A continuación se incluye una entrada completa de una sesión no relacionada con la programación, una revisión mensual de la cuenta publicitaria:

- **[missing-context]** The brief didn't say the French campaigns were deliberately
  paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
  → Fix (altitude: process): add campaign-status flags to the monthly brief template

Un momento, un coste con un(est.)indicador, una etiqueta, una solución que alguien podría poner en práctica la semana que viene. Compárese con la versión inservible de la misma observación: «las instrucciones eran confusas»: ni momento, ni coste, ni paso siguiente. La vaguedad es, en sí misma, un modo de fallo.

4. El derecho a no decir nada. «Nada destacable» es una respuesta válida y útil; un registro repleto de conclusiones inventadas eclipsa las reales.

Otro aspecto a tener en cuenta en el diseño: la grabación debe realizarse sin restricciones; un agente que necesite permiso para grabar tiende a subestimar los problemas. Deje que grabe libremente y que la retroalimentación humana sirva como corrección a posteriori: una señal complementaria por parte de la persona que también participó en la sesión, no un punto de control en el que el bucle tenga que esperar.

Las reglas de «nunca registrar»

Los registros perduran más allá de sus sesiones: se guardan, se comparten y se agrupan. Hay cosas que nunca se incluyen:

• Secretos, credenciales, tokens o claves de API, en cualquier formato, incluso si son parciales.
• Datos de los clientes o información personal.
• Datos empresariales no publicados o cifras confidenciales: describa el efecto, no los datos.
• Por encima de todo, las personas. Nunca un nombre, un cargo ni nada que identifique a quien haya provocado una deficiencia. Describa la deficiencia y lo que ha costado: «el briefing dejó al público desorientado», no «el briefing de X». Las entradas critican las aportaciones y los sistemas, no a las personas —la misma disciplina que rige una buena retrospectiva y lo que hace que el registro sea seguro para leerlo en conjunto.

Es de esperar que se analicen críticamente los datos de entrada: los pliegos de condiciones poco claros, la falta de contexto y los requisitos presentados fuera de plazo suelen ser precisamente donde se encuentra la información útil. El agente debe analizar su propio trabajo con la misma honestidad. Si no es posible describir las dificultades de un ámbito sin revelar información confidencial, mantenga privadas las entradas de dicho ámbito y comparta únicamente el resumen general.

Dónde se encuentra el registro

Un registro por ámbito de revisión —el límite en el que se aplican las correcciones—. Para la mayor parte del trabajo de desarrollo, ese ámbito es el repositorio: su documentación, configuración y convenciones se encuentran en el repositorio, por lo que su registro de incidencias también debe estar allí. Fuera del código, el ámbito es la cuenta publicitaria, la bandeja de entrada de asistencia o la interacción con el cliente; mantenga el registro en la carpeta de documentos de ese espacio de trabajo. Un registro archivado fuera de su ámbito es uno que el responsable final de la corrección nunca encontrará; una entrada escrita en un directorio temporal desaparece al finalizar la sesión.

Lo que debe permanecer idéntico en todas partes no es el almacenamiento, sino la estructura: el esquema, y no el almacenamiento, es lo que permite agregar los registros posteriormente. Esa es la perspectiva de equipo que se aborda en este capítulo: los registros comparables, independientemente de las personas, los agentes, las sesiones y las herramientas, son los que hacen posible, en primer lugar, la agregación a nivel de equipo. Adapte el almacenamiento con total libertad; mantenga intacto el esquema.

¿Qué vendrá después?

Una pila de buenos registros es materia prima, no una idea. Los siguientes capítulos continúan a partir de aquí: elegir la altitud de cada punto de referencia (la diferencia entre una nota de memoria y la refactorización a la que la fricción sigue apuntando); la síntesis de las entradas en un resumen de una página que el equipo pueda leer conjuntamente; y la ceremonia en la que las personas y el registro se encuentran —la retrospectiva—, con los registros del agente como aportación de los participantes. Este ciclo es un ejemplo del «Flywheel de retroalimentación»: incorporar los aprendizajes a los artefactos que proporcionan contexto (martinfowler.com). Y la disciplina de las entradas es el análisis de errores, «la actividad más importante en las evaluaciones» (Husain y Shankar, Preguntas frecuentes sobre las evaluaciones), trasladada al momento más económico posible: mientras la sesión en la que se produjo la fricción aún está en curso.

Todo lo anterior funciona con un archivo de texto y cualquier agente compatible. Si prefiere no crear la plantilla usted mismo, la ai-session-retroskill gratuita implementa este formato de entrada de principio a fin; la guía de inicio rápido le explica cómo instalarla en unos diez minutos.

Próximo capítulo: ¿Dónde debería situarse la corrección? — el problema de la altitud y la tabla de enrutamiento.