Metaingeniería de sistemas de AI: de las trazas a una memoria mejor

Viacheslav Dubrov

2026-09-12 · Actualizado 2026-09-12 · 25 min · Agentes de IA

Traducción automática

Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Este artículo inaugura Meta-Engineering AI Systems, una guía en seis partes sobre ingeniería de AI en bucle cerrado: usar agentes para investigar fallos, probar cambios y utilizar los resultados para mejorar sistemas de AI.

El comportamiento de una aplicación de AI depende de algo más que de su modelo. Los prompts, la información recuperada, la memoria almacenada, las herramientas y el código de la aplicación influyen en lo que sucede. Cuando una respuesta es incorrecta, varios cambios pueden parecer razonables. El problema de ingeniería consiste en decidir qué cambio ayuda, cuánto cuesta y qué más puede romper.

Aquí uso metaingeniería para referirme al diseño del propio proceso de mejora: qué evidencias ve el agente, qué puede cambiar, cómo probamos sus propuestas y quién decide si se adoptan. Bucle cerrado describe cómo ese proceso aprende de sus experimentos. Cada resultado informa de lo que probamos o usamos después, incluso cuando un cambio propuesto falla.

Podemos automatizar este trabajo por etapas. Una persona puede especificar los cambios exactos que se deben probar, definir un conjunto de alternativas permitidas para un algoritmo de búsqueda o delegar la siguiente propuesta en un agente LLM. El runner prueba cada candidato y conserva las evidencias para la siguiente decisión. Esta serie se centra en incorporar agentes a ese proceso, manteniendo la ejecución, la evaluación y la adopción bajo un control explícito.

La pregunta que recorre las seis partes es cuánto de ese trabajo podemos delegar en un agente sin dejar de confiar en las evidencias y en la decisión de adoptar un cambio. Empezaremos cartografiando el sistema completo y después construiremos una pequeña versión operativa alrededor de la memoria del agente.

Qué cierra el bucle

Hay dos bucles distintos que debemos tener presentes. Dentro de una aplicación de agente, el bucle de runtime elige una acción, llama a una herramienta, observa el resultado y continúa con la tarea actual del usuario. El bucle de mejora trabaja entre distintas versiones de esa aplicación. Investiga el comportamiento de ejecuciones completadas y prueba cambios destinados a mejorar las ejecuciones posteriores.

El bucle de mejora comienza con una evidencia: una respuesta incorrecta, un cambio de estado no deseado, un coste excesivo u otro fallo observable. Una traza registra los pasos que han llevado a ese resultado. El proponente elige un candidato, una versión concreta de un cambio. Un runner ejecuta el candidato sobre tareas definidas y un evaluador comprueba el comportamiento resultante frente a los requisitos. En el experimento en vivo de este artículo, un agente LLM actúa como proponente:

La evaluación informa de una decisión; no se autoriza a sí misma. Alguien debe decidir si el beneficio medido justifica adoptar el cambio, incluidos sus efectos sobre el coste, los permisos y otros comportamientos necesarios. En esta serie empezamos con un revisor humano. El proponente puede sugerir un cambio, pero no puede reescribir las comprobaciones, aumentar su propio presupuesto ni concederse aprobación.

Hay dos vías de retorno. El historial de experimentos alimenta propuestas posteriores, incluso cuando se rechaza un candidato. Si un candidato se aprueba y se adopta, su comportamiento proporciona nuevas evidencias durante el uso. Mantener un cambio reversible es importante cuando esas evidencias contradicen el experimento original. Registrar una puntuación es solo un paso; el bucle se cierra cuando las evidencias cambian lo que probamos o usamos después.

Lo que se mejora es el target. Puede ser una política de memoria, un pipeline de retrieval, código de selección de herramientas o el programa que ensambla el contexto de un modelo. El entrenamiento del modelo es otra intervención posible. El bucle puede funcionar con los pesos del modelo fijos: el agente puede mejorar el programa que lo rodea sin entrenar un modelo. Esta primera demo ya incluye el agente LLM externo. En partes posteriores reforzaremos el evaluador y comprobaremos si la búsqueda agentic merece su coste frente a métodos más sencillos.

