Eu passei os últimos dois anos ajustando prompts. Colocava “aja como um especialista”, definia o formato de saída exato e torcia para o modelo não alucinar na resposta. Funcionava bem para escrever e-mails, mas em produção, a história era outra.
A lógica de tentar extrair a resposta certa apenas com texto — o modelo “chat-first” — é frágil. Quando você coloca um LLM (Large Language Model) para processar dados de clientes ou tomar decisões de roteamento em um sistema, ele sofre de degradação silenciosa. O modelo falha em casos isolados, gera uma resposta gramaticalmente perfeita, mas factualmente errada. Como o texto parece normal, os sistemas de monitoramento não disparam alertas.
O foco mudou. Não tentamos mais adivinhar o prompt perfeito. Nós damos ferramentas para o modelo e pedimos para ele agir. É a transição para os fluxos de trabalho agênticos (agentic workflows).
Como os agentes diferem dos prompts tradicionais
No modelo antigo, você enviava uma pergunta, o modelo processava a string com base nos pesos da rede neural e devolvia outra string.
Em um sistema agêntico, o modelo atua como um motor de raciocínio. Você entrega um objetivo (“Resolva o ticket de suporte do cliente #4022”) e um conjunto de ferramentas (uma API do Jira, acesso ao banco de dados no PostgreSQL e uma função de envio de e-mail).
O agente não devolve a resposta de uma vez. Ele gera um plano de execução. Primeiro, ele percebe que precisa dos dados do cliente. Ele escreve uma query SQL, chama a ferramenta do PostgreSQL e analisa o retorno. Depois, entende que o problema é de faturamento. Ele acessa a API da Stripe para verificar o status do pagamento. Se o pagamento falhou, ele aciona a ferramenta de e-mail para avisar o cliente e fecha o ticket no Jira.
Ele erra no meio do processo. A query SQL falha por causa de uma aspa mal colocada. O agente lê a mensagem de erro, corrige a sintaxe e tenta de novo. Essa capacidade de iterar, testar e usar o mundo exterior como verificador de fatos reduz a alucinação quase a zero nas tarefas operacionais.
A arquitetura de um agente na prática
Você não precisa construir isso do zero. Bibliotecas de orquestração estruturam esse fluxo em componentes claros.
O padrão ReAct
A abordagem mais testada em produção é o ReAct (Reasoning and Acting). O modelo opera em ciclos de Pensamento, Ação e Observação.
- Pensamento: O modelo analisa o estado atual e decide o próximo passo.
- Ação: Ele invoca uma função externa (uma busca na web, um cálculo matemático, um POST em uma API).
- Observação: Ele absorve o resultado da função e inicia um novo ciclo de pensamento.
graph TD
A[Objetivo / Prompt Inicial] --> B(Pensamento: O que devo fazer agora?)
B --> C{Ação: Qual ferramenta usar?}
C -->|API ou Banco de Dados| D[Observação: Resultado da Ferramenta]
D --> B
C -->|Resposta Final| E[Fim do Processo]Isso transfere a carga de processamento do conhecimento interno do modelo para os sistemas externos. O LLM não precisa “saber” o preço atualizado da assinatura — ele só precisa saber como chamar a API de precificação.
Memória e persistência
Para que o agente funcione em tarefas complexas, ele precisa lembrar do que já fez. Sem memória, ele entra em loops infinitos, chamando a mesma API repetidas vezes com os mesmos parâmetros.
A arquitetura padrão usa um banco de dados vetorial ou grafos para manter o contexto. Cada passo do agente é registrado. Antes de agir, ele consulta o próprio histórico. O LangGraph é a biblioteca dominante para criar esses grafos de estado. Ela permite definir ciclos de execução onde o agente pode pausar e pedir aprovação humana antes de executar ações destrutivas, como deletar uma conta ou reembolsar um cliente.
Orquestração nativa na AWS
Levar isso para a nuvem exige infraestrutura específica. Subir scripts Python funciona em provas de conceito, mas a gestão de chaves de API, escalabilidade e controle de latência quebram em produção.
O Amazon Bedrock Agents abstraiu a maior parte dessa complexidade. Em vez de escrever o loop de execução na mão, você fornece uma especificação OpenAPI (Swagger). O Bedrock lê os endpoints disponíveis e mapeia quais funções o agente pode chamar.
Quando o agente decide executar uma ação, o Bedrock aciona diretamente uma função Lambda. Isso elimina a necessidade de expor credenciais para o modelo ou lidar com o roteamento interno manualmente.
Os filtros de segurança também mudaram. O Amazon Bedrock Guardrails não faz apenas filtragem de palavras ofensivas. Ele cruza a resposta do agente com os documentos da empresa em tempo real, bloqueando ações que fogem das políticas corporativas ou revelam dados pessoais nas chamadas de ferramenta.
[INSERIR IMAGEM: Captura de tela da configuração de políticas do Amazon Bedrock Guardrails destacando o bloqueio de PII]
Monitoramento de agentes em produção
Colocar um agente no ar introduz um risco sistêmico: como você depura um sistema não determinístico? Se o agente tomou a decisão errada, qual parte do processo falhou? Foi a interpretação inicial ou o retorno da API?
A rotina do engenheiro de machine learning passou da formatação do prompt para a criação de pipelines de avaliação.
Rastreabilidade do raciocínio
Cada passo precisa ser registrado em logs estruturados. Exemplo de um rastro de execução:
{
"agent_id": "support_agent_01",
"step": "action",
"tool_invoked": "postgres_query",
"input": "SELECT status FROM payments WHERE client_id = 4022",
"observation": "ERROR: syntax error at or near '4022'",
"next_thought": "A query falhou. Preciso formatar o client_id como string e tentar novamente."
}Ferramentas de observabilidade capturam essa cadeia de pensamentos do agente. Se ele falhou em resolver o ticket, o engenheiro revisa o grafo de execução, identifica que a ferramenta de busca interna não retornou o documento certo e ajusta a indexação do banco de dados — não o prompt do modelo.
Modelos avaliando modelos
Auditar manualmente os logs de milhares de execuções é impossível. A indústria resolveu isso usando LLM-as-a-Judge. Você coloca um modelo maior, como o Claude 3.5 Sonnet, para rodar em segundo plano analisando as decisões tomadas por agentes menores, como o Haiku.
O modelo juiz lê a transcrição da ação do agente e avalia a precisão técnica e a adesão às regras de negócio. As execuções com nota baixa caem na fila para revisão humana.
A engenharia de prompts baseada em testar dezenas de variações de palavras morreu. O trabalho agora é desenhar arquiteturas de software onde a IA atua como o módulo de orquestração conectando sistemas tradicionais.
Referências técnicas
- Bedrock na prática: Documentação oficial do Amazon Bedrock Agents sobre integração de ferramentas.
- Orquestração de estado: Repositório do LangGraph para modelagem de agentes baseada em grafos.
- Avaliação em produção: Padrões de arquitetura para implementar LLM-as-a-Judge e rastrear execuções.