IA aplicada10 min de leitura

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

Wispr Flow, Actively e Pendo mostram como agentes de IA entram em produtos reais, com memória, testes e limites.

Por Felipe Natanael·8 de setembro de 2026·Nível: Intermediário

Fonte principal: vídeo oficial da Anthropic. Os prazos e resultados citados neste texto são relatos dos participantes da conversa, não uma auditoria independente das empresas.

A conversa reúne Sahaj, da Wispr Flow, Mihir, da Actively, e Todd, da Pendo, com mediação de Lance Martin, da Anthropic.

Os três estão construindo produtos com agentes de IA. O vídeo apresenta o Claude Managed Agents, mas a parte mais útil é mais simples: cada equipe começou por um trabalho concreto e criou um jeito de conferir se a IA estava ajudando.

Antes de escolher a ferramenta, cada equipe decidiu qual tarefa a IA faria, que informação ela precisaria e como alguém saberia se o resultado estava certo.

Aqui, agente significa uma IA que recebe uma tarefa, busca informações e executa alguns passos para chegar a um resultado.

A pergunta é:

Qual trabalho precisa ser feito, e como vou saber se foi bem feito?

Primeiro, definir o trabalho

No caso da Wispr Flow, Sahaj descreve a reunião como uma jornada que começa antes da chamada e continua depois dela.

O trabalho inclui preparar a conversa, entender quem estará presente, chegar a um resultado, registrar os combinados e acompanhar o próximo passo.

O agente entra para preparar um resumo antes da reunião. Ele reúne informações sobre a pessoa, o contexto da conversa, discussões anteriores e o resultado desejado.

O risco aparece rápido. Um resumo errado pode ser pior do que nenhum resumo. O sistema pode confundir pessoas, atribuir uma informação à fonte errada ou apresentar como confirmado algo que não foi verificado.

Por isso, Sahaj relata que a equipe usa um conjunto de critérios para conferir o resultado. No vídeo, eles chamam isso de outcome. A conferência verifica fatos, fontes, organização, ordem e utilidade para quem vai ler.

Uma parte prepara o resumo e outra confere se ele atende aos critérios. Isso reduz o risco de a IA aprovar o próprio erro.

Quando o resultado não passa pela conferência, a equipe pode escolher não mostrar o resumo ao usuário.

Esse detalhe vale mais do que parece. Em alguns fluxos, a resposta correta do sistema é admitir que ainda não tem segurança suficiente para responder.

Sahaj também relata que a primeira versão foi construída em um dia. O produto não ficou resolvido em um dia.

Nas semanas seguintes, a equipe ajustou as instruções, as ferramentas, a busca, a ordem das informações e o fluxo até entender o que ajudava de verdade.

A estrutura técnica acelerou a primeira tentativa. O uso real construiu o produto.

O que a IA precisa lembrar

Na Actively, Mihir descreve uma IA para cada conta de vendas. Ela acompanha o contexto daquela conta e tenta identificar o próximo movimento mais útil.

O problema muda quando a equipe precisa analisar muitas contas ao mesmo tempo.

No vídeo, Mihir apresenta o Watchtower, uma ferramenta que reúne informações entre contas, gera relatórios, prioriza oportunidades e organiza previsões. Ele relata que essa versão foi colocada de pé em cerca de duas semanas.

A parte mais interessante está na forma de organizar o contexto.

Uma empresa pode usar um campo do Salesforce de maneira diferente de outra. Um time pode chamar uma etapa de “avaliação”, enquanto outro usa “discovery”. Algumas informações pertencem à conta. Outras pertencem ao usuário ou à organização.

Mihir descreve camadas de memória para lidar com essas diferenças:

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

O ponto não é guardar tudo. É recuperar a informação certa no momento certo.

Memória sem escopo cria confusão. O sistema precisa saber de onde veio uma informação, a quem ela pertence e em qual situação deve ser usada.

O Watchtower também divide o trabalho. Ele pode filtrar candidatos, distribuir tarefas para cada conta e reunir os resultados depois.

A lógica é simples: um trabalho grande precisa ser quebrado em tarefas menores, cada uma com o contexto correto.

O ganho não vem de fazer uma conversa interminável com um modelo. Vem de organizar o trabalho para que cada agente receba uma tarefa possível e o sistema consiga comparar os resultados.

Quando a IA mexe no código

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

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

O fluxo descrito é:

um comportamento problemático aparece nos dados;
o agente investiga o código relacionado;
ele sugere uma alteração;
a equipe revisa a proposta e pode enviá-la para entrar no código;
o sistema acompanha se o problema volta.

Todd apresenta a ideia de um software auto-curável como visão de longo prazo.