Elige cuánto de la búsqueda delegar

Supón que ya sabes qué probar: comparar dos modelos en un paso de extracción o probar thresholds de memoria de 0.6, 0.7 y 0.8. Puedes proporcionar esas opciones y automatizar la ejecución, la puntuación y los informes. Después de leer los resultados, eliges el siguiente experimento. El feedback loop funciona aunque el sistema no haya inventado los candidatos.

Utilizo cuatro modos de trabajo para hacer visible esa división. La figura muestra una forma de delegar progresivamente más diseño de experimentos: empezar con elecciones exactas de modelo, dejar que el sistema busque configuraciones y componentes aprobados, o pedir a un agente que investigue los fallos y elija el siguiente experimento. La persona especifica menos de cada intento, pero sigue estableciendo las reglas de la búsqueda.

Los nombres de los modos describen disposiciones prácticas para esta serie, no una escala de autonomía estándar del sector. Qué puede cambiar y quién elige el cambio son decisiones independientes. Los ejemplos de espacios de búsqueda de Optuna combinan la elección del modelo con rangos de parámetros. La búsqueda de pipelines de scikit-learn compara componentes alternativos mediante un grid search convencional. Sustituir un componente no convierte por sí mismo el proceso en más agentic. Las anchuras de la figura ilustran la división del trabajo en estos ejemplos; no son porcentajes medidos de control ni de esfuerzo.

La investigación dirigida por un agente describe cómo se elige el siguiente intento. El agente lee los fallos y resultados anteriores, propone un cambio y se adapta después de la prueba. Esto sigue la distinción de los patrones de workflows y agentes de Anthropic: un proceso predefinido puede automatizar la ejecución, mientras que un agente dirige sus siguientes pasos a partir del feedback. También son posibles métodos híbridos: MIPROv2 de DSPy utiliza un modelo para proponer instrucciones y Bayesian optimization para buscar sus combinaciones. Una comparación fija de modelos no necesita un proponente LLM; sus resultados entran en el feedback loop cuando guían el siguiente experimento o la siguiente versión del sistema.

Los permisos de propuesta, ejecución y adopción siguen siendo independientes. Un agente puede redactar un cambio para su aprobación antes de cada ejecución, o probar cambios permitidos sin supervisión mientras una persona revisa su adopción. Una lista de componentes aprobados sigue necesitando implementaciones compatibles; el permiso para seleccionar un adapter no incluye el permiso para escribir uno. En todos los modos, el agente se mantiene dentro de los cambios permitidos, las comprobaciones fijas y el presupuesto, y no puede concederse autorización para desplegar. Delegar más trabajo también deja margen para la supervisión: el estudio de Anthropic sobre agentes desplegados describe cómo los usuarios pasan de aprobar acciones individuales a monitorizar e intervenir.

Todos los modos pueden utilizar el mismo experiment ledger: un registro de cada cambio intentado. Conserva el candidato y su padre, el cambio exacto y quién lo proporcionó, las versiones de las pruebas y del entorno, el resultado, el coste y cualquier fallo o rechazo. Ese historial permite que una persona entregue la siguiente propuesta a un agente —o recupere el control— sin perder las evidencias. Las puntuaciones de distintas versiones de las pruebas también deben distinguirse.

Esta demo combina la búsqueda de configuración con la investigación dirigida por un agente. Definimos cinco ajustes, las pruebas, el presupuesto y la regla de selección. El agente elige valores y la siguiente hipótesis a partir del feedback; Python ejecuta las pruebas automáticamente. La revisión humana del lanzamiento sigue siendo independiente. El repositorio también acepta un candidate JSON proporcionado por una persona mediante lab evaluate. Los sweeps de modelos, los adapters de componentes y el código escrito por agentes son opciones de diseño más amplias para partes posteriores, no modos implementados en esta demo de memoria.

Por qué examinar esto ahora

