Sessions, Memory & Skills

Los LLMs son inherentemente stateless: todo su razonamiento ocurre dentro de la context window de una única llamada de API. Nada de lo anterior existe para el modelo — a menos que alguien lo coloque ahí. La Context Engineering es el proceso de armar y gestionar dinámicamente la información dentro de la context window para habilitar agentes stateful e inteligentes.

Es la evolución natural del Prompt Engineering: en lugar de pulir una instrucción estática, el ingeniero de contexto orquesta el payload completo — seleccionando, resumiendo e inyectando estratégicamente distintos tipos de información en cada turno, con máxima relevancia y mínimo ruido. Sistemas externos (RAG, session stores, memory managers) gestionan el contexto; el framework lo orquesta todo.

Todo lo que el modelo "ve" en un turno cabe en tres categorías. El armado es dinámico: las memorias no son estáticas, los few-shot examples deben ser relevantes para la tarea (no hardcoded) y el RAG responde a la query inmediata.

El histórico de conversación crece sin parar. Ventanas más grandes soportan transcripciones largas, pero: el costo y la latencia suben con cada token y aparece el context rot — la atención del modelo a la información crítica disminuye a medida que el contexto crece. La solución es mutar el histórico dinámicamente: sumarización, poda selectiva, compactación.

Una session encapsula el histórico de diálogo y la working memory de una conversación continua: un registro autocontenido ligado a un usuario específico. Un usuario puede tener múltiples sessions — logs distintos y desconectados entre sí.

El agente anexa events y muta el state según la lógica del negocio. La estructura refleja la lista de objetos Content de la Gemini API — cada Content tiene role (user/model) y parts (texto, imágenes, tool calls): un turno = un Event.

# o histórico é uma lista de Content: role + partsresponse = client.models.generate_content( model="gemini-2.5-flash", contents=[{"role": "user",  "parts": [{"text": "Quero ir a Paris em novembro"}]},{"role": "model", "parts": [{"text": "Direto ou com escala?"}]},{"role": "user",  "parts": [{"text": "Direto, por favor"}]}, ], )

El framework es un traductor universal entre tu código y el LLM: mantiene el histórico y el state, construye las requests, parsea y almacena las respuestas. Para Gemini, la request es List[Content] — cada Content con role y parts. El framework mapea tu objeto interno (ej. un Event de ADK) a role/parts antes de la llamada. Esta abstracción desacopla la lógica del agente del LLM específico — y previene el vendor lock-in.

