Criar um agente de IA é fácil. Colocá-lo em produção é outra história.

Isso não é falta de competência técnica. É a consequência natural de tratar um agente como se fosse só "um prompt bem escrito rodando em loop". Essa abordagem tem um teto baixo, e esse teto aparece rápido quando o ambiente é real.

O que realmente acontece quando um agente sai do laboratório

Quando um agente passa a operar em produção, com usuários reais, dados reais e volume real, uma série de problemas emerge que simplesmente não aparecem nos testes controlados:

Perda de contexto. Conversas longas ou tarefas com múltiplas etapas fazem o agente esquecer decisões tomadas anteriormente, repetir perguntas já respondidas ou contradizer ações que ele mesmo executou.

Loops infinitos. Sem mecanismos claros de parada, um agente que depende de si mesmo para decidir o próximo passo pode entrar em ciclos de tentativa e erro que nunca convergem, e que o usuário nem percebe até a fatura chegar.

Estado inconsistente. Este é o problema que mais subestimamos quando saímos do protótipo. Um agente pode raciocinar corretamente e, mesmo assim, executar a mesma ação duas vezes, perder o ponto de retomada após uma falha ou assumir que uma etapa foi concluída quando não foi. Memória conversacional e estado de execução são problemas diferentes. O primeiro trata de "o que foi dito". O segundo trata de "o que foi feito, em qual etapa e o que ainda pode ser refeito com segurança". Tratar os dois como a mesma coisa é uma das causas mais comuns de comportamento imprevisível em produção.

Alto consumo de tokens. Cada chamada adicional, cada retry, cada contexto reenviado por falta de memória estruturada tem custo. Em escala, esse custo deixa de ser marginal e passa a ser uma linha relevante no orçamento de engenharia.

Respostas não verificadas. Um agente que executa ações (chamar uma API, escrever em um banco, gerar um documento) sem nenhuma camada de validação está, na prática, colocando a confiabilidade do sistema nas mãos de um componente probabilístico. Isso funciona até o dia em que não funciona.

Custos crescentes sem controle. A soma de tudo isso é um sistema que fica mais caro conforme escala, exatamente o oposto do que se espera de uma arquitetura de software madura.

Por que Prompt Engineering sozinho não resolve isso

Prompt Engineering foi essencial na primeira onda, quando o problema central era "como fazer o modelo entender o que eu quero". Prompt design, system prompts, structured outputs, instruções de tool use e políticas de comportamento continuam sendo componentes importantes, e continuarão sendo. Mas eles deixaram de ser suficientes.

O problema atual é outro: como fazer um sistema baseado em componentes probabilísticos operar com previsibilidade, custo controlado e confiabilidade de produção. Isso não se resolve ajustando a redação de um prompt. Isso se resolve com engenharia, desenhando estado, execução, observabilidade, avaliação e mecanismos de segurança ao redor do modelo.

Em produção, o modelo não deve ser o sistema. Ele deve ser um componente probabilístico dentro de uma arquitetura cuja camada de controle estabelece fronteiras determinísticas de estado, autorização, execução, observabilidade e recuperação de falhas. E quanto maior o impacto da decisão, menor deve ser a autonomia irrestrita desse componente.

O que realmente exige um agente confiável em produção

Depois de levar múltiplos agentes para produção em contextos diferentes (jurídico, financeiro, recrutamento), cheguei a um conjunto de pilares que considero não negociáveis:

• Arquitetura e limites de autonomia
• Estado, memória e execução durável
• Segurança, autorização e controle de acesso
• Observabilidade e SLOs
• Avaliação contínua da trajetória, não só da resposta final
• Controle de custo por orçamento de execução

Arquitetura e limites de autonomia

O ponto de partida é a separação clara entre a camada determinística de execução e a camada probabilística de decisão do modelo. O agente decide o quê, o sistema garante o como. Ou, em fluxos de maior risco: o agente interpreta, planeja e propõe; o sistema valida, autoriza e controla a execução.

Autonomia também precisa ser uma decisão arquitetural, não uma consequência do que o modelo é tecnicamente capaz de fazer. Nem toda ferramenta disponível para um agente deveria poder ser executada livremente. Uma arquitetura madura define limites de ação, scopes de autorização, budgets e políticas de aprovação por nível de risco. Em vez de perguntar apenas "o agente consegue executar isso?", a pergunta correta é "em quais condições ele está autorizado a executar isso?".

Em operações críticas, como movimentação financeira ou decisão jurídica, o agente pode interpretar, planejar e recomendar, enquanto regras determinísticas e mecanismos de autorização continuam controlando a execução.

Estado, memória e execução durável

Memória é sobre contexto conversacional, estruturada e com escopo definido, não "jogar o histórico inteiro no contexto" a cada chamada. Estado é sobre execução, e aqui entra um conceito que considero central na engenharia de agentes atual: execução durável.

Workflows agentic não podem depender da expectativa de que todo o fluxo terminará em uma única execução ininterrupta. Um processo pode falhar, um worker pode reiniciar, uma API externa pode ficar indisponível, uma credencial pode expirar, e uma aprovação humana pode levar horas. Por isso, agentes em produção precisam persistir estado, criar checkpoints e ser capazes de retomar a execução exatamente de onde pararam, sem repetir efeitos colaterais já realizados. A idempotência é uma das garantias fundamentais nesse desenho, ao lado de deduplicação, retries e compensação. Na prática, em muitos sistemas distribuídos trabalhamos com entrega at-least-once e projetamos handlers idempotentes, deduplicação e controle de side effects para obter semântica effectively-once no nível da operação.

Segurança, autorização e controle de acesso

