Por Qué Tu Agente IA Tiene Alzheimer: Harness, Memoria y Skills en Producción

El genio sin hipocampo

Tu agente IA es brillante durante 90 minutos. Resuelve una incidencia compleja, encuentra el endpoint no documentado, descubre que la API rechaza peticiones sin un header específico, aprende que el sistema de tickets duplica entradas si pides cierre dos veces seguidas. Termina la tarea, cierras la sesión, te vas a comer.

Al volver, le pides exactamente lo mismo. El agente vuelve a empezar desde cero. Vuelve a probar el endpoint mal, vuelve a descubrir el header, vuelve a duplicar tickets antes de aprender que no debe. Paga otra vez el coste de descubrimiento. Y otra vez, y otra vez.

No es un fallo del modelo. Es un fallo de diseño. Hemos construido genios sin hipocampo: capaces de razonar como pocos humanos cuando tienen contexto, incapaces de retener lo aprendido de una sesión a otra. Y en producción, esa amnesia tiene un coste — en facturas de tokens, en horas perdidas, en variabilidad de resultados.

Llevamos un par de años montando agentes que sí recuerdan. La parte interesante: la diferencia entre uno y otro no está en el modelo. Está en el sistema alrededor del modelo. Eso es lo que llamamos harness, y es donde se decide hoy si un agente IA es producto o demo.

Por qué la inteligencia del modelo ya no es el cuello de botella

Hace tres años, mejorar un agente significaba esperar al siguiente modelo. GPT-3.5 fallaba donde GPT-4 acertaba; pasabas el dolor hasta el siguiente release y se compensaba con el salto bruto de capacidad.

En 2026 esa dinámica se rompió. Los modelos de frontera — Claude Opus, GPT-5, Gemini 3, Llama 4 — están en una banda de rendimiento donde la diferencia entre el "mejor" y el "segundo" es marginal para la mayoría de tareas empresariales. Cambiar de modelo no transforma el agente. Lo afina.

Lo que sí transforma el agente es el sistema alrededor del modelo. Hay un experimento que circula en la comunidad y resume bien el punto: misma versión del mismo modelo, misma tarea — construir un pequeño editor de juegos 2D. Sin un sistema estructurado alrededor, el agente gastaba unos dólares, tardaba 20 minutos y producía algo no funcional. Con un sistema bien diseñado — instrucciones claras, estado persistente, verificación obligatoria, scope acotado, ciclo de vida definido — el agente gastaba más, tardaba más, y producía un producto usable.

El modelo no cambió. Solo cambió el entorno. El salto de calidad fue de orden de magnitud.

Ese resultado tiene una implicación incómoda para quien sigue evaluando IA por benchmark de modelo: si tu agente no funciona en producción, es muy poco probable que la causa sea el modelo. La causa, casi siempre, es que el agente está operando sin harness.

Qué es un harness y por qué importa

Un harness es el conjunto de piezas que rodean al agente y le obligan a comportarse como un sistema, no como una conversación.

No es un framework. No es una librería que se instala. Es una decisión arquitectónica: el agente vive dentro de un repositorio, con archivos que lee al arrancar, estado que persiste en disco, verificación que ejecuta antes de declarar tarea completada, scope definido en un fichero estructurado, y un ciclo de vida que limpia y entrega cuando termina.

Cinco subsistemas que en proyectos de producción siempre están — porque sin ellos el agente improvisa:

Instructions. Un fichero AGENTS.md o CLAUDE.md en el repo que el agente lee al inicio de cada sesión. Contiene la guía operativa: qué hace este sistema, qué convenciones sigue, qué herramientas tiene, qué decisiones ya están tomadas. No es documentación humana — es manual para agentes. Cambia el formato: menos prosa, más reglas; menos contexto histórico, más estado actual.

State. Ficheros que registran qué se ha hecho y qué falta. Un progress.md que el agente actualiza al cerrar cada paso. Un feature_list.json con tareas y su estado. Un log de decisiones que se quedaron a medias. El agente no inicia cada sesión a ciegas — lee el estado, retoma desde donde se quedó, y al terminar deja constancia.

Verification. El agente no declara "listo" — lo demuestra. Antes de cerrar una tarea, ejecuta tests, lint, type-check, lo que aplique al dominio. Si pasa, sigue; si no pasa, no avanza. Esto convierte la confianza en algo medible. "El modelo dice que está bien" deja de ser un criterio.

Scope. Una cosa a la vez. El agente no decide qué hacer libremente; lee una lista priorizada de tareas, coge una, la cierra y vuelve a la lista. Sin esto, el agente acumula trabajos a medio hacer y diverge — la trampa clásica del LLM que se entusiasma con tangentes.

