La diferencia entre un valor modesto y un valor sustancial con herramientas de IA procede de la arquitectura que envuelve al modelo. Steve Yegge observó a principios de 2026 que los desarrolladores que usan agentes de codificación IA reportan ganancias de productividad significativas en tareas adecuadas; las cifras varían considerablemente según la metodología y el tipo de tarea. Los mismos modelos. La misma inteligencia subyacente. La variable es la estructura.
En una sola semana de abril de 2026, cinco desarrolladores independientes publicaron marcos de referencia para la arquitectura de agentes IA. Garry Tan (Y Combinator), Andrej Karpathy, Viv Trivedy, Daniel Miessler y un repositorio comunitario que alcanzó 19.700 estrellas en GitHub convergieron en la misma tesis central: colocar la inteligencia en archivos markdown portables, mantener la infraestructura de orquestación lo más delgada posible y dejar que el modelo haga el razonamiento. Este artículo analiza en qué coincidieron, en qué discrepan y qué implica para quienes construyen con IA.
Los principios de la arquitectura
- La inteligencia pertenece a los archivos de habilidades en markdown, no al código del framework. Las habilidades son portables, versionables y mejoran automáticamente cuando mejora el modelo.
- El harness debe hacer cuatro cosas y nada más. Ejecutar el modelo en bucle, leer y escribir archivos, gestionar el contexto, garantizar la seguridad. Cada función que se añade más allá de eso consume contexto y ralentiza el razonamiento.
- Cinco desarrolladores publicaron de forma independiente la misma tesis en tres días (del 12 al 15 de abril de 2026). Garry Tan, Andrej Karpathy, Viv Trivedy, Daniel Miessler y un repositorio comunitario con 19.700 estrellas en GitHub. La convergencia entre fuentes independientes es una de las señales de que un patrón arquitectónico es sólido.
- LangChain discrepa y tiene benchmarks que lo demuestran. Harrison Chase sostiene que el harness ES el producto. La respuesta puede depender de si se están construyendo herramientas de consumo o pipelines empresariales.
- Las instrucciones prescriptivas caducan. El contexto, no. Cada receta paso a paso que se escribe para una IA se degrada con el siguiente lanzamiento de modelo. El contexto sobre quién es usted y qué quiere se acumula con el tiempo.
La arquitectura es compacta
Los debates públicos sobre runtimes de agentes en producción se han centrado cada vez más en una arquitectura compacta: un bucle de modelo, herramientas, gestión de contexto y controles de seguridad. Garry Tan describió ese patrón como un impulsor de productividad que llevaba meses enseñando en Y Combinator: la brecha de productividad proviene de lo que envuelve al modelo.
Tan sintetizó la arquitectura en tres capas:
| Capa | Qué contiene | Propiedad clave |
|---|---|---|
| Habilidades gruesas | Procedimientos en markdown que codifican juicio, proceso y conocimiento de dominio | Portable. Usted es su dueño. |
| Harness CLI delgado | Unas 200 líneas: JSON de entrada, texto de salida, gestión de contexto, seguridad | Mínimo. Lo provee el proveedor. |
| Su aplicación | QueryDB, ReadDoc, Search, Timeline. Operaciones deterministas. | Fiable. Misma entrada, misma salida. |
El principio es direccional. La inteligencia sube hacia las habilidades. La ejecución baja hacia herramientas deterministas. El harness se mantiene delgado. El 90% del valor reside en la capa de habilidades. El harness es un conductor que lee archivos, no quien los posee.
La experiencia propia de Tan ilustra el punto. Su CLAUDE.md personal comenzó con 20.000 líneas: cada peculiaridad, cada convención, cada lección acumulada. El resultado: la atención de Claude Code se degradó. El propio modelo le indicó que lo redujera. La solución fue unas 200 líneas de punteros a documentos que se cargan bajo demanda. Las 20.000 líneas de conocimiento siguen existiendo, pero se cargan cuando son relevantes en lugar de contaminar la ventana de contexto en cada turno.
Si está construyendo herramientas o flujos de trabajo con IA para su negocio, definir la arquitectura correcta desde el inicio determina si termina con una demo que impresiona o con un sistema que funciona en producción.
Cinco conceptos que distinguen las implementaciones de IA de alto rendimiento
La arquitectura se apoya en cinco conceptos. Ignorar cualquiera de ellos hace que el sistema rinda por debajo de su potencial.
1. Archivos de habilidades
Una habilidad es un documento markdown reutilizable que enseña al modelo el proceso para una categoría de tarea. El usuario proporciona la tarea; la habilidad proporciona el procedimiento. Funciona como una llamada a un método: mismo procedimiento, argumentos distintos, resultados radicalmente diferentes.
El ejemplo de Tan: una habilidad llamada /investigate con siete pasos (delimitar el conjunto de datos, construir una línea de tiempo, diarizar cada documento, sintetizar, argumentar ambos lados, citar fuentes). Apúntela a un científico de seguridad y 2,1 millones de correos de descubrimiento y obtendrá un analista de investigación médica. Apúntela a una empresa fantasma y registros de la FEC y obtendrá un investigador forense. Los mismos siete pasos. La invocación aporta el contexto.
2. Resolvers
Un resolver es una tabla de enrutamiento para el contexto. Cuando aparece el tipo de tarea X, se carga primero el documento Y. Sin resolver, un desarrollador cambia un prompt y lo publica. Con resolver, el modelo lee primero la documentación del conjunto de evaluaciones, ejecuta benchmarks y revierte si la precisión cae más de un 2%. El desarrollador no sabía que existía ese conjunto de evaluaciones. El resolver cargó el contexto adecuado en el momento adecuado.
3. Latente frente a determinista
Cada paso de un sistema es una cosa o la otra. Confundirlos es el error más frecuente en el diseño de agentes. Un LLM puede sentar a 8 personas en una mesa teniendo en cuenta las personalidades. Pídale que siente a 800 y alucinará un plano de asientos que parece plausible pero es completamente incorrecto. Se trata de un problema determinista forzado al espacio latente. Los mejores sistemas son implacables con este límite.
4. Diarización
El modelo lee todo lo relativo a un sujeto y redacta un perfil estructurado. Ninguna consulta SQL produce esto. Ningún pipeline RAG lo produce. El modelo debe leer, sostener contradicciones en mente, detectar qué cambió y cuándo, y sintetizar inteligencia estructurada.
El equipo de Tan construyó un sistema para YC Startup School que gestiona 6.000 perfiles de fundadores de esta manera. La diarización detecta cosas que ninguna búsqueda por palabras clave encontraría: una fundadora que dice "Datadog para agentes de IA" pero cuyos commits en GitHub son un 80% de código de facturación. Está construyendo una herramienta FinOps disfrazada de observabilidad. Esa brecha entre lo que se dice y lo que realmente se construye requiere leer simultáneamente el historial de commits, la solicitud y la transcripción del asesor. Ninguna búsqueda por similitud de embeddings la encuentra.
5. Mejoras permanentes
La instrucción de Tan a su IA: "Si me pides que haga algo y es el tipo de cosa que necesitará ocurrir de nuevo, codifícalo en un archivo de habilidad. Si debe ejecutarse automáticamente, ponlo en un cron. Si tengo que pedirte algo dos veces, has fallado." Cada habilidad escrita es una mejora permanente. No se degrada. Cuando llega el siguiente modelo, cada habilidad mejora de inmediato. El sistema se acumula.
Cinco marcos publicados en una semana llegan a la misma conclusión
La convergencia es la señal más potente. Estos cinco conjuntos de trabajo surgieron de forma independiente entre el 12 y el 15 de abril de 2026. Ninguno de estos desarrolladores colaboraba entre sí. Llegaron a la misma arquitectura desde puntos de partida distintos.
| Marco | Dónde reside la inteligencia | Qué permanece delgado |
|---|---|---|
| Tan (habilidades gruesas) | Archivos de habilidades en markdown, SOUL.md | El harness: conductor, no cerebro |
| Karpathy (CLAUDE.md) | Archivos de instrucciones de comportamiento | Sin framework. Un solo archivo .md |
| Trivedy (fragmentos de contexto) | Memoria externalizada, capa de recuperación | El harness gestiona el contexto, no posee el conocimiento |
| Miessler (lección amarga) | Contexto sobre identidad, objetivos y criterio | Instrucciones sobre cómo ejecutar |
| Comunidad (repo con 19.700 estrellas) | Habilidades, comandos slash, reglas en CLAUDE.md | Subagentes reemplazan la compactación. Grep reemplaza RAG |
Tan llegó aquí tras publicar un volumen elevado de código en producción en dos meses, donde el recuento de líneas es una métrica de rendimiento y ese rendimiento es inusual con gstack (más de 23.000 estrellas en GitHub en su primera semana; las estrellas miden visibilidad, no idoneidad para producción). Karpathy llegó desde el análisis de los tres modos de fallo persistentes de los asistentes de codificación IA. Trivedy llegó tras iterar sobre el diseño del harness a través de más de 30 versiones. Miessler llegó aplicando la lección amarga de Richard Sutton a las herramientas de IA.
La convergencia entre múltiples fuentes independientes es una de las señales de que un patrón arquitectónico es sólido.
LangChain discrepa, y tiene benchmarks que lo demuestran
Harrison Chase (CEO de LangChain) publicó Deep Agents la misma semana y argumentó lo contrario: el harness ES el producto. Planificación de tareas integrada, generación de subagentes, middleware, hooks, infraestructura de orquestación completa. Su evidencia: cambiar únicamente el harness llevó al DeepAgent de LangChain de fuera del top 30 al top 5 en TerminalBench 2.0.
LangChain procesa millones de llamadas de agentes diariamente, por lo que la objeción merece atención. Sus benchmarks son públicos. La división real: la posición de Tan es que cada pieza de lógica en el harness limita el razonamiento que el modelo podría haber realizado. Cuanto mejor sea el modelo, más delgado debería ser el harness. La posición de Chase es que la ingeniería del harness extiende la capacidad del modelo en lugar de reemplazarla.
Ambas posiciones pueden ser correctas en contextos diferentes. Los agentes de consumo y personales, donde importan la portabilidad y la longevidad, favorecen el harness delgado. Los pipelines empresariales, donde importan la fiabilidad y la auditabilidad, pueden justificar un harness más grueso. Ninguno de los dos lados cuestiona que las habilidades deben ser gruesas. La pregunta útil para su proyecto es en qué lado de la línea se encuentra su caso de uso.
La mayoría de las empresas que construyen funcionalidades de IA por primera vez deberían empezar con una arquitectura delgada y añadir infraestructura solo cuando encuentren problemas concretos de fiabilidad. ¿No sabe dónde encaja su proyecto? Hable con webvise sobre qué arquitectura se adapta mejor.
Sus instrucciones caducarán. Su contexto, no.
Daniel Miessler publicó el diagnóstico más preciso de la semana. Lo denomina la auditoría de ingeniería de la lección amarga, a partir de la observación de Richard Sutton en 2019 de que los enfoques generales que escalan con la computación superan de forma consistente a los enfoques codificados manualmente a largo plazo.
Aplicado a las herramientas de IA: la mala ingeniería del harness son instrucciones prescriptivas. "Primero copie este archivo, luego cargue esto, después haga aquello." Microgestión paso a paso de la ejecución de la IA. Este enfoque se degrada a medida que los modelos se vuelven más inteligentes. Los pasos excesivamente rígidos impiden que el modelo aplique su propio razonamiento.
La buena ingeniería del harness es contextual. Quién es usted, en qué trabaja, qué intenta lograr, cómo se ve un buen resultado y cómo uno malo. Identidad, criterio, estándares, objetivos. El modelo determina el cómo.
El diagnóstico de Miessler es sencillo. Si su configuración se lee como una receta (paso 1, paso 2, paso 3), está haciendo mala ingeniería del harness. Si se lee como un documento de contexto (quién soy, qué importa, cuáles son las herramientas), está haciendo buena ingeniería del harness. El contexto sobre quién es usted nunca caduca. Las instrucciones prescriptivas quedan obsoletas con cada mejora del modelo.
La arquitectura no es complicada. Habilidades gruesas, harness delgado, separación implacable entre trabajo latente y determinista. La parte difícil es la disciplina: codificar el juicio en habilidades reutilizables en lugar de hacer trabajo puntual, mantener el harness delgado cuando la tentación es añadir funciones, y confiar en que el modelo resuelva el "cómo" cuando se le da el "qué" y el "por qué" correctos.
webvise construye sistemas con IA siguiendo estos principios de arquitectura. Tanto si necesita un flujo de trabajo de agentes, un pipeline automatizado o una integración de IA lista para producción, la arquitectura importa más que el modelo.
Las prácticas de webvise están alineadas con las normas ISO 27001 e ISO 42001.