El principio del feedback forma parte de la ingeniería habitual. El trabajo reciente que me interesa introduce coding agents en el proceso de investigación y experimentación. Nos proporciona implementaciones concretas que podemos examinar, en lugar de pedirnos que demos por hecho que la mejora autónoma funcionará.

autoresearch de Karpathy especifica un experimento compacto: modificar un programa de entrenamiento, ejecutarlo con un presupuesto fijo de tiempo de entrenamiento, inspeccionar el resultado de validación y registrar si el intento se conserva, se descarta o falla. Las instrucciones separan el archivo de entrenamiento editable del código de evaluación fijo. Esa separación hace que el trabajo propuesto y su criterio de éxito sean inspeccionables.

Meta-Harness, un preprint de marzo de 2026, estudia un target distinto: el código que controla qué información almacena, recupera y presenta a su modelo una aplicación LLM. Su proponente puede inspeccionar mediante un filesystem el código fuente, las puntuaciones y las trazas de ejecución de candidatos anteriores. El historial de experimentos se convierte en material de trabajo para la siguiente investigación.

Estos proyectos motivan la pregunta de ingeniería de la serie: una vez que un agente puede investigar y proponer cambios, ¿qué debe hacer el sistema que lo rodea para que esos experimentos sean útiles? Un mayor número de intentos no demuestra por sí solo que las decisiones sean mejores. Un evaluador débil puede recompensar un cambio perjudicial, y un proceso de búsqueda puede explotar repetidamente esa debilidad. Probaremos el valor de las propuestas agentic frente a alternativas más sencillas, en lugar de asumir que ofrecen una ventaja.

Cómo construyen las seis partes un único sistema

Los artículos desarrollarán un único proyecto complementario acumulativo. Cada parte parte de una pregunta que el experimento anterior dejó abierta y añade el mecanismo necesario para investigarla.

Las comprobaciones de privacidad y la revisión humana deben estar presentes en la primera versión. La parte 5 refuerza esa protección a medida que el proponente adquiere capacidades. Del mismo modo, la parte 6 investiga un posible uso de las evidencias acumuladas; cada parte anterior debe seguir siendo útil sin entrenar un modelo nuevo.

Dale al agente externo un target pequeño e inspeccionable

Imagina un asistente que recuerda los datos de la cuenta de Ada. El 1 de enero aprende que vive en Berlín. El 3 de enero aprende que se mudará a París a partir del 10 de enero. Si le preguntamos por su ciudad el 5 de enero, responde París.

La memoria contiene ambos hechos. La regla de retrieval prefiere el recibido más recientemente sin comprobar cuándo pasa a ser válido. Ese es un fallo concreto que un agente de mejora puede investigar.

El target es deliberadamente solo una herramienta de memoria, no un asistente completo. Recibe hechos preparados, los almacena o rechaza y recupera un valor para una pregunta. Su writer, el tratamiento de fechas, el retrieval y la selección de respuestas son Python convencional. Dejamos fuera de este experimento la extracción desde conversaciones y la generación de respuestas en lenguaje natural, para poder identificar qué ha hecho realmente un cambio de regla.

El LLM está en el bucle externo del experimento de Python. El agente recibe los resultados de las pruebas, decide qué ajustes cambiar y vuelve a recibir el siguiente resultado. Las campañas registradas utilizan un modelo real para elegir esos cambios.

Esta división nos permite probar el bucle de ingeniería sin introducir una segunda fuente de comportamiento del modelo dentro de la herramienta de memoria. En una aplicación mayor, ambos bucles podrían utilizar modelos. Aquí basta un LLM para que el proceso de mejora sea agentic. Otro LLM puede desempeñar el mismo papel de proponente; sus propuestas deben seguir el mismo schema y superar las mismas comprobaciones.

Inspecciona el experimento

El repositorio complementario en GitHub contiene el agente externo, la herramienta de memoria, las pruebas y pequeños informes de tres campañas LLM reales. Las solicitudes, respuestas y trazas completas están disponibles en un archivo de evidencias con checksum. El informe del experimento sigue los cambios propuestos, sus resultados medidos y cada decisión de detenerse. Más adelante en el artículo utilizaremos el repositorio para ejecutar una campaña nueva.

