Agentic AI e LangGraph per workflow B2B
Un agent che sa chiamare tool non è automaticamente un prodotto. Nel B2B, agentic AI significa workflow durevoli: leggere contesto, decidere, chiamare API, attendere umani, ritentare i failure, lasciare un audit trail. Framework come LangGraph aiutano a modellarlo come grafo esplicito con stato, branch e interrupt invece di un prompt loop fragile. Questa guida è per founder e lead engineering che mettono agent dentro SaaS o tool interni. Copre quando gli agent battono i chatbot, design del grafo, permessi, human-in-the-loop, osservabilità e failure mode. Si abbina a RAG in produzione quando il retrieval è un nodo tool, e a integrazione ERP e osservabilità quando gli agent toccano sistemi che muovono soldi.
Agent vs chatbot vs automazione classica
Usa un chatbot quando il lavoro è Q&A con eventuali citazioni. Usa automazione deterministica (regole, BPM, script) quando il path è noto e non deve inventare step. Usa un agent quando il path richiede giudizio sui tool: classificare intent, raccogliere campi mancanti, scegliere quale API, fermarsi per approvazione, riprendere. I design stile LangGraph brillano quando servono checkpoint, branching, cicli (retry / clarify) e interrupt umani senza perdere stato. Non wrappare ogni cron job in un LLM. Gli agent aggiungono costo, latenza e nuovi failure mode; pagano quando l'ambiguità è reale e i tool sono ben vincolati.
- Chat: risposte grounded, senza side effect
- Automazione: path fisso, SLA forti
- Agent: uso tool con branch e gate di approvazione
- Hybrid: l'agent drafta, l'automazione esegue dopo sign-off
Design del grafo: stato, nodi, edge
Modella il workflow come nodi con uno state object tipizzato: goal utente, tenant, campi raccolti, risultati tool, storia decisioni, stato approvazione. Preferisci nodi piccoli con una responsabilità a un mega-prompt che fa tutto. Gli edge codificano regole di business reali: 'se importo > soglia → nodo approvazione', 'se soft-fail ERP → retry con backoff', 'se RAG vuoto → chiedi chiarimento'. Tieni i side effect irreversibili in nodi dedicati con chiavi di idempotenza. Persisti lo stato ai checkpoint così un crash a metà volo può riprendere. La memoria chat effimera non basta per processi B2B di ore.
- Separa nodi plan / retrieve / act / verify
- Conserva correlation ID su ogni chiamata tool
- Rendi i nodi side-effect idempotenti e replay-safe
- Versiona le definizioni di grafo come contratti API
Tool, permessi e least privilege
Ogni tool è un'API con blast radius. Esponi tool stretti ('get_order_status', 'create_draft_ticket') non 'run_arbitrary_sql'. Lega i tool al principal autenticato e al tenant, mai a un service role god-mode per comodità. Allinea i permessi a SSO e identity. L'agent eredita ciò che l'utente può fare; l'impersonation di supporto deve essere auditata. Valida gli argomenti tool con schema. Rifiuta importi fuori range, plant ID sconosciuti e write fuori dai resource set ammessi prima che la chiamata HTTP esca dal tuo confine.
Human-in-the-loop come nodo di prima classe
I buyer enterprise si aspettano approvazione per azioni irreversibili: cambio prezzi, mass email, post ERP, grant di accesso. Progetta nodi interrupt con payload chiaro: cosa succederà, perché, evidenze, e approve / reject / edit. Il comportamento di timeout deve essere esplicito: escalate, cancel o park. Hang silenziosi distruggono fiducia. Dopo l'approvazione, continua dal checkpoint senza chiedere al modello di reinventare il piano. Gli umani editano lo state; il grafo riprende.
- Definisci quali azioni richiedono sempre un umano
- Mostra citazioni o evidenze tool sulla card di approvazione
- Audita chi ha approvato e cosa è cambiato
- Permetti approve parziale (edita campi, poi continua)
RAG come tool dentro il grafo
Tratta il retrieval come un nodo con filtri e confidence, non come stuffing ambientale del prompt. L'agent deve decidere quando cercare, poi groundare gli step successivi sulle fonti restituite. Segui le pratiche RAG in produzione per tenancy e evaluation. Un agent che recupera la policy del tenant sbagliato è un incidente di security, non un'allucinazione carina.
Failure mode tipici dei sistemi agentici
Loop: il modello ritenta per sempre. Limita le iterazioni e forza escalate. Write parziali: tool A ok, tool B fail. Compensa o saga. Allucinazione tool: endpoint o ID inventati. Schema stretti e allowlist. Prompt injection via doc recuperati o testo ticket: tratta testo non trusted come dati, non come istruzioni. Esaurimento budget: cap di token o tool-call per run. State avvelenato: campi intermedi sbagliati che inquinano nodi successivi. Valida le transition di state come qualsiasi workflow engine. Sono rischi di delivery da mettere in stime di progetto e production readiness.
Osservabilità e evaluation per gli agent
Traccia ogni run: sequenza nodi, latenza tool, uso token, approvazioni, esito finale. Correlalo a tenant e journey ID di business così il support può replayare 'perché questa bozza ordine è fallita'. Valuta offline con scenari scriptati: happy path, campi mancanti, outage tool, tentativi injection, reject di approvazione. Online, campiona run per violazioni di policy e loop inutili. Collega le metriche alle aspettative SLA: agent che mancano le deadline servono path di escalation come ogni altra automazione.
- Persisti trace complete di run con policy di retention
- Alerta su hit del cap iterazioni e spike errori tool
- Suite di regressione sui bump di versione grafo
- Red-team prompt injection via ticket e documenti
Delivery MVP con contractor
Scope di un vertical journey end-to-end: es. 'intake email support → classifica → bozza ticket → approve umano → crea nel sistema'. Non-goal: swarm multi-agent, browsing open-ended, write ERP non supervisionati. I criteri di acceptance includono tool in allowlist, test ACL, UX approvazione, replay da checkpoint e runbook. Collega a assunzione contractor e scope MVP. Preferisci grafi espliciti a 'il modello si regolerà' per qualsiasi cosa che tocchi system of record di produzione.
Prossimi passi
Disegna il workflow su una lavagna con i side effect in rosso. Se non sai nominare approvazione e rollback per ogni nodo rosso, non sei pronto per un agent non supervisionato. Vedi RAG in produzione, altre risorse, case study, prenota una call o contatti per review di un design agentico prima che tocchi ERP o dati cliente.
Domande frequenti
Serve proprio LangGraph?
Serve una state machine o un grafo esplicito con checkpoint, interrupt e confini tool tipizzati. LangGraph è un'opzione solida nell'ecosistema Python/JS; il requisito di prodotto sono workflow durevoli e auditabili, non un brand particolare.
Un agent può chiamare tanti tool in sicurezza?
Sì se i tool sono stretti, permission-checked, validati a schema, rate-limited e i side effect sono idempotenti con gate umani sulle azioni irreversibili. Tool ampi tipo 'fai qualsiasi cosa' sono come nascono gli incidenti.
In cosa differisce da un motore BPM tradizionale?
Il BPM codifica path noti; gli agent gestiscono ambiguità e linguaggio ai bordi. Molti sistemi B2B combinano entrambi: nodi LLM per classificazione e drafting, nodi deterministici per post e billing.
Cosa misurare prima di espandere il pilot?
Task success rate, rate di override umano, media tool call per successo, conteggio incident da write sbagliate e time-to-resolution vs il processo manuale precedente. I rating vanity della chat non bastano.