Quantos Agentes sua empresa tem em produção? O problema começa quando ninguém consegue responder

É relativamente fácil saber quantos Agentes de IA existem em uma empresa quando há dois, três ou cinco deles.

Um atende clientes. Outro consulta documentos internos. Um terceiro auxilia o comercial. Quem participou das implementações provavelmente conhece todos pelo nome, sabe aproximadamente como funcionam e consegue dizer quem procurar quando alguma coisa dá errado.

O problema aparece quando essa estrutura começa a crescer.

Marketing cria um Agente. Comercial cria outro. Atendimento contrata um fornecedor diferente. Tecnologia desenvolve uma automação própria. Recursos Humanos inicia um projeto piloto. Uma ferramenta que começou como chatbot recebe integrações, passa a executar ações e se transforma em parte relevante da operação.

Alguns meses depois, uma pergunta aparentemente simples começa a produzir respostas diferentes:

Quantos Agentes de IA a empresa possui atualmente em produção?

Se ninguém consegue responder com segurança, o problema não é apenas de documentação.

É de gestão.

O Agentic AI Lens da AWS descreve essa mudança de estágio de forma direta: alguns Agentes desenvolvidos por uma equipe ainda podem ser tratados como um projeto. Dezenas de Agentes distribuídos entre diferentes equipes formam um portfólio, e portfólios exigem mecanismos de gestão diferentes.

Sem uma visão transversal, aumentam as chances de desenvolvimento duplicado, dependências desconhecidas e sistemas que continuam consumindo recursos depois de perder relevância.

O crescimento dos Agentes tende a ser descentralizado

A adoção de Inteligência Artificial raramente acontece por meio de um plano perfeitamente coordenado.

Ela costuma começar de baixo para cima.

Uma área identifica um processo repetitivo e cria um Agente. Outra encontra uma oportunidade diferente. Um funcionário experimenta uma plataforma SaaS. Tecnologia constrói uma solução interna. Um fornecedor entrega outra.

Individualmente, todas essas decisões podem fazer sentido.

O problema é que cada equipe passa a enxergar apenas uma pequena parte da infraestrutura existente.

Um novo Agente de suporte pode ser desenvolvido sem que a equipe saiba que outra área já possui uma solução capaz de executar boa parte das mesmas tarefas. Um novo conector com o CRM pode ser criado mesmo que uma integração semelhante já exista. Dois departamentos podem pagar por ferramentas diferentes que resolvem praticamente o mesmo problema.

A AWS trata esse acúmulo como agent sprawl: Agentes surgem em diferentes partes da organização sem uma fonte confiável que mostre o que existe, quem responde por cada solução e se aquilo ainda é utilizado.

O resultado não é apenas desperdício de desenvolvimento. Também aparecem versões divergentes, integrações repetidas, custos fragmentados e capacidades que ninguém sabe ao certo quem mantém.

Ter muitos Agentes não é necessariamente um problema.

Ter muitos Agentes sem saber exatamente o que cada um representa dentro da operação é.

Um Agente em produção não é apenas mais um item em uma lista

Um Agente pode ter acesso a CRM, ERP, banco de dados, documentos, e-mail, agenda, sistema financeiro, APIs e outros Agentes.

Pode consultar informações.

Pode tomar decisões.

Pode executar ações.

Pode gerar custos variáveis conforme o volume de utilização.

E pode se tornar dependência de processos que não pertencem à equipe que originalmente o criou.

Por isso, saber apenas que determinado Agente existe não é suficiente.

Imagine que a empresa decida desligar um Agente aparentemente pouco utilizado. Na visão da equipe responsável, ele recebe poucas solicitações diretamente.

O que ninguém percebeu é que três outras automações consultam esse Agente durante seus próprios processos.

A tentativa de economizar cria uma falha em cadeia.

Esse risco cresce ainda mais em arquiteturas com múltiplos Agentes, nas quais loops, tarefas duplicadas e falhas em cascata podem aparecer quando as relações entre componentes deixam de ser visíveis.

