Ao promover a introdução de agentes de IA para outros departamentos dentro da Notion como parte do meu trabalho e oferecer 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 presa nos mesmos lugares.
▍Barreiras Operacionais
① O Problema dos Escopos se Tornarem Muito Pequenos
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 que pesquisa informações quando uma nova entrada chega ao banco de dados de leads. Minha intenção era que, uma vez que a base estivesse pronta, automatizar a criação de e-mails seria fácil.
No entanto, após configurar a construção inicial e entregar a responsabilidade para a equipe operacional, eles não automatizaram os rascunhos de e-mail nem depois de várias semanas. Quando os entrevistei, eles disseram: "Já é muito conveniente só para pesquisar leads!" A equipe não percebeu que poderia ir até os rascunhos de e-mail, ou a ideia de automatizar tanto assim nem passou pela cabeça deles. Também parecia que eles estavam hesitantes porque achavam difícil.
Este é o primeiro padrão onde a implementação do agente trava: 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á muito conhecimento tácito. Tentar ser minucioso demais resulta em um tempo perdido apenas nas entrevistas, sem nunca chegar à fase de construção. O número de partes interessadas aumenta, e o custo de construir consenso cresce. O entusiasmo inicial gradualmente se esvai...
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 for definido, o escopo necessário e suficiente para o agente é determinado. Visar vagamente "eficiência de negócios com agentes" leva à lama.
③ Ausência de Propriedade
Mesmo que um promotor o construa com momentum, se a responsabilidade por melhorias ou correções de bugs for ambígua, o uso gradualmente desaparece. O promotor também fica sem energia. Idealmente, a equipe operacional deve nutrir o agente como se fosse seu. Se isso faltar, as coisas parecem boas nos primeiros três meses, mas não escalam. À medida que o número de partes interessadas aumenta — especialmente quando o escopo do trabalho cresce — a necessidade de consenso e confirmação aumenta, e o senso de responsabilidade (quem é o dono) gradualmente se dilui.
Esses três não são problemas independentes; eles estão todos conectados. Se o design do escopo estiver errado, a propriedade não será estabelecida, e se não houver um dono, o escopo não se expandirá.
▍Barreiras Organizacionais
Mesmo que você supere as barreiras operacionais, existem mais quatro paredes além de apenas "fazer algo que funcione" em uma empresa.
④ Transparência do Capital de Tokens
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 tokens e da gestão 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 rodam, 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 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. Somente 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 específico de LLM é um risco. E se o desempenho cair temporariamente? E se parar devido a uma falha? E se restrições de exportação o tornarem 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 propriedade. Para garantir que não termine apenas com "IA é incrível", são necessárias primeiro bases para governança e observabilidade.
Nem muito pequeno, nem muito grande, e nutrido 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.