Lifecycle. Cada sesión empieza con un init.sh que comprueba el entorno (dependencias, salud de servicios, datos disponibles) y termina con un handoff.md que resume qué se hizo y qué queda. Esto es lo que permite que la siguiente sesión, sea del mismo agente o de otro, retome sin pérdida de contexto.

Estos cinco subsistemas no requieren ningún producto especial. Se montan con archivos planos en el repo, scripts de bash, JSON, markdown. La complejidad no está en la tecnología; está en tomarse en serio el diseño.

Memoria de agente: tres horizontes, tres tecnologías

La memoria del agente no es una sola cosa. Son tres horizontes que se combinan según necesidad:

Corto plazo: el contexto activo. Es la conversación de la sesión actual, lo que el modelo tiene "en mente" en el prompt. Limitado por la ventana del modelo (200K o 1M tokens según proveedor). Si la sesión es larga, hay que comprimir, resumir o paginar. Esto se gestiona con técnicas de context engineering: cuánto historial se incluye, qué se descarta, qué se sumariza.

Medio plazo: la memoria de proyecto. Ficheros en el repositorio que viven más allá de una sesión: el CLAUDE.md con convenciones del proyecto, el progress.md con estado de las tareas, los decisions.md con razonamientos pasados. Esto es lo que permite que un agente abra una sesión nueva y sepa "dónde estaba" sin reexplorar todo. Es la forma de memoria más infravalorada — funciona sin librerías, sin servicios externos, solo con archivos versionados.

Largo plazo: la memoria persistente sobre hechos. Lo que el agente debe recordar entre proyectos, entre usuarios, entre meses. Aquí entran soluciones especializadas — MemGPT para gestionar memoria jerárquica del propio agente, Zep para memoria conversacional de usuarios y hechos sobre ellos, vector stores propios para recuerdos semánticos. La elección depende del caso: si necesitas que el agente recuerde "este cliente prefiere reuniones los martes", eso es Zep o equivalente; si necesitas que recuerde "qué procesos críticos hay en este sector", eso es un vector store de conocimiento.

Un error frecuente: usar largo plazo cuando bastaba medio. Casi todos los agentes empresariales que vemos atascados creen que necesitan MemGPT cuando lo que les falta es un CLAUDE.md bien escrito. La memoria persistente sofisticada se justifica cuando hay multiplicidad real de usuarios o de contextos. Para un agente que opera sobre un solo proyecto, los archivos del repo son el 90% del problema resuelto.

Skill graduation: el agente que escribe su propio manual

La técnica que más cambia el coste operativo de un agente en producción tiene un nombre incómodo en castellano: skill graduation. La idea es simple. Cuando el agente resuelve por primera vez una tarea compleja — descubrir el endpoint correcto, navegar un proceso multi-paso, normalizar datos de una fuente nueva — ese aprendizaje no se queda en la sesión. Se cristaliza en un fichero markdown reusable que cualquier futura sesión puede cargar y ejecutar.

El primer run es caro a propósito: el agente explora, falla, aprende, converge. Pero el resultado no es solo "tarea hecha" — es una skill nueva: un documento con los pasos exactos, las llamadas API que funcionan, los errores conocidos, los workarounds. La siguiente vez que la tarea aparece, el agente carga la skill y la ejecuta directa. El coste cae de minutos a segundos, de varios dólares a céntimos, y la variabilidad de resultado cae casi a cero.

Tenemos clientes donde esta técnica cambió la economía de procesos enteros. Un caso: un agente que genera reportes mensuales sobre fuentes heterogéneas (un Drive corporativo, un ERP, dos hojas de cálculo dispersas que alguien actualiza a mano). El primer ciclo tardó dos horas — el agente tuvo que descubrir qué hoja era la "buena", qué columnas estaban en formato europeo y cuáles en americano, qué filas eran encabezado y cuáles datos. Ese conocimiento quedó cristalizado en una skill versionada en el repo. Los ciclos siguientes: minutos. Y cuando alguien cambia la estructura de la hoja, el agente detecta el desajuste y actualiza la skill bajo aprobación humana — no la reescribe a ciegas.

Hay un matiz importante. Una skill graduada no es un script. Es un híbrido: instrucciones en lenguaje natural (qué hacer, cuándo, qué errores esperar) combinadas con piezas deterministas (comandos exactos, llamadas API, regex). El agente sigue razonando, pero parte de un mapa, no de una página en blanco.

Cómo se ve esto en la práctica

