No Controlled Autonomy Lab, eu implementei a mesma tarefa de análise de incidente usando seis arquiteturas com graus diferentes de controle e autonomia. O padrão mais autônomo do experimento recebe cinco ferramentas e decide quais consultar, em que ordem e quando já existe evidência suficiente para concluir.
Essa liberdade foi deliberadamente colocada dentro de uma fronteira estreita:
As cinco ferramentas são somente leitura;
O código limita a execução a seis steps e oito tool calls, valida cada ferramenta contra uma allowlist e restringe o acesso ao incidente ativo;
Não há shell, restart, rollback, alteração de configuração ou qualquer operação de escrita em produção.
O laboratório nasceu para investigar quem determina o próximo passo da execução: o código ou o modelo. Depois de trabalhar com essa separação, uma segunda dimensão ficou mais evidente para mim. Um sistema pode conceder bastante liberdade para o agente decidir como executar uma tarefa e, ainda assim, limitar fortemente os efeitos que aquela execução pode produzir.
É essa diferença que passei a tratar como autonomia e autoridade.
Ampliar ↗Escolher o caminho não implica poder executar qualquer efeito#
Pense em um agente de operações recebendo um alerta de aumento de latência. Ele pode consultar métricas, deployments recentes, dependências, runbooks e incidentes anteriores. Não é necessário definir previamente se a investigação deve começar por métricas ou por mudanças recentes. A própria evidência encontrada em cada etapa pode orientar a próxima consulta.
Agora acrescente duas ferramentas ao mesmo agente:
Ampliar ↗A trajetória cognitiva continua parecida, mas a consequência de uma decisão ruim mudou bastante: enquanto uma consulta incorreta gera um diagnóstico pior, um rollback incorreto altera um ambiente compartilhado e pode ampliar o incidente que o agente deveria resolver.
Essa diferença tende a desaparecer quando tudo é modelado apenas como tool calling. Para o LLM, consultar métricas e reiniciar um serviço podem ser duas funções descritas no mesmo catálogo. Para a arquitetura, elas representam níveis muito diferentes de autoridade.
O ponto fica ainda mais claro em outros domínios. Um agente de atendimento pode consultar o status de uma cobrança, preparar um pedido de estorno ou efetivamente aprovar o estorno. Um coding agent pode ler um repositório, gerar um patch, abrir um pull request, fazer merge e iniciar um deploy. O fato de essas operações serem tecnicamente acessíveis ao runtime não significa que devam estar igualmente disponíveis para qualquer execução.
Capability e authority precisam aparecer separadas no desenho#
Tenho usado uma separação simples para raciocinar sobre isso. Capability descreve o que a plataforma consegue fazer. Authority descreve o que uma determinada execução pode fazer naquele contexto, usando aquela identidade e sob aquelas condições.
Uma API de pagamentos pode oferecer a capability para transferir dinheiro. A autoridade concedida a um agente pode ser muito mais estreita: consultar dados, preparar os parâmetros da transação e solicitar aprovação. O serviço continua capaz de movimentar valores, mas essa capacidade não precisa estar diretamente disponível ao componente que interpreta linguagem natural.
Esse recorte ajuda também a avaliar catálogos de ferramentas. Um conjunto com search_logs, get_metrics e read_ticket expõe uma superfície operacional pequena. Outro com delete_customer, transfer_funds e deploy_release muda o perfil de risco mesmo que os dois usem exatamente o mesmo protocolo de tool calling.
Em sistemas com agentes, portanto, o catálogo de tools também funciona como uma forma de política. Ele define parte do espaço de ações que o modelo consegue alcançar.
Ampliar ↗Read e write ajudam, mas a fronteira real está no efeito#
Separar ferramentas de leitura e escrita é um bom começo, mas ainda é um corte grosseiro. Há operações de escrita que apenas preparam algo para revisão e outras que produzem um efeito externo imediatamente.
Ampliar ↗Essa diferença é útil porque permite manter parte da autonomia sem entregar, junto com ela, toda a autoridade disponível no processo.
O agente pode elaborar a ação, montar os parâmetros, reunir evidências e explicar por que acredita que aquela é a próxima etapa adequada. A execução do efeito pode depender de outra decisão, feita por política determinística, por uma identidade com privilégios específicos ou por aprovação humana.
Esse desenho não elimina decisões ruins do modelo. Ele limita a distância que uma decisão ruim consegue percorrer sem encontrar outra fronteira.
Aprovação humana precisa estar ligada ao que foi aprovado#
Human-in-the-loop costuma aparecer em diagramas como um bloco entre o agente e a ação. Na implementação, o detalhe importante é o que exatamente aquela aprovação autoriza.
Imagine uma transferência preparada pelo agente com valor, destinatário e conta de origem. O usuário revisa esses dados e aprova. Se qualquer um desses parâmetros mudar depois, a aprovação anterior não deveria continuar válida automaticamente.
Um estado como:
Ampliar ↗é insuficiente para representar essa relação. A aprovação precisa estar associada à ação concreta, aos parâmetros apresentados, ao aprovador e, quando fizer sentido, a um prazo ou a uma execução específica.
O mesmo vale para retries. Um timeout de transporte não deveria permitir que uma autorização criada para uma tentativa fosse reutilizada indefinidamente ou aplicada a um payload diferente. Quanto mais próximo o agente chega de efeitos financeiros, alterações de produção ou comunicação externa, mais importante fica tratar aprovação como um artefato verificável, e não como um booleano perdido no estado da conversa.
Ampliar ↗Falha de controle não deveria aumentar a autoridade#
Há um padrão de fallback que funciona bem para disponibilidade e é perigoso quando aplicado a autorização. Um componente falha e o sistema tenta um caminho mais permissivo para continuar operando.
Se um serviço de policy estiver indisponível, por exemplo, executar a ação diretamente preserva disponibilidade às custas do controle que deveria decidir se aquela ação era permitida. O mesmo problema aparece quando uma identidade específica não pode ser obtida e o sistema cai para uma service account mais ampla, ou quando uma ferramenta restrita falha e o agente recebe acesso a uma ferramenta genérica com privilégios maiores.
Para side effects relevantes, eu prefiro a propriedade oposta: quanto menor a confiança sobre identidade, política ou contexto, menor a autoridade disponível para aquela execução.
Isso aproxima o desenho de um comportamento fail-closed. Uma falha na consulta de métricas pode resultar em uma análise incompleta. Uma falha no componente que decide se uma transferência é autorizada deveria impedir a transferência, não abrir uma rota alternativa mais ampla.
O modelo pode propor; outro componente pode autorizar#
Uma forma de tornar essa fronteira explícita é separar proposta, decisão de política e execução do efeito.
Ampliar ↗O agente continua sendo responsável por interpretar contexto e sugerir a próxima ação. Pode produzir algo estruturado como:
Ampliar ↗A decisão de política avalia informações que não precisam ficar sob controle do modelo: identidade, papel, limite financeiro, ambiente, segregação de função, risco da operação, estado da transação e versão da política aplicável.
Ampliar ↗O componente que possui a credencial capaz de executar o reembolso verifica essa decisão antes de produzir o efeito.
Essa separação é especialmente útil porque uma resposta plausível do modelo deixa de ser equivalente a uma autorização. Prompt injection, hallucination, contexto incompleto e classificação incorreta continuam sendo riscos, mas o impacto possível passa a depender também das fronteiras implementadas fora do modelo.
Credenciais amplas anulam parte dessa separação#
A arquitetura fica incoerente quando o prompt restringe o comportamento e a identidade usada pelo runtime continua excessivamente privilegiada.
Um system prompt pode dizer que o agente só deve consultar dados. Se a credencial disponível para a ferramenta também permite alteração e exclusão, a restrição mais importante está sendo implementada no componente menos determinístico da cadeia.
Quando a infraestrutura permite, acho melhor reduzir a capacidade efetivamente disponível: credenciais read-only, tokens de curta duração, restrição por recurso, scopes específicos, allowlists e endpoints voltados a operações delimitadas.
O prompt continua tendo função. Ele orienta a decisão do agente e ajuda a produzir comportamento coerente. Só não deveria ser a única barreira entre uma interpretação probabilística e um efeito sensível.
Autonomia faz mais sentido quando é atribuída à ação#
Também tenho evitado classificar uma aplicação inteira como “autônoma” ou “com HITL”. Dentro do mesmo agente, ações diferentes podem justificar níveis diferentes de controle.
Ampliar ↗Essa gradação me parece mais útil do que aplicar um único nível de autonomia ao sistema inteiro. Consultar documentação ou produzir um diagnóstico pode acontecer sem aprovação, enquanto alterar configuração, executar rollback ou movimentar valor atravessa fronteiras operacionais diferentes.
Melhorar reasoning, tool use ou planejamento pode justificar entregar problemas mais complexos ao agente. Isso não implica ampliar, na mesma proporção, as permissões que ele recebe.
O bounded agent acabou servindo como um exemplo dessa separação#
No Controlled Autonomy Lab, o objetivo inicial era comparar trajetórias de execução e observar o que mudava quando parte da escolha do próximo passo saía do código e passava para o modelo.
O bounded agent acabou representando bem essa separação. Ele escolhe quais evidências consultar e em qual ordem, enquanto permissões, budgets e capacidade de ação permanecem definidos pela aplicação. A autonomia está na investigação; a fronteira de autoridade continua explícita.
Isso não significa que agentes de produção devam permanecer read-only. Em muitos processos, o valor aparece justamente quando o sistema consegue concluir uma ação. O ponto é tratar a passagem entre decisão e efeito como uma fronteira arquitetural própria, com controles proporcionais ao impacto daquela ação.
A partir daí surge outra questão. Se uma ação precisa de autorização, qual identidade está efetivamente exercendo essa autoridade: o usuário, o agente, a workload que o hospeda ou uma autoridade delegada?
Esse é o próximo problema que quero explorar.