Quando um agente ganha tool use, acesso a banco de dados, APIs e sistemas corporativos, segurança deixa de ser um item de checklist e vira arquitetura. Cada ferramenta precisa operar com least privilege, scopes específicos, validação de parâmetros e trilhas de auditoria.

Prompt injection deixa de ser apenas um problema de conteúdo quando o agente possui capacidade de execução. Uma instrução maliciosa embutida em um documento, um e-mail ou uma resposta de API pode resultar em acesso indevido a dados, chamadas externas não autorizadas ou alterações de estado. Tratar isso como superfície de ataque, e não como detalhe de prompt, é o que diferencia um sistema pronto para ambiente enterprise de um protótipo exposto.

Segurança também inclui governança dos dados que atravessam o agente: quais informações entram no contexto, quais podem ser persistidas, quais podem sair do perímetro da organização e quem pode recuperá-las depois.

Observabilidade e SLOs

Observabilidade responde a uma pergunta: o que aconteceu? Latência, custo por interação, task completion rate, tool error rate, fallback rate e taxa de intervenção humana precisam estar instrumentados desde o dia um.

Algumas dessas métricas aparecem tanto em observabilidade quanto em avaliação; a diferença está no que fazemos com elas. Observabilidade explica a execução. Evals julgam sua qualidade.

Produção também exige SLOs. Não basta saber que o agente "funciona na maioria das vezes". Precisamos definir o que sucesso significa: taxa de conclusão de tarefas, p95 de latência (e p99 quando o volume justificar), custo máximo por execução, taxa aceitável de fallback e percentual de intervenções humanas. Sem isso, confiabilidade continua sendo uma percepção, não uma propriedade mensurável do sistema.

Avaliação contínua da trajetória

Avaliação responde a uma pergunta diferente da observabilidade: o comportamento foi bom? E avaliar um agente não significa apenas comparar a resposta final com uma resposta esperada.

Em sistemas agentic precisamos avaliar a trajetória: se a ferramenta correta foi escolhida, se os argumentos enviados estavam corretos, se houve chamadas desnecessárias, se políticas foram respeitadas e se o objetivo final foi realmente concluído. Vale inclusive separar duas métricas que costumam ser tratadas como uma só: tool selection accuracy, se a ferramenta certa foi escolhida, e tool invocation success, se essa ferramenta executou corretamente. Um agente pode acertar a segunda e errar a primeira, e nesse caso a chamada retorna sucesso técnico sobre uma decisão semanticamente errada. Isso envolve métricas como task completion rate, tool selection accuracy, tool invocation success, policy adherence e, em cenários com retrieval, groundedness. Muitas falhas não aparecem na resposta final. Aparecem no caminho utilizado para chegar até ela.

Nada disso é útil sem versionamento e rastreabilidade. Modelo, prompts, tool schemas, políticas, configuração de retrieval e grafo de execução precisam estar associados à execução que produziram, incluindo, em cenários de RAG, quais documentos e trechos foram usados. Sem essa trilha, reproduzir uma falha ou explicar uma regressão se torna quase impossível.

Controle de custo por orçamento de execução

Todo agente deveria operar dentro de um orçamento de execução definido antes de rodar, não observado depois. Número máximo de passos, retries, tokens, tempo e custo não deveriam ser consequências descobertas em produção, mas limites arquiteturais desde o desenho do fluxo. Um agente sem budget é, na prática, um processo probabilístico com acesso potencialmente ilimitado a recursos computacionais, e é exatamente esse desenho que produz loops infinitos e faturas fora de controle.

Contendo falhas: failure domains e human-in-the-loop

Uma arquitetura madura também procura conter falhas, não apenas evitá-las. Uma resposta ruim do modelo não deveria automaticamente virar uma operação ruim no sistema. Um timeout de uma ferramenta não deveria necessariamente derrubar o workflow inteiro. Modelo, ferramentas, memória, retrieval e sistemas externos precisam ter failure domains claros, permitindo retry, fallback, degradação controlada ou escalonamento para intervenção humana. O objetivo não é eliminar toda possibilidade de falha, algo impossível em sistemas distribuídos, mas limitar o blast radius quando ela acontecer.

E human-in-the-loop não é necessariamente sinal de que o agente falhou. Em processos de alto risco, como os que costumo encontrar em contextos financeiros, jurídicos e de recrutamento, pode ser uma decisão deliberada de arquitetura. O sistema deve saber quando continuar autonomamente, quando solicitar confirmação e quando escalar a decisão para uma pessoa.

O que fica de fora, de propósito

Não coloquei frameworks ou plataformas específicas no centro deste artigo, sejam frameworks agentic como LangGraph e CrewAI, engines de durable execution como Temporal, ou SDKs de agentes. São categorias diferentes de ferramenta, resolvendo problemas diferentes. Frameworks evoluem rápido e escolhas de stack mudam. Os princípios continuam: estado, autorização, execução durável, observabilidade, avaliação de trajetória e controle de custo valem independentemente da stack escolhida.

O curioso é que boa parte dessa engenharia não nasceu com a IA. Idempotência, observabilidade, retries, circuit breakers, máquinas de estado, autorização e fallback já existiam muito antes de qualquer LLM. O que mudou foi termos colocado um componente probabilístico no centro de fluxos que antes eram predominantemente determinísticos. A disciplina de engenharia continua sendo a mesma. O que muda é onde e como ela precisa ser aplicada.

A diferença entre demo e produção

Em uma demo, o objetivo é mostrar que o agente consegue fazer alguma coisa. Em produção, o objetivo é garantir que ele faça a coisa certa, dentro dos limites certos, pelo custo esperado, e que o sistema saiba exatamente o que fazer quando isso não acontecer.

É essa diferença que separa um agente interessante de um sistema confiável.