A Limpeza dos Agentes: O Que Se Devia Ter Construído em Vez Disso
Abra o LinkedIn numa manhã qualquer e conte os posts sobre agentes de AI. Fluxos agênticos. Comércio agêntico. Orquestração multiagente. Enxames de agentes. O vocabulário está em todo o lado, as implementações multiplicam-se, e a promessa é consistente: os agentes vão transformar o seu negócio.
O que se segue é previsível. Dentro de 18 a 24 meses, um número significativo de organizações estará a desativar discretamente agentes que custam mais a manter do que o valor que produzem.
Mas este texto não é sobre apontar o problema. É sobre o que se deve construir em vez disso.
O que está realmente a ser implementado
Antes de discutir alternativas, vale a pena ser preciso sobre o aspeto real da maioria das implementações de «agentes» na prática.
A arquitetura segue tipicamente este padrão: um sistema existente gera dados ou um gatilho. Esse gatilho chama uma camada de orquestração. A camada de orquestração envia um prompt a uma API de LLM. O LLM devolve texto. Uma camada de parsing extrai dados estruturados desse texto. Uma camada de validação verifica o output. Uma camada de transformação reformata-o para o sistema de destino. O sistema de destino recebe os dados.
São seis camadas novas inseridas entre dois sistemas que antes comunicavam diretamente. Cada camada acrescenta latência, superfície de manutenção e risco de falha. E o passo do LLM no meio introduz algo que antes não existia na cadeia de integração: o não-determinismo. O mesmo input pode produzir output diferente em dias diferentes, porque o fornecedor do modelo o atualiza sem aviso, ou porque o prompt segue um caminho de tokens ligeiramente diferente.
Para alguns casos de uso, esta arquitetura faz sentido. Para a maioria do que se implementa hoje, uma avaliação honesta concluiria que um script bem desenhado com lógica condicional produziria resultados idênticos — mais rápido, mais barato, e de forma determinística.
Não é uma preocupação teórica. É uma realidade de manutenção e de debugging. Quando ocorre um incidente de produção numa integração tradicional, a causa-raiz é rastreável: um valor mudou, um serviço esgotou o tempo, um esquema foi modificado. Quando ocorre um incidente de produção num pipeline de agentes, a causa-raiz pode ser que o LLM interpretou um prompt de forma diferente hoje em relação a ontem. Diagnosticar isso é um desafio fundamentalmente diferente — e significativamente mais difícil.
A limpeza que aí vem
O padrão é previsível porque tem precedentes.
Os microserviços passaram pelo mesmo ciclo. As organizações decompuseram monólitos em centenas de serviços, descobriram que a complexidade de orquestração excedia o problema original, e passaram anos a consolidar de volta rumo a fronteiras de serviço racionais. A tecnologia não estava errada. A aplicação é que foi indiscriminada.
A migração para a cloud teve a sua própria correção. Os projetos de lift-and-shift que moveram aplicações para a cloud sem rearquitetura acabaram por custar mais do que a infraestrutura on-premise que substituíram. A tecnologia não estava errada. O pressuposto de que mover era inerentemente melhor é que estava errado.
As implementações de agentes vão seguir o mesmo arco. Não porque os agentes enquanto conceito sejam falhos, mas porque o critério de implementação na maioria das organizações não é «este problema exige genuinamente raciocínio autónomo?». É «conseguimos pôr um agente nisto?».
A diferença entre essas duas perguntas é a diferença entre engenharia e marketing.
Onde a AI realmente transforma — sem agentes
É aqui que esta análise se torna construtiva. As aplicações mais valiosas de AI em ambientes empresariais muitas vezes não envolvem agentes de todo. Envolvem usar as capacidades da AI precisamente onde resolvem problemas que antes não podiam ser resolvidos — ou que eram proibitivamente caros de resolver com abordagens tradicionais.
1. Resgate de conhecimento institucional
Toda a empresa tem conhecimento crítico preso nas cabeças de pessoas perto da reforma, enterrado em código não documentado, ou disperso por anos de threads de email e relatórios de incidentes que provavelmente nunca mais serão lidos.
A AI é genuinamente transformadora aqui — não como um agente que toma decisões, mas como uma ferramenta que extrai, estrutura e torna pesquisável o conhecimento que de outra forma sairia porta fora.
A implementação prática: alimentar um sistema de recuperação com relatórios históricos de incidentes, runbooks, documentos de arquitetura e comentários de código. Não para tomar decisões autónomas — para tornar o conhecimento da própria organização acessível às pessoas que dele precisam. Quando um engenheiro júnior enfrenta um incidente às 2 da manhã, a diferença entre ter a experiência coletiva da organização pesquisável e não ter nada mede-se em horas de indisponibilidade.
Nenhum agente necessário. Um sistema RAG bem implementado com indexação adequada faz isto melhor, mais depressa e de forma mais fiável do que qualquer agente autónomo.
2. Geração de documentação a partir da realidade
A queixa número um em todas as empresas onde trabalhei: a documentação não existe, está desatualizada, ou foi escrita por alguém que não compreendia o sistema.
A AI consegue fazer engenharia inversa de documentação a partir de código, ficheiros de configuração e comportamento do sistema. Não documentação perfeita — mas documentação 70% correta é infinitamente mais valiosa do que documentação que não existe. Um humano revê, corrige e aprova. A AI fez o trabalho pesado que era perpetuamente adiado — não por preguiça, mas por prioridades concorrentes.
É exatamente o padrão que a DiagnosticMind operacionaliza. A AI faz a extração e a estruturação. O humano com perícia de domínio faz a validação e a correção. O resultado é documentação que reflete de facto o sistema tal como existe hoje, não como foi desenhado há cinco anos.
Nenhum agente necessário. Um LLM bem instruído com acesso ao material-fonte certo produz isto em horas em vez de semanas.
3. Assistência ao diagnóstico — a segunda opinião inteligente
Quando ocorre um incidente de produção, os primeiros 15 minutos determinam se é resolvido depressa ou se escala para uma crise de várias horas. O estrangulamento não é, normalmente, o acesso aos dados — é a interpretação. O painel de monitorização mostra 47 alertas. Qual deles importa? Quais são sintomas e qual é a causa?
A AI pode servir de assistente de diagnóstico que correlaciona alertas, sugere causas-raiz prováveis com base em padrões históricos, e realça o sinal no ruído. Não a tomar decisões — a apresentar análise que ajuda o humano a tomar melhores decisões mais depressa.
Isto funciona quando é implementado como uma ferramenta que o engenheiro consulta, não como um agente que toma ação autónoma sobre sistemas de produção. A distinção importa enormemente: uma ferramenta que sugere «com base em padrões históricos, esta combinação de alertas indica tipicamente esgotamento do pool de ligações à base de dados» é valiosa. Um agente que reinicia serviços autonomamente com base nessa análise é perigoso.
Nenhum agente necessário. Correspondência de padrões contra dados históricos de incidentes, com um LLM a fornecer interpretação em linguagem natural.
4. Triagem e encaminhamento inteligentes
Tickets de suporte, pedidos de mudança, relatórios de incidentes — toda a empresa processa milhares destes, e o encaminhamento baseia-se normalmente em correspondência simples de palavras-chave ou atribuição manual. O resultado: os tickets caem na fila errada, andam a saltar entre equipas, e o tempo de resolução inflaciona.
A AI pode melhorar isto genuinamente ao interpretar a intenção e o conteúdo técnico de um pedido e encaminhá-lo para a equipa certa com a prioridade certa. Não porque compreenda o domínio técnico a fundo — mas porque consegue interpretar linguagem natural melhor do que qualquer sistema baseado em palavras-chave.
Esta é uma das poucas áreas em que chamar-lhe «agente» é, defensavelmente, justo — está a interpretar input ambíguo e a tomar uma decisão de encaminhamento. Mas a implementação deve ser estreita, bem delimitada, e ter uma sobreposição humana. No momento em que começa a tomar decisões de resolução em vez de decisões de encaminhamento, o perfil de risco muda drasticamente.
5. Avaliação de competência — medir o que importa
É aqui que a indústria tem uma lacuna quase total. As organizações gastam milhares de milhões em formação, certificação e desenvolvimento profissional — e medem o resultado pela presença. Completaram o curso? Confirmado. Viram o webinar? Confirmado. Conseguem de facto aplicar o que supostamente aprenderam? Essa parte raramente se mede.
A AI torna a avaliação de competência baseada em cenários economicamente viável pela primeira vez. Apresentar a um profissional uma situação realista, avaliar o seu raciocínio através de uma série de pontos de decisão adaptativos, e produzir uma avaliação baseada em evidência da capacidade demonstrada. Não um teste de escolha múltipla — uma simulação de diagnóstico que mede o pensamento.
Nenhum agente necessário. Um motor de cenários adaptativo com avaliação de respostas assistida por AI.
O quadro de decisão: agente, ferramenta ou script?
Antes de implementar qualquer solução assistida por AI, três perguntas atravessam o hype:
«Este problema exige raciocínio autónomo sobre situações ambíguas e imprevisíveis?»
Se sim — território de agente genuíno. Apoio ao cliente para pedidos complexos, de vários passos, com caminhos imprevisíveis. Negociação em tempo real onde os parâmetros mudam dinamicamente. São casos de uso legítimos, e são mais raros do que o mercado sugere.
Se não — não construa um agente. Construa uma ferramenta ou um script.
«O que acontece quando a AI produz um output incorreto?»
Se a consequência é menor — um rascunho de email ligeiramente errado, um encaminhamento de ticket subótimo que é corrigido por um humano — o risco é aceitável. Implementar, monitorizar, iterar.
Se a consequência é significativa — uma transação errada, uma mudança em produção, uma decisão de conformidade — a AI deve informar, não agir. O humano no ciclo não é uma limitação. É a decisão de engenharia que mantém o sistema seguro.
«Um script bem desenhado com lógica condicional produziria o mesmo resultado?»
Seja honesto. Se a resposta é sim, construa o script. Será mais rápido, mais barato, determinístico, depurável e sustentável. O LLM só acrescenta valor quando o input é genuinamente ambíguo ou não-estruturado de formas que a lógica condicional não consegue tratar.
A conclusão
As organizações que vão extrair valor real e duradouro da AI nos próximos três anos não serão as que têm mais agentes. Serão as que aplicaram a AI precisamente onde resolve problemas que antes não podiam ser resolvidos — resgate de conhecimento, documentação a partir da realidade, assistência ao diagnóstico, triagem inteligente e verificação de competência — mantendo a automação tradicional para tudo o que a automação tradicional trata perfeitamente bem.
A limpeza dos agentes aí vem. A pergunta para cada organização é se estará a desmantelar experiências falhadas ou a construir sobre fundações sólidas.
A tecnologia não está errada. A aplicação é que importa. E saber a diferença entre «isto precisa de AI» e «isto precisa de um script» pode ser a competência diagnóstica mais valiosa nas TI empresariais neste momento.