Da programação aos agentes de trabalho do conhecimento — Karan Vaidya, Composio
AAI Engineer
Computing/SoftwareInternet Technology
Transcript
00:00:00Olá, pessoal, sou o Karan Vedya, cofundador e CTO da Composio.
00:00:19A maioria das chamadas de ferramentas de agentes
00:00:21ainda acontece em uma única área.
00:00:23Sem surpresas, é a engenharia de software.
00:00:26Qualquer outro tipo de trabalho está ficando muito para trás.
00:00:29Se os modelos continuam melhorando, então
00:00:32por que ainda estamos limitados apenas à programação com agentes?
00:00:35Essa é a pergunta de um trilhão de dólares que estou aqui para responder.
00:00:43Três anos atrás, os agentes de código eram apenas autocompletar.
00:00:47Hoje, a engenharia de software é totalmente autônoma.
00:00:50Passamos de apertar tab, tab, tab para apenas deixar o Claude codar.
00:00:56Isso é simplesmente mágico.
00:00:59E por que isso aconteceu tão rápido na programação?
00:01:04A maioria das pessoas pensaria que são os modelos.
00:01:06Sim, os modelos melhoraram muito ao longo do tempo, nos últimos dois a três anos, e também os
00:01:13harneses, Claude Code, Codex, Cursor.
00:01:17Mas sozinhos, isso não teria sido suficiente.
00:01:20Isso só funcionou porque toda a infraestrutura e os sistemas ao redor do código foram literalmente feitos
00:01:26para agentes.
00:01:27O código veio com o suporte que os agentes precisavam.
00:01:31Você tem o repositório, o histórico de commits, testes, CI/CD, revisão, linters, reversão se algo
00:01:39der errado.
00:01:39O tipo de coisa que faz você confiar nos agentes, os sistemas ao redor do código.
00:01:45Agora, estamos apontando esses mesmos agentes incríveis para todo o resto: suporte, finanças, vendas.
00:01:54Mas os agentes que se saíram fenomenalmente bem na programação estão trabalhando às cegas porque a
00:02:00infraestrutura ao redor da programação nem existe em outros campos.
00:02:04Então, como fechamos a ponte entre os agentes de código e os agentes de trabalho de conhecimento?
00:02:11Acreditamos que sejam seis primitivas centrais, e a programação tinha todas as seis, enquanto o trabalho de conhecimento não
00:02:19tem nenhuma.
00:02:20E é isso que precisamos construir.
00:02:24A primeira é a centralização.
00:02:26Os agentes de código funcionaram tão bem, em parte, porque estavam muito próximos da fonte da verdade.
00:02:34Eles sabiam o quê, o porquê e o como.
00:02:37Você dá a eles o repositório, a infraestrutura como código, fecha o ciclo e deixa o modelo
00:02:43trabalhar.
00:02:44O agente começa com tudo o que precisa em um só lugar, que é a base de código.
00:02:51Isso é exatamente o que falta no trabalho de conhecimento hoje.
00:02:55Por exemplo, um único negócio está espalhado por cinco plataformas diferentes.
00:03:00Os registros estão no Salesforce, os documentos no Notion, os e-mails no Gmail, conversas no
00:03:05Slack e o histórico de suporte está no Zendesk.
00:03:09Não há uma única fonte da verdade, um único lugar para obter todas as informações.
00:03:14O código é separado, e cada aplicativo tem seu próprio login.
00:03:18Antes que um agente de trabalho de conhecimento possa começar a fazer as coisas, ele tem que ir lá e puxar todas as
00:03:23pontas e meio que amarrá-las sozinho.
00:03:27E esse ainda é o ponto de partida onde o agente de código começou.
00:03:30Ele já tinha tudo.
00:03:32Então, como você pode esperar que um agente de trabalho de conhecimento faça o mesmo nível de trabalho que um agente de código?
00:03:39Portanto, a primeira coisa que construímos é o centro ausente.
00:03:42Um lugar onde todos os seus aplicativos, todas as suas conexões, todos os seus logins existem.
00:03:46Para que o agente não precise fazer o trabalho difícil de juntar tudo.
00:03:51Eles encontram tudo em um único lugar.
00:03:55E eles obtêm a linha de base com a qual o agente de código começou, que é o repositório, a informação
00:03:59em todas as pilhas em um único lugar.
00:04:02Essa é a fundação com a qual você começa, e você pode dar acessos de gravação ao seu agente.
00:04:09A próxima coisa de que o agente precisa é de senso de histórico, a capacidade de olhar para o passado.
00:04:16No código, você ganha isso de graça.
00:04:18O Git mantém um registro de cada coisa que entrou, de cada alteração feita.
00:04:23Assim, o agente pode sempre olhar para trás e ver como uma certa alteração foi feita.
00:04:27Por que algo funcionou, por que algo não funcionou.
00:04:31Pense no tipo de coisa que você realmente pede para o seu agente fazer.
00:04:34Tivemos que reverter uma alteração no passado devido a alguma falha, mas isso foi bem difícil de conseguir.
00:04:40Você pode olhar para isso e trazer de volta?
00:04:43Ele apenas lê o histórico, traz de volta e executa.
00:04:46O histórico não é apenas para o agente.
00:04:49Também é para você manter um registro do que o agente está fazendo.
00:04:53Você pode ver o que o agente está fazendo, onde ele está errando, onde ele está tendo sucesso.
00:04:58E em vez de confiar no que o agente está te dizendo, você pode simplesmente ir a esses aplicativos específicos
00:05:04e ver o que ele fez.
00:05:09Agora, faça essas mesmas perguntas sobre o trabalho de conhecimento.
00:05:12O que levou o CRM a estar no estado em que se encontra hoje?
00:05:16Como meu colega redigiu aquele e-mail incrível que levou ao fechamento do negócio?
00:05:22Qual é o processo real para escalar um problema de suporte ou até mesmo resolvê-lo?
00:05:27As respostas estão espalhadas por centenas de aplicativos, e nenhum deles mantém o histórico.
00:05:31Portanto, o agente não tem memória.
00:05:33Ele começa de um estado em branco quase todas as vezes.
00:05:36Não faz ideia do que foi tentado antes, do que funcionou, do que não funcionou.
00:05:40E você também não tem nada para olhar.
00:05:44Assim que o agente roda, ele te diz que concluiu com sucesso.
00:05:47Você não sabe se ele realmente concluiu com sucesso.
00:05:49Não há como saber se está certo ou não.
00:05:52E é isso que está faltando, um registro do trabalho.
00:05:56Agora, como tudo finalmente passa por um único lugar, essa centralização,
00:06:02podemos construir uma camada sobre ela, o registro.
00:06:06Cada ação que o agente realiza pode ser registrada em todos os outros aplicativos.
00:06:12O que ele tocou, o que ele ignorou, o que funcionou, o que não funcionou.
00:06:17Através disso, primeiramente, o agente ganha memória.
00:06:20Ele pode olhar para trás e ver como tarefas semelhantes foram feitas antes, o que foi bem-sucedido e replicar novamente.
00:06:28Ele não começa com um estado em branco o tempo todo.
00:06:31Segundo, você ganha confiança.
00:06:33Você finalmente pode ver exatamente o que o agente está fazendo.
00:06:36Então, em vez de torcer para que ele faça a coisa certa, você pode simplesmente voltar, conferir e pegá-lo se ele fizer algo errado.
00:06:44E à medida que você o vê cada vez mais fazendo as coisas certas, você desenvolverá confiança e delegará mais tarefas a ele.
00:06:50A próxima coisa de que um agente precisa é de contexto.
00:06:53E há realmente dois tipos de contexto, se você pensar bem.
00:06:57O primeiro é a forma da plataforma, a arquitetura.
00:07:01Como as coisas fluem umas para as outras, como as coisas estão ligadas, os fluxos de dados.
00:07:05Mais ou menos como um mapa que um engenheiro sênior carrega na cabeça, e que um engenheiro júnior leva provavelmente três meses para desenvolver.
00:07:12O segundo é o estilo.
00:07:13Isso não é o que está objetivamente correto, mas sim o que é considerado bom na sua empresa.
00:07:19Portanto, como você faz as coisas, coisas como linter, verificações de tipo, etc.
00:07:24E talvez você use um decorador do TypeScript, que mais ninguém usaria.
00:07:29Isso não está exatamente em algum manual.
00:07:32Está mais na sua base de código.
00:07:34Está tudo disponível na sua base de código.
00:07:35Assim, o agente pode simplesmente ir e olhar e descobrir as especificações, o que você gosta, os linters, formatadores, etc.
00:07:45Agora, chegando ao trabalho de conhecimento, a mesma coisa.
00:07:48Digamos que você esteja escrevendo um documento para um cliente.
00:07:50Para sequer começar, eu teria que abrir o banco de dados para puxar o uso deles, verificar post-hoc como eles realmente vêm usando as coisas,
00:07:58e o Salesforce para ver os detalhes do negócio deles.
00:08:01Só então eu posso começar a escrever a primeira linha do documento.
00:08:05A resposta não estava isolada em apenas uma dessas ferramentas.
00:08:09Eu consigo escrever este documento porque estou juntando as pontas de todas essas ferramentas em um único contexto na minha cabeça.
00:08:15Portanto, juntando histórico e contexto, é assim que você mapeia como a organização funciona.
00:08:21E essa parte não está disponível facilmente para o agente.
00:08:26Então, assim como fizemos a centralização e o registro, o histórico que acabamos de construir, aquele que dá memória ao agente e permite verificar o que ele fez,
00:08:36também faz mais uma coisa interessante.
00:08:38Se você registrar o suficiente do que cada agente está fazendo, você começa a ver padrões.
00:08:42Você começa a ver como a organização funciona e começa a formar habilidades, que são algum tipo de destilação de como a organização vem trabalhando.
00:08:51Quais abordagens funcionam, quais não funcionam, o que levou a falhas no passado, etc.
00:08:57O registro não é mais apenas o histórico do que aconteceu.
00:09:01É um retrato de como sua empresa opera.
00:09:03E ele realmente funciona em três níveis diferentes.
00:09:06Como uma ferramenta funciona em geral, o que é aplicável a todas as pessoas.
00:09:09Como a empresa faz as coisas e como você prefere fazer as coisas.
00:09:13O que é considerado bom para você.
00:09:15E esse é o contexto que faltava para um agente de trabalho de conhecimento.
00:09:19Como o trabalho realmente é feito.
00:09:21O verdadeiro manual de instruções, por assim dizer.
00:09:23E a preferência de uma empresa, de um usuário individual.
00:09:27E agora o agente pode consultá-lo e parar de adivinhar como a empresa opera.
00:09:34A outra razão pela qual os agentes de código funcionam tão bem.
00:09:37Eles testam a si mesmos.
00:09:38O trabalho verifica a si mesmo.
00:09:40Verificação.
00:09:41No momento em que o agente escreve código, uma série de verificações o acompanha.
00:09:44Os testes unitários conseguem pegar pequenos erros.
00:09:47Os testes de integração pegam aqueles que afetam componentes a três blocos de distância.
00:09:52O sistema de tipos nem sequer funcionaria e rodaria se algo estivesse errado.
00:09:57O compilador nem sequer faria o build.
00:10:00Por cima disso ficam as verificações de software.
00:10:02Linters, formatadores, bugbot.md, habilidades de revisão, et cetera.
00:10:06E eles garantem que o código corresponda à forma como sua equipe gosta de seguir os padrões dela.
00:10:12Nada disso chega até você.
00:10:14O agente completa o ciclo sozinho e se certifica de seguir o padrão e conseguir rodar o código.
00:10:21Agora, pense sobre, tipo, há algum tempo, eu apontei meu open claw para uma abordagem de recrutamento.
00:10:28E-mails em massa para candidatos.
00:10:30Ele rodou.
00:10:31Ele enviou toneladas de e-mails.
00:10:34Alguns de vocês podem até ter recebido do meu open claw.
00:10:37Ele fez exatamente o que eu mandei fazer.
00:10:40Também foi um desastre.
00:10:42Do tipo que acaba no Twitter com o meu nome estampado nele.
00:10:46É, acho que vocês conseguem imaginar a confusão que deu.
00:10:51Eu não fiquei muito feliz quando isso aconteceu.
00:10:54E tem mais.
00:10:55Todas as verificações do slide anterior teriam passado.
00:10:58Os e-mails eram válidos.
00:11:00Os endereços eram reais.
00:11:00Eles realmente chegaram a pessoas reais que publicaram.
00:11:04Não havia nenhum teste no mundo para questionar o que realmente importava.
00:11:10Isso deveria ter sido enviado?
00:11:13Essa é a lacuna.
00:11:14No código, esses testes dizem o que está errado e o que está certo.
00:11:17Aqui, a internet me disse que eu estava errado.
00:11:21Então, nós construímos as verificações que estão faltando.
00:11:24O problema na thread acima não foi que a abordagem estava errada.
00:11:28Foi que ela foi enviada antes mesmo de eu ficar sabendo.
00:11:31Portanto, a solução é simples.
00:11:33Pegar antes mesmo de ser real.
00:11:35Então, temos duas maneiras de fazer isso.
00:11:37Primeiro, antes que o agente envie qualquer coisa, ele verifica os rascunhos de e-mail que enviei antes, se corresponde ao meu estilo, se corresponde à qualidade que eu gosto.
00:11:47Segundo, antes de fazer qualquer coisa destrutiva no cenário do mundo real, fornecemos aos agentes caixas de saída que simulam as ferramentas reais, e eles podem enviar, podem realizar ações nessas caixas de saída.
00:11:59Então, em vez de o raio de impacto atingir o mundo real, ele atingirá um sandbox, e então poderei revisar antes de o agente fazer a coisa real.
00:12:07Junte esses dois e você terá algo que o trabalho de conhecimento nunca teve.
00:12:11Uma forma de o agente verificar seu próprio trabalho antes mesmo de ele ser real.
00:12:16Ele finalmente pode fechar seu próprio ciclo em vez de parar para esperar por você, e com tudo isso, você pode confiar na ação que ele está tomando sem ser bombardeado com os tweets que eu publico.
00:12:29A próxima coisa de que o agente precisa é governança.
00:12:32Construir confiança é controlar o que o agente pode fazer, erguendo as paredes certas ao redor dos agentes.
00:12:39No código, isso já está praticamente resolvido e possui várias camadas.
00:12:44O agente pode fazer o que quiser em sua própria branch, mas não pode fazer merge para a main.
00:12:49Um revisor humano fica entre ele e o merge para a main.
00:12:52Os arquivos críticos têm donos de código, então sempre que ele toca em um deles, as pessoas certas são envolvidas.
00:12:58Usamos agentes para enviar para implantações de preview, nunca deixando que toquem nas implantações de produção, então controlamos isso por lá.
00:13:04A governança não é uma única barreira, mas várias delas, cada uma variando em tamanho, dependendo do raio de impacto que expõe.
00:13:12Nada disso desacelera o agente nas partes seguras, apenas o impede de estragar a produção.
00:13:19E quanto mais rígidas forem essas linhas, mais você poderá confiar no agente e deixá-lo solto.
00:13:25Você provavelmente viu esta.
00:13:27A diretora de alinhamento do Meta Super Intelligence Lab conectou um agente ao seu e-mail, e ele começou a destruir seu e-mail, deletando vários deles.
00:13:36Ela disse para ele parar, e ele continuou; no fim, ela teve que correr para uma máquina física para pará-lo, mas a essa altura 200 e-mails já haviam sumido.
00:13:45Ela havia dito a ele antecipadamente no prompt para confirmar antes de agir em casos assim, mas aquilo era apenas um prompt, que provavelmente seria compactado.
00:13:53E se alguém cujo único trabalho é o alinhamento de IA não consegue dar o prompt correto ao agente, então provavelmente nenhum de nós consegue.
00:14:03E essa é a verdadeira razão pela qual esses agentes são tão difíceis de confiar, não porque são piores que os agentes de código, mas porque não há nenhuma parede ao redor deles.
00:14:12No código, a parede já estava construída no sistema enquanto desenvolvíamos antes.
00:14:17O trabalho de conhecimento também tem algumas partes e pedaços aqui e ali.
00:14:20Por exemplo, o Gmail tem escopos.
00:14:21O Salesforce tem níveis de permissão.
00:14:23Mas está tudo tão disperso por toda parte que é muito difícil ter controle real, e na maioria das vezes as pessoas acabam fazendo isso via prompt.
00:14:32E o prompt é frágil.
00:14:34O agente encontrará essas brechas.
00:14:36As coisas serão compactadas.
00:14:38E em grande escala, uma dessas cercas vai quebrar, e você também estará na mesma situação em que 200 dos seus e-mails importantes estão desaparecendo.
00:14:47Então, o que realmente o pararia não é uma instrução melhor, mas uma parede que o agente não consiga cruzar, mesmo que esquecesse que essa parede existia.
00:15:00Então construímos essas paredes em duas camadas.
00:15:03A primeira camada é determinística: controle sobre o que o agente pode alcançar, ao que ele tem acesso.
00:15:09Um agente de recrutamento provavelmente pode apenas ler os e-mails.
00:15:13Um agente de suporte pode criar um rascunho de e-mail, mas não enviá-lo de fato.
00:15:17O limite vive fora desses agentes.
00:15:19Ele não pode ser contestado pelo agente, nem esquecido ou compactado.
00:15:24A instrução de uso falhou porque vivia na memória do agente dentro do prompt.
00:15:28Isso não.
00:15:30Mas só o acesso não a teria salvo, porque ela estava de fato construindo um agente de e-mail.
00:15:36Portanto, ele definitivamente precisava de acesso àquele e-mail.
00:15:39A outra coisa que fazemos é fornecer políticas, o que significa que você pode definir políticas em linguagem natural sobre o que o agente pode fazer, mesmo com esses acessos.
00:15:49Então, coisas como nunca excluir mais de 10 e-mails sem minha permissão.
00:15:53Nunca enviar e-mails para fora de um determinado domínio.
00:15:56Regras que, mesmo com esse acesso, controlam o comportamento.
00:16:00Portanto, entre essas duas coisas, uma camada controla o que o agente pode alcançar, e a outra camada pode controlar o comportamento com o que ele pode fazer com esse alcance.
00:16:09Juntas, elas formam uma governança real para o agente.
00:16:11Em vez de pedir para o agente se comportar, é impor o que ele pode fazer.
00:16:17O último pilar: reversibilidade.
00:16:20E é aqui que chegamos quando as coisas dão errado.
00:16:25Posso desfazer isso?
00:16:27No código, quase sempre você pode.
00:16:30Cada alteração é registrada.
00:16:32As coisas podem ser revertidas.
00:16:33Você pode dar git revert no último commit, ou git bisect para encontrar o commit que quebrou sua produção e revertê-lo.
00:16:41Tipo, não estou dizendo que é bom.
00:16:44Não vou fingir que seja.
00:16:45Se as coisas vão para produção e quebram, é sempre ruim.
00:16:48Mas ainda assim não é permanente.
00:16:50Você ainda pode voltar atrás.
00:16:51E é isso que lhe dá confiança para deixar seus agentes trabalharem e fazerem um pouco de mágica.
00:16:57Porque mesmo que eles quebrem as coisas, você tem um caminho de volta.
00:17:03Para o trabalho de conhecimento, não existe botão de desfazer.
00:17:05Coisas como pense na caixa de entrada dela.
00:17:07Aqueles 200 e-mails sumiram.
00:17:09Eles desapareceram.
00:17:10Esse é o caso normal, aliás.
00:17:12O caso de desastre é um e-mail enviado que você não pode reverter.
00:17:15Uma transferência que já foi feita, então você não pode reaver esse dinheiro.
00:17:18Um registro excluído, gone para sempre.
00:17:20A maioria das ações no trabalho de conhecimento, na verdade, não tem botão de desfazer.
00:17:24E isso muda toda a equação.
00:17:27Isso muda o raio de impacto.
00:17:29Com código, você pode confiar no agente depois do fato.
00:17:31Deixe-o rodar.
00:17:32Verifique o resultado.
00:17:33Desfaça se estiver errado.
00:17:34Por aqui, não há como voltar atrás.
00:17:36O único caminho que lhe resta é confiar antes que o agente aja.
00:17:40É isso que faz esses agentes parecerem perigosos de uma forma que os agentes de código nunca pareceram.
00:17:44Não é que eles falhem com frequência.
00:17:46É que por aqui a falha é para sempre.
00:17:49Portanto, ou você confia totalmente de antemão ou nunca o deixa agir.
00:17:55Deixe-me ser honesto.
00:17:56A reversibilidade é o mais difícil de replicar no trabalho de conhecimento.
00:17:59O desfazer real, da forma como existe para código, provavelmente não existe em todos os cenários do trabalho de conhecimento.
00:18:04Mas temos alguns cenários onde o desfazer existe, e nós os chamamos assim.
00:18:09Digamos que você adicione um marcador.
00:18:11Você pode remover o marcador depois.
00:18:14Mas para ações que você não pode desfazer de jeito nenhum, como exclusões definitivas que fazem os e-mails sumirem da sua caixa de entrada,
00:18:21nós novamente fornecemos um sandbox onde o agente pode fazer a coisa primeiro no sandbox,
00:18:25e você pode revisar, para só então ir para o ambiente de produção.
00:18:30Nada disso toca o mundo real.
00:18:31Essa é toda a reviravolta.
00:18:32No código, você pode desfazer o erro depois que ele acontece.
00:18:35Aqui, você o pega antes que aconteça.
00:18:37Timing diferente, mesmo resultado.
00:18:39Um erro que não vai perdurar.
00:18:41Pense nela novamente.
00:18:42As ações que pudéssemos reverter, daríamos a elas um botão de reverter.
00:18:45As que não pudéssemos, o agente passaria pelo sandbox primeiro,
00:18:48e ela seria avisada: seus 1.200 e-mails estão prestes a ser excluídos.
00:18:52Você quer isso?
00:18:54Ainda não está pronto.
00:18:57Mas através de bilhões de ações pelas quais estamos passando,
00:19:00estamos aprendendo no caminho quais podem ser revertidas, quais não podem,
00:19:04e preparando o sandbox de acordo.
00:19:09Se você levar uma coisa daqui hoje, leve isto.
00:19:11Por dois anos, o modelo foi o gargalo.
00:19:14Portanto, todo mundo estava correndo em direção a modelos cada vez melhores.
00:19:17Agora os modelos ficaram bons o suficiente, a ponto de a engenharia de software ser 100% autônoma.
00:19:23Mas agora todo o resto é o gargalo.
00:19:26O mesmo modelo que escreve seu código também pode fazer seu recrutamento, vendas e outros trabalhos de conhecimento.
00:19:36Mas no momento ele está trabalhando às cegas.
00:19:39Sem histórico, sem contexto, sem formas de verificar, sem diretrizes, sem desfazer.
00:19:44Portanto, o gargalo se mudou.
00:19:48Agora é a infraestrutura que ninguém construiu ainda, e é isso que estamos construindo na Composio.
00:19:54Sim, estamos impulsionando um bilhão de chamadas de ferramenta no total, com 300 milhões de chamadas de ferramenta acontecendo todos os meses.
00:20:02E se você está construindo um agente, basta apontá-lo para a Composio e ver a mágica acontecer para o trabalho de conhecimento.
00:20:08E se você quiser construir o substrato futuro dos agentes de IA, por favor, venha falar comigo.
00:20:13Estamos definitivamente contratando, e há muito, muito o que fazer.
00:20:17Os modelos continuarão melhorando.
00:20:19O gargalo não serão os modelos.
00:20:21Serão as coisas ao redor deles.
00:20:22Obrigado.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video