Como 3 empresas estão construindo produtos com agentes de IA

Eu assisti à conversa de Lance Martin, da Anthropic, com Sahaj, da Wispr Flow, Mihir, da Actively, e Todd, da Pendo.

O vídeo fala sobre o Claude Managed Agents. Só que, para mim, essa não é a parte mais importante.

A pergunta que vale é outra:

O que esses caras estão fazendo com IA que alguém consegue adaptar para um trabalho real?

Minha resposta: eles não começam montando um agente porque a tecnologia existe. Começam por uma tarefa. Depois decidem como reconhecer um bom resultado, o que a IA pode acessar e em que momento uma pessoa precisa conferir o trabalho.

É isso que eu quero tirar do vídeo aqui. Menos nome de recurso. Mais aplicação.

Os prazos e resultados citados neste texto são relatos dos próprios participantes da conversa. Não são uma auditoria independente das empresas.

A tese em 20 segundos

Aqui, agente significa uma IA que recebe um trabalho, busca informações, executa alguns passos e entrega um resultado. Dar esse nome para um fluxo não faz o trabalho ficar útil automaticamente.

A pergunta é:

Qual trabalho precisa ser feito, e como eu vou saber se ficou bom?

Comece pela tarefa, não pela ferramenta

Agora imagina uma situação simples: você tem uma reunião amanhã com alguém que já conversou com você outras vezes. Antes da chamada, precisa lembrar o que foi discutido, entender o momento da pessoa e chegar com alguma preparação. Depois, ainda precisa registrar os combinados e acompanhar o próximo passo.

Foi nesse tipo de trabalho que a Wispr Flow colocou um agente.

Sahaj conta que o agente prepara um resumo antes da reunião. Ele junta informações sobre a pessoa, conversas anteriores, o contexto e o resultado que a reunião deveria produzir.

O risco aparece rápido. Um resumo errado pode atrapalhar mais do que ajudar. A IA pode misturar duas pessoas, atribuir uma informação à fonte errada ou tratar uma suposição como fato.

Por isso, a equipe criou uma conferência do resultado. No vídeo, eles chamam essa regra de outcome. Antes de mostrar o resumo, o sistema verifica se os fatos fazem sentido, se as fontes estão certas e se aquilo ajuda alguém a se preparar.

Se o resumo não passa, ele não aparece para o usuário. Para mim, essa é uma das melhores ideias do vídeo: em alguns casos, não entregar nada é melhor do que entregar uma resposta bonita e errada.

Esse é um detalhe que muita gente esquece quando fala de agentes. Não basta pedir para a IA responder. Você precisa decidir o que acontece quando a resposta não é confiável.

Sahaj também diz que a primeira versão saiu em um dia. Isso não quer dizer que o produto ficou pronto em um dia.

Depois vieram os ajustes: instrução, busca, ordem das informações e fluxo. A primeira versão serviu para descobrir se aquilo ajudava de verdade.

O que construiu o produto foi o uso real, não a primeira configuração.

Memória não é salvar tudo

Na Actively, Mihir descreve um agente para cada conta de vendas. Ele acompanha o histórico daquela conta e tenta apontar o próximo movimento.

Isso funciona para uma conta. Mas o problema muda quando a equipe precisa olhar muitas contas ao mesmo tempo.

No vídeo, Mihir apresenta o Watchtower. A ferramenta olha várias contas, organiza relatórios, ajuda a priorizar oportunidades e participa das previsões. Ele relata que a primeira versão chegou aos clientes em cerca de duas semanas, depois de um teste interno.

O ponto que eu levaria não é “coloque memória no seu agente”. É: organize o contexto antes de pedir mais inteligência.

Uma empresa pode usar um campo do Salesforce de um jeito. Outra pode usar o mesmo campo para outra coisa. Um time chama uma etapa de “avaliação”; outro chama de “discovery”. Se a IA mistura esses contextos, a resposta sai errada mesmo que o modelo seja bom.

Por isso, eles separam as informações:

• memória da conta;
• memória do usuário;
• memória da organização;
• conhecimento agregado entre contas.

