Memoria de agentes: lograr lo mismo que ACE con muchos menos tokens

Introducción

Cuando un agente basado en LLM falla en una tarea multi‑paso —dividir una cuenta, localizar una canción o conciliar un pedido entre múltiples aplicaciones— casi nunca es por falta de conocimiento. El modelo suele equivocarse en la paginación de una API, en elegir a la persona correcta, o en devolver un valor cuando no se pidió. El problema no es qué sabe el modelo, sino cómo usar ese conocimiento de forma confiable.

Dos sistemas recientes abordan esto aprovechando las propias trayectorias del agente para extraer lecciones reutilizables y volver a inyectarlas en inferencia sin entrenar pesos ni etiquetado humano: ACE (Agentic Context Engineering) y ALTK‑Evolve. Ambos son formas de memoria agentífica, pero difieren en cómo construyen y entregan esas lecciones —y esa diferencia tiene un gran impacto en la factura de tokens.

Qué es una “lección” y cómo la organizan

En este contexto, una lección es una regla, pauta o instrucción que el agente deriva de episodios pasados. ACE agrupa las lecciones en un único playbook evolutivo y consolidado; ALTK‑Evolve las almacena como guías individuales recuperables.

A pesar de las diferencias terminológicas, ambos equipos coinciden en algo crucial: no deben colapsar o resumir esas lecciones hasta perder detalle. ACE identifica dos fallas de diseño al comprimir contexto: la “brevity bias” (tendencia a instrucciones cortas y genéricas) y el “context collapse” (cuando se pierde detalle al resumir todo el contexto en cada paso). Su respuesta es mantener un playbook detallado, con contador por cada punto que registre cuántas veces fue útil.

ALTK‑Evolve llega a la misma conclusión desde otra dirección: conserva un conteo de soporte para cada pauta y evita reducir el almacén a un puñado de reglas. Una lección observada en cinco episodios es distinta y tan valiosa como una vista una sola vez; ambas se deben preservar.

Dónde coinciden ACE y ALTK‑Evolve

• Ambos convierten trayectorias de agente en lecciones reutilizables sin actualizar pesos ni requerir etiquetas humanas.
• Ambos mantienen metadatos de respaldo (cuántos episodios apoyan una lección) en lugar de resumir y perder esa evidencia.
• Ambos permiten que el modelo distinga utilidad a la hora de leer las lecciones, en lugar de forzar un resumen que pueda borrar matices.

En suma: no comprimir, contar. Los contadores por punto en ACE y los “support counts” en ALTK‑Evolve son variantes de la misma idea.

Dónde difieren: consolidación y entrega

Las diferencias operativas se dan en dos frentes:

1. Consolidación (cómo se construye la memoria)

• ACE hace crecer un playbook único a través de un bucle Generator → Reflector → Curator, aplicando actualizaciones delta y desduplicando por embeddings. Cuando varias lecciones son casi idénticas se agrupan y la lección sobreviviente hereda el conteo combinado, reduciendo el tamaño del almacén sin perder el registro de soporte.

• ALTK‑Evolve también crea lecciones con causalidad y trazabilidad hasta la trayectoria origen, y además tipifica las guías (por ejemplo: estrategia, recuperación, optimización) y las extrae a nivel de subtarea para facilitar transferencia entre aplicaciones.

2. Entrega (qué llega al modelo en inferencia)

Aquí está la gran diferencia: ACE inyecta el playbook completo en cada paso durante la resolución de la tarea, igual para cualquier modelo o tarea. ALTK‑Evolve adopta la entrega como un dial: siempre incluye un núcleo pequeño y de alto soporte, y extiende ese núcleo con un puñado de lecciones seleccionadas para la tarea actual (por similaridad coseno o guiado por LLM y priorización por soporte). Cuando el modelo tiene suficiente capacidad de contexto, puede usarse el conjunto consolidado, pero solo si tiene sentido.

La consecuencia práctica es que ambas arquitecturas pueden disponer de las mismas lecciones, pero ACE siempre las envía todas en cada paso mientras que ALTK‑Evolve solo envía lo que el modelo realmente puede aprovechar.

Resultados experimentales (misma base agent)

En AppWorld, con el mismo agente ReAct base, ambos sistemas se ejecutaron internamente y los resultados muestran la diferencia en precisión y tokens por tarea:

• DeepSeek‑V3.2

  • ACE: TGC/SGC 80.4 / 73.2 — Tokens por tarea: 634K
  • ALTK‑Evolve: TGC/SGC 89.3 / 80.4 — Tokens por tarea: 263K

• gpt‑oss‑120b

  • ACE: TGC/SGC 54.8 / 35.7 — Tokens por tarea: 777K
  • ALTK‑Evolve: TGC/SGC 56.0 / 37.5 — Tokens por tarea: 116K

Interpretación de los números:

• En el modelo más capaz (DeepSeek‑V3.2), ALTK‑Evolve obtiene mejores métricas y usa ~40% del costo de inferencia en tokens frente a ACE.
• En el modelo más débil (gpt‑oss‑120b), ALTK‑Evolve empata o supera levemente la precisión a aproximadamente una séptima parte del costo en tokens.

El relato por dificultad muestra que cada sistema mejora respecto a su línea base sin memoria. En modelos con más capacidad, entregar lecciones de forma selectiva permite que más lecciones útiles coexistan sin perjudicar al modelo; en modelos más limitados, enviar menos contexto relevante vence a inundarlos con un playbook completo.

Qué significa esto para equipos y decisiones de producto

Para equipos que construyen agentes en América Latina —donde el presupuesto de inferencia y la latencia tienen un impacto directo en la viabilidad comercial— estos resultados sugieren prioridades prácticas:

• No resuman en exceso la memoria agentífica: conserven las lecciones detalladas y su evidencia de soporte.
• Traten la entrega como una variable: calibren cuánta memoria inyectar según la capacidad del modelo y el presupuesto de tokens. No existe una talla única.
• Implementen recuperación por relevancia y priorización por soporte para reducir tokens sin sacrificar precisión en los modelos que no pueden procesar contexto enorme.
• Para modelos muy capaces, evaluar la inyección del conjunto consolidado puede ayudar; para opciones más económicas u on‑device, la selección por tarea suele ser más eficiente.

En mercados latinoamericanos, donde muchas soluciones deben balancear costos operativos, latencia y disponibilidad de modelos, esta opción de entrega selectiva permite escalar agentes con memoria sin que la factura de tokens crezca desmesuradamente.

Recomendaciones prácticas

1. Registrar y contar. Mantengan metadatos de soporte para cada lección desde el inicio.
2. Tipificar. Extraigan tipo y subtask para facilitar transferencia entre casos de uso locales (por ejemplo, integrar distintas aplicaciones bancarias o de e‑commerce típicas en la región).
3. Recuperación jerarquizada. Use un núcleo de alta confianza y añada lecciones por relevancia por tarea; reserve la inyección total solo para modelos con suficiente contexto.
4. Medir tokens y rendimiento por nivel de dificultad. Prioricen configuraciones que maximicen desempeño por token, no solo precisión absoluta.

Conclusión

ACE y ALTK‑Evolve concuerdan en la idea esencial: la memoria agentífica no debe comprimirse hasta perder evidencia. La diferencia crítica es cómo y cuánto se sirve esa memoria en inferencia. Elegir una estrategia de entrega consciente del modelo y del costo de tokens puede lograr la misma o mejor precisión con una fracción del consumo de tokens. Para equipos en América Latina que deben equilibrar presupuesto e impacto, esa decisión de diseño puede ser la que haga viable desplegar agentes LLM a escala.