Um agente que só sabe continuar não é autônomo. É uma tarefa em execução procurando alguém para puxar a tomada.

TL;DR

Ensinar um agente a executar uma tarefa sem definir a condição de parada é delegar risco, não trabalho. Um sistema útil precisa saber qual resultado encerra a tarefa, quanto tempo, custo e escopo pode consumir, quais ações exigem autorização humana e o que fazer quando a evidência é insuficiente ou o mesmo erro se repete. Parar não é falhar: pode ser concluir, pedir uma decisão, recusar uma ação fora de autoridade ou voltar a um estado seguro. A autonomia responsável não se mede pelo número de passos que a máquina deu sozinha. Mede-se pelo quanto ela consegue fazer sem ultrapassar a fronteira que deveria continuar humana.

Existe uma mania meio infantil de medir agente pelo quanto ele parece disposto.

Ele pesquisa. Abre abas. Chama ferramentas. Cria arquivos. Tenta outra vez. Chama mais uma ferramenta. Quando as tentativas falham sem trazer evidência nova ou mudar a condição do problema, faz o que muito sistema faz quando ninguém ensinou o contrário: continua executando.

Na demonstração, isso parece autonomia.

Na operação, pode ser só uma forma mais cara de não saber terminar.

Um agente não precisa apenas de uma lista de coisas que pode fazer. Precisa de um contrato de parada: as condições em que deve concluir, suspender, pedir decisão, recusar uma ação ou voltar atrás.

Sem isso, “seja proativo” vira a instrução técnica equivalente a entregar uma furadeira para alguém e sair da sala antes de explicar onde passam os canos.

Executar é só metade do verbo

Uma automação determinística costuma ter um fim bem comportado: recebeu a entrada, aplicou a regra, produziu a saída. Se uma condição não fecha, ela falha e informa o erro — ou deveria.

Um agente tem mais margem para escolher o próximo passo. Pode pesquisar, comparar fontes, consultar um sistema, preparar um rascunho ou coordenar outras tarefas. Essa margem é justamente o que o torna útil em trabalhos menos lineares.

Também é o que torna insuficiente dizer apenas: “resolva isto”.

Resolver o quê, exatamente? Até que ponto? Com que fontes? Em quanto tempo? Com qual custo? O que vale como resposta aceitável? Quem decide quando uma exceção sai da autoridade do sistema?

O NIST AI Risk Management Framework trata risco como algo dependente do contexto de uso e destaca que tolerância a risco não é prescrita pelo documento: ela precisa ser definida por quem responde pelo sistema. É uma estrutura voluntária, não uma receita pronta para agentes. Mas ajuda a colocar a pergunta no lugar certo: o limite não nasce do modelo. Nasce da consequência que a operação aceita ou não aceita.

Uma boa condição de parada transforma essa consequência em comportamento observável.

Quatro formas corretas de parar

“Parar” não significa que toda tarefa termina em erro vermelho e alguém perde a tarde. Um agente bem desenhado pode chegar a quatro finais legítimos:

1. Concluir: entregou o resultado que atende aos critérios de aceite definidos antes. Critério de aceite é a condição verificável que separa “parece pronto” de “está pronto para este uso”.
2. Escalonar: encontrou uma decisão que precisa de alguém com autoridade, contexto de negócio ou responsabilidade que o sistema não possui.
3. Abster-se: não há evidência suficiente para uma recomendação confiável, as fontes divergem ou a tarefa pede uma afirmação que ele não pode sustentar.
4. Recuar: houve falha, repetição improdutiva ou risco acima do limite; o sistema interrompe a tentativa e preserva ou restaura um estado seguro quando isso for possível.

O problema não é um agente chegar ao segundo, terceiro ou quarto final.

O problema é escondê-los porque a apresentação comercial prefere fingir que toda rota termina em “feito”.

Limite não é um botão vermelho gigante

Quando alguém fala em limitar um agente, muita gente imagina um único freio de emergência. Ele é necessário em alguns contextos, mas não resolve sozinho o problema.

Uma autonomia saudável costuma ter limites em camadas:

Limite	Pergunta que ele responde	Exemplo prático
Tempo	Quanto uma tarefa pode durar antes de perder valor?	Interromper uma pesquisa depois de 20 minutos sem fonte suficiente e devolver a lacuna.
Custo	Quanto recurso pode ser consumido para este benefício?	Encerrar uma cadeia de consultas antes de transformar uma resposta simples numa pequena auditoria financeira.
Escopo	Quais sistemas, dados e ações pertencem a esta tarefa?	Consultar o sistema de gestão de relacionamento com clientes (CRM) para preparar uma resposta, mas não alterar cadastro ou enviar mensagem.
Autoridade	O que o sistema pode fazer sozinho e o que só pode recomendar?	Preparar um pagamento; nunca aprová-lo ou executá-lo sem a pessoa responsável.
Repetição	Quantas tentativas idênticas deixam de ser persistência e viram um ciclo de tentativas sem avanço (loop)?	Parar depois de duas falhas da mesma integração e abrir um incidente com contexto.
Irreversibilidade	Qual ação não pode ser desfeita com segurança?	Pedir aprovação antes de apagar dados, revogar acesso, publicar ou comunicar algo externamente.