A ideia é simples: cada informação precisa ter um dono e um lugar.

Se um agente de vendas usa uma informação de uma conta em outra conta, ele pode sugerir uma ação completamente errada. Memória sem contexto vira bagunça.

O Watchtower também quebra o trabalho. Ele filtra contas, distribui tarefas menores e reúne os resultados depois.

Esse é o ganho: cada etapa recebe só o contexto necessário para fazer sua parte.

Não é uma conversa interminável com um modelo. É um trabalho bem dividido, com cada parte recebendo a informação certa.

Se a IA pode mexer no código, coloque limite

Na Pendo, Todd descreve uma conexão entre comportamento dos usuários, código e correção.

A empresa já tinha dados sobre como as pessoas usam seus produtos. O passo apresentado no vídeo é juntar esses dados com o código para investigar problemas e sugerir mudanças.

Agora imagina dar acesso do agente ao código do seu produto. Ele pode encontrar o problema, sugerir uma alteração e abrir uma pull request. Mas ele não deveria poder fazer qualquer coisa em qualquer lugar.

No vídeo, a Pendo controla esse acesso. O agente lê o código, usa apenas as ferramentas liberadas e envia a mudança para revisão. A equipe também acompanha as métricas para ver se a alteração melhorou ou piorou o produto.

O fluxo fica assim:

1. um comportamento problemático aparece nos dados;
2. o agente investiga o código relacionado;
3. ele sugere uma alteração;
4. uma pull request é criada e enviada ao repositório;
5. as métricas mostram se a mudança ajudou ou se precisa ser revista.

Todd fala em chegar a um software que consiga se corrigir sozinho. Eu trataria isso como uma visão de longo prazo, não como uma receita para colocar um agente solto em produção.

Se eu fosse aplicar isso em um projeto pequeno, toda mudança passaria por revisão humana e teria uma forma clara de desfazer. Sem isso, você troca uma economia de tempo por uma madrugada corrigindo problema.

O sandbox ajuda a limitar o que a IA consegue acessar e fazer. No vídeo, isso envolve o código do cliente, as ferramentas liberadas e os dados enviados ao agente.

A documentação da Anthropic sobre sandboxes explica esse isolamento para arquivos, rede e ferramentas.

Só que sandbox não resolve a decisão de produto. Ele limita o estrago possível. Ainda cabe à equipe decidir qual tarefa vale automatizar e como conferir o resultado.

O teste começa no erro real

Na parte sobre avaliação, os participantes contam que não começaram com uma planilha perfeita de testes.

Primeiro veio o uso.

As equipes usaram as primeiras versões, observaram respostas boas e ruins e tentaram entender se aquilo resolvia um problema que alguém queria repetir.

Isso mostra se existe valor antes de gastar tempo montando uma estrutura enorme de medição.

Depois, os erros viram casos de teste. Entram perguntas reais, tarefas difíceis e respostas que parecem boas, mas falham em um detalhe importante.

Um teste pode estar muito bem montado e ainda não representar o que acontece no trabalho. Por isso, eles combinam uso interno, perguntas reais de clientes e feedback de fora.

Assim, a equipe não treina o agente apenas para passar numa prova que ela mesma inventou.

O teste precisa acompanhar a promessa do produto.

Se o sistema promete um resumo confiável, não basta o texto parecer bem escrito. É preciso conferir fatos, fontes e utilidade.

Se promete uma alteração no código, é preciso ver se a mudança é segura, correta e útil depois que entra no produto.

Cada erro novo precisa entrar nos próximos testes. E eles admitem uma coisa importante: avaliar memória que muda e informações externas ainda é difícil.

Use o que já existe até aparecer um limite real

O vídeo também fala sobre usar Claude Managed Agents ou construir a própria estrutura.

Para um projeto pequeno, minha leitura é direta: use uma estrutura pronta quando você ainda está tentando descobrir se o trabalho tem valor. Não gaste semanas construindo a usina antes de saber se alguém precisa da energia.

Uma plataforma pronta pode reduzir o trabalho inicial de rodar a IA, guardar contexto, isolar arquivos e usar ferramentas. Você testa o fluxo primeiro.