Entiende una prueba antes de leer la puntuación

Un scenario es una historia de prueba completa. Un event es una acción enviada a la herramienta de memoria: write, query o delete. El scenario de la mudanza futura tiene cuatro eventos:

1. Guarda city = Berlin, effective el 1 de enero.
2. Guarda city = Paris, received el 3 de enero pero effective el 10 de enero.
3. Pregunta por la ciudad el 5 de enero. Espera Berlín.
4. Pregunta por la ciudad el 12 de enero. Espera París.

Las entradas ya están estructuradas. Por ejemplo, el hecho de París identifica al propietario (north workspace, usuario ada), el subject (account), la propiedad (city), el valor (Paris) y la fecha de efectividad. Las cadenas Berlín y París proceden de los datos de prueba, no de un modelo que genere memorias a partir de una conversación.

Confidence es una puntuación proporcionada que se utiliza para decidir si se almacena un hecho propuesto. El writer la compara con min_confidence. Una propuesta delivery = courier con puntuación 0.4 se rechaza con el threshold base de 0.7, pero se almacena con un threshold de 0.2. La puntuación la proporciona el autor de la prueba; no es una probabilidad medida de que la propuesta sea correcta. Evaluamos cómo gestiona la regla de almacenamiento esas puntuaciones, no si un modelo puede estimarlas de forma fiable.

Cada scenario comienza con una lista Python vacía de registros de memoria. Las actualizaciones aceptadas cierran el periodo de validez del valor anterior y añaden un registro nuevo. Después de las dos escrituras de ciudad, los registros describen:

La función de respuesta devuelve el primer registro recuperado que coincide con la propiedad solicitada. El evaluador compara ese valor con la respuesta esperada. Un scenario completo solo se supera si todas las respuestas son correctas y se superan todas las comprobaciones de reglas de datos aplicables. La eliminación, el aislamiento entre propietarios y las escrituras prohibidas tienen comprobaciones explícitas junto a la calidad de la respuesta.

Las pruebas proporcionan directamente los IDs de propietario; esta demo no tiene sistema de autenticación. Un servicio real debe obtener esos IDs de la solicitud autenticada. Rechazar una entrada marcada explícitamente como instrucción tampoco demuestra la detección de instrucciones ocultas en texto ordinario.

Dale también un schema a la memoria

Los hechos necesitan sus propias reglas. Utilizo Schema-Guided Agent Memory (SGAM) para el patrón en el que los schemas gobiernan el estado almacenado y su ciclo de vida. Aquí demostramos una pequeña parte: hechos tipados, propiedad, referencias a la fuente, intervalos de validez y eliminación. El schema SGR posterior gobernará lo que el agente externo puede proponer; este schema de memoria gobierna lo que la herramienta puede almacenar.

El registro de París después de la segunda escritura contiene:

{
    "tenant": "north",
    "user": "ada",
    "entity": "account",
    "key": "city",
    "value": "Paris",
    "confidence": 0.95,
    "source": "user",
    "valid_from": "2026-01-10",
    "schema_version": 1,
    "memory_type": "fact",
    "id": "m002",
    "source_event_id": "future-move:event-2",
    "observed_at": "2026-01-03",
    "valid_to": null,
    "supersedes_memory_id": "m001"
}

source_event_id apunta al evento que proporcionó París. supersedes_memory_id vincula París con el registro de Berlín, m001. schema_version: 1 identifica el formato del registro; no significa que el programa pueda migrar datos antiguos automáticamente.

MemoryRecord y Memory.write() hacen cumplir ese formato. Las referencias a fuentes ausentes, las fechas no válidas y los campos mal formados se rechazan antes de modificar el historial almacenado. Un intervalo cerrado debe terminar después de empezar. Berlín puede terminar el 10 de enero mientras París empieza ese mismo día; ninguno de los dos registros tiene un intervalo vacío.

