Un executor intelligente è un agente a mandato ristretto: può adattarsi a stati non noti a priori, ma soltanto per conseguire lo scopo tipizzato del proprio executor.
| Proprietà | Executor normale | Executor intelligente |
|---|---|---|
| Contratto pubblico | Input e output tipizzati | Identico |
| Esecuzione | Procedura diretta | Ciclo adattivo bounded |
| Scopo | Fissato dal nome dell'executor | Identico e non ridefinibile dal modello |
| Autorità | Capacità e gate del manifest | Identica; non può auto-estendersi |
| Esito | Schema e postcondizioni | Identico, compreso il fallimento esplicito |
Operativamente è un vero agente: osserva, sceglie un passo, agisce e verifica. Architetturalmente resta un executor perché non può cambiare obiettivo, invocare capacità estranee o inventare un formato d'uscita.
Il mandato è definito da nome e descrizione dell'executor, schema degli argomenti, capacità dichiarate, policy di consenso, budget e postcondizione. Il modello interno riceve solo l'osservazione minima necessaria e sceglie entro uno spazio d'azioni fissato dal codice.
Il planner non conosce le transizioni interne. Per lui login_sites(session_ids) continua a restituire sessioni autenticate o un motivo di mancato accesso, anche se internamente ha dovuto trovare l'area login, attraversare più schermate o cedere un 2FA all'utente.
Il ciclo generale è observe → resolve → verify preconditions → gate → execute → verify postconditions. Ogni iterazione consuma un budget di passi e tempo. I resolver deterministici hanno precedenza; un modello locale interviene solo sull'ambiguità residua e può selezionare esclusivamente oggetti enumerati dal runtime.
Il ciclo termina con successo verificato, handoff esplicito all'utente oppure errore tipizzato. Non può continuare indefinitamente, abbassare una policy, approvare la propria azione o trasformare una postcondizione non verificata in successo.
L'approccio è generale quando lo scopo è stretto ma il percorso varia: login web, navigazione in interfacce, recupero da risposte API variabili, wizard multi-stadio e individuazione di un oggetto dentro una struttura osservabile. Servono uno spazio d'azioni limitato, progresso riosservabile e una postcondizione verificabile.
Non è adatto a ricerca aperta, strategia multi-dominio o compiti creativi senza criterio di completamento. Quelli appartengono al planner. login_sites e la navigazione bounded di act_sites sono le prime implementazioni, non un dominio privilegiato nella documentazione.
Un executor intelligente fallisce chiuso: restituisce lo stesso schema pubblico con un codice causale, conserva solo lo stato necessario a un eventuale handoff sicuro e non inventa un risultato. CAPTCHA, conferme esterne o ambiguità non risolvibili diventano richieste esplicite all'utente; budget esaurito, target instabile e postcondizione assente diventano errori verificabili.