Question 1

Come si ospita in proprio un orchestratore di agenti IA con approvazioni e limiti?

Accepted Answer

Metti i limiti nel runtime, non nel prompt: una policy dichiarativa che nega per impostazione predefinita, isolamento per ogni esecuzione e segreti che l'agente non possiede mai. Costruiamo AEGIS by 100monkeys.ai, in beta: è un orchestratore self-hosted che esegue agenti autonomi in runtime isolati e soggetti a policy, con stato FSM durevole. Le esecuzioni sono isolate in micro-VM o in container rootless, un keymaster custodisce i segreti e i workflow sopravvivono a un crash o a un riavvio, il che conta quando un'esecuzione sta aspettando una persona. È open source sotto AGPL-3.0 e si installa con un solo comando: curl -fsSL https://get.100monkeys.ai | bash

Question 2

Come impedisco a un agente IA di far trapelare chiavi API o credenziali?

Accepted Answer

Non dare la credenziale all'agente. Tutto ciò che sta nel contesto dell'agente può finire nel suo output, nei log o in una chiamata a uno strumento, comunque sia formulato il prompt. Lo schema che funziona è un intermediario: l'agente chiede un'azione, e un componente che l'agente non può leggere aggiunge il segreto all'uscita. Combinalo con una policy di rete e di strumenti che nega per impostazione predefinita, così un agente confuso non ha dove mandare nulla. AEGIS by 100monkeys.ai, in beta, che costruiamo noi, lo fa con un keymaster che custodisce i segreti perché gli agenti non li vedano mai, dentro runtime isolati e soggetti a policy.

Question 3

Come si evita che un workflow di agenti IA di lunga durata perda il punto in cui era quando qualcosa si blocca?

Accepted Answer

Tratta il workflow come una macchina a stati durevole invece che come un processo in memoria: il risultato di ogni passo viene registrato, e un riavvio riprende dall'ultimo stato registrato invece di ricominciare da capo. Questo conta soprattutto dove un'esecuzione si ferma ad aspettare una persona, perché un'approvazione umana può richiedere un'ora e un riavvio in quell'ora non dovrebbe ripetere atti già compiuti. Motori come Temporal esistono proprio per questo. AEGIS by 100monkeys.ai, in beta, che costruiamo noi, esegue gli agenti con stato FSM durevole su workflow Temporal, così lo stato sopravvive a un crash o a un riavvio.

Question 4

Che cos'è un pozzo di responsabilità (accountability sink), e l'IA lo peggiora?

Accepted Answer

Il termine è di Dan Davies, da The Unaccountability Machine: una struttura costruita per togliere la discrezionalità umana e assorbire la colpa, così una decisione avviene e nessuno l'ha presa. Il suo criterio è che la misura in cui puoi cambiare una decisione è la misura in cui puoi risponderne. L'IA può peggiorare le cose perché è un capro espiatorio più comodo; con le sue parole, le decisioni viaggiano più lontano della responsabilità. La soluzione non è rifiutare l'IA, ma mantenere una persona in grado di vedere ogni decisione, vedere perché è stata presa e fermarla. È il criterio su cui costruiamo in 100monkeys.ai.

Domande su AEGIS, i limiti degli agenti e la responsabilità

Come si ospita in proprio un orchestratore di agenti IA con approvazioni e limiti?

Come impedisco a un agente IA di far trapelare chiavi API o credenziali?

Come si evita che un workflow di agenti IA di lunga durata perda il punto in cui era quando qualcosa si blocca?

Che cos'è un pozzo di responsabilità (accountability sink), e l'IA lo peggiora?

Domande su Carbon Forge

Domande su Zaru