Isso não é burocracia colocada em cima da IA para estragar a diversão.

É o que reduz o risco de enviar um e-mail errado para cinco mil pessoas quando uma instrução ambígua como “limpar a base” é executada sem revisão.

Escalonar não é transferir qualquer decisão para um humano cansado

Também existe o extremo oposto: um “agente” que pede aprovação para cada clique e chama isso de segurança. Se alguém precisa confirmar toda consulta, toda classificação e toda frase de um rascunho, não ganhou capacidade. Transformou cada ação de baixo risco em um gargalo de aprovação.

O ponto é delimitar a fronteira certa.

Uma tarefa de baixo impacto pode ser concluída automaticamente quando tiver entradas completas, fonte definida e critérios claros. Uma tarefa com impacto financeiro, jurídico, reputacional ou humano pede degraus adicionais de revisão. Entre uma coisa e outra há um campo enorme de recomendações, rascunhos, simulações e ações reversíveis que podem aliviar trabalho sem fingir que responsabilidade evaporou.

A documentação de segurança para agentes da OpenAI recomenda combinar controles em camadas e manter supervisão humana para ações de maior impacto. É orientação do fornecedor sobre seus próprios recursos, não uma certificação de que qualquer fluxo construído com eles está seguro. O princípio, porém, é mais amplo que uma plataforma: a revisão humana precisa ser posicionada onde ela muda a consequência, não usada como carimbo decorativo no fim.

Eu prefiro formular a regra assim:

O agente pode avançar enquanto a consequência permanece dentro da autoridade que recebeu e a evidência continua suficiente. Quando uma das duas deixa de ser verdade, ele devolve a decisão com contexto.

Devolver com contexto importa. “Não consegui” é um aviso. “Não consegui porque as duas fontes oficiais divergem, tentei estas consultas, descartei estas alternativas e preciso que você escolha entre A e B” é uma passagem de bastão.

Evidência terminal: o recibo de que a tarefa terminou

Em sistemas mais complexos, a resposta final não deveria ser apenas uma frase simpática dizendo que tudo foi resolvido. Ela precisa deixar um registro terminal: a evidência mínima de que a tarefa terminou, de que forma terminou e o que ficou pendente.

Para cada execução relevante, eu quero conseguir responder:

• qual objetivo recebeu;
• quais fontes, ferramentas e permissões foram usadas;
• qual critério de aceite foi satisfeito — ou qual não foi;
• que ação foi tomada, por quem e sob qual autorização;
• que incerteza, exceção ou risco residual permaneceu;
• como voltar atrás, quando houve mudança reversível;
• quem precisa decidir o próximo passo, quando o resultado for escalonado.

Não é necessário registrar cada pensamento intermediário, muito menos despejar dados sensíveis em um registro de eventos (log). Registro útil não é voyeurismo de máquina. É rastreabilidade suficiente para conferir uma decisão, corrigir o fluxo e não precisar reconstituir o incidente por arqueologia digital.

Essa é uma diferença importante entre o agente que parece ocupado e o sistema que pode ser operado depois que a pessoa que o configurou saiu de férias.

Ações irreversíveis merecem uma fronteira explícita

Há ações que podem ser desfeitas sem drama: salvar um rascunho, criar uma tarefa interna, produzir uma simulação, marcar uma divergência para revisão.

Há outras que se espalham pelo mundo antes de alguém conseguir pedir desculpas: publicar um comunicado, excluir dados, alterar permissão, enviar uma cobrança, encerrar uma conta, assumir um compromisso em nome de outra pessoa.

Não basta escrever “tenha cuidado” na instrução que orienta o sistema (prompt). Cuidado é uma qualidade humana admirável; como controle operacional, é uma gelatina conceitual.

A fronteira precisa aparecer na arquitetura: ferramentas separadas, permissões mínimas, ambiente de teste, confirmação humana quando houver impacto material e um caminho de retorno quando ele existir. No artigo sobre agentes genéricos, falei que uma demonstração quase sempre omite exceção, fonte de verdade e dono da decisão. A condição de parada é onde essas três omissões finalmente cobram a conta.