A AWS recomenda registrar tanto as dependências upstream, os Agentes ou sistemas que utilizam determinado Agente, quanto as dependências downstream, os Agentes, ferramentas e serviços que ele próprio utiliza.

Em termos simples, duas perguntas precisam ser respondidas:

Quem quebra se eu alterar este Agente?

O que precisa continuar funcionando para este Agente operar?

Quando essas relações deixam de caber na cabeça de uma pessoa, a empresa precisa de um mapa.

O catálogo de Agentes funciona como esse mapa

Uma empresa que começa a operar vários Agentes precisa de uma fonte central de verdade sobre seu portfólio.

Isso não significa necessariamente contratar uma grande plataforma de governança logo no início.

O catálogo pode começar em uma ferramenta interna, banco de dados ou estrutura simples de gestão.

O importante é existir um lugar oficial onde os Agentes relevantes estejam registrados.

A AWS recomenda que esse catálogo permita visualizar proprietário, capacidades, dependências, estágio do ciclo de vida, perfil de custo e indicadores de valor de negócio.

Na prática, um catálogo minimamente útil deveria responder perguntas como estas.

Identidade

• Qual é o nome do Agente?
• Em qual área da empresa ele opera?
• Qual problema foi criado para resolver?
• Qual ambiente ou canal utiliza?

Responsabilidade

• Quem é o proprietário de negócio?
• Qual equipe técnica responde pela solução?
• Quem precisa ser acionado em caso de incidente?

Capacidade

• O que esse Agente consegue fazer?
• Quais ferramentas e sistemas consegue acessar?
• Que tipo de dado utiliza?
• Quais ações está autorizado a executar?

Dependências

• Quais sistemas ou Agentes dependem dele?
• De quais sistemas ele depende?
• Quais APIs, ferramentas e serviços estão conectados?

Ciclo de vida

• Está em desenvolvimento?
• Está em piloto?
• Está em produção?
• Está em revisão?
• Está sendo descontinuado?
• Já deveria ter sido aposentado?

Economia e resultado

• Quanto custa por mês?
• Qual seu volume de utilização?
• Que resultado de negócio produz?
• Existe alguma métrica que justifique sua permanência?

A diferença é importante.

Isso deixa de ser uma lista de Agentes e passa a ser um portfólio de ativos operacionais.

Responsável pelo Agente não significa apenas responsável pelo código

O campo de proprietário merece atenção especial.

Em muitas empresas, a resposta para "quem é responsável por este Agente?" acaba sendo o nome da pessoa que desenvolveu a solução.

Isso é insuficiente.

Um Agente pode continuar tecnicamente funcionando mesmo depois de perder utilidade para o negócio. Também pode executar corretamente uma regra que já não faz mais sentido para a área responsável.

Por isso, é útil separar pelo menos duas responsabilidades.

A primeira é a responsabilidade técnica: quem mantém integração, infraestrutura, modelos, ferramentas e funcionamento.

A segunda é a responsabilidade de negócio: quem consegue dizer se o Agente continua resolvendo o problema para o qual foi criado.

Esse segundo proprietário é importante porque decisões de investimento, mudança e aposentadoria não podem depender apenas de indicadores técnicos.

Um Agente com disponibilidade perfeita pode estar executando um processo que ninguém mais precisa.

Custo sem atribuição é um problema maior do que parece

Agentes possuem uma característica importante: parte relevante do custo pode variar conforme a utilização e o comportamento da execução.

Há consumo de modelos, infraestrutura, APIs externas, armazenamento, observabilidade, integrações e trabalho de manutenção.

Dependendo do nível de autonomia, também podem existir várias chamadas de ferramentas e ciclos de raciocínio dentro de uma única tarefa. Por isso, além de controlar o portfólio, é importante estabelecer limites de tempo, custo e chamadas de ferramenta para cada Agente.

Um piloto inicialmente barato pode ganhar escala.

Outro pode praticamente deixar de ser utilizado enquanto seus recursos permanecem disponíveis.

Um terceiro pode consumir muito para produzir pouco resultado.

