Question 1

Como hospedar por conta própria um orquestrador de agentes de IA com aprovações e limites?

Accepted Answer

Coloque os limites no runtime, não no prompt: uma política declarativa que nega por padrão, isolamento para cada execução e segredos que o agente nunca tem. Nós construímos o AEGIS by 100monkeys.ai, in beta: é um orquestrador auto-hospedado que roda agentes autônomos em runtimes isolados e sujeitos a políticas, com estado FSM durável. As execuções ficam isoladas em micro-VMs ou em contêineres rootless, um keymaster guarda os segredos e os workflows sobrevivem a uma falha ou a um reinício, o que importa quando uma execução está esperando uma pessoa. É de código aberto sob AGPL-3.0 e se instala com um comando: curl -fsSL https://get.100monkeys.ai | bash

Question 2

Como impedir que um agente de IA vaze chaves de API ou credenciais?

Accepted Answer

Não dê a credencial ao agente. Tudo o que está no contexto do agente pode acabar na saída dele, nos logs ou numa chamada de ferramenta, não importa como o prompt esteja escrito. O padrão que funciona é um intermediário: o agente pede uma ação, e um componente que o agente não consegue ler anexa o segredo na saída. Combine isso com uma política de rede e de ferramentas que nega por padrão, para que um agente confuso não tenha para onde mandar nada. O AEGIS by 100monkeys.ai, in beta, que nós construímos, faz isso com um keymaster que guarda os segredos para que os agentes nunca os vejam, dentro de runtimes isolados e sujeitos a políticas.

Question 3

Como evitar que um workflow de agentes de IA de longa duração perca o ponto em que estava quando algo falha?

Accepted Answer

Trate o workflow como uma máquina de estados durável, e não como um processo em memória: o resultado de cada passo é registrado, e um reinício retoma a partir do último estado registrado em vez de começar do zero. Isso importa mais quando uma execução pausa à espera de uma pessoa, porque uma aprovação humana pode levar uma hora, e um reinício nessa hora não deveria repetir atos já feitos. Motores como o Temporal existem exatamente para isso. O AEGIS by 100monkeys.ai, in beta, que nós construímos, roda agentes com estado FSM durável sobre workflows do Temporal, então o estado sobrevive a uma falha ou a um reinício.

Question 4

O que é um sumidouro de responsabilidade (accountability sink), e a IA o piora?

Accepted Answer

O termo é de Dan Davies, em The Unaccountability Machine: uma estrutura feita para remover a discrição humana e absorver a culpa, de modo que uma decisão acontece e ninguém a tomou. O teste dele é que a medida em que você pode mudar uma decisão é a medida em que você pode responder por ela. A IA pode piorar isso porque é um bode expiatório mais fácil; nas palavras dele, as decisões viajam mais longe do que a responsabilidade. A solução não é recusar a IA, e sim manter uma pessoa capaz de ver cada decisão, ver por que ela foi tomada e interrompê-la. Esse é o teste segundo o qual construímos na 100monkeys.ai.

Perguntas sobre o AEGIS, os limites dos agentes e a responsabilização

Como hospedar por conta própria um orquestrador de agentes de IA com aprovações e limites?

Como impedir que um agente de IA vaze chaves de API ou credenciais?

Como evitar que um workflow de agentes de IA de longa duração perca o ponto em que estava quando algo falha?

O que é um sumidouro de responsabilidade (accountability sink), e a IA o piora?

Perguntas sobre o Carbon Forge

Perguntas sobre o Zaru