Um agente para vendas, outro para suporte, um terceiro para finanças, mais dois contratados por áreas diferentes. Cada iniciativa parece pequena e independente. Em poucos meses, porém, a empresa pode ter várias portas de entrada, identidades incompatíveis, memórias que divergem, integrações duplicadas e ninguém capaz de responder quanto custa ou por que uma ação foi tomada.
Esse problema é conhecido como agent sprawl: a proliferação de agentes sem uma arquitetura comum de gestão. O risco não está simplesmente no número. Agentes especializados podem ser a escolha correta. O problema aparece quando cada um vira seu próprio plano de controle, com política, credencial, catálogo de ferramentas, aprovação, evidência e ciclo de vida separados.
O princípio
Especialize capacidades; não fragmente a responsabilidade por identidade, política, execução e prova.
Como o agent sprawl começa
Normalmente não nasce de uma decisão explícita de criar desordem. Uma área assina uma ferramenta para responder clientes. Outra cria um agente interno com acesso ao CRM. O time de dados publica um assistente sobre documentos. Um fornecedor instala um agente para o ERP. Cada piloto resolve uma dor local e usa o caminho mais rápido disponível.
A fragmentação aparece quando a iniciativa precisa atravessar fronteiras. O agente de vendas promete uma condição que o de crédito não conhece. O de atendimento consulta uma base antiga. O de logística chama a mesma operação com outro nome. Uma pessoa muda de função, mas conserva acesso em três consoles. Uma política é atualizada num lugar e esquecida nos demais.
Sete custos de gestão que crescem silenciosamente
1. Portas de entrada e experiências concorrentes
O trabalhador precisa descobrir qual agente atende cada pedido, aprender comandos diferentes e repetir contexto quando a tarefa muda de área. A empresa troca o excesso de telas pelo excesso de conversas. A promessa de reduzir fricção termina em novos favoritos, bots, caixas de entrada e notificações.
2. Identidades e permissões que derivam
Cada agente pode representar o usuário de uma forma e guardar sua própria credencial. A revogação deixa de ser uma decisão única. A pergunta “quem podia fazer isso naquele momento?” exige reconciliar diretórios, tokens, grupos e regras de fornecedores diferentes. Em agentes que agem, identidade não é cadastro: é parte do controle da consequência.
3. Memórias e fontes de verdade conflitantes
Um agente memoriza preferência, outro resume a conversa e um terceiro indexa documentos. Sem escopo, validade, proveniência e exclusão consistentes, a empresa acumula versões plausíveis do mesmo fato. O problema não é apenas resposta errada: conteúdo persistido num contexto pode contaminar decisões futuras.
4. Ferramentas duplicadas e efeitos concorrentes
Dois times criam conectores diferentes para “atualizar pedido”. Eles validam campos, tratam retentativa e interpretam erro de maneiras distintas. Quando ambos recebem o mesmo evento, a organização ganha condições de corrida, duplicidade e contratos que evoluem sem coordenação.
5. Aprovação excessiva ou inconsistente
Um agente pede confirmação para toda ação; outro executa sem mostrar consequência; um terceiro manda a aprovação para a pessoa errada. O volume gera fadiga e o controle vira ritual. Aprovação útil depende de risco, alçada, parâmetros, prazo e estado da execução, não de uma janela genérica.
6. Evidência e investigação fragmentadas
Conversa em um console, chamada em outro, aprovação por e-mail e resultado no ERP não formam automaticamente uma trilha. Quando há incidente, equipes discutem versões em vez de reconstruir uma sequência comum entre pedido, decisão, tentativa e efeito.
7. Custo, qualidade e ciclo de vida invisíveis
Modelos, buscas, chamadas, conectores e revisões humanas chegam em faturas diferentes. Prompts mudam sem regressão compartilhada. Agentes permanecem ativos depois que o dono sai ou o processo muda. Sem portfólio comum, a empresa não sabe quais capacidades geram valor, quais repetem funções e quais deveriam ser aposentadas.
Mais agentes também criam novas falhas em cadeia
Uma arquitetura multiagente adiciona fronteiras de confiança. Um agente precisa descobrir outro, autenticar sua identidade, limitar o que envia, validar o que recebe e impedir que uma instrução maliciosa atravesse a cadeia. A OWASP inclui falhas em cascata entre os riscos de sistemas multiagentes e recomenda validar comunicações, isolar memória, limitar profundidade, retentativas e custo, além de testar se um agente comprometido consegue ampliar seu privilégio por meio de outro.
O trabalho da Anthropic sobre agentes confiáveis observa que subagentes acrescentam perguntas sobre compreensão e capacidade de direção pelo usuário. Especialização pode melhorar desempenho, mas cada delegação precisa preservar objetivo, contexto, limite e responsabilidade. “O agente A pediu” não deve se tornar autorização suficiente para o agente B executar.
O sinal do mercado exige governança, não contagem
O Work Trend Index 2026 da Microsoft informa que agentes ativos em seu ecossistema Microsoft 365 cresceram 15 vezes em um ano. O dado não revela números absolutos, cobre apenas a telemetria do fornecedor e não mede maturidade ou resultado empresarial. Seu valor aqui é mostrar a velocidade de proliferação possível, não provar adoção universal.
Na mesma direção, a iniciativa de padrões de agentes do NIST coloca autenticação, identidade, interoperabilidade e interações seguras entre humanos e agentes ou entre múltiplos agentes entre suas frentes centrais. Isso sugere que a pergunta executiva não deveria ser “quantos agentes temos?”, mas “quantos planos de identidade, política e evidência precisamos governar?”.
A arquitetura-alvo: uma experiência, capacidades especializadas
| Dimensão | Muitos agentes independentes | Operação unificada |
|---|---|---|
| Entrada | Um bot, aplicativo ou comando por área | Uma conversa contínua que encaminha pela intenção |
| Identidade | Cadastro e token em cada solução | Contexto comum de pessoa, empresa e função |
| Capacidades | Conectores duplicados e credenciais amplas | Catálogo de ferramentas estreitas e reutilizáveis |
| Política | Regras e aprovações em cada agente | Gates comuns por consequência e alçada |
| Execução | Retentativa e erro tratados de formas diferentes | Um caminho governado com idempotência e falha fechada |
| Evidência | Logs separados por fornecedor | Relação entre pedido, decisão, tentativa e resultado |
| Gestão | Custo e qualidade por console | Prontidão, diagnóstico e portfólio em um plano de controle |
Uma experiência unificada não obriga a empresa a usar um único modelo, prompt ou mecanismo. Por trás dela podem existir workflows determinísticos, ferramentas especializadas, recuperações de conhecimento e até agentes com escopos diferentes. A unidade está no contrato de gestão: a mesma identidade, os mesmos gates, uma linguagem comum de estado e uma evidência relacionada.
Exemplo composto: três agentes e um pedido bloqueado
Considere um exemplo composto, sem representar cliente ou resultado da Uiless. Um cliente pede antecipação de entrega. O agente de atendimento registra “urgente” e promete análise. O agente de vendas encontra limite comercial e altera prioridade. O agente de logística, alimentado por outra base, programa separação. O agente financeiro mantém o bloqueio. Cada um parece ter cumprido sua tarefa, mas ninguém responde pelo resultado de ponta a ponta.
Numa operação unificada, a intenção “avaliar antecipação” recupera pedido, cliente e bloqueios por capacidades especializadas. A política não permite que atendimento ou vendas removam a trava financeira. A decisão chega à alçada correta com efeito previsto. Após aprovação, uma única execução idempotente atualiza o sistema responsável e devolve o estado confirmado. Atendimento, vendas e logística veem o mesmo resultado sem conversar com três agentes diferentes.
A melhoria deve ser medida por tempo até decisão válida, promessas revertidas, reprocessamento, divergências entre sistemas, aprovações sem ação e custo por caso resolvido. Reduzir o número de agentes visíveis é consequência; o objetivo é reduzir fragmentação do trabalho e do controle.
Quando vários agentes são justificáveis
- Fronteira de risco: capacidades sensíveis exigem isolamento técnico e credenciais próprias.
- Contexto especializado: domínio, ferramentas e avaliações são suficientemente diferentes para merecer um componente dedicado.
- Escala e disponibilidade: carga ou criticidade pedem ciclos independentes.
- Responsabilidade clara: existe dono, objetivo, orçamento, conjunto de testes e condição de aposentadoria.
- Handoff contratado: entradas, saídas, identidade, confiança e estado de falha entre componentes estão definidos.
Mesmo nesses casos, não é necessário criar outra experiência para o usuário nem duplicar governança. O agente especializado pode permanecer atrás de uma capacidade estreita. A empresa preserva separação técnica onde ela protege o negócio e unidade operacional onde ela reduz confusão.
Como diagnosticar agent sprawl antes de comprar mais uma solução
- Inventarie agentes, donos, usuários, canais, modelos, memórias, ferramentas e custos.
- Marque capacidades duplicadas e sistemas que recebem gravações por mais de um caminho.
- Teste se desligamento, troca de função e revogação de acesso chegam a todos os agentes.
- Reconstrua três operações reais da intenção ao efeito; registre os consoles necessários.
- Compare políticas, aprovações, estados de erro e retenção de dados.
- Defina o que deve ser compartilhado e o que precisa continuar isolado.
- Crie critérios de entrada, mudança e aposentadoria para o portfólio.
O diagnóstico complementa o modelo operacional de responsabilidades. Para controles específicos, aprofunde identidade e permissões e trilha de auditoria. Governar agentes exige tanto desenho organizacional quanto uma arquitetura que consiga aplicar as decisões.
Como a Uiless ajuda
A Uiless oferece uma identidade e uma conversa voltadas a quem trabalha, enquanto capacidades especializadas permanecem por trás da experiência. Aplicativo, voz, WhatsApp, Telegram, IoT e API podem convergir para o mesmo contexto. A intenção é encaminhada à ferramenta ou ao fluxo adequado sem exigir que a pessoa escolha e administre um bot por departamento.
Na camada de controle, empresa, função, permissões, aprovação, limite de custo e prontidão são aplicados antes da execução. Conectores REST, OpenAPI e adaptadores controlados entram num caminho comum de ferramenta, com idempotência, falha fechada, diagnóstico e evidência relacionada. O painel concentra configuração e investigação. Assim, especialização não precisa criar novas ilhas de credencial e auditoria.
A proposta não é um agente onipotente nem conexão instantânea com qualquer legado. Cada sistema precisa de um contrato seguro e cada capacidade precisa de dono. A diferença é reutilizar a mesma base de gestão para ampliar o que a operação consegue fazer. Esse desenho é uma aplicação direta da metodologia Uiless: uma porta de intenção, execução especializada e governança coerente de ponta a ponta.
