Muita gente, ao pensar em colegas de trabalho com IA, tem como primeira intuição que eles deveriam funcionar como uma equipe, com um agente para cada função. Um para engenharia, um para marketing, um que só escreve posts para o blog.
Nós também construímos assim. O Okou permitia criar vários agentes em um workspace, cada um com seu próprio nome, avatar, Instruções e Workflows. Em agosto, chegamos a publicar um post sobre como vários agentes dividem o trabalho e passam tarefas uns para os outros. Nosso próprio workspace tinha vários deles. Lucas escrevia nossos posts do blog, Lisa cuidava da contabilidade, Iris tratava das relações com investidores e eu tinha um agente chamado Emily, que fazia a triagem do meu e-mail.
Mas a intuição do usuário é só um ponto de referência. Antes do Notion, a intuição das pessoas sobre ferramentas de documentos era que elas precisavam de cabeçalho e rodapé.
Multiagente também não é uma capacidade fundamental. Capacidades fundamentais são aquelas de que todo produto de IA vai precisar em algum momento: conversar, criar apresentações e sites, operar um computador. Ter vários agentes não está nessa lista.
Veja o Lucas, nosso antigo agente do blog. Cerca de um terço das Instruções dele é o mesmo modelo genérico que o Okou padrão usa. O resto são três procedimentos específicos: como publicar um post do blog no Strapi, como escrever as páginas de casos de uso do nosso site e como gerar o relatório diário de conversão de cadastros. Todos os 13 Workflows associados ao Lucas são públicos no workspace. Nenhum deles pertence só ao Lucas.
Então a diferença entre o Lucas e o Okou padrão se resume a um nome, um avatar e três procedimentos que deveriam ter sido Workflows. Esses procedimentos estão presos dentro do Lucas. Peça ao Okou padrão para publicar um post do blog e nenhuma dessas regras estará disponível.
Conforme o número de agentes crescia, cresciam também as combinações. Muitos agentes, muitos Workflows e muitas conversas interagem entre si, e cada combinação é uma lógica que nós precisamos manter e que os usuários precisam aprender. Esbarramos em perguntas que não conseguíamos responder bem do ponto de vista do usuário:
- Por que dois agentes não podem compartilhar o mesmo Workflow?
- Por que eu só posso falar com o Okou no Slack, e não com o meu próprio agente privado? Se o Lucas é uma pessoa, eu deveria conseguir falar com ele em qualquer lugar.
- Por que a memória é compartilhada entre todos os agentes? Se cada agente é uma pessoa, cada um deveria ter sua própria memória.
Tudo isso tem solução, mas cada ponto exige um trabalho de engenharia de verdade. Se ficarem sem solução, o multiagente continua sendo uma experiência pela metade. Também tivemos dificuldade para encontrar um problema que só vários agentes conseguissem resolver. A reclamação que mais ouvíamos era que havia agentes demais para gerenciar.
Então decidimos que cada pessoa tem um só Okou. O modelo é mais simples:
- Cada pessoa tem um Okou padrão.
- O seu Okou pertence a você e é privado.
- O seu Okou e o Okou de um colega não são o mesmo agente.
- O seu Okou pode usar qualquer Workflow que alguém da sua organização tenha deixado como Public.
O que antes ficava preso a um agente agora fica onde faz mais sentido:
- As Instruções pertencem a você. Você escreve um único conjunto, e o Okou o segue na web, no Slack e nas automações.
- Os Workflows pertencem ao workspace. Qualquer pessoa pode usar um Workflow Public que um colega publicar, e você pode copiá-lo e torná-lo seu.
- As contas conectadas pertencem a você, então você não precisa mais escolher qual agente recebe acesso.
- As conversas ficam agrupadas em Projetos, por cliente, projeto ou tema.
Nesse modelo, um agente é pouco mais que um conjunto de Instruções. Os três procedimentos dentro do Lucas deveriam virar Workflows que qualquer pessoa pode usar.
Multiagente é, na verdade, uma prática de gestão dentro de uma organização, uma forma de gerenciar o que a IA pode fazer. Cada organização tem seus próprios métodos de gestão, e nenhum conjunto serve para todo mundo. Um único agente está mais próximo de uma ferramenta, e ferramentas são mais fáceis de entender e adotar. Do que os usuários mais precisam é concluir a tarefa. Em seguida, de uma ferramenta para fazer isso. Do que menos precisam é de um método para fazer isso.
O time de Applied AI da Anthropic percebeu algo parecido em um post recente sobre implantações de agentes em empresas. Nas comparações entre várias implantações, um único agente com Skills frequentemente superava em qualidade um design dividido em subagentes especialistas, e muitas vezes com custo e latência menores por tarefa. Eles também escrevem que “com muita frequência vemos empresas darem a cada equipe ou tipo de problema seu próprio subagente, e a arquitetura de agentes acaba virando uma cópia do organograma”. O post deles trata de arquitetura de agentes, não de design de produto, mas o raciocínio também se aplica.
Olhando para os produtos de IA de hoje, vemos quatro modelos:
- Muitos agentes, muitas conversas. Esse era o Okou.
- Um agente, muitas conversas. É assim que funcionam o ChatGPT, o Codex e o Claude Cowork.
- Um agente, uma conversa. É assim que funciona o Instinct.
- Muitos agentes, cada um com uma única conversa. É assim que funciona o Grok bot.
Nós tínhamos a combinação mais complexa, e ela não resolvia mais problemas.
Sabemos que esta é uma mudança que quebra a compatibilidade. Duas coisas nos impediram de fazê-la antes: pedir que você aprendesse uma nova forma de trabalhar, com um só Okou mais Workflows, e a falta de um caminho claro para o que você já tinha construído. Este é o caminho:
- Suas conversas continuam lá. Você pode encontrá-las pelos Projetos, pela busca e pelos links originais.
- Se você usava agentes diferentes para organizar conversas, use Projetos. Manter as conversas agrupadas por categoria era o principal motivo pelo qual muita gente criava agentes extras. O Claude e o ChatGPT resolvem a mesma necessidade com Projetos.
- Se você escreveu Instruções diferentes para agentes diferentes, mantenha o que elas têm em comum nas suas Instruções pessoais e transforme os procedimentos específicos em Workflows.
Quanto antes pararmos de construir abstrações em cima de vários agentes, melhor. Quando você abrir o Okou, não vai mais precisar decidir a qual agente pedir. Diga ao Okou o que precisa ser feito, e o Okou cuida do resto.
