Pra mim, um agente em produção comporta-se como um sistema fechado, capaz de receber uma tarefa ambígua e levá-la até uma condição de término reconhecível, decompondo o problema em passos e ajustando a trajetória conforme observa o retorno de cada ação externa. Um agente que não funciona costuma falhar pelo mesmo motivo de fundo: percebe mal o estado do ambiente e age sobre informação incompleta, ou perde dentro da execução o que já tinha aprendido. Na minha avaliação, a diferença entre os dois está na presença simultânea de quatro capacidades operando de forma coordenada. Quando uma é fraca, as outras compensam por algum tempo e depois colapsam.
A percepção do estado do ambiente no momento da decisão é onde tudo começa. Antes do raciocínio, o agente precisa separar o que está dado do que está apenas implícito, identificando o que precisa ser consultado externamente. Isso envolve ler o prompt e inspecionar o histórico da conversa, consultar ferramentas que expõem o estado do sistema externo e, a partir daí, reconstruir uma representação operacional do problema. Agentes que pulam essa etapa produzem planos baseados em suposições do modelo sobre como o mundo costuma estar, e não sobre como ele está. O efeito é imediato em tarefas que envolvem dados vivos: o agente responde com confiança sobre um arquivo já removido, ou sobre um registro cujo schema mudou e cujo serviço, naquela mesma sessão, já retornou erro duas vezes. A fragilidade aqui não vem do modelo inventar, mas da ausência de um passo explícito de leitura do ambiente antes do planejamento.
Sobre essa leitura incide o raciocínio, que num agente eficaz nunca é uma única passada do modelo gerando resposta direta. Na minha análise, o raciocínio útil opera em camadas: separa a definição do objetivo da escolha de estratégia, e separa essa estratégia da enumeração dos passos que vão de fato ser executados. Isso permite que o agente reconsidere sem refazer tudo e identifique quando um passo falha por razão local versus quando a estratégia inteira precisa ser descartada, mantendo decisões intermediárias num formato inspecionável depois. Agentes que acoplam raciocínio e ação num único passo produzem trajetórias que parecem competentes enquanto tudo vai bem e se tornam opacas no primeiro erro, até porque não existe um plano explícito contra o qual comparar o desvio. A diferença entre raciocínio implícito e raciocínio registrado é a diferença entre um agente que você opera e um que só consegue reiniciar.
A ação sobre o mundo externo por meio de ferramentas é onde a maior parte das falhas operacionais se concentra. Um agente age quando chama uma função ou executa código local, e quando toca o mundo externo via API, banco ou e-mail. Cada uma dessas ações carrega latência e taxa de falha próprias, com semântica de retry específica e efeitos colaterais que podem ou não ser reversíveis. Pra mim, um agente eficaz trata ferramentas como superfícies com contrato, e não como primitivas neutras: distingue falha transitória de erro de plano e sabe quando uma chamada idempotente pode ser repetida ou quando uma ação já mutou estado. O modo de falha mais perigoso é outro: a ferramenta retorna resultado plausível mas errado, e isso passa despercebido tanto pelo modelo quanto pelo observador. A qualidade do catálogo de ferramentas, da descrição de cada uma e dos guardrails que as cercam determina se o agente opera em produção ou apenas em demonstração.
A memória fecha o conjunto e opera em duas camadas cuja distinção costuma ser perdida nas implementações iniciais. Dentro de uma única execução, o agente precisa lembrar o que já tentou e o que observou, sabendo qual hipótese já foi descartada e qual estado intermediário já foi alcançado, pra não entrar em laços improdutivos. Entre execuções, precisa reter o que foi aprendido sobre o ambiente e sobre o usuário com quem interage, sem ter que recarregar tudo no contexto a cada invocação. A memória de curto prazo é barata e direta, geralmente tratada pelo próprio histórico do thread. Já a de longo prazo exige uma camada externa, com política explícita pra decidir o que entra e o que pode ser descartado, recuperando o item certo no momento certo, tema já tratado no post anterior sobre externalização de contexto. Agentes sem memória de longo prazo repetem erros que um humano no mesmo lugar teria eliminado na terceira ocorrência, e consomem tokens recompondo informação que poderia estar indexada.
Na minha avaliação, o ponto em que essas quatro capacidades deixam de ser independentes é o ciclo de execução. A interdependência aparece nos modos de falha: percepção pobre alimenta raciocínio sobre um mundo que não está lá, e quando esse raciocínio não tem caminho até a ação ele se reduz a relatório descritivo. A ação por sua vez, sem consultar memória da própria sessão, repete erros que ela mesma já cometeu. Um agente eficaz é o que mantém as quatro em equilíbrio operacional, num ciclo reconhecível a cada passo em que observação e decisão antecedem a ação, e o registro do que aconteceu alimenta a próxima reavaliação. Quando um time projeta um agente começando pelo modelo e pelo prompt, sem antes decidir como cada uma dessas quatro capacidades vai ser implementada e operada com instrumentação adequada, o que nasce é um protótipo cuja única forma de melhoria é ajustar o prompt até a próxima falha, num ciclo que nunca converge porque o problema nunca foi o prompt.