Isso não significa entregar controle total à IA. A equipe usa um sandbox, um ambiente separado, para limitar o que a automação pode acessar e fazer.

A equipe precisa decidir o que o agente pode ler, quais ferramentas pode usar, o que pode modificar, quais mudanças exigem aprovação humana e que evidência acompanha a sugestão.

Também precisa existir uma forma de desfazer a alteração e verificar se a correção melhorou o produto.

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

Mas o sandbox não resolve a decisão de produto. Ele apenas limita o espaço em que a IA pode agir enquanto a equipe aprende quais tarefas podem ser automatizadas com segurança.

O uso real vem antes dos testes

Na parte sobre os testes, os participantes relatam que não começaram com um conjunto perfeito de avaliações.

Primeiro veio o uso real.

As equipes colocaram as primeiras versões nas próprias mãos, observaram respostas, procuraram casos bons e ruins e tentaram entender se havia uma experiência que as pessoas realmente queriam repetir.

Esse estágio ajuda a descobrir se existe valor antes de construir uma estrutura grande de medição.

Depois, os problemas observados viram casos de teste. Entram perguntas reais, erros que voltaram, tarefas difíceis, tipos diferentes de conta e respostas que parecem boas, mas falham em algum detalhe.

Isso evita duas armadilhas. A primeira é otimizar o agente para um conjunto artificial criado pela própria equipe. A segunda é confundir uma demonstração bonita com um produto confiável.

Os testes precisam acompanhar a promessa do produto.

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

Se promete uma alteração no código, é preciso avaliar segurança, correção, revisão e efeito depois da mudança.

Os testes também não são um selo permanente. O uso cria novos casos, que precisam entrar no conjunto de testes.

Usar uma plataforma pronta ou construir tudo?

O vídeo também trata da escolha entre usar Claude Managed Agents e construir tudo por conta própria.

Minha leitura para um projeto pequeno é direta: uma plataforma pronta faz sentido quando a prioridade é aprender sobre o resultado e a estrutura técnica não é o diferencial do produto.

Ela pode reduzir o trabalho inicial para rodar a IA, guardar contexto, isolar arquivos e usar ferramentas. A equipe testa o fluxo antes de construir cada parte por conta própria.

A estrutura própria passa a fazer mais sentido quando o controle vira parte central do produto. Isso pode acontecer quando cada centavo importa, o tempo de resposta é crítico, há exigências específicas de segurança, o volume é alto ou o sistema de agentes é a principal competência da empresa.

Na conversa, os participantes discutem o equilíbrio entre custo, controle e tempo de resposta. A decisão não precisa ser tomada no primeiro dia.

Eu seguiria esta ordem:

provar que o resultado tem valor;
descobrir onde o custo e o tempo de resposta realmente estão;
substituir apenas o que virou uma restrição real.

Construir tudo primeiro pode produzir bastante código sem responder se alguém precisa do trabalho que a IA executa.

A ferramenta é o meio. O problema que ela resolve continua sendo a parte mais importante.

Minha avaliação do vídeo

O vídeo vale a pena porque mostra três produtos reais e explica decisões que normalmente ficam escondidas: conferir o resultado, organizar as informações e limitar o que a IA pode fazer.

O principal insight é simples: o agente vem depois do trabalho. Primeiro você define a tarefa e o que seria um bom resultado. Depois escolhe se a IA consegue ajudar e como alguém vai conferir o que ela fez.

O que dá para aplicar

Para um projeto pequeno, eu copiaria quatro coisas:

começar por uma tarefa específica;
definir como um resultado bom será reconhecido;
testar com casos reais antes de tentar automatizar tudo;
dar mais liberdade à IA somente depois de entender os erros.

Isso pode funcionar com um agente, um script ou até 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.

O que não dá para copiar diretamente

Uma equipe com produto, dados e infraestrutura próprios consegue fazer coisas que a maioria das pessoas não consegue fazer em um fim de semana. O Watchtower, a leitura da base de código e os ambientes isolados dependem de informação organizada, tempo e manutenção.

Também não dá para tratar os prazos do vídeo como promessa. Dizer que a 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, nem inclui todo o trabalho que veio antes e depois.

Não basta instalar uma ferramenta e esperar 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 é uma receita pronta para qualquer negócio. Ele mostra como produtos reais usam IA sem entregar tudo para ela, e ajuda a separar uma decisão útil de um recurso apresentado como novidade.

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

Esse será o critério da série: pegar um vídeo ou material, traduzir o que importa, mostrar como aplicar e dizer com clareza o que parece funcionar, o que exige estrutura demais e o que não vale copiar.

Fontes

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.