Supón que la siguiente escritura dice Roma, también effective el 10 de enero. El writer rechaza ese conflicto y deja París sin cambios. Un segundo hecho de París para la misma fecha simplemente reutiliza el registro. Una actualización con una fecha effective anterior también se rechaza: este writer pequeño no reconstruye historiales recibidos tarde. Son políticas fijas que el agente externo no puede cambiar. Su ajuste deduplicate controla las confirmaciones repetidas con una fecha effective posterior.

El baseline sigue ignorando deliberadamente los filtros de subject y fecha al leer. Almacena registros válidos, pero puede elegir el incorrecto. El fallo que damos al agente para que lo repare es ese. El aislamiento entre propietarios se aplica a todas las configuraciones, y la eliminación borra todas las versiones de la propiedad solicitada dentro del subject de ese propietario.

Esta es una demostración en memoria de esas reglas de SGAM. No tiene una base de datos persistente, un servicio de retención ni un sistema de migración. Unas pruebas de regresión del writer independientes comprueban las escrituras rechazadas y los límites de los intervalos; no son scenarios adicionales en la puntuación de la campaña de 20 historias.

Deja que el agente elija un cambio

Una campaign es un intento de mejorar la configuración original, empezando con un historial nuevo del agente. Una iteration es una llamada en la que el agente propone un cambio o decide detenerse. La siguiente iteration recibe feedback de las anteriores.

La campaña comienza ejecutando únicamente el baseline. Supera 13 de 20 scenarios. Después damos al agente:

• los ajustes actuales y su significado;
• las mediciones del baseline;
• trazas de scenarios fallidos, escrituras rechazadas y confirmaciones duplicadas;
• los cambios que puede proponer;
• las propuestas anteriores y sus resultados, cuando los hay.

La primera solicitud no contiene configuraciones mejoradas listas para usar. El repositorio también incluye cuatro configuraciones preparadas manualmente para explicar la mecánica de la memoria, pero el agente en vivo no empieza con esas respuestas.

El agente puede cambiar cinco ajustes de la herramienta existente:

Una propuesta puede cambiar como máximo dos ajustes. Los valores numéricos tienen límites: confidence entre 0 y 1, y top_k entre 1 y 8. El contrato registra los cambios de configuración permitidos por la herramienta; el schema y el validator del agente añaden las reglas de propuesta.

En este proceso, el agente no tiene herramientas de shell ni de filesystem. No puede editar Python, las respuestas esperadas, el aislamiento entre propietarios, el comportamiento de eliminación, el schema de memoria, la gestión de conflictos, la puntuación, los presupuestos ni la autoridad de lanzamiento. Su salida son datos que Python puede aceptar o rechazar. Esto es un pequeño experimento de configuración, no un sandbox para código arbitrario escrito por un agente.

Convierte cada propuesta en un registro de decisión SGR

Utilizo Schema-Guided Reasoning para hacer inspeccionable la decisión. Cada respuesta del modelo tiene los mismos campos:

La solicitud de OpenAI Responses utiliza un JSON Schema estricto generado a partir de modelos Pydantic. Los objetos rechazan campos adicionales y cada campo del patch es obligatorio, pero puede ser null, es decir, “dejar este ajuste sin cambios”. Structured Outputs restringe la forma de la respuesta. Python sigue comprobando que las referencias existan, que los valores estén permitidos y que la configuración propuesta no se haya probado ya.

El schema no demuestra la hipótesis ni expone el razonamiento interno del modelo. Son registros de decisión concisos que podemos comprobar frente a las evidencias.

En la primera iteration registrada, el agente identificó el retrieval entre subjects y los hechos devueltos fuera de su intervalo de validez. Su respuesta real propuso este patch:

{
    "min_confidence": null,
    "filter_entity": true,
    "time_aware": true,
    "deduplicate": null,
    "top_k": null
}

El modelo eligió esos dos ajustes. El runner proporcionó el ID del padre y asignó el ID del candidato; el modelo no podía redirigir el cambio a un padre o archivo arbitrario.

Sigue el cambio a través de Python