A recomendação de gestão de portfólio da AWS inclui custo mensal e indicadores de valor de negócio justamente para permitir que essas diferenças apareçam.

A pergunta deixa de ser apenas:

"Esse Agente funciona?"

E passa a incluir:

"Quanto custa mantê-lo?"

"Quantas vezes ele é utilizado?"

"Que resultado produz?"

"Existe outra solução fazendo praticamente a mesma coisa?"

"Esse Agente continua merecendo existir?"

Um sistema pode funcionar perfeitamente e ainda assim não justificar seu custo.

Antes de construir outro Agente, procure no catálogo

Uma das regras mais simples de governança pode evitar bastante desperdício:

antes de desenvolver um novo Agente, procure se alguma capacidade equivalente já existe.

Esse procedimento parece óbvio, mas depende de uma condição: aquilo que existe precisa ser encontrável.

Não adianta ter um Agente chamado `sales_assistant_v2` se uma pessoa procurando por uma solução capaz de "qualificar leads e consultar informações de produtos" não consegue descobrir que ele existe.

É justamente esse problema que o AWS Agent Registry tenta resolver com busca híbrida.

A pesquisa combina palavras-chave com busca semântica. Isso permite procurar tanto pelo nome exato de um recurso quanto pela intenção da capacidade desejada.

O princípio é mais importante do que a tecnologia utilizada:

descobrir antes de construir.

Se algo semelhante já existe, a empresa pode avaliar três caminhos:

1. reutilizar a capacidade existente;

2. estender o que já existe;

3. justificar por que uma implementação independente realmente é necessária.

Esse pequeno controle pode evitar meses de duplicação acumulada.

Também reduz um problema comum de governança: criar cinco soluções parecidas e descobrir depois que nenhuma delas pode ser descontinuada facilmente porque cada área construiu dependências próprias.

Todo Agente precisa de uma estratégia de aposentadoria

Empresas costumam ter processos melhores para colocar sistemas em produção do que para retirá-los.

Com Agentes, isso pode produzir rapidamente um cemitério de soluções esquecidas.

Um projeto começa como piloto.

Funciona durante algum tempo.

A pessoa responsável muda de área.

A prioridade da empresa muda.

O processo de negócio é alterado.

Outro Agente assume a função.

Mas ninguém desliga oficialmente o anterior.

Ele permanece existindo, consumindo algum nível de infraestrutura, manutenção, atenção operacional e superfície de segurança.

A orientação da AWS sobre descomissionamento e agent sprawl recomenda um ciclo estruturado de retirada, com estados como ativo, em revisão, depreciado e descomissionado.

A aposentadoria não deveria começar quando alguém percebe por acaso que um Agente está abandonado.

Ela deveria fazer parte do desenho do ciclo de vida.

Para cada Agente, deveria ser possível responder:

Em quais condições consideraríamos que ele não precisa mais existir?

Baixa utilização pode ser um sinal, mas não deve ser o único critério.

Um Agente usado apenas no fechamento trimestral pode ficar semanas sem chamadas e ainda ser importante. O mesmo vale para processos sazonais ou tarefas críticas executadas poucas vezes.

O objetivo da revisão é separar baixa utilização legítima de abandono.

Uma revisão trimestral transforma catálogo em gestão

Depois que o catálogo existe, ele não pode virar apenas mais uma planilha esquecida.

A AWS propõe revisões trimestrais do portfólio observando quatro dimensões.

1. Utilização

Quais Agentes realmente continuam sendo utilizados?

Quais praticamente não recebem chamadas?

A utilização mudou desde a última revisão?

2. Eficiência de custo

O valor produzido continua proporcional ao custo?

O custo cresceu mais rápido do que o volume de tarefas?

Existe infraestrutura mantida para uma capacidade que quase não é utilizada?

3. Redundância

Existem dois ou mais Agentes resolvendo problemas muito parecidos?

Uma capacidade poderia ser consolidada?

Uma equipe está reconstruindo algo que já existe em outra área?

4. Saúde

Quais soluções apresentam aumento de erros?

Algum Agente está utilizando configurações desatualizadas?