Un proyecto real, anonimizado. Empresa de servicios profesionales, equipo de unas 200 personas, mucho proceso manual sobre Confluence, Drive y un ERP propio. El planteamiento inicial del cliente era "queremos un agente que conteste preguntas internas". La trampa: ese encargo, sin harness, produce un chatbot que se desentiende del problema a los dos meses.

Lo que montamos:

• Un AGENTS.md en el repo del agente que describe la empresa, los sistemas conectados, las convenciones internas (qué significa cada acrónimo, qué procesos son críticos, qué tipos de pregunta requieren escalado).
• Un progress.md que el agente actualiza con cada conversación relevante — qué se preguntó, qué se respondió, qué se quedó pendiente.
• Una carpeta skills/ con markdown versionado. Cuando el agente descubre cómo responder a una clase nueva de pregunta — "informes trimestrales del área X" o "estado de proyecto Y" — escribe el procedimiento y lo guarda. La próxima vez ejecuta directo.
• Verificación: cada respuesta del agente cita las fuentes (URL de Confluence, fila SQL, fragmento de Drive). Si una respuesta no se puede citar, no se da.
• Lifecycle: cada sesión empieza con un script que valida que los sistemas conectados responden, y termina con un commit al estado.

Resultado a los tres meses: el coste medio por consulta bajó alrededor de un 70% frente al primer mes (skills graduadas comen el grueso de las preguntas frecuentes). El tiempo de respuesta para casos rutinarios bajó de 40-60 segundos a 5-10. Y, lo más útil, las skills se convirtieron en activo del cliente — documentación viva de cómo funciona realmente la empresa, escrita por el agente en su descubrimiento y revisada por el equipo.

Cuando llega un agente nuevo (porque cambia el modelo, porque se monta una segunda capa de orquestación), no parte de cero. Lee el repo del agente anterior y empieza con todo el aprendizaje cristalizado. Eso es continuidad operativa, no rotación de proveedor.

Qué exigir cuando contratas un agente IA en producción

Reducido a checklist:

1. Repositorio del agente versionado, con AGENTS.md o CLAUDE.md legibles por humanos y por agentes.
2. Estado persistido en disco, no solo en la sesión del modelo. Si el agente se reinicia, debe poder retomar.
3. Verificación como evidencia ejecutable: tests, lint, validación de salida. Nada de "el modelo dijo que está bien".
4. Skills graduadas y versionadas en un directorio del repo. Reusables, auditables, ejecutables.
5. Memoria multi-sesión real: el agente no empieza cada sesión a ciegas.
6. Capacidad de retomar trabajo de sesión interrumpida: si se cayó la conexión, si se acabó el contexto, el agente debe poder continuar desde el último estado.
7. Handoff documentado entre sesiones: notas estructuradas que el siguiente agente lee.
8. Observabilidad de decisiones: cada paso del agente queda registrado en un formato que un humano puede revisar.

Si el equipo que te entrega el agente no puede mostrarte estos ocho elementos en el repositorio del propio sistema, no estás contratando un agente — estás contratando un chatbot que la siguiente semana costará lo mismo en exploración que hoy.

Cómo lo construimos en producción

En proyectos de agentes serios, el harness no es algo que se monta al final — es lo primero. Antes de elegir modelo, antes de diseñar el prompt, antes de escribir una sola tool, mapeamos qué tiene que recordar el agente entre sesiones, qué evidencia ejecutable demostrará que ha hecho bien su trabajo, y dónde van a vivir las skills que se graduarán.

El repositorio del agente es un proyecto de software en toda regla, con CI/CD propio, tests sobre los prompts críticos, evals automatizados sobre el comportamiento. No es una colección de scripts atados con cinta; es una unidad de despliegue versionada que el cliente puede leer, editar y mantener cuando nosotros ya no estemos.

Detrás de cada uno de estos sistemas hay un equipo de desarrolladores que cree que la ingeniería seria de IA empieza por preguntarse cómo va a aprender el agente, no por elegir el modelo. La excelencia técnica no se mide por la elegancia del primer prompt — se mide porque el agente cuesta cada mes menos que el anterior, y dentro de un año sigue siendo el activo del cliente, no el del proveedor.

Producción significa que el agente compone valor con el tiempo, no que se reinicia cada lunes. Esa es la diferencia entre un sistema que aprende y un genio sin hipocampo.

Si tu agente IA está bien para hacer demos pero te asusta dejarlo solo un lunes por la mañana — o si estás evaluando proveedores y no tienes criterios para distinguir un proyecto de un chatbot caro — podemos auditar tu sistema, mapear su harness actual y entregarte el plan para que el agente empiece a recordar.