Tanto el baseline como la nueva configuración almacenan los mismos registros de Berlín y París. El cambio propuesto afecta a los registros que puede considerar el retrieval.

En Memory.query(), estos switches activan dos filtros:

if self.config.filter_entity:
    eligible = [r for r in eligible if r["entity"] == event["entity"]]
if self.config.time_aware:
    eligible = [r for r in eligible if valid_at(r, event["as_of"])]

La comprobación de validez incluye la fecha inicial y excluye la fecha final:

def valid_at(item: dict, at: str) -> bool:
    return item["valid_from"] <= at and (
        item["valid_to"] is None or at < item["valid_to"]
    )

Las fechas utilizan YYYY-MM-DD, por lo que su orden de strings coincide con su orden en el calendario. Para la pregunta del 5 de enero, París queda excluida porque pasa a ser válida el 10 de enero. Berlín sigue disponible. Para la pregunta del 12 de enero, París es válida y Berlín es histórica.

Python ejecuta la configuración propuesta en las 20 historias. Este primer cambio mejora el resultado de 13/20 a 19/20, con todas las hard checks implementadas superadas. Cambia dos filtros a la vez, por lo que la mejora en el conjunto de la suite mide su efecto combinado. La traza de la ciudad identifica qué hizo el filtro de fecha en este caso concreto.

El runner selecciona esta configuración como padre para el siguiente experimento. Esa selección no la despliega. En la siguiente solicitud, el modelo recibe el resultado medido, los ajustes seleccionados y las evidencias restantes.

La siguiente decisión debe utilizar el resultado

Esta es la primera campaña completa. Cada fila es una respuesta real del modelo, no un paso escrito de antemano en un script de demostración:

La segunda respuesta citó el scenario de confirmaciones duplicadas. Esa historia escribe language = German tres veces. La deduplicación conserva un registro en lugar de tres y mantiene la respuesta. En el conjunto de la suite, la media de registros almacenados bajó de 1.70 a 1.60, mientras que el éxito se mantuvo en 19/20.

La tercera propuesta abordó un fallo diferente. Una preferencia de idioma útil tenía una confidence proporcionada de 0.6, por debajo del threshold 0.7 actual. Bajar el threshold a 0.6 permitió admitirla sin dejar de rechazar la propuesta incierta del mensajero, con puntuación 0.4. El éxito alcanzó 20/20; la media de registros almacenados pasó a ser 1.65, porque la memoria conservaba ahora el hecho útil adicional.

En la cuarta llamada, el agente decidió detenerse: no tenía otro cambio respaldado por las evidencias proporcionadas que proponer. Es una decisión del modelo, no una prueba de que la configuración sea globalmente óptima.

La siguiente solicitud contiene los resultados actuales y las decisiones anteriores. Después de comprobar que su reparación del retrieval ayudaba, el agente pasó al almacenamiento y a la admisión de escrituras. El runner no proporcionó esos patches ni una secuencia de pasos escrita de antemano.

La regla de selección es fija: exigir que pasen todas las hard checks, priorizar un mejor éxito en scenarios completos y, con el mismo éxito, preferir menos registros almacenados. Un resultado peor mantiene el padre anterior. Las pruebas también ejercitan esa ruta de rechazo con una propuesta regresiva programada; no fue una regresión de calidad medida en estas tres campañas en vivo.

Una ejecución de desarrollo independiente contiene un rechazo real de validación: el agente citó agent-01, un ID de candidato, como si fuera un scenario. La respuesta coincidía con el JSON Schema, pero su referencia no identificaba un evento proporcionado, así que Python la rechazó antes de evaluarla. El controller devuelve la respuesta rechazada y el error de validación específico como feedback; las pruebas offline comprueban ese comportamiento. Las tres campañas descritas a continuación no tuvieron fallos de validación.

Repite la campaña de búsqueda, no la prueba determinista

La misma configuración de memoria y las mismas entradas producen las mismas respuestas. Repetir esa evaluación no añade evidencias sobre la calidad de las respuestas. El runner comprueba una configuración nueva una vez y reutiliza los resultados verificados de los padres para las comparaciones.

