AGENTIKO: separare agentività e capacità
Una diversa architettura per costruire agenti AI autonomi, sostituibili, controllabili e privi di potere operativo diretto
Abstract
I framework per agenti AI tendono a costruire l'agente come un'unità software che riunisce nello stesso perimetro ragionamento, accesso al modello linguistico, strumenti, credenziali e stato. AGENTIKO parte da un'ipotesi differente, secondo la quale per essere autonomo un agente deve poter decidere come affrontare un problema, ma non è necessario che possieda direttamente i mezzi con i quali agire.
L'architettura si propone quindi di separare l'agentività dalla capacità. Il runner conserva la strategia e il processo decisionale mentre le credenziali, gli strumenti, la memoria autorevole, i budget, controllo degli effetti e verifica dei risultati risiedono in un servizio centrale denominato Centro Operativo. Le azioni concrete vengono eseguite da un ulteriore componente che è l'Esecutore.
Il risultato è un modello nel quale il runner può essere piccolo, remoto, sostituibile e potenzialmente non fidato, senza per questo dovergli consegnare le credenziali dell'infrastruttura. Il paper analizza le conseguenze di questa impostazione in termini di semplicità, sicurezza, persistenza, controllo dei costi ed efficienza del ciclo agentico, evidenziandone anche i limiti e i requisiti ancora necessari per una validazione sperimentale completa.
Parole chiave: AI agents, agentic systems, zero trust, capability security, LLM orchestration, tool calling, durable execution, least privilege, distributed agents.
Separando ciò che l'agente decide da ciò che l'agente può fare.
1. Il problema
Il punto dal quale sono partito è piuttosto semplice ed è la constatazione, supportata dagli ultimi case in termini di AI agentica, che più rendiamo autonomo un agente AI e più tendiamo a consegnargli potere.
Gli diamo accesso al modello, agli strumenti, al database, al filesystem, API, posta elettronica, servizi esterni, memoria e spesso anche il controllo del proprio ciclo di esecuzione, e poi tentiamo di recuperare sicurezza aggiungendo guardrail, regole, filtri e sistemi di osservazione.
A mio avviso esiste almeno una domanda che dobbiamo farci prima, ed è questa: è davvero necessario che l'agente possieda tutto ciò?
Un agente deve certamente poter ragionare, perchè deve poter interpretare un obiettivo e scegliere una strategia, correggersi e decidere quale sia la prossima azione. Da questo però non deriva necessariamente che debba detenere direttamente le credenziali o gli strumenti necessari per eseguire quell'azione.
Ho quindi pensato di attuare questa separazione formale, che è la base fattuale di AGENTIKO.
Oppure, in una notazione deliberatamente algoritmica:
2. Principio fondativo
In AGENTIKO l'agente non contiene ciò che lo rende potente.
Non possiede le chiavi dei provider LLM e non possiede direttamente gli strumenti. Nemmeno conserva lo stato autorevole della missione e non decide autonomamente che il lavoro sia stato completato. Sopratutto NON deve conoscere la topologia dell'infrastruttura.
Gli rimane però quello che personalmente considero essenziale: decidere come affrontare il problema.
Tutto il resto viene trasferito al Centro Operativo.
CENTRO OPERATIVO = STATO + CAPACITA + POLICY + BUDGET + CONTROLLO
La regola architetturale che ne consegue è altrettanto importante, ovvero che quando nasce la tentazione di aggiungere una nuova capacità al runner, occorre chiedersi se quella capacità non debba invece diventare un comando del Centro Operativo.
Perchè se il runner continua a crescere fino ad avvolgere ed incorporare infrastruttura, autorizzazione, stato e strumenti, il principio viene perso.
3. Le tre entità
3.1 Il Runner
Il runner è il processo agentico e può essere scritto in qualsiasi linguaggio e può essere ospitato praticamente ovunque.
Conosce l'indirizzo del Centro Operativo e possiede una credenziale limitata con la quale si presenta al sistema.
Le sue funzioni essenziali sono poche:
- richiedere una missione;
- comporre il prompt necessario a decidere la prossima azione;
- interrogare un modello attraverso il Centro Operativo;
- richiedere l'esecuzione di un comando;
- continuare fino a quando lo stato della missione non cambia.
La regola fondamentale è che un runner deve poter morire senza che muoia il lavoro.
3.2 Il Centro Operativo
Il Centro Operativo rappresenta il vero cuore dell'architettura.
Ha il compito di assegnare missioni e custodirne lo stato, fornire accesso ai modelli linguistici, autorizzare i comandi, applicare limiti, tenere la contabilità, registrare gli eventi e valutare i risultati.
Coincide con il punto nel quale l'autonomia decisionale dell'agente incontra le regole stabilite dal sistema.
3.3 L'Esecutore
L'Esecutore è il componente che produce effetti concreti sul mondo esterno, quello che esegue funzionalità asservienti.
Può scaricare una pagina web, scrivere un record, interrogare un servizio, inviare un messaggio oppure svolgere qualsiasi altra operazione prevista dal catalogo dei comandi.
Ha capacità di Callback (o Remote Callback) e può usare un client per eseguire funzioni che richiedono mascheratura.
Il runner non chiama direttamente l'Esecutore ma chiede invece al Centro Operativo di eseguire un'azione e sarà quest'ultimo, se autorizzata, a inoltrarla.
+-------------+ HTTP +------------------+ API +------------+
| | ------------------> | | ---------------> | |
| RUNNER | | CENTRO OPERATIVO | | ESECUTORE |
| | <------------------ | | <--------------- | |
+-------------+ +------------------+ +------------+
|
|
v
+---------+
| LLM |
+---------+
4. Una sola interfaccia
Un'altra scelta volutamente semplice è quella di ridurre l'interfaccia conosciuta dal runner a un unico endpoint.
POST /api/v1/exec
Ogni operazione viene espressa come comando.
{
"cmd": "web.fetch",
"args": {
"url": "https://esempio.it"
},
"idem": "4821:17:1"
}
La stessa forma viene utilizzata per interrogare il modello, leggere il contesto, scrivere un fatto, ottenere l'elenco delle capacità disponibili o sottoporre il risultato di un obiettivo.
Questo concentra autenticazione, audit, rate limiting, multitenancy e policy nello stesso punto.
Non elimina la complessità complessiva del sistema, ma la sposta e la accentra. L'accentramento può essere ulteriormente diluito demandando funzionalità specifiche ad ulteriori esecutori.
L'obiettivo è ridurre fortemente il termine relativo a ogni singolo runner, accettando che il Centro Operativo diventi un'infrastruttura più sofisticata ma condivisa da tutti gli agenti.
5. La missione è più importante dell'agente
In AGENTIKO l'entità persistente non è il runner ma la missione.
Il runner prende temporaneamente in carico una missione attraverso un lease e, fino a quando lavora, ogni chiamata valida rinnova implicitamente il lease.
Relay: se il processo si interrompe, il lease scade ed un altro runner può acquisire la stessa missione e continuare il lavoro.
MISSIONE = ENTITA DUREVOLE
Questo cambia il modo di pensare al recupero dopo un errore.
Non occorre ricostruire lo stato contenuto nel processo morto perché lo stato importante non avrebbe dovuto trovarsi lì.
6. L'autonomia resta nel runner
Centralizzare le capacità non significa centralizzare il ragionamento.
È il runner a decidere come costruire il prompt e come affrontare l'obiettivo. Il Centro Operativo fornisce ciò che deve essere raggiunto e quali capacità sono disponibili, ma non dovrebbe imporre il percorso logico.
Questa distinzione per me è fondamentale.
Se fosse il Centro Operativo a costruire sistematicamente la strategia, due runner diversi finirebbero per comportarsi nello stesso modo e l'agente diventerebbe poco più di un esecutore remoto.
RUNNER = COME
AGENTIKO tenta quindi di mantenere il massimo possibile di autonomia cognitiva e il minimo possibile di autorità operativa diretta.
7. Capability discovery
Il runner non dovrebbe ricevere necessariamente, a ogni turno, l'intero catalogo di strumenti del sistema.
Può interrogare il Centro Operativo attraverso un comando come:
cmdlist("web.*")
cmdlist("mail.*")
cmdlist("data.*")
La risposta deve contenere soltanto le capacità effettivamente disponibili per quella missione, quel tenant e quella credenziale.
Questo significa che il modello non dovrebbe vedere strumenti che non potrebbe comunque utilizzare.
La discovery coincide quindi, per quanto possibile, con il perimetro di autorizzazione.
Questo riduce contemporaneamente la superficie operativa e la quantità di schema che deve essere inserita nel contesto del modello.
8. Perché questo cambia la sicurezza
La sicurezza degli agenti viene sovente affrontata cercando di convincere il modello a non fare qualcosa.
AGENTIKO prova a spostare il problema.
Il modello potrebbe ANCHE DECIDERE che sarebbe utile eseguire un'operazione non consentita. Ma se quella capacità non gli viene concessa, la decisione non si traduce in azione.
In altre parole, una istruzione malevola può modificare ciò che il modello desidera fare senza necessariamente modificare ciò che il sistema gli permette di fare.
È questa, più della prompt engineering, la difesa che considero interessante.
Un prompt injection può tentare di convincere l'agente a spedire informazioni a un dominio esterno, ma se il comando non esiste o non è autorizzato oppure l'Esecutore applica una lista di destinazioni consentite, l'azione viene bloccata indipendentemente dalla convinzione del modello.
9. Least privilege applicato agli agenti
Le capability non dovrebbero essere semplicemente abilitate o disabilitate.
L'evoluzione naturale del modello consiste nel renderle parametriche.
mail.send:
allowed_domains:
- cliente.it
max_recipients: 5
attachments: false
Oppure:
data.record.write:
dataset: leads
max_rows_per_turn: 20
La capacità reale diventerebbe quindi:
Un agente potrebbe possedere il diritto di inviare una email senza possedere il diritto di inviarla a chiunque.
10. Il successo non lo dichiara chi esegue il lavoro
In molti sistemi agentici l'agente termina quando ritiene di avere concluso.
AGENTIKO separa anche questa autorità.
Il runner può sottoporre il risultato attraverso un comando di completamento, ma la decisione finale appartiene al Centro Operativo.
Il principio è semplice: produrre un risultato e collaudare quel risultato non sono la stessa attività.
Il giudizio può avvenire su due livelli.
10.1 Verifica deterministica
Tutto ciò che può essere verificato con codice tradizionale non dovrebbe essere sottoposto a un modello linguistico.
Numero di record, presenza di campi, formato degli URL, appartenenza a un insieme e altri vincoli formali possono essere verificati in modo deterministico.
10.2 Giudizio semantico
Il modello viene utilizzato soltanto quando il criterio richiede valutazioni come pertinenza, qualità, coerenza o aderenza al mandato.
GIUDIZIO LLM SOLO QUANDO SERVE
Questo riduce costo, latenza e variabilità.
11. Stato e memoria
Il contesto della missione può essere separato in categorie con durata differente.
| Sezione | Funzione | Durata |
|---|---|---|
mission |
Mandato, vincoli, riferimenti permanenti | Intera missione |
facts |
Conclusioni acquisite e considerate stabili | Persistente |
history |
Azioni, risultati, errori e passaggi precedenti | Compattabile |
scratch |
Appunti temporanei relativi all'obiettivo corrente | Effimera |
Non tutte le informazioni hanno lo stesso valore e non tutte devono sopravvivere con la stessa granularità.
La cronologia può essere compattata quando cresce troppo, mentre i fatti contestuali (importanti) rimangono intatti.
12. Inferenza: cosa migliora realmente
AGENTIKO non rende più veloce il calcolo interno di un transformer.
Non modifica attention, KV cache, quantizzazione, batching o decoding.
Non migliora direttamente l'inferenza del modello.
Può però migliorare l'economia dell'inferenza all'interno di un sistema agentico.
Su alcuni di questi termini il Centro Operativo può intervenire.
12.1 Model routing
Il runner non deve necessariamente specificare il modello concreto.
Può richiedere, per esempio, un profilo:
fast deep
Il Centro Operativo può scegliere provider e modello in funzione di costo, disponibilità, qualità o policy.
In questo modo centinaia di runner possono cambiare modello senza essere modificati.
12.2 Structured output
La validazione dell'output strutturato può essere responsabilità del Centro Operativo.
Il runner non deve replicare decine di volte la stessa logica di parsing, riparazione e retry.
MODEL OUTPUT
|
v
VALIDAZIONE
|
+--> valido --> runner
|
+--> correggibile --> repair
|
+--> invalido --> errore strutturato
La fragilità legata all'output dei modelli viene quindi concentrata in un solo punto aggiornabile.
12.3 Tool discovery selettiva
Se forziamo il modello a scegliere soltanto fra cinque strumenti utili invece che fra cento strumenti teoricamente disponibili, diminuiscono sia la quantità di contesto sia la possibilità di scelta errata.
**Questo vantaggio è alla data attuale in fase di misurazione sperimentalmente, poichè una discovery troppo frequente potrebbe introdurre round trip tali da annullare parte del risparmio.
13. Budget e limiti
Il budget non dovrebbe essere una raccomandazione inserita nel prompt.
Deve essere un limite applicato dall'infrastruttura.
Alla stessa maniera possono essere imposti:
- numero massimo di turni;
- durata massima;
- numero massimo di chiamate a un comando;
- spesa massima;
- numero massimo di retry.
Un agente non deve essere convinto a rispettare un budget, perchè questa condizione netta potrebbe inficiare le performances. Più semplicemente gli deve essere impedito superarlo.
14. Audit come conseguenza del protocollo
Se tutte le operazioni devono passare dallo stesso punto, quel punto può registrarle automaticamente.
tenant mission turn command arguments result tokens cost duration timestamp
L'osservabilità non viene aggiunta successivamente all'agente ma è conseguenza diretta del fatto che l'agente NON possiede canali operativi alternativi.
La proprietà vale naturalmente soltanto per le azioni che passano effettivamente dal sistema.
15. Il vantaggio sulla semplicità
La semplificazione più evidente riguarda chi sviluppa nuovi agenti.
Un runner non deve necessariamente integrare direttamente:
- SDK OpenAI, Anthropic, Google o altri provider;
- driver database;
- sistemi di code;
- SMTP;
- API esterne;
- tracing;
- budget accounting;
- persistenza;
- gestione dei segreti.
Deve conoscere essenzialmente il protocollo AGENTIKO.
Questo rende possibile scrivere runner in PHP, Python, Go, Rust o in qualsiasi altro ambiente capace di effettuare una richiesta HTTP.
La complessità non scompare, ma viene ammortizzata in una infrastruttura centrale invece di essere replicata in ogni agente.
16. Confronto concettuale con i framework agentici correnti
| Proprietà | Framework agentico tradizionale | AGENTIKO |
|---|---|---|
| Strategia | Agente o runtime | Runner |
| Accesso LLM | Runtime o applicazione | Centro Operativo |
| Credenziali | Runtime o tool host | Centro Operativo / Esecutore |
| Stato autorevole | Sessione, agente o workflow | Missione |
| Tool | Registrati nell'applicazione | Capability remote |
| Completamento | Agente o workflow | Giudice esterno |
| Budget | Configurazione applicativa | Vincolo della missione |
| Fault recovery | Checkpoint o runtime | Missione persistente + lease |
| Linguaggio | Dipendente dall'SDK | Qualsiasi client HTTP |
| Trust model | Agente normalmente interno | Runner trattato come non fidato |
Tool discovery, structured output, human in the loop o tracing NON sono invenzioni di AGENTIKO.
Esistono già nei framework moderni.
La differenza che considero realmente interessante riguarda il modo nel quale queste primitive vengono ricomposte intorno a un confine di fiducia diverso.
17. Il vero cambio di prospettiva
Un agente tradizionale viene generalmente trattato come una parte del software.
AGENTIKO tenta di trattarlo come un soggetto esterno incaricato (provvisorio) al quale viene assegnato un mandato.
La differenza è notevole.
A un collaboratore esterno non consegniamo necessariamente la password amministrativa del sistema, il budget senza limiti e il diritto di approvare il proprio stesso lavoro.
Gli assegniamo un compito. Gli forniamo gli strumenti necessari. Limitiamo ciò che può fare. Verifichiamo il risultato.
Questa è la metafora che descrive meglio l'architettura.
E' UN FORNITORE.
18. Un limite importante: sicurezza delle capacità e sicurezza dei dati non sono la stessa cosa
AGENTIKO può evitare di consegnare al runner le credenziali operative del sistema e questo non significa automaticamente che un runner eseguito su una macchina ostile possa ricevere dati riservati senza rischio.
Se il runner riceve il contesto della missione, tecnicamente può leggere quel contesto.
Se viene ospitato su una infrastruttura completamente controllata da un terzo malevolo, potrebbe tentare di trasmettere altrove ciò che ha ricevuto attraverso canali esterni al protocollo AGENTIKO.
Il modello di sicurezza deve quindi distinguere le due cose.
Per gestire informazioni sensibili con runner realmente non fidati possono diventare necessari ulteriori strumenti:
- sandbox con traffico in uscita controllato;
- ambienti amministrati dal proprietario della piattaforma;
- redazione dei dati;
- tokenizzazione;
- Trusted Execution Environment;
- remote attestation;
- minimizzazione del contesto inviato al runner.
Sotto questo contesto AGENTIKO può rendere un runner non fidato INCAPACE di utilizzare le credenziali e le capacità del sistema al di fuori del proprio mandato. La riservatezza dei dati consegnati al runner richiede invece un ulteriore livello di protezione.
19. Idempotenza
Ogni richiesta operativa deve poter essere associata a una chiave di idempotenza.
mission_id : turn : sequence
Se la stessa richiesta viene ricevuta nuovamente, il sistema può restituire il risultato precedente senza ripetere l'azione.
Questo è necessario per poter sostituire un runner senza rischiare di duplicare effetti.
La protezione deve però arrivare fino all'Esecutore.
Immaginiamo questa sequenza:
Centro Operativo
|
v
Esecutore
|
v
Email inviata
|
X
Crash prima della conferma
Se il sistema non conosce l'esito, potrebbe ripetere l'invio.
Per questo motivo l'idempotenza deve essere end to end e, dove possibile, propagata fino al servizio esterno.
20. Lease e fencing
Anche il meccanismo del lease richiede una protezione aggiuntiva.
Un runner potrebbe perdere temporaneamente la connessione mentre il suo lease scade ed un secondo runner potrebbe acquisire la missione e, poco dopo, il primo tornare operativo.
Per evitare che entrambi agiscano contemporaneamente è opportuno introdurre un contatore monotono, per esempio:
lease_epoch = 148
Ogni richiesta deve portare l'epoch corrente.
In questo modo il vecchio detentore del lease non può continuare a produrre effetti una volta sostituito.
21. Il Centro Operativo diventa un'infrastruttura critica
La centralizzazione semplifica il controllo ma aumenta il valore del componente centrale.
Se il Centro Operativo conserva segreti, stato, policy e accesso all'Esecutore, deve essere trattato come un asset infrastrutturale di massimo livello.
Sono quindi necessari, fra gli altri:
- secret management dedicato;
- cifratura dei dati a riposo;
- segmentazione di rete;
- autenticazione forte fra Centro Operativo ed Esecutore;
- rotazione delle credenziali;
- audit non modificabile;
- backup verificati;
- controlli amministrativi separati;
- rate limiting;
- replica e failover.
22. Cosa rende AGENTIKO interessante
AGENTIKO non nasce dall'idea che tutto ciò che esiste nei framework attuali sia sbagliato.
Al contrario, molte delle primitive necessarie sono già note e mature.
Ciò che cambia è il punto nel quale viene tracciato il confine.
Checkpoint, tool calling, memory, guardrail, human review e tracing possono essere trovati in molti sistemi. La scelta che definisce AGENTIKO è sottrarre queste responsabilità al runner quando rappresentano potere infrastrutturale.
Sono tre attività diverse e non esiste una necessità tecnica per cui debbano appartenere allo stesso processo.
23. Possibile marketplace di agenti
Da questa separazione deriva una conseguenza ulteriore.
Un soggetto esterno potrebbe sviluppare e distribuire un runner specializzato senza avere accesso alle credenziali del cliente.
Potrebbero esistere, per esempio:
- agenti di ricerca;
- agenti commerciali;
- agenti di procurement;
- agenti per strutture alberghiere;
- agenti di analisi documentale;
- agenti di monitoraggio;
- agenti verticali per singoli settori.
Il fornitore dell'agente fornirebbe la strategia.
L'organizzazione fornirebbe soltanto le capacità che decide di concedere.
PIATTAFORMA = AUTHORITY
La strategia agentica potrebbe quindi diventare distribuibile senza rendere distribuibili le credenziali.
24. Stato attuale del progetto
AGENTIKO è stato ideato e progettato da Federico Lomazzi ed è attualmente in fase di sviluppo.
L'architettura descritta in questo paper deriva dalla revisione 1.0 del documento di progettazione e non deve essere presentata come una piattaforma già completamente validata in produzione.
Una prima implementazione sperimentale è stata tuttavia già sottoposta a un test iniziale.
Al momento della redazione di questo documento non vengono riportati qui valori quantitativi relativi a tale prova, perché una descrizione sperimentale corretta richiede la pubblicazione almeno di configurazione, modello utilizzato, missione, numero di turni, comandi eseguiti, consumo di token, costi, errori osservati e risultato finale.
Il test iniziale rappresenta quindi una prima verifica di fattibilità del modello, non ancora una validazione comparativa delle sue prestazioni.
25. Cosa deve essere misurato
Per capire se i vantaggi teorici si trasformano in vantaggi reali occorre passare dai principi ai benchmark.
25.1 Complessità
Lo stesso agente dovrebbe essere implementato con AGENTIKO e con alcuni framework correnti.
Andrebbero misurati almeno:
- righe di codice;
- numero di dipendenze;
- tempo di implementazione;
- quantità di codice dedicato alla persistenza;
- quantità di codice dedicato alla gestione degli errori;
- quantità di codice dedicato alle credenziali e ai tool.
25.2 Token
Il confronto deve essere effettuato utilizzando la stessa missione e, ove possibile, lo stesso modello.
25.3 Fault tolerance
Il runner dovrebbe essere terminato artificialmente in turni casuali per verificare:
- percentuale di missioni recuperate;
- azioni duplicate;
- tempo di ripresa;
- perdita di stato.
25.4 Sicurezza
Il sistema dovrebbe essere sottoposto deliberatamente a tentativi di:
- invocare comandi non autorizzati;
- raggiungere domini proibiti;
- superare il budget;
- accedere a dati di tenant differenti;
- riutilizzare lease scaduti;
- duplicare operazioni con side effect.
25.5 Costi
Occorre misurare separatamente:
Solo così sarà possibile stabilire se la riduzione della complessità distribuita giustifichi il costo aggiuntivo del Centro Operativo.
26. Come si può falsificare la tesi
Una architettura non deve soltanto spiegare perché potrebbe funzionare. Deve indicare anche come dimostrare che non funziona.
La proposta AGENTIKO perderebbe parte importante della propria forza se i test mostrassero che:
- il Centro Operativo introduce una latenza sproporzionata;
- il runner cresce inevitabilmente fino a replicare la complessità di un SDK;
- la gestione dello stato continua a richiedere grandi quantità di contesto;
- la capability discovery richiede più round trip di quanto faccia risparmiare;
- il giudice produce troppi errori di valutazione;
- il costo della nuova infrastruttura supera il vantaggio ottenuto sui runner;
- la concorrenza e il recupero richiedono un livello di complessità incompatibile con il modello dichiarato.
Questi non sono problemi che voglio nascondere perchè sono precisamente i punti sui quali il progetto è un corso di verifica.
27. Conclusione
La maggior parte dei sistemi agentici parte dall'agente e gli aggiunge progressivamente capacità.
AGENTE + modello + memoria + strumenti + credenziali + stato + tracing + guardrail
AGENTIKO prova a seguire la direzione opposta.
AGENTE - credenziali - strumenti diretti - stato autorevole - autorita sul budget - autorita sul completamento
Fino a lasciare all'agente la capacità di osservare un problema e decidere che cosa tentare dopo.
Questa impostazione produce tre conseguenze principali.
Semplicità. Il runner può essere piccolo, remoto, sostituibile e indipendente dal linguaggio con cui è stato scritto.
Sicurezza. L'agente non deve essere affidabile per poter utilizzare in sicurezza capacità limitate. Le credenziali e l'autorità rimangono altrove.
Controllo dell'inferenza. Routing dei modelli, budget, verifica deterministica, structured output, discovery selettiva degli strumenti e gestione del contesto possono essere centralizzati e misurati.
Il progetto deve ancora dimostrare sperimentalmente quanto questi vantaggi incidano su costi, latenza, robustezza e qualità rispetto alle soluzioni esistenti.
Ma la domanda iniziale rimane, a mio avviso, sufficientemente importante da meritare questa verifica:
AGENTIKO propone che non sia necessario.
L'agente può continuare a scegliere la strategia senza possedere direttamente i mezzi.
In altre parole:
La formulazione che considero più precisa dell'intera architettura è quindi questa:
Riferimenti essenziali
- Federico Lomazzi, AGENTIKO. Framework PHP per la creazione e l'orchestrazione di agenti AI, Documento di architettura, revisione 1.0, settembre 2026.
- POOE/POOA pec-imapbe009.it.dadapec with LMTP/id ILmvDQdHqGo2HBIA1AyESQ
- NIST, SP 800-207: Zero Trust Architecture.
- OWASP, AI Agent Security Cheat Sheet e documentazione relativa ai rischi di prompt injection e least privilege.
- LangChain, documentazione LangGraph relativa a persistence, checkpointing, durable execution e human in the loop.
- OpenAI, documentazione Agents SDK relativa a tools, guardrails, tracing, structured output e tool discovery.
- Microsoft, documentazione Microsoft Agent Framework relativa a agenti, workflow, stato, middleware e interoperabilità remota.
- Model Context Protocol, specifiche e documentazione relative a tools, resources e autorizzazione.