Cosa c'è oggi, cosa manca e in che ordine ha senso affrontarlo. Ogni voce è pensata per essere un'aggiunta, non una riscrittura.
Fatto (v0.1)
- Supervisore che sceglie a runtime quale agente coinvolgere, con routing vincolato agli agenti realmente esistenti
- Agenti dichiarativi in YAML, ricaricabili senza riavviare il processo
- Tool con registro estensibile e memoria controllata dagli agenti
- Quattro livelli di memoria: checkpoint, storico, riassunto progressivo, fatti a lungo termine
- Tracing proprietario con span annidati, token e costi reali per modello
- API REST + streaming SSE
- Console web: sezione Osservabilità e sezione Workflow
- Test del backend che non richiedono credenziali AWS
Prossimi passi
1. Autenticazione e multi-utenza
Oggi user_id arriva dal client. Serve un'identità verificata (Supabase Auth è
la scelta naturale visto il database), policy RLS per utente e propagazione del
user_id reale a memoria e tracing.
2. Modifica della configurazione dalla UI
La vista Workflow oggi legge. Il passo successivo è scrivere: modificare prompt,
modello e tool di un agente dal pannello laterale, con salvataggio su
agents.yaml (o su tabella dedicata), versionamento e possibilità di tornare
indietro. È l'estensione più richiesta e la struttura è già predisposta:
export_topology() espone tutto ciò che serve.
3. Controllo dei costi
Budget per utente e per giorno, blocco o passaggio automatico a un modello più
economico al superamento della soglia, alert. I dati ci sono già tutti in runs.
4. Ricerca semantica nella memoria
Embedding con Amazon Titan e pgvector, mantenendo il trigram come fallback.
Il punto di intervento è la sola query in long_term.recall()
(vedi MEMORIA.md).
5. Human-in-the-loop
Sospensione della run con interrupt, coda di approvazioni nella UI, ripresa con
Command(resume=...). Il checkpointer rende la cosa già possibile: manca
l'interfaccia.
6. Valutazione della qualità
Un dataset di casi di prova, esecuzione periodica, confronto fra versioni di prompt e modelli. Senza questo, migliorare i prompt resta un esercizio a sensazione.
7. Esecuzione parallela
Oggi il supervisore delega a un agente per volta. Per compiti indipendenti
(ricerca su più fonti) LangGraph supporta il fan-out con Send: più veloce, e
il modello dati del tracing lo regge già.
8. Distribuzione
Dockerfile per backend e frontend, healthcheck, migrazioni automatiche all'avvio, deploy su un ambiente gestito.
Debito tecnico noto
| Voce | Nota |
|---|---|
create_react_agent | deprecato in LangGraph 1.x a favore di langchain.agents.create_agent; migrare prima della 2.0, l'unico punto da toccare è app/agents/builder.py |
| Ritenzione delle tracce | nessuna cancellazione automatica: su volumi alti serve una politica di retention |
| Prezzi dei modelli | scritti a mano in models.yaml, vanno verificati e aggiornati periodicamente |
| Riassunto | strategia a finestra fissa: su conversazioni molto lunghe conviene valutare una compressione gerarchica |
| Test end-to-end | i test coprono struttura e API, non l'inferenza reale su Bedrock |