El agente externo puede elegir propuestas diferentes, así que ejecutamos tres campañas independientes. Cada una comenzó en el mismo baseline de 13/20, recibió un historial nuevo y tuvo como máximo cuatro decisiones del modelo. Ninguna campaña recibió los descubrimientos de la anterior.

Las tres campañas eligieron la misma secuencia: activar ambos filtros de retrieval, deduplicar las confirmaciones, bajar el confidence threshold a 0.6 y detenerse.

Hubo 12 llamadas al modelo: nueve propuestas que Python evaluó, seguidas de tres decisiones de detenerse. Cada campaña ejecutó el baseline más tres configuraciones nuevas sobre 20 historias: 80 ejecuciones de la herramienta de memoria por campaña. Las 20 historias se mantuvieron iguales durante todo el proceso.

Las tres seleccionaron los mismos ajustes finales. Es una observación pequeña sobre un modelo, un prompt, un target y una suite pública de pruebas concretos. No estima con qué fiabilidad mejorará el optimizer sistemas desconocidos. Una comparación más sólida pertenece a una parte posterior de la serie: campañas repetidas con presupuestos equivalentes, métodos de propuesta competidores y pruebas que el proponente no pueda inspeccionar.

Lee la calidad y el coste al nivel adecuado

El experimento tiene dos costes distintos. Ejecutar la herramienta de memoria utiliza tiempo de CPU local y no hace llamadas al modelo. Ejecutar el proponente externo utiliza tokens de entrada y salida. Un campo de coste cero del proveedor en un informe de evaluación de memoria solo describe la herramienta interna; no es el coste de la campaña.

Para el estudio registrado el 11 de septiembre de 2026 utilizamos GPT-5.6 Luna (gpt-5.6-luna), un reasoning effort de low, el schema SGR y las instrucciones guardados, y un máximo de 4.096 tokens de salida por llamada. El programa desactivó los reintentos automáticos del SDK y estableció un timeout de solicitud de 60 segundos. Se conservan las solicitudes exactas, los IDs devueltos por el modelo, el uso y las duraciones de las llamadas.

La estimación del coste basada en tokens para las 12 llamadas al modelo es de USD 0.039177, frente a un presupuesto configurado de USD 0.50. El cálculo utiliza las tarifas publicadas del modelo, incluye el recargo de escritura de cache informado en el uso e ignora los descuentos de lectura de cache. Es una estimación conservadora basada en el uso registrado, no una factura. El hardware y el tiempo de desarrollo quedan fuera de esa cifra.

Antes de cada llamada, el runner reserva una estimación superior basada en el tamaño acotado de la entrada y en el máximo de tokens de salida. Si el presupuesto restante no puede cubrir esa reserva, se detiene. Las llamadas fallidas o interrumpidas permanecen en el registro; cuando no hay información de uso, se conserva el importe reservado en lugar de tratarlo como cero.

En cuanto a la calidad de las respuestas, 20/20 significa que todas las respuestas y hard checks aplicables han pasado en estas 20 historias preparadas. No significa que la memoria esté lista para producción. Todas las historias son casos públicos de desarrollo; el proponente puede consultar las trazas seleccionadas y el feedback de la suite. Cubren actualizaciones, preguntas históricas, incertidumbre, duplicados, distractores, separación entre propietarios, eliminación y escrituras no permitidas. Las etiquetas search, evaluation y adversarial organizan la suite original; no convierten ninguno de estos casos en un test set oculto.

Esta pequeña suite toma ideas de LongMemEval, MemoryAgentBench, VehicleMemBench y GateMem. Las entradas y la puntuación son propias; los resultados no reproducen esos benchmarks.

También puedes comparar cuatro configuraciones preparadas manualmente en el repositorio. Ilustran por qué aceptar más hechos puede empeorar las respuestas y cómo puede mejorar el almacenamiento sin aumentar la calidad de las respuestas. También muestran el lado especificado por la persona del mismo mecanismo de experimentación: el autor proporciona los candidatos y Python los evalúa. Son comparaciones didácticas útiles, no evidencias de que la búsqueda agentic supere a una persona competente o a otro método de búsqueda.

