Qué probaron exactamente y por qué las cifras no son decorativas
Me encantan estas publicaciones no por el titular llamativo, sino por el momento en que se puede señalar un fallo de arquitectura. Vercel puso a prueba a sus agentes con tareas que requerían la documentación de Next.js, dejando intencionadamente parte del conocimiento fuera del pre-entrenamiento del modelo. Esto ya es una prueba real del comportamiento del sistema, no una simple demo bonita.
El esquema era sencillo. Un agente base sin ayuda externa superaba las evaluaciones en un 53%. Luego, se le proporcionaban 'skills' o un archivo AGENTS.md, y aquí es donde comenzó lo interesante.
Los 'skills' en este diseño estaban estructurados como carpetas con un SKILL.md, metadatos, instrucciones y archivos adicionales. El agente primero tenía que darse cuenta de que el 'skill' necesario existía, luego decidir que debía invocarlo y solo entonces cargar su contenido. En teoría, suena ordenado. En la práctica, el agente a menudo ni siquiera llegaba a ese paso.
Según los datos de Vercel, los 'skills' por sí solos también dieron un 53%. Es decir, cero mejora. Peor aún: en aproximadamente el 56% de los casos, el agente no invocaba el 'skill' en absoluto, aunque fuera relevante.
En cambio, AGENTS.md funcionó como un contexto constante en el system prompt. No hace falta buscar nada, ni tomar una decisión intermedia sobre la carga. Si en este archivo se coloca un resumen comprimido de la documentación o un índice, el agente lo ve siempre. En las evaluaciones de Vercel, la versión con el contexto completo y comprimido en AGENTS.md alcanzó una tasa de éxito del 100%.
Lo que me llamó la atención aquí no fue la magia del markdown. Fue que el markdown ganó no por ser elegante, sino porque eliminó un punto de fallo innecesario. El modelo no se olvidó de invocar la herramienta porque, simplemente, no se le dio la oportunidad de hacerlo.
Qué cambia esto en la arquitectura e implementación de la IA
Si traducimos esto del lenguaje de los benchmarks al de la producción, la conclusión es muy pragmática. Cuando el conocimiento crítico para realizar una tarea reside en una mecánica opcional, estás construyendo un sistema frágil. Puede ser elegante en un diagrama, pero inestable en la práctica.
Veo esto constantemente en proyectos de automatización con IA. El equipo le da al agente un conjunto de herramientas, 'skills', capas de memoria, enrutadores y un poco de esperanza por encima. Luego, todos se sorprenden de por qué el agente a veces es inteligente y otras veces parece haber olvidado dónde está.
El enfoque con AGENTS.md sugiere una arquitectura más práctica para las soluciones de IA. Las reglas básicas, el índice de conocimiento del dominio, las restricciones, el formato de respuesta y las rutas clave deben mantenerse en un contexto constante. Los 'skills' y las herramientas deben reservarse para lo que realmente necesita ser cargado bajo demanda: manuales pesados, APIs externas, procedimientos poco frecuentes.
Es decir, no es un 'o uno o lo otro', sino un híbrido adecuado. Yo lo formularía así: AGENTS.md para el determinismo, 'skills' para la extensibilidad. Esto ya se parece a una arquitectura de IA madura, y no a un conjunto de funciones que acabaron por casualidad en el mismo repositorio.
También hay una limitación, y es justa. El contexto constante no se puede inflar infinitamente. Vercel muestra claramente que el objetivo no es meter toda la documentación en AGENTS.md, sino comprimirla en un resumen corto, útil y bien indexado. Mencionaron un tamaño de unos 8 KB en lugar de los 40 KB del material original, lo que suena muy sensato.
¿Quiénes se benefician de este cambio? Los equipos que necesitan una automatización predecible con IA: soporte, copilotos internos, flujos de trabajo con agentes para desarrollo, operaciones y gestión de documentos. ¿Quiénes pierden? Los proyectos cuya arquitectura se basa en la fe de que el modelo 'adivinará por sí solo qué módulo invocar'.
Yo no convertiría esto en una ley universal de la naturaleza. Son los resultados de Vercel en evaluaciones específicas sobre Next.js, y en otras tareas el panorama podría cambiar. Pero la señal es muy fuerte: al implementar la inteligencia artificial en procesos reales, hay que diseñar no solo el conocimiento del agente, sino también la ruta de acceso a ese conocimiento.
En Nahornyi AI Lab, es precisamente en este punto donde más a menudo recortamos lo superfluo. No añadimos diez abstracciones más a un agente, sino que eliminamos una decisión innecesaria que toma de forma inestable. Y, de repente, todo empieza a funcionar mejor, más barato y con más tranquilidad.
Este análisis fue realizado por mí, Vadym Nahornyi, en Nahornyi AI Lab. Me dedico a desarrollar soluciones de IA y a construir sistemas de agentes con mis propias manos, por lo que estos detalles para mí no son teoría, sino la rutina diaria de ingeniería. Si quieres discutir tu caso, implementar IA o realizar una automatización con IA sin magia frágil, escríbeme. Analizaremos tu proyecto juntos.