Mayo 2026 · 11 min de lectura · Fran Olivares, fundador de OlivaresAI
La gestión de proyectos es mayormente trabajo de memoria. ¿Quién lleva este stream? ¿Qué acordamos sobre la ventana de migración? ¿Por qué bajamos de prioridad el rate limiter? ¿Cuándo bloquea la revisión legal el release? Un agente que tiene que volver a preguntar estas cosas cada mañana no es un agente — es un becario un poco más rápido. La forma de cambiar eso es darle al modelo una capa de memoria persistente que pueda leer y escribir entre turnos, poblada automáticamente desde la conversación. Esta guía recorre la arquitectura de referencia y el código de integración, usando la Claude API de Anthropic como LLM y la REST API de Alma como capa de memoria.
Tres razones estructurales. Primero, las entidades que un PM sigue (personas, decisiones, entregables, SLAs, riesgos) son por sí mismas duraderas — sobreviven a cualquier conversación concreta por definición. Segundo, el estilo conversacional es alta frecuencia y bajo esfuerzo: mensajes cortos de stand-up, aclaraciones rápidas, preguntas tipo «¿qué dijimos sobre X?». Cargar la rebanada correcta de contexto de forma barata importa. Tercero, el coste de olvidar es alto: una decisión perdida se convierte en un release perdido, una dependencia olvidada se convierte en un bloqueo.
Una conversación stateless con Claude gestiona bien una única sesión de planificación. En cuanto el usuario quiere continuidad («ayer acordamos…», «¿qué bloquea al equipo de auth esta semana?»), la conversación tiene que reproducir el historial completo en la ventana de contexto (caro, eventualmente imposible) o apoyarse en una capa de memoria fuera del modelo.
Cuatro piezas en movimiento:
messages.create del SDK de Anthropic con un system prompt consciente del proyecto. Tool use está habilitado para que el modelo pueda pedir entidades por nombre a la capa de memoria cuando lo necesite.stakeholder, decision, sla, risk) y una puntuación de importancia. Los episodios capturan stand-ups diarios comprimidos; los procedimientos capturan workflows recurrentes («cómo gestionamos los hotfixes»).Cinco categorías cubren la mayoría de equipos: stakeholder (personas con rol + responsabilidades), decision (qué se acordó, cuándo, por quién, con la justificación), sla (compromisos con otros equipos o clientes), risk (issues abiertos con responsable + mitigación), milestone (fecha objetivo + alcance + estado). Cada memoria lleva una puntuación de importancia para que el ensamblador priorice los items críticos en la recuperación.
La categoría no es solo organización — forma parte de la señal de recuperación. Cuando el usuario pregunta «¿qué decidimos?», el ensamblador pondera más alto las memorias de categoría decision. Cuando pregunta «¿quién está bloqueado?», las memorias de categoría risk suben. El ensamblado de contexto de Alma expone pesos de boost por categoría justo para este caso de uso.
Tres fases por mensaje del usuario. El pseudo-código de abajo usa Node.js con el SDK de Alma y el SDK de Anthropic, pero la misma forma funciona en Python o cualquier otro stack:
const { systemPrompt } = await alma.context.assemble({ query: userMessage, environmentId: projectId });const stream = anthropic.messages.stream({ model: 'claude-opus-4-7', system: systemPrompt, messages: [{ role: 'user', content: userMessage }] });await alma.memories.extract({ text: lastTurn, environmentId: projectId });La fase 3 corre en segundo plano — el usuario ve la respuesta en streaming inmediatamente y la extracción ocurre en el siguiente ~1 s sin bloquear. Las nuevas memorias se deduplican, las contradicciones se detectan contra entradas existentes y el almacén se mantiene limpio automáticamente. Referencia completa del SDK: @olivaresai/alma-sdk; equivalentes HTTP en la documentación de la REST API.
Usa los environments de Alma: un entorno por proyecto. Cada entorno tiene sus propias memorias, episodios, procedimientos y bloques Soul, completamente aislados de los demás. El agente pasa environmentId en cada llamada de memoria; la API hace cumplir el límite. Las queries cruzadas entre proyectos simplemente no son posibles sin un cambio explícito de entorno — que es el default correcto para una herramienta PM donde filtrar decisiones del proyecto A al proyecto B es un problema real.
Para agentes PM de equipo (múltiples humanos interactuando con el mismo agente), usa el recurso teams de Alma: cada equipo tiene memorias compartidas visibles para todos los miembros, más memorias por usuario para preferencias personales. El control de acceso basado en roles controla quién puede escribir qué.
Mensaje del usuario: «stand-up: equipo backend, Maria está desbloqueando la migración hoy, José está con el rate limiter; decidimos posponer el release GA al viernes porque legal sigue revisando el DPA». Flujo del agente:
Arqueología de decisiones. «¿Por qué bajamos de prioridad el rate limiter?» — el agente recupera la memoria de la decisión más el episodio que la rodea y la memoria del riesgo que referenciaba. Devuelve la respuesta con citaciones a los registros, para que el usuario pueda profundizar en la conversación si lo necesita.
Búsqueda de stakeholder. «¿Quién lleva la migración?» — consulta directa de memoria contra la categoría stakeholder, devuelve el registro. Si la respuesta es obsoleta (el rol cambió la semana pasada), la detección de contradicciones lo pilla en la próxima conversación que mencione al nuevo responsable.
Generación recurrente de informes. «Genera un informe de estado para el stream de auth de esta semana» — el agente ensambla una ventana de contexto de episodios, decisiones y riesgos etiquetados para ese stream y luego redacta el informe a partir de esa rebanada curada. Esto es significativamente más barato y preciso que pedir a Claude que resuma historial de chat en bruto.
Presupuestos de token por defecto en el ensamblador: ~2 K tokens para memorias, ~1 K para episodios, ~500 para procedimientos, ~500 para bloques Soul. Total ~4 K — muy por debajo del presupuesto de contexto de cualquier modelo y los aciertos de cache se amortizan a lo largo de la conversación. Si tu proyecto es pequeño (<100 memorias activas), puedes bajar más el presupuesto. Si es grande (10 K+ memorias), el ensamblador se queda en ~4 K porque la recuperación limita el número de registros incluidos incluso cuando el almacén es grande.
Dos cosas importan operativamente: los bloques Soul (la identidad del agente) deben cachearse como prefijo estable del system prompt para que las llamadas repetidas no vuelvan a pagar los input tokens; y el contexto dinámico (memorias + episodios) debe ir tras el breakpoint de cache para que cada llamada solo resuba la porción cambiada. La documentación de prompt caching de Anthropic cubre la colocación del breakpoint.
En un flujo típico de equipo PM (~20 mensajes/día por usuario, mayoritariamente stand-ups + aclaraciones), el coste marginal está dominado por las propias llamadas al LLM. La capa de memoria añade: una llamada de assemble (unos KB de lectura + recuperación, ~30 ms), una llamada de extract (Haiku, ~$0,001 por turno). Sobrecarga total de memoria al día por usuario activo: bastante menos de un centavo. Compara con el valor de que el equipo PM no pierda decisiones — y las cuentas son obvias.
El plan Starter ($14/mes) de Alma es el nivel de entrada e incluye la capa de memoria persistente. Regístrate en alma.olivares.ai, genera una API key en Settings y clona el starter del SDK desde la página de desarrolladores. Cablea el bucle de tres fases en el código de tu agente, apúntalo a un único proyecto de prueba y déjalo correr una semana. El almacén se poblará de forma natural a partir de las conversaciones; verás cómo decisiones, stakeholders y riesgos se acumulan sin entrada de datos manual. A partir de ahí solo es subir las categorías y afinar el ensamblador.
Lectura relacionada: Memoria persistente para IA: guía completa 2026 · Cómo dar memoria persistente a la IA · Arquitectura de memoria de tres capas · Documentación de ensamblado de contexto · Environments.