<code-segment id="0" lang="text">
Promovendo a introdução de agentes de IA para outros departamentos dentro da Notion como parte do meu trabalho e fornecendo suporte de implementação para empresas que usam a abordagem FDE, certos padrões surgiram. Eu construí agentes para vendas, vendas internas, marketing, desenvolvimento de produtos, sucesso do cliente e muito mais, mas todos enfrentam barreiras comuns no nível operacional e barreiras organizacionais no nível empresarial. Ambas são inevitáveis, e acredito que a maioria das empresas fica travada nos mesmos lugares.
</code-segment>
▍Barreiras Operacionais
① O Problema dos Escopos se Tornarem Pequenos Demais
Tentei criar um agente para vendas que "pesquisasse automaticamente quando um lead chega". Imaginei o fluxo de trabalho completo: quando um prospect entra na lista, o agente pesquisa e analisa informações internas e externas, e então cria um rascunho de e-mail. Comecei construindo a parte em que ele pesquisa informações quando uma nova entrada chega ao banco de dados de leads. Minha intenção era que, uma vez estabelecida a base, automatizar a criação de e-mails seria fácil.
No entanto, após configurar a construção inicial e passar a responsabilidade para a equipe operacional, eles não automatizaram os rascunhos de e-mail mesmo depois de várias semanas. Quando entrevistei eles, disseram: "Já é muito conveniente só ter a pesquisa de leads!" A equipe não percebeu que poderia ir até os rascunhos de e-mail, ou a ideia de automatizar tanto assim sequer passou pela cabeça deles. Também parecia que estavam hesitantes por acharem difícil.
Este é o primeiro padrão em que a implementação do agente empaca: tornar o escopo do trabalho pequeno demais, resultando em um uso de baixo retorno, apesar de ter construído o agente. Acaba sendo usado apenas para funções isoladas ou tarefas menores.
② O Problema de Parar Por Ser Grande Demais
O segundo problema é o oposto: tentar transformar um processo de negócio complexo em um agente apenas para perceber que o processo em si não é estruturado com alta resolução. Pessoas diferentes fazem as coisas de maneiras diferentes, ou há conhecimento tácito demais. Tentar ser minucioso demais resulta em tempo se esvaindo apenas durante as entrevistas, sem nunca chegar à fase de construção. O número de stakeholders aumenta, e o custo de alinhamento dispara. O entusiasmo inicial gradualmente se desfaz...
Esta é uma questão de definição de escopo no gerenciamento de projetos. O que você quer fazer com o agente? Qual resultado você quer alcançar? Se o resultado está definido, o escopo necessário e suficiente para o agente é determinado. Almejar vagamente "eficiência de negócios com agentes" leva para a lama.
③ Ausência de Responsabilidade (Ownership)
Mesmo que um promotor construa com impulso, se a responsabilidade por melhorias ou correções de bugs for ambígua, o uso gradualmente diminui. O promotor também perde o fôlego. Idealmente, a equipe operacional deveria cultivar o agente como seu. Se isso faltar, as coisas parecem boas nos primeiros três meses, mas não escalam. À medida que o número de stakeholders aumenta — especialmente quando o escopo do trabalho cresce — a necessidade de alinhamento e aprovação aumenta, e o senso de responsabilidade (quem é o dono) gradualmente se desfaz.
Esses três não são problemas independentes; eles estão todos conectados. Se o design do escopo estiver errado, a responsabilidade não será estabelecida, e se não houver um responsável, o escopo não se expandirá.
▍Barreiras Organizacionais
Mesmo que você supere as barreiras operacionais, existem mais quatro muros além de apenas "fazer algo que funcione" em uma empresa.
④ Transparência do Capital de Token
Mesmo que o consumo de tokens seja visível por departamento, muitas vezes não está claro "que tipo de trabalho foi feito e qual resultado foi obtido". Isso se torna um problema da perspectiva do capital de token e do gerenciamento de tokens, tornando impossível justificar o orçamento. Consequentemente, a gestão vê os tokens apenas como um custo de consumo, perguntando: "Então, quanto vai custar?"
⑤ Governança
Quem pode criar agentes, quem pode vê-los e quem os gerencia? Se isso for ambíguo, a organização será inundada com "agentes perdidos" ou "agentes zumbis" que funcionam, mas ninguém usa. Ninguém assume responsabilidade, nenhum orçamento é garantido, tokens são consumidos de forma desperdiçada e os riscos de segurança aumentam até que tudo pare.
⑥ Observabilidade
Quantas vezes o agente foi executado, com que frequência ele teve sucesso e onde ele falhou? Este é um requisito mínimo para a operação, mas muitas ferramentas são fracas nisso. Você não pode melhorar o que não pode ver. Apenas com observabilidade você pode construir um ciclo de feedback para a melhoria do agente.
⑦ Flexibilidade na Seleção de Modelos
Depender excessivamente de um provedor de LLM específico é um risco. E se o desempenho cair temporariamente? E se parar devido a uma falha? E se restrições de exportação torná-lo indisponível? Se você não puder mudar para outro provedor imediatamente, não poderá implementar agentes diretamente ligados às operações de negócios. A IA se tornou infraestrutura, mas a dependência extrema é atualmente tolerada cegamente.
Resumo
A implementação de agentes parece uma discussão técnica, mas na verdade é sobre design de negócios e responsabilidade (ownership). Para garantir que não termine apenas com "a IA é incrível", fundações para governança e observabilidade são necessárias primeiro.
Nem pequeno demais, nem grande demais, e cultivado por alguém com responsabilidade. E um sistema para apoiar isso como organização. Acredito que os agentes só se enraízam quando tanto a operação quanto a organização estão alinhadas.