Existem integrações instáveis ou problemas recorrentes de desempenho?

Essa dimensão depende de visibilidade operacional. O histórico da conversa mostra o que o usuário recebeu, mas nem sempre mostra o caminho interno que levou ao resultado. Por isso, observabilidade para reconstruir erros e chamadas de ferramentas também faz parte de uma gestão madura do portfólio.

A partir dessas quatro dimensões, a revisão pode produzir decisões concretas:

manter, quando o Agente continua saudável e relevante;

investir, quando utilização e resultado justificam expansão;

consolidar, quando várias soluções executam funções semelhantes;

aposentar, quando custo, utilização ou relevância já não justificam sua permanência.

É assim que um catálogo deixa de ser documentação e se transforma em ferramenta de gestão.

Valor de negócio precisa ser mensurável

Uma dificuldade aparece quando a empresa tenta comparar os Agentes do portfólio: nem todos produzem o mesmo tipo de resultado.

Um Agente comercial pode ser acompanhado por oportunidades qualificadas, propostas geradas ou vendas assistidas.

Um Agente de atendimento pode ser medido por resolução, tempo poupado, encaminhamentos e qualidade.

Um Agente interno pode reduzir trabalho manual, encontrar informações ou executar rotinas administrativas.

Não existe uma única métrica que funcione para todos.

O importante é não deixar o valor completamente subjetivo.

Cada Agente deveria ter pelo menos um pequeno conjunto de indicadores que explique por que a empresa continua investindo nele. Esse raciocínio complementa as métricas que vão além do tempo de resposta, porque portfólio não deve ser avaliado apenas pelo número de Agentes ativos, mas pelos resultados que cada um produz.

Sem essa atribuição, Agentes tendem a permanecer em produção simplesmente porque já estão lá.

Faça este diagnóstico na sua empresa

Há uma forma simples de identificar se o problema já começou.

Tente responder:

1. Quantos Agentes estão atualmente em produção?

2. Existe uma lista oficial ou o número depende de perguntar para várias pessoas?

3. Todo Agente possui um responsável técnico e um responsável de negócio claramente identificados?

4. Sabemos quais sistemas cada Agente pode acessar?

5. Sabemos quais outros sistemas ou Agentes dependem dele?

6. É possível descobrir se determinada capacidade já existe antes de desenvolver outra?

7. Conseguimos atribuir custos aos Agentes individualmente ou pelo menos por operação?

8. Existe alguma métrica de negócio que justifique a existência de cada Agente?

9. Existe um status claro de ciclo de vida para cada um?

10. Alguém revisa periodicamente quais deveriam ser mantidos, consolidados, expandidos ou aposentados?

Quanto mais respostas forem "não sei", maior o sinal de que a empresa está deixando de administrar Agentes individualmente sem ainda ter começado a administrar seu portfólio.

Essa transição tende a ficar mais importante conforme a Inteligência Artificial deixa de ser um conjunto de experimentos isolados e passa a participar diretamente da infraestrutura operacional das organizações.

A pergunta não é quantos Agentes você consegue criar

Criar mais um Agente está ficando progressivamente mais fácil.

Esse é justamente o motivo pelo qual governá-los ficará mais importante.

Quando o custo técnico de criação cai, mais áreas conseguem experimentar, construir e colocar novas soluções para funcionar.

O gargalo muda.

Primeiro, o desafio era conseguir construir.

Depois, passa a ser conseguir administrar aquilo que foi construído.

Empresas maduras provavelmente não serão aquelas que simplesmente acumularem o maior número de Agentes.

Serão aquelas capazes de responder quais existem, por que existem, quem responde por eles, quanto custam, de que dependem, quais resultados produzem e quando chegou a hora de desligá-los.

Cinco Agentes podem ser administrados de memória.

Cinquenta já exigem portfólio, responsáveis e critérios de aposentadoria.

Se hoje ninguém na empresa consegue responder com segurança quantos Agentes estão realmente em produção, talvez o momento de começar esse catálogo não seja quando existirem cinquenta.

Talvez seja agora.