Maggio 2026 · lettura 11 min · Fran Olivares, Founder di OlivaresAI
Il project management è soprattutto lavoro di memoria. Chi possiede questo stream? Cosa abbiamo concordato sulla finestra di migrazione? Perché abbiamo ridotto lo scope del rate limiter? Quando la revisione legale blocca il rilascio? Un agente che deve richiedere queste domande ogni mattina non è un agente: è uno stagista leggermente più veloce. Il modo in cui si cambia questo è dando al modello un livello di memoria persistente che può leggere e scrivere tra i turni, popolato automaticamente dalla conversazione. Questa guida illustra l'architettura di riferimento e il codice di integrazione, usando l'API Anthropic Claude come LLM e la REST API di Alma come livello di memoria.
Tre ragioni strutturali. Primo, le entità che un PM traccia (persone, decisioni, deliverable, SLA, rischi) sono esse stesse di lunga durata: sopravvivono a qualsiasi singola conversazione per definizione. Secondo, lo stile conversazionale è ad alta frequenza e basso sforzo: brevi messaggi di stand-up, chiarimenti rapidi, domande «cosa abbiamo detto su X?». Caricare la fetta giusta di contesto a buon mercato conta. Terzo, il costo del dimenticare è alto: una decisione persa diventa un rilascio mancato, una dipendenza dimenticata diventa un blocco.
Una conversazione Claude stateless gestisce bene una singola sessione di pianificazione. Non appena l'utente vuole continuità («ieri abbiamo concordato…», «cosa blocca il team auth questa settimana?»), la conversazione deve riprodurre l'intera cronologia nella finestra di contesto (costoso, alla fine impossibile) o affidarsi a un livello di memoria esterno al modello.
Quattro parti in movimento:
messages.create dall'SDK Anthropic con un system prompt consapevole del progetto. Tool use abilitato in modo che il modello possa chiedere al livello di memoria entità per nome quando serve.stakeholder, decision, sla, risk) e un punteggio di importanza. Gli episodi catturano gli stand-up giornalieri compressi; le procedure catturano workflow ricorrenti («il modo in cui gestiamo gli hotfix»).Cinque categorie coprono la maggior parte dei team: stakeholder (persone con ruolo + responsabilità), decision (cosa è stato concordato, quando, da chi, con la motivazione), sla (impegni verso altri team o clienti), risk (problemi aperti con owner + mitigazione), milestone (data obiettivo + scope + stato). Ogni memoria porta un punteggio di importanza in modo che l'assemblatore possa dare priorità agli elementi ad alto rischio nel recupero.
La categoria non è solo per organizzazione: è parte del segnale di recupero. Quando l'utente chiede «cosa abbiamo deciso?», l'assemblatore pesa di più le memorie di categoria decision. Quando chiede «chi è bloccato?», le memorie di categoria risk salgono. L'assemblaggio del contesto di Alma espone pesi di boost per categoria esattamente per questo caso d'uso.
Tre fasi per messaggio utente. Lo pseudo-codice sotto usa Node.js con l'SDK Alma e l'SDK Anthropic, ma la stessa forma funziona in Python o qualsiasi altro 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 viene eseguita in background: l'utente vede immediatamente la risposta in streaming, e l'estrazione avviene in circa 1 s senza bloccare. Le nuove memorie vengono deduplicate, le contraddizioni vengono rilevate rispetto alle voci esistenti e l'archivio rimane pulito automaticamente. Riferimento SDK completo: @olivaresai/alma-sdk; equivalenti HTTP nella documentazione REST API.
Usi gli ambienti di Alma: un ambiente per progetto. Ogni ambiente ha le proprie memorie, episodi, procedure e blocchi Soul, completamente isolati dagli altri. L'agente passa environmentId su ogni chiamata di memoria; l'API impone il confine. Le query cross-progetto semplicemente non sono possibili senza un cambio di ambiente esplicito, che è il default giusto per uno strumento PM in cui far trapelare decisioni dal progetto A al progetto B è un problema reale.
Per agenti PM team-wide (più umani che interagiscono con lo stesso agente), usi la risorsa teams di Alma: ogni team ha memorie condivise visibili a tutti i membri, più memorie per utente per preferenze personali. Il controllo degli accessi basato sui ruoli controlla chi può scrivere cosa.
Messaggio utente: «stand-up: team backend, Maria sblocca la migrazione oggi, José sul rate limiter; abbiamo deciso di spostare il rilascio GA a venerdì perché il legale sta ancora rivedendo il DPA». Il flusso dell'agente:
Archeologia delle decisioni. «Perché abbiamo ridotto lo scope del rate limiter?»: l'agente recupera la memoria della decisione più l'episodio circostante e la memoria del rischio a cui faceva riferimento. Restituisce la risposta con citazioni ai record, in modo che l'utente possa approfondire nella conversazione se necessario.
Ricerca di stakeholder. «Chi possiede la migrazione?»: query di memoria diretta sulla categoria stakeholder, restituisce il record. Se la risposta è obsoleta (il ruolo è cambiato la settimana scorsa), il rilevamento delle contraddizioni la cattura nella conversazione successiva che menziona il nuovo owner.
Generazione di report ricorrenti. «Genera un report di stato per lo stream auth questa settimana»: l'agente assembla una finestra di contesto di episodi, decisioni e rischi taggati per quello stream, poi redige il report da quella fetta curata. Questo è significativamente più economico e accurato che chiedere a Claude di riassumere la cronologia chat grezza.
Budget di token predefiniti nell'assemblatore: ~2 K token per memorie, ~1 K per episodi, ~500 per procedure, ~500 per blocchi Soul. Totale ~4 K — ben al di sotto del budget di contesto di qualsiasi modello, e gli hit di cache si ammortizzano lungo la conversazione. Se il Suo progetto è piccolo (<100 memorie attive), può abbassare ulteriormente il budget. Se è grande (10 K+ memorie), l'assemblatore rimane a ~4 K perché il recupero limita il numero di record inclusi anche quando l'archivio è grande.
Due cose contano operativamente: i blocchi Soul (l'identità dell'agente) dovrebbero essere memorizzati nella cache come un prefisso stabile del system prompt in modo che le chiamate ripetute non ripaghino i token di input; e il contesto dinamico (memorie + episodi) dovrebbe stare dopo il breakpoint della cache in modo che ogni chiamata ri-carichi solo la porzione modificata. La documentazione sul prompt caching di Anthropic copre il posizionamento del breakpoint.
Su un tipico flusso di team PM (~20 messaggi/giorno per utente, prevalentemente stand-up + chiarimenti), il costo marginale è dominato dalle chiamate LLM stesse. Il livello di memoria aggiunge: una chiamata assemble (pochi KB di lettura + recupero, ~30 ms), una chiamata extract (Haiku, ~$0,001 per turno). Overhead totale di memoria al giorno per utente attivo: ben sotto un centesimo. Confronti con il valore del team PM che non perde decisioni, e la matematica è ovvia.
Il piano Starter di Alma ($14/mese) è il livello di ingresso e include il livello di memoria persistente. Si registri su alma.olivares.ai, generi una API key in Impostazioni e cloni l'SDK starter dalla pagina sviluppatori. Cabli il loop in tre fasi nel codice del Suo agente, lo punti su un singolo progetto di test e lo esegua per una settimana. L'archivio si popolerà naturalmente dalle conversazioni; vedrà decisioni, stakeholder e rischi accumularsi senza inserimento dati manuale. Da lì è solo questione di aumentare le categorie e regolare l'assemblatore.
Letture correlate: Memoria persistente per l'AI: guida completa 2026 · Come dare memoria persistente all'AI · Architettura di memoria a tre livelli · Documentazione assemblaggio del contesto · Ambienti.