Construir agentes de IA con herramientas, memoria y autonomía controlada · Módulo 2: Capacidades y contexto
Gestionar plan, contexto y memoria
Arquitectura para distinguir estado, historial, plan, artifacts y memoria persistente y evitar contaminación o autoridad indebida del contexto.
Objetivo de aprendizaje
Construir estado y memoria versionables, aislados y con procedencia para sostener tareas largas sin usar el historial como fuente de verdad.
Un agente necesita contexto para decidir, pero «recordar todo» no es una estrategia. En tareas largas el historial crece, aparecen observaciones contradictorias y parte de la información deja de ser útil. La aplicación debe decidir qué contexto conservar, qué estado persistir y qué memoria permitir.
Distingue cinco conceptos
Estado de dominio Hechos confirmados del entorno.
Contexto de ejecución Información necesaria para el turno actual.
Historial Mensajes y tool results anteriores.
Plan Representación provisional de próximos pasos.
Memoria persistente Información que sobrevive a un run o sesión.
No los mezcles.
El estado no debe depender del resumen del modelo
Si una incidencia es closed, guarda ese estado estructuradamente.
No dependas de:
«En el resumen anterior parecía estar cerrada.»
La memoria generada puede perder condiciones.
Usa el plan como hipótesis
Un plan no es una orden irreversible.
Puede cambiar si:
- una tool falla;
- aparece evidencia nueva;
- el usuario modifica el objetivo;
- un recurso ya no existe.
Registra plan y revisiones cuando sean útiles para trazabilidad, pero no fuerces planificación explícita en cada tarea si solo añade tokens.
Construye contexto por prioridad
Orden típico:
- invariantes;
- objetivo;
- estado;
- evidencia;
- herramientas;
- historial relevante;
- contexto auxiliar.
El contexto es finito.
Anthropic destaca que context engineering para agentes consiste en gestionar el conjunto limitado de tokens disponible durante una trayectoria y diseñar herramientas que aporten observaciones útiles sin ruido.
Compacta con cuidado
Cuando el historial crece puedes:
- resumir;
- eliminar observaciones obsoletas;
- conservar referencias;
- persistir artifacts;
- dividir tarea;
- crear checkpoint.
Pero nunca compactes de forma que se pierdan:
- permisos;
- decisiones humanas;
- invariantes;
- IDs;
- efectos ejecutados;
- pendientes.
Memoria persistente: solo con una finalidad
Antes de guardar memoria pregunta:
- ¿qué mejora?
- ¿quién puede leerla?
- ¿cuánto dura?
- ¿cómo se corrige?
- ¿cómo se elimina?
- ¿qué fuente la creó?
OWASP identifica memory poisoning como riesgo: contenido malicioso persistido puede influir en sesiones futuras.
Por tanto, valida y aísla memoria.
Separa memoria del tenant
Una memoria compartida entre clientes es un riesgo grave.
Incluye:
- user_id;
- tenant_id;
- provenance;
- timestamp;
- scope;
- TTL.
No recuperes memoria solo por similitud semántica sin permisos.
Conserva artifacts fuera del chat
Para tareas largas es mejor guardar:
- informe;
- tabla;
- fichero;
- diff;
- checklist;
- checkpoint;
y referenciarlo por ID.
El agente no necesita reenviar todo el contenido en cada turno.
Detecta loops de planificación
Señales:
- repite la misma tool;
- reescribe el mismo plan;
- oscila entre dos acciones;
- vuelve a leer la misma evidencia.
El harness puede mantener un fingerprint de estados o tool calls.
Si se repite sin progreso, detén o escala.
Ejemplo
Un agente prepara una auditoría.
Estado:
- 12 documentos revisados;
- 3 pendientes;
- 2 incidencias abiertas.
Artifacts:
- tabla de hallazgos;
- notas de evidencia.
Plan:
- revisar 3;
- contrastar 2 incidencias;
- generar borrador.
No necesita guardar cada frase de razonamiento.
Usa memoria episódica y semántica con cuidado
Puede ser útil distinguir:
Episódica Hechos de ejecuciones previas:
- «en el run 123 falló la API».
Semántica Conocimiento consolidado:
- «el sistema X requiere autorización Y».
Pero esta clasificación no convierte automáticamente la información en fiable.
Toda memoria necesita:
- fuente;
- fecha;
- confianza;
- ámbito;
- política de actualización.
No almacenes razonamiento privado como memoria
El sistema necesita decisiones, evidencias y artifacts, no cadenas internas de razonamiento.
Guarda:
- resultado;
- motivo resumido;
- evidencia;
- acción.
Esto es más estable y auditable.
Diseña recuperación de memoria
Una memoria persistente puede recuperarse por:
- clave;
- contexto;
- similitud.
La similitud no debe saltarse permisos o vigencia.
Primero aplica scope y autorización; después relevancia.
Corrige memoria
Si el usuario o una fuente autorizada demuestra que un dato es incorrecto:
- marca superseded;
- conserva historia si se necesita;
- evita recuperarlo;
- registra corrección.
No sobrescribas sin trazabilidad cuando el cambio importe.
Reduce memoria cuando no aporta valor
Un agente que resuelve tickets independientes puede no necesitar memoria entre sesiones.
No introduzcas persistencia «porque los agentes tienen memoria».
Cada memoria aumenta:
- privacidad;
- seguridad;
- mantenimiento;
- riesgo de contaminación.
Ejercicio
Diseña un esquema para:
- run state;
- checkpoint;
- artifact;
- memory.
Incluye scopes, TTL, permisos y provenance.
Simula una memoria maliciosa y una memoria obsoleta. Define cómo se detectan y retiran.
Resultado de la lección
Debes terminar con un agente que puede trabajar durante múltiples pasos sin convertir el historial completo en su base de datos ni permitir que memoria no validada adquiera autoridad sobre el sistema.