Domain Knowledge Base - AI Agents
Come funziona il dominio, prima di scrivere una riga di codice? Scegli un documento dall'albero a sinistra: ogni pagina spiega una parte del modello.
Regole di Business - AI Agents
Questo documento elenca le regole di business fondamentali del dominio AI Agents, identificate con codice univoco BR-NNN. Ogni regola è technology-independent e descrive un vincolo invariante sul comportamento di un sistema agentico.
---
BR-001 - Ogni Run deve avere una condizione di arresto
Codice: BR-001
Nome: Limite massimo di iterazioni e budget per ogni esecuzione
Descrizione: Ogni Run di un Agente deve definire almeno una condizione di arresto esplicita: numero massimo di Step (iterazioni), budget di token, budget di tempo o costo monetario. Un agente non può eseguire un ciclo percezione-decisione-azione illimitato.
Motivazione: Prevenire loop infiniti, esaurimento del budget e costi incontrollati (il rischio principale di un'architettura agentica).
Priorità: CRITICA
Attori: Orchestratore, Operatore
Violazione: la Run viene forzata in stato FAILED con motivo max_iterations_exceeded / budget_exceeded.
Tracciabilità: INV-02; agent-run-lifecycle.md; ReAct (arXiv:2210.03629).
---
BR-002 - Idempotenza delle Tool Call con effetti collaterali
Codice: BR-002
Nome: Le azioni con side-effect devono essere sicure al retry
Descrizione: Ogni Tool che produce effetti collaterali esterni (scrittura su DB, invio email, pagamento) deve supportare un meccanismo di idempotenza (es. idempotency_key) affinché un retry dell'Agente dopo un timeout non duplichi l'effetto.
Motivazione: Gli agenti ritentano le azioni; senza idempotenza un retry causa effetti duplicati (doppio ordine, doppia email).
Priorità: ALTA
Attori: Tool Executor, Orchestratore
Tracciabilità: INV-06; tool-invocation.md Flusso Alternativo.
---
BR-003 - Validazione dello schema prima dell'esecuzione di un Tool
Codice: BR-003
Nome: Gli argomenti generati dal modello devono validare contro lo schema del Tool
Descrizione: Prima di invocare un Tool, l'Orchestratore deve validare gli argomenti prodotti dal modello (ToolCall.arguments) contro lo Schema di Funzione dichiarato. Argomenti non conformi (tipo errato, campo obbligatorio mancante) non vengono passati al Tool ma restituiti al modello come errore correggibile.
Motivazione: I modelli possono allucinare argomenti o nomi di funzione; la validazione previene esecuzioni malformate e injection.
Priorità: ALTA
Attori: Orchestratore, Tool Executor
Violazione: ToolValidationFailed → il messaggio di errore viene reintrodotto nel contesto per auto-correzione.
Tracciabilità: BR-006; OWASP LLM Top 10 (LLM01).
---
BR-004 - Grounding obbligatorio per le risposte fattuali
Codice: BR-004
Nome: Le affermazioni fattuali devono essere ancorate al contesto recuperato
Descrizione: Quando un Agente risponde con informazioni fattuali su un dominio specifico, deve basarle su contesto recuperato verificabile (RAG) e non sulla conoscenza parametrica non verificata. Le affermazioni devono essere tracciabili a una fonte (citazione, chunk recuperato).
Motivazione: Ridurre le allucinazioni e garantire faithfulness verso le fonti.
Priorità: ALTA
Attori: Agente, Retriever
Tracciabilità: BR-008; RAG (arXiv:2005.11401); rag-retrieval.md.
---
BR-005 - Approvazione umana per le azioni ad alto rischio
Codice: BR-005
Nome: Human-in-the-Loop obbligatorio per operazioni irreversibili o sensibili
Descrizione: Le azioni classificate ad alto rischio (eliminazione dati, spese sopra una soglia, comunicazioni esterne, modifiche di produzione) devono sospendere la Run e richiedere l'approvazione esplicita di un Operatore umano prima dell'esecuzione.
Motivazione: Limitare i danni di decisioni errate dell'agente su operazioni non reversibili.
Priorità: CRITICA
Attori: Operatore, Orchestratore, Guardrail
Violazione: l'azione viene bloccata; la Run entra in stato WAITING_APPROVAL.
Tracciabilità: human-approval.md; agent-run-lifecycle.md stato WAITING_APPROVAL.
---
BR-006 - I Guardrail valutano ogni input e ogni output
Codice: BR-006
Nome: Filtraggio di sicurezza su input utente e output del modello
Descrizione: Ogni input proveniente da una fonte non fidata (utente, contenuto web, risultato di tool) e ogni output destinato all'utente o ad azioni deve attraversare i Guardrail per il rilevamento di prompt injection, contenuti dannosi e fuga di dati sensibili.
Motivazione: Difendersi da prompt injection, jailbreak e data exfiltration.
Priorità: CRITICA
Attori: Guardrail, Orchestratore
Tracciabilità: OWASP LLM Top 10 (LLM01, LLM06); INV-05.
---
BR-007 - Il contesto non deve superare la finestra del modello
Codice: BR-007
Nome: Gestione del Token Budget e troncamento controllato
Descrizione: L'Orchestratore deve garantire che il contesto assemblato (system prompt + memoria + cronologia + risultati tool) non superi la finestra di contesto del modello. Quando si avvicina al limite, deve applicare una strategia esplicita (riassunto, troncamento della cronologia più vecchia, compattazione della memoria), mai un troncamento silenzioso che perde informazioni critiche.
Motivazione: Evitare errori di overflow e degrado della qualità per perdita di contesto rilevante.
Priorità: ALTA
Attori: Orchestratore, Memoria
Tracciabilità: INV-04; agent-run-lifecycle.md.
---
BR-008 - Ogni Tool Result rientra nel ciclo decisionale
Codice: BR-008
Nome: L'osservazione di una azione alimenta la decisione successiva
Descrizione: Il risultato (Observation) di ogni Tool invocato deve essere reintrodotto nel contesto dell'Agente prima della decisione successiva. L'agente non può pianificare lo step N+1 ignorando l'esito dello step N. Errori dei tool sono osservazioni valide da cui l'agente può recuperare.
Motivazione: Garantire il loop ReAct corretto (Reason → Act → Observe) e la capacità di auto-correzione.
Priorità: ALTA
Attori: Agente, Orchestratore
Tracciabilità: ReAct (arXiv:2210.03629); tool-invocation.md; INV-07.