Salta al contenuto principale

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.