La maggior parte delle demo di agenti si ferma alla generazione di un piano plausibile. Questo tutorial di MarkTechPost parte invece da dove quelle demo si fermano: dare all’agente una memoria persistente, un contesto operativo e un posto dove riscrivere ciò che è successo. Lo scenario è fittizio ma ispirato all’economia reale delle operazioni di un evento: il MongoDB Open, un torneo di tennis, al sesto giorno di gioco, con pioggia in arrivo, capacità di hospitality al coperto limitata e due percorsi visitatore da proteggere: Mikiko, alla prima visita, e Nina, ospite premium con aspettative e uno storico che l’agente può recuperare.
Il punto tecnico interessante non è il generatore di piani, ma l’idea che un agente utile deve percepire cosa è cambiato, recuperare il contesto giusto, agire e persistere il risultato mentre c’è ancora una finestra utile per intervenire. Se la pioggia è a 20 minuti e i posti al coperto si stanno riempiendo, non serve una dashboard post-evento.
MongoDB Atlas come unico backend
L’architettura mette Atlas al centro sia come layer operativo sia come layer di memoria. Record operativi, memoria semantica, embedding vettoriali, documenti visuali e azioni dell’agente vivono tutti nello stesso data layer, senza dover sincronizzare i dati in un secondo vector database o riconciliare ciò che dice la memoria con lo stato del sistema operativo. La demo usa quattro layer di stato: record operativi (ospiti, visite, stato del venue, eventi meteo, prenotazioni, metriche, azioni), memoria semantica in una collection memory_store con embedding Voyage e Atlas Vector Search, documenti visuali con embedding multimodali, e lo stato dell’agente con i checkpoint di LangGraph.
Retrieval, Vision RAG e loop LangGraph
Il retrieval combina la ricerca vettoriale con uno scoring lessicale deterministico sul testo delle memorie: utile perché le query operative mescolano intento semantico e termini esatti come “rain delay” o “dinner reservation”. Per la conoscenza che non è testo (mappe di accessibilità, matrici allergeni, schede di risposta al meteo), il Vision RAG recupera il documento visuale più rilevante da Atlas e lo passa a Claude Vision insieme alla domanda.
Il grafo LangGraph segue cinque nodi: perceive (recupera memorie e stato operativo), plan (chiama Claude con il contesto recuperato per azioni specifiche per persona), hitl_gate (approvazione automatica in V1, con il punto dove inserire l’approvazione umana in produzione), act (esegue tool che aggiornano Atlas) e reflect (scrive nuove inferenze nella memoria semantica).
Cosa tenere presente
Lo stack è una FastAPI con MongoDB Atlas, eseguibile in locale (Python 3.12, uv) e deployabile su Vercel. Il repo va trattato come demo di riferimento, non come piattaforma di produzione: manca l’autenticazione, il rate limiting, l’isolamento tenant e una suite CI, e il percorso completo dell’agente LangGraph resta uno script di validazione, non un endpoint pubblico.
- Tenere memoria operativa, semantica e documenti visuali in un solo backend evita la frammentazione tra sistemi separati.
- L’hybrid search unisce similarità vettoriale e scoring lessicale, adatto a query che mescolano concetti e termini operativi esatti.
- Il loop perceive-plan-act-reflect chiude il cerchio scrivendo l’esito come memoria per la prossima situazione simile.
Fonte: Build an Agentic Event Venue Operator with MongoDB Atlas, Voyage, and LangGraph — https://www.marktechpost.com/2026/07/17/build-an-agentic-event-venue-operator-with-mongodb-atlas-voyage-and-langgraph/
Hai qualcosa da aggiungere? Unisciti alla discussione.