O agente não precisa ficar “menos inteligente” para aceitar uma fronteira.

Ele só precisa ser menos irresponsavelmente solto.

Repetição de erro não é perseverança

Outro sinal clássico de um contrato mal escrito é o loop que muda de roupa a cada tentativa.

Uma integração retorna erro. O agente tenta de novo. O erro retorna. Ele troca um parâmetro aleatório, tenta de novo, chama outra ferramenta, repete a mesma operação e no final produz um relatório de duzentas linhas explicando que trabalhou bastante.

Persistência é útil quando a nova tentativa traz informação nova: uma credencial foi renovada, uma dependência voltou, uma fonte adicional apareceu, uma pessoa resolveu uma ambiguidade.

Sem mudança de condição, repetir é apenas automatizar teimosia.

Por isso, o contrato precisa declarar o que conta como tentativa diferente, qual erro encerra imediatamente a operação e quando o padrão exige escalonamento. A ideia se conecta ao que escrevi em “Escreveu, não leu: a IA não assina por você”: uma saída fluente não encerra a responsabilidade. Da mesma forma, uma sequência longa de ações não prova que houve progresso.

O rollback começa antes do erro

Rollback é o nome técnico para voltar a um estado anterior conhecido quando uma alteração falha ou produz consequência indesejada. Só que ele não aparece por mágica depois do problema.

Para reverter algo, você precisa ter preservado estado, identificadores, permissões e um caminho testado antes de precisar dele. É por isso que uma cópia de recuperação (backup), versão, aprovação e limite de ação pertencem à mesma conversa.

No artigo sobre limpeza operacional, a pergunta era quando uma automação pode apagar. Aqui ela é anterior: quando um agente pode alterar alguma coisa sabendo que talvez precise desfazer?

As duas perguntas têm a mesma resposta incômoda: não quando o modelo parece confiante, mas quando a operação sabe o que está protegendo e como recupera.

Autonomia que cabe numa empresa real

Eu não quero agentes transformados em assistentes decorativos que pedem permissão até para respirar. Também não quero uma máquina solta, com acesso demais e uma instrução otimista de “faça o que for preciso”. Entre esses dois personagens existe engenharia.

Um agente pode ser muito útil ao pesquisar opções, consolidar informações, encontrar inconsistências, preparar decisões, executar ações reversíveis e organizar trabalho. Em várias situações, isso libera pessoas para o que exige negociação, contexto humano, responsabilidade, leitura de consequência e definição de direção.

Mas autonomia não é a quantidade de tarefas que você abandonou nas mãos de um sistema.

É a qualidade do limite que você conseguiu desenhar.

Na i-9.ai, isso começa antes de escolher modelo ou ferramenta: entender a tarefa, as fontes, o impacto, a autoridade, os critérios de aceite e o que deve acontecer quando a realidade foge do roteiro. Depois vem a arquitetura. E, só então, a autonomia que a empresa realmente consegue sustentar.

Se sua empresa está discutindo o que um agente poderia fazer, comece por uma pergunta menos simpática e bem mais útil: em que situação ele deve parar?

Para se aprofundar

• NIST AI Risk Management Framework 1.0: estrutura voluntária para mapear, medir, governar e gerir risco de IA; sustenta a importância de contexto, tolerância a risco e responsabilidades, mas não prescreve o desenho de um agente específico.
• OpenAI — Safety in building agents: orientação técnica sobre guardrails, limites de ferramentas e supervisão humana em fluxos de agentes; é documentação de fornecedor, não validação independente de uma implementação.
• NIST — AI RMF Playbook: exemplos operacionais associados ao framework; serve como repertório de perguntas, não substitui a definição de autoridade e risco da organização.
• Common Weakness Enumeration — CWE-636: referência para o princípio de falhar de forma segura; sua aplicação a agentes neste artigo é uma síntese operacional, não uma regra exclusiva de IA.

Referências e limites de uso

• O NIST sustenta que risco, impacto e tolerância dependem do contexto e que a governança atravessa o ciclo de vida. Ele não define qual limite de custo, tempo ou aprovação é correto para uma empresa específica.
• A documentação da OpenAI sustenta a recomendação de controles em camadas e intervenção humana em ações de maior impacto. Ela não garante que guardrails eliminem erro, abuso ou consequência inesperada.
• O CWE-636 sustenta a noção geral de não permitir que uma falha leve a um estado menos seguro. Traduzir esse princípio para “parar e escalar quando falta evidência” é a interpretação operacional defendida neste texto.

Continue lendo

• A melhor resposta não é a que mais me agrada
• Agentes genéricos podem ser seu pior primeiro contato com IA
• Se a IA vai fazer o trabalho, não demita quem sabe quando ela está errada