Ejecuta una campaña nueva del agente

Para que el agente elija nuevas propuestas, clona el proyecto complementario y descarga las evidencias registradas:

git clone --branch v0.2.2 --depth 1 https://github.com/slavadubrov/meta-engineering-ai-lab.git
cd meta-engineering-ai-lab
uv sync --frozen
uv run --frozen python scripts/fetch_evidence.py
uv run --frozen python -m lab verify artifacts/agent-study-03 --source

La descarga comprueba SHA-256 y restaura las grabaciones completas bajo artifacts/. No hace llamadas al modelo. Si ya has descargado las evidencias, omite ese paso y ejecuta el comando de verificación.

Guarda un OPENAI_API_KEY en un archivo local .env.local. El repositorio ignora ese archivo. Después ejecuta:

uv run --frozen --env-file .env.local python -m lab campaign \
  --live --campaigns 3 --iterations 4 --budget-usd 0.50 \
  --output artifacts/my-agent-study

--live activa explícitamente las llamadas al proveedor. Tener una key en el entorno no convierte en live agent los comandos offline de memoria ni el navegador. --campaigns 3 crea tres historiales de agente independientes; --iterations 4 limita las decisiones dentro de cada uno. Utiliza un directorio de salida nuevo para cada estudio: las evidencias existentes nunca se sobrescriben.

Abre artifacts/my-agent-study/report.md para consultar los resultados de la campaña y los enlaces a cada solicitud, respuesta y evaluación de Python. Compara los cambios propuestos con la campaña registrada arriba: el agente puede elegir de forma diferente aunque las pruebas de memoria sean deterministas.

El README relaciona el código con los comandos. El informe de campaña congelado y el checksum del archivo y el índice de ejemplos permiten inspeccionar directamente las evidencias de este artículo.

Mantén separado el historial de experimentos de la memoria del usuario

La herramienta de memoria almacena la ciudad y el idioma de Ada. El historial de experimentos almacena lo que vio el agente, el patch propuesto, cualquier rechazo, las mediciones resultantes y qué configuración se convirtió en el siguiente padre. Estos almacenes tienen objetivos distintos.

Cada iteration conserva la solicitud exacta con las instrucciones y el schema, la respuesta del proveedor, el uso y el timing, el resultado de la validación y cualquier evaluación completada. Las propuestas fallidas siguen siendo visibles. Los hashes de los archivos vinculan las evidencias guardadas con la implementación y las entradas utilizadas en el experimento.

Estos son hechos sintéticos, por lo que el registro público puede conservar los estados completos. Las trazas reales necesitan una política de retención independiente: eliminar un hecho de la herramienta de memoria no borra las copias anteriores de los logs de experimentos ni de las copias de seguridad. La prueba de eliminación de la demo comprueba los registros de la herramienta y las lecturas posteriores, no el borrado en todos los posibles almacenes.

Qué debe poner a prueba el siguiente artículo

Ahora tenemos un agente dentro del bucle de mejora. Propone un cambio, recibe un resultado medido, elige el siguiente cambio y puede decidir detenerse. Las propuestas no válidas siguen una ruta de rechazo independiente y permanecen registradas. Su autoridad está limitada a la configuración; las pruebas y la revisión del lanzamiento siguen siendo responsabilidades separadas.

El siguiente riesgo es el propio evaluador. Si el éxito recompensa conservar todos los hechos, el agente puede aprender a conservar también las conjeturas. Si una suite solo pregunta por la ciudad actual, puede pasar por alto un cambio que destruya información histórica útil. Un proponente más capaz puede explotar las mediciones débiles con mayor eficiencia.

La parte 2, Haz que se pueda puntuar antes de hacerlo autónomo, pregunta cómo probar esas mediciones antes de dar más libertad al proponente. El 20/20 de la primera campaña es el punto de partida de esa investigación.