O agente de execução só precisa "fazer o trabalho"

A separação de poderes (aqui: a divisão entre execução, auditoria e aprovação em agentes distintos) foi explicada no episódio anterior e no seguinte.

A partir de agora, vamos detalhar cada uma das três funções. Começamos pela função de execução.

O que é o agente de execução

O agente de execução é a IA que realiza o trabalho diretamente.

Escrever código, redigir textos, executar comandos, processar dados. Ele assume "a tarefa em si".

É simplesmente uma entidade que "recebe o que precisa ser feito e entrega o resultado".

Na estrutura que estamos construindo nesta série, o agente de execução é projetado na forma de um subagent (ou seja, uma IA que recebe e realiza tarefas). Cada função tem seu próprio responsável, e cada um se concentra em "seu próprio trabalho". O agente de execução é um deles, especializado em concluir as tarefas que lhe são passadas.

O que o agente de execução "faz"

O agente de execução assume a realização de tarefas concretas.

Por exemplo, estas são as tarefas que confiamos a ele:

• Escrever o rascunho de um artigo
• Processar dados especificados e gerar um arquivo de saída
• Registrar dados no banco de dados
• Operar o sistema seguindo um procedimento definido previamente

Em todos os casos, "o que fazer" está definido de antemão, e o agente age dentro desse escopo.

O ponto importante é que o agente de execução "age dentro do escopo das instruções". "Até onde vai" e "com base em quais critérios" são decididos pelo design prévio ou por outro responsável. O agente de execução conclui o trabalho dentro dessa estrutura.

Existe um motivo para adotarmos essa estrutura. Quando se dá ao agente de execução também a responsabilidade de "julgar", a execução e a tomada de decisão passam a acontecer no mesmo lugar. Quando revisamos o processo depois, fica difícil ver "com que base aquela ação foi tomada". Esse era o problema.

Quando separamos execução e julgamento, o registro fica mais fácil de acompanhar. "O que foi feito" e "por que aquilo foi autorizado" ficam em camadas distintas. Isso se torna eficaz na operação real.

O que o agente de execução "não faz"

Aqui está o ponto central desta estrutura.

O agente de execução não julga por conta própria se seu trabalho está "correto".

Não verifica por si mesmo se o rascunho que escreveu está certo. Não decide por si mesmo se o resultado de um comando executado é aceitável. Não aprova por conta própria dizendo "está tudo bem".

Estamos evitando intencionalmente uma estrutura em que "quem realizou o trabalho avalia o próprio trabalho".

Por quê?

Porque auditar o próprio trabalho é estruturalmente difícil. Manter o foco na execução e ao mesmo tempo fazer uma avaliação objetiva é algo complicado mesmo para humanos. O mesmo vale para a IA: o modo otimizado para executar e o modo otimizado para identificar problemas não funcionam bem ao mesmo tempo.

Por isso, a auditoria (ou seja, a verificação por um responsável independente) fica com outro agente. E a decisão final de "avançar" ou "parar" fica com outro mecanismo ainda.

Esta é uma das razões para dividir as três funções. Quanto mais poderoso for o agente de execução, mais importante se torna a restrição de que ele "não pode dar o aval por conta própria".

O que aprendemos ao projetar o agente de execução

Ao colocar em prática, ficou claro que a "clareza do escopo" do agente de execução se reflete diretamente na qualidade do conjunto.

Quanto mais nítida for a fronteira entre "até aqui posso fazer" e "a partir daqui, outro responsável assume", mais fácil fica acompanhar o registro das ações. Quando algo dá errado, fica mais simples rever em qual etapa o problema ocorreu.

Por outro lado, se passarmos ao agente de execução uma instrução como "faça uma verificação também, se precisar" ou "julgue conforme achar necessário", o registro fica vago. Tudo se resume a "a IA fez". E o ponto de responsabilidade de quem projetou o sistema também fica invisível.

Um design que diz "só precisa fazer o trabalho" parece uma restrição à primeira vista. Mas, na prática, é justamente essa restrição que melhora a visibilidade do conjunto. Até agora, é essa a percepção que temos na operação real.