Agentes de IA em produção: autonomia é uma decisão arquitetural

Agentes de IA em produção: autonomia é uma decisão arquitetural.

No último artigo, falei sobre orquestração de contexto e MCP.

Sobre como entregar o contexto certo, do jeito certo, para a ferramenta certa.

Mas existe uma pergunta que vem logo depois, e que quase ninguém faz em voz alta:

Depois que o agente tem contexto e ferramentas, o que ele pode fazer sozinho?

Essa é a pergunta mais importante da era dos agentes.

E ela não é técnica.

É arquitetural.

O hype dos agentes autônomos

O discurso atual é sedutor:

• Agentes que resolvem tickets sozinhos
• Agentes que fazem deploy
• Agentes que negociam com fornecedores
• Agentes que operam sistemas financeiros
• Agentes que conversam com outros agentes

Na demo, tudo funciona.

O agente recebe um objetivo, planeja, chama ferramentas, ajusta o plano e entrega o resultado.

Impressiona.

Mas, em produção, a pergunta muda:

• O que acontece quando o agente erra?
• Quem aprovou aquela ação?
• Dá para desfazer?
• Quanto custou aquela execução de 47 passos?
• Por que ele chamou aquela API três vezes?

Se a arquitetura não responde essas perguntas, você não tem um agente.

Tem um risco operacional com interface de chat.

Agente não é feature. É sistema distribuído com autonomia.

Um agente em produção reúne quase todos os problemas clássicos de sistemas distribuídos:

• Chamadas a serviços externos que podem falhar
• Estado que precisa ser mantido entre passos
• Operações que precisam ser idempotentes
• Concorrência entre execuções
• Timeouts, retries e compensações

E adiciona um problema novo:

O fluxo não é determinístico. Quem decide o próximo passo é um modelo probabilístico.

Isso muda tudo.

Em um sistema tradicional, o arquiteto desenha o fluxo.

Em um sistema com agentes, o arquiteto desenha os limites do fluxo.

Essa é a diferença entre engenharia de software e arquitetura de IA.

Os níveis de autonomia

Quando trabalho com times adotando agentes, a primeira coisa que faço é tirar a palavra “autônomo” da conversa.

E substituir por uma escala.

Nível	O agente...	Exemplo
0 — Assistente	Sugere, o humano executa	Rascunho de resposta para o suporte
1 — Copiloto	Executa ações reversíveis com aprovação	Abre um PR para revisão
2 — Supervisionado	Executa sozinho dentro de limites, humano audita	Classifica e roteia tickets
3 — Autônomo restrito	Executa ações com impacto real dentro de um orçamento	Reembolsos até um valor-limite
4 — Autônomo	Decide e executa sem supervisão direta	Raramente justificável hoje

O ponto não é chegar ao nível 4.

O ponto é que cada ação, de cada agente, precisa ter um nível definido.

E esse nível precisa estar na arquitetura.

Não no prompt.

Por que o prompt não é um limite

Um erro que vejo com frequência:

“Coloquei no system prompt que ele não pode apagar registros.”

Isso não é controle.

É sugestão.

Prompt é instrução probabilística. Pode ser ignorado, mal interpretado ou contornado por um conteúdo malicioso vindo de um documento, um e-mail ou uma página web.

Limites reais vivem fora do modelo:

• Permissões da ferramenta, não do agente
• Escopos de credencial mínimos
• Listas de ações permitidas por contexto
• Validação de parâmetros antes da execução
• Aprovação humana como etapa do fluxo, não como pedido educado

Se o agente não consegue apagar registros porque a ferramenta não expõe essa operação, você tem um limite.

Se ele não deveria apagar porque o prompt pediu, você tem uma esperança.

Quatro decisões arquiteturais antes de colocar um agente em produção

1. Classifique as ações por reversibilidade e impacto

Toda ferramenta que o agente acessa deve ser classificada:

• Leitura — consultar dados
• Escrita reversível — criar rascunho, abrir PR, agendar
• Escrita irreversível — enviar e-mail, pagar, apagar, publicar

Ações irreversíveis não deveriam passar sem uma etapa de confirmação explícita.

Simples assim.

2. Dê orçamento ao agente

Agentes sem limite de passos, tempo e custo são uma fatura esperando para acontecer.

Defina por execução:

• Número máximo de passos
• Tempo máximo
• Custo máximo em tokens
• Número máximo de chamadas por ferramenta

Quando o orçamento acaba, o agente para e escala para um humano.

Isso conecta diretamente com o que escrevi sobre custo de IA em produção: o preço do token é só o começo. O custo real está no comportamento do sistema.

3. Trate cada execução como uma transação auditável

Cada execução de agente deveria gerar um registro com:

• Objetivo recebido
• Contexto utilizado
• Plano gerado
• Cada ferramenta chamada, com parâmetros e resultado
• Decisões tomadas e por quê
• Custo e duração

Sem isso, você não consegue explicar o que aconteceu.

E se não consegue explicar, não consegue confiar.

4. Desenhe o caminho de falha antes do caminho feliz

A pergunta não é “o agente consegue resolver?”.

A pergunta é “o que acontece quando ele não consegue?”.

• Ele para ou insiste?
• Ele escala para quem?
• O estado parcial fica consistente?
• Existe compensação para ações já executadas?

Agente bom não é o que nunca falha.

É o que falha de forma previsível.

Multiagentes: mais agentes, mais arquitetura

Muitas equipes, ao encontrar limites em um agente, respondem criando mais agentes.

Um planejador. Um executor. Um revisor. Um agente que coordena os outros.

Às vezes faz sentido.

Mas cada agente adicional multiplica:

• Pontos de falha
• Custo
• Latência
• Dificuldade de rastrear uma decisão

Antes de adicionar um agente, vale perguntar:

Isso precisa de outro agente ou de uma etapa determinística bem desenhada?

Na maioria das vezes, um fluxo determinístico com um modelo chamado nos pontos certos é mais barato, mais rápido e mais confiável do que uma sociedade de agentes conversando entre si.

O papel do arquiteto na era dos agentes

O arquiteto de IA não é quem escolhe o framework de agentes da moda.

É quem responde:

• Onde o modelo decide e onde o sistema decide
• Quais ações exigem humano no circuito
• Quais limites são garantidos pela infraestrutura
• Como cada execução é rastreada e auditada
• Como o sistema se comporta quando o modelo erra

Isso é o que transforma agente de demo em agente de operação.

Reflexão final

Autonomia não é um recurso que você liga no modelo.

É um orçamento de confiança que você concede ao sistema.

E esse orçamento deveria crescer na mesma medida da sua capacidade de observar, limitar e corrigir o que o agente faz.

Empresas que tratarem autonomia como configuração vão colecionar incidentes.

Empresas que tratarem autonomia como decisão arquitetural vão escalar agentes com segurança.

No próximo artigo, vou aprofundar justamente a base que sustenta tudo isso: observabilidade em sistemas de IA.

Porque não existe autonomia sem rastreabilidade.