Construa sua própria estrutura quando o controle virar parte importante do produto: custo, tempo de resposta, segurança, volume ou algum requisito que a plataforma não atende.

Essa decisão não precisa acontecer no primeiro dia.

Eu faria nesta ordem:

1. provar que o resultado ajuda alguém;
2. medir onde estão o custo e o tempo;
3. trocar apenas o que virou um problema de verdade.

Construir tudo primeiro pode gerar muito código e nenhuma resposta sobre o que realmente importa: alguém precisa desse trabalho?

Eu só construiria a infraestrutura própria quando ela mudasse o resultado, o custo ou o controle do produto.

Minha leitura do vídeo

O vídeo vale porque mostra três produtos reais e decisões que normalmente ficam escondidas. Como conferir o resultado. Como organizar informação. Como limitar a IA.

Eu copiaria a disciplina de começar pela tarefa e conferir o resultado. Não copiaria a infraestrutura nem os prazos como se fossem receita para qualquer projeto.

O que dá para aplicar

Para um projeto pequeno, eu levaria quatro coisas:

1. começar por uma tarefa específica;
2. decidir o que significa “ficou bom”;
3. testar com casos reais antes de automatizar tudo;
4. liberar mais ações só depois de entender os erros.

Isso pode ser feito com um agente, um script ou até com uma pessoa aprovando cada etapa. O mecanismo vem depois do resultado.

Essa leitura conversa com a ideia de que o agente é apenas uma parte do ciclo. O valor aparece quando a IA ajuda alguém a executar, conferir e melhorar um trabalho que antes era difícil, lento ou inconsistente.

Faça este teste antes de montar qualquer agente

Escolha uma tarefa que se repete nesta semana: preparar um resumo, organizar informações de um cliente ou revisar uma primeira versão. Não monte o agente ainda.

1. Faça a tarefa do jeito que você faz hoje e anote o tempo.
2. Escreva em uma frase o que seria um bom resultado.
3. Peça para uma IA fazer uma primeira versão.
4. Revise como você revisaria o trabalho normal.
5. Compare o tempo total, incluindo correção e retrabalho.

Se a revisão consumir a economia, o resultado do teste é não automatizar ainda. Você descobriu um limite antes de criar mais uma coisa para manter.

O que não dá para copiar diretamente

Esses três casos dependem de informação organizada, tempo e manutenção. Eu não trataria o Watchtower, a leitura da base de código ou ambientes isolados como receita de fim de semana para um projeto pequeno.

Também não dá para tratar os prazos do vídeo como promessa. Dizer que uma primeira versão ficou pronta em um dia ou duas semanas conta a experiência daqueles times. Não significa que qualquer pessoa terá o mesmo resultado. E não mostra todo o trabalho que veio antes e depois.

Instalar uma ferramenta não produz o mesmo efeito. A parte difícil é ter uma tarefa clara, informação suficiente e alguém acompanhando o que acontece.

Veredito

O vídeo é bom como estudo de caso, mas não é receita pronta para qualquer negócio. Ele mostra produtos reais usando IA sem entregar tudo para ela.

Para quem só quer uma ferramenta para responder perguntas, boa parte do vídeo é avançada demais. Para quem está construindo algo ou tentando melhorar um trabalho repetitivo, os critérios de resultado e os limites de ação são úteis.

O principal ponto, para mim, é este: IA boa não é a que parece mais inteligente na demonstração. É a que economiza tempo ou dinheiro em um trabalho real sem criar outra ocupação de configuração e manutenção.

Fontes

• Vídeo original: How founders build on Claude Managed Agents
• Visão geral do Claude Managed Agents
• Memória em Managed Agents
• Sandboxes self-hosted e isolamento de ferramentas
• Wispr Flow
• Actively
• Pendo AI
• O ápice prático da IA é um ciclo, não um agente

Os prazos e resultados relatados neste texto são declarações dos próprios fundadores durante o vídeo. Eles são apresentados como relatos de construção, não como auditoria independente de desempenho.