session = Session( id="s_771", events=[event_1, event_2, event_3],  # histórico cronológicostate={"cart_items": [...]},          # working memory separada)

class AgentState(TypedDict): messages: Annotated[list, add_messages]  # históricocart: dict                                 # dados de trabalho# o grafo pode reescrever o state a cada passo (ex.: compactar)

Hay un trade-off crítico: la misma abstracción que desacopla al agente del LLM lo aísla de agentes de otros frameworks. El aislamiento se solidifica en la capa de persistencia — el schema de la base queda acoplado a los objetos internos del framework y el registro se vuelve no portable. Un agente LangGraph no puede interpretar nativamente los objetos Session/Event de un agente ADK: handoff seamless, imposible.

En una arquitectura simple, la session es un log inmutable. A medida que escala, el uso de tokens explota — y cuatro limitaciones golpean a las aplicaciones sensibles a la latencia:

Las tres estrategias de compactación

# limita o contexto enviado ao LLM, sem modificar o log persistidoplugin = ContextFilterPlugin(num_invocations_to_keep=10)# ou: compactação agendada de eventosconfig = EventsCompactionConfig(compaction_interval=5, overlap_size=1)

Mecanismos de trigger

Sessions y memory viven en simbiosis: las sessions son la fuente primaria para generar memorias, y las memorias son la estrategia clave para gestionar el tamaño de las sessions. Una alimenta a la otra, en un ciclo continuo.

Una memoria es un snapshot de información extraída y significativa de una conversación o fuente: una representación condensada que preserva el contexto importante, persistida entre sesiones para una experiencia continua y personalizada.

Cuatro capacidades que un sistema de memoria habilita

Las cinco capas colaborando en cada turno

El retrieval de memoria se compara frecuentemente con RAG, pero los principios arquitectónicos son diferentes: RAG lidia con datos externos estáticos; Memory, con contexto dinámico y específico del usuario. Son complementarios — y un agente verdaderamente inteligente necesita ambos.

Las memorias se clasifican por cómo se almacenan y capturan — y trabajan juntas para un entendimiento rico y contextual. Regla de oro: las memorias son descriptivas, no predictivas.

Anatomía de una memoria

Una 'memoria' es una pieza atómica de contexto devuelta por el memory manager y usada por el agente como contexto. Aunque el schema exacto puede variar, una memoria generalmente consta de dos componentes: content y metadata.

Declarative × Procedural (ciencia cognitiva)

Patrones de organización

Arquitecturas de storage

Mecanismos de creación

Alcance: a quién describe la memoria

Memoria multimodal: origen × contenido

from google.genai import types client = vertexai.Client(project=..., location=...) response = client.agent_engines.memories.generate( name=agent_engine_name, direct_contents_source={"events": [{"content": types.Content( role="user", parts=[ types.Part.from_text("This is context about the multimodal input."), types.Part.from_bytes(data=CONTENT_AS_BYTES, mime_type=MIME_TYPE), types.Part.from_uri(file_uri="file/path/to/content", mime_type=MIME_TYPE) ] )}]}, scope={"user_id": user_id})

La generación transforma autónomamente datos conversacionales raw en insights estructurados y significativos — un pipeline ETL dirigido por LLM (Extract, Transform, Load). Eso es lo que distingue a los memory managers de los RAG engines y las bases de datos tradicionales: en lugar de que el dev especifique operaciones de base manualmente, el LLM decide cuándo agregar, actualizar o fusionar memorias — abstrayendo la complejidad de gestionar contenido, encadenar llamadas y correr servicios en background.

memories.generate( scope={"user_id": "u_8123"}, direct_contents_source=session_events,   # matéria-prima rawconfig={"wait_for_completion": False},   # assíncrono, em background)

La pregunta fundamental de la extracción es: "¿qué información de esta conversación es lo bastante significativa para volverse memoria?" No es sumarización simple — es filtrado inteligente y dirigido: separar la señal (hechos, preferencias, metas) del ruido (cortesías, relleno).

"Significativo" no es universal — lo define el propósito del agente. Un agente de soporte al cliente extrae números de pedido y problemas técnicos; un coach de bienestar extrae metas de largo plazo y estados emocionales. Personalizar esa definición es la clave de un agente eficaz.

Cómo el LLM sabe qué extraer

La mayoría de los managers funcionan out-of-the-box con temas comunes (preferencias, hechos clave, metas) — y muchos permiten temas personalizados. El ejemplo del paper: una conversación sobre una cafetería genera dos memorias de feedback — "el café de filtro estaba tibio" y "la música estaba demasiado alta".

config = MemoryGenerationConfig( memory_topics=[ ManagedTopicEnum.USER_PERSONAL_INFO,          # tópico built-inCustomMemoryTopic( name="business_feedback", description="feedback about the coffee shop", ), ], generate_memories_examples=[...],                  # few-shot: conversa → fatos)

La consolidación integra información nueva en una base de conocimiento coherente, precisa y evolutiva. Es la etapa más sofisticada: sin ella, la memoria se vuelve un log ruidoso, contradictorio y poco fiable. Esta "auto-curación" gestionada por LLM es lo que eleva al memory manager más allá de una base de datos simple.

Los cuatro problemas que resuelve

El proceso en tres pasos

"Garbage in, garbage out" es aún más crítico para los LLMs: aquí es "garbage in, confident garbage out". Para decisiones confiables y una consolidación eficaz, el agente debe evaluar críticamente la calidad de sus propias memorias — y la fiabilidad deriva de la provenance: el registro detallado de origen e historial.

Linaje durante la gestión

La confianza evoluciona — y la poda es activa

La confianza no es estática: crece con la corroboración (múltiples fuentes fiables consistentes) y decae con la edad y el conflicto. El memory pruning (olvido activo) identifica y descarta memorias que dejaron de ser útiles — por decaimiento temporal (una reunión de hace 2 años vale menos que la de la semana pasada), baja confianza (una inferencia débil nunca corroborada) o irrelevancia (detalles triviales antiguos frente a las metas actuales). Consolidación reactiva + poda proactiva = base de conocimiento curada, no un log creciente de todo.

Los memory managers automatizan extracción y consolidación después de que la generación se dispara — pero quien decide cuándo intentar generar es el agente. Es una elección arquitectónica crítica: balancear data freshness contra costo computacional y latencia.

Estrategias de trigger

Memory-as-a-tool: el agente decide

En el enfoque más sofisticado, la generación se expone como una herramienta (ej. create_memory) cuya definición describe qué tipos de información son significativos. El agente analiza la conversación y llama a la herramienta autónomamente cuando identifica algo que vale la pena persistir — transfiriendo la responsabilidad de identificar lo "significativo" del memory manager al agente/dev.

def generate_memories(tool_context):# opção 1: histórico completo da sessionmemory_service.add_session_to_memory(tool_context.session)# opção 2: só o último turno, assíncronomemories.generate(..., config={"wait_for_completion": False}) runner = Runner(agent=agent, memory_service=VertexAiMemoryBankService())

# aqui o AGENTE extrai (extract_memories) e envia ao Memory Bank# apenas para CONSOLIDAR com as memórias existentesmemories = extract_memories(direct_memories_source={"fact": query}) memory_bank.store(memories)  # consolidação delegada ao serviço

Background, siempre

La estrategia de retrieval depende de la organización: un structured user profile es un lookup simple (el perfil entero o un atributo); una collection es un problema de búsqueda complejo — encontrar la información más pertinente en un pool grande y poco estructurado.

El retrieval eficaz es crucial: memorias irrelevantes confunden al modelo y degradan la respuesta; el contexto perfecto produce una interacción notablemente inteligente. El desafío central es balancear utilidad con un presupuesto de latencia estricto.

Las tres dimensiones del scoring

Técnicas de precisión (y su costo)

Timing: cuándo buscar

# Option 1: PreloadMemoryTool embutida — busca por similaridade em todo turnoagent = LlmAgent( ..., tools=[adk.tools.preload_memory_tool.PreloadMemoryTool()] )# Option 2: callback customizado — mais controle sobre como as memórias são buscadasdef retrieve_memories_callback(callback_context, llm_request): user_id = callback_context._invocation_context.user_id app_name = callback_context._invocation_context.app_name response = client.agent_engines.memories.retrieve( name="projects/.../locations/.../reasoningEngines/...", scope={"user_id": user_id, "app_name": app_name}) memories = [f"* {memory.memory.fact}" for memory in list(response)]if not memories:return  # nenhuma memória para acrescentar às System Instructions# anexa as memórias formatadas às System Instructionsllm_request.config.system_instruction += "\nHere is information that you have about the user:\n"llm_request.config.system_instruction += "\n".join(memories) agent = LlmAgent( ..., before_model_callback=retrieve_memories_callback, )

# Option 1: LoadMemoryTool embutida — o agente decide quando buscaragent = LlmAgent( ..., tools=[adk.tools.load_memory_tool.LoadMemoryTool()], )# Option 2: tool customizada — descreva que tipos de informação podem estar disponíveisdef load_memory(query: str, tool_context: ToolContext):"""Retrieves memories for the user. The following types of information may be stored for the user: * User preferences, like the user's favorite foods. ..."""# busca memórias por similaridaderesponse = tool_context.search_memory(query)return response.memories agent = LlmAgent( ..., tools=[load_memory], )

La posición influye en el razonamiento del LLM, los costos operativos y la calidad de la respuesta. En la práctica, la estrategia híbrida funciona mejor: system prompt para memorias estables/globales (el perfil del usuario, siempre presente); dialogue injection o memory-as-a-tool para memorias transitorias/episódicas (relevantes solo para el contexto inmediato).

Memorias en las System Instructions

Anexar memorias al system prompt con un preámbulo les da alta autoridad y separa el contexto del diálogo — ideal para información estable y global. Típicamente vía template (ej. Jinja) con un bloque <MEMORIES> iterando sobre retrieved_memory.memory.fact.

from jinja2 import Template template = Template("""{{ system_instructions }}<MEMORIES> Here is some information about the user:{% for retrieved_memory in data %}* {{ retrieved_memory.memory.fact }}{% endfor %}</MEMORIES> """) prompt = template.render( system_instructions=system_instructions, data=retrieved_memories )

Memorias en el Conversation History

Inyectando directamente en el diálogo — antes del histórico completo o justo antes de la última query del usuario. Riesgos: ruido (más tokens, confusión si son irrelevantes) y dialogue injection (el modelo trata la memoria como algo realmente dicho en la conversación). Cuidado con la perspectiva: si usas role "user" con memorias user-level, escribe en primera persona. Caso especial: retrieval vía tool calls — las memorias llegan como tool output.

def load_memory(query: str, tool_context):"""Search the user's long-term memories."""response = tool_context.search_memory(query)return response.memories  # entra no contexto como tool output

¿Y las memorias procedimentales?

El paper se enfocó en declarative — reflejo del mercado comercial actual, cuyas plataformas están arquitecturadas para extraer/almacenar/recuperar el "qué". Pero almacenar el "cómo" no es un problema de information retrieval — es un problema de reasoning augmentation, con su propio ciclo de vida:

La evaluación de memoria es un proceso de múltiples capas: verificar que el agente recuerde las cosas correctas (calidad), encuentre las memorias cuando las necesita (retrieval) y que usarlas realmente ayude a lograr objetivos (task success). En la academia, benchmarks reproducibles; en la industria, impacto directo en el agente de producción.

Del prototipo a producción, el foco cambia a concerns enterprise-grade: escalabilidad, resiliencia y seguridad. La regla número uno: desacoplar el procesamiento de memoria de la lógica principal — la UX nunca puede ser bloqueada por generación cara.

Concurrencia, fallas y escala global

Privacidad y riesgos de seguridad

Las memorias derivan de — e incluyen — datos del usuario. Piensa en un archivo corporativo seguro gestionado por un archivista profesional: preserva conocimiento valioso mientras protege a la empresa.

El viaje de un turno conversacional a inteligencia persistente está gobernado por la Context Engineering — armar dinámicamente histórico, memorias y conocimiento externo en la context window. Depende de la interacción de dos sistemas distintos e interconectados: