A maioria dos produtos de IA trata a memória como um recurso pessoal — lembrando fatos sobre um usuário ou uma conversa. Mas a IA que colabora entre equipes precisa de um tipo de memória fundamentalmente diferente. Os sistemas de IA se tornam mais úteis quando podem se basear no que aprenderam anteriormente. Mas, em softwares corporativos, a memória não se resume a armazenar mais contexto. O problema mais difícil é tornar essa memória útil em todos os trabalhos compartilhados, mantendo-a ao mesmo tempo inspecionável, governável e com reconhecimento de permissões.
Esse é o desafio que nos propusemos a resolver com os Assistentes de IA.
Os assistentes de IA atuam em um ambiente diferente. Eles colaboram em tarefas, projetos e documentos compartilhados. Recebem feedback de várias pessoas. Trabalham em vários sistemas. E precisam melhorar com o tempo sem se tornar um enigma cheio de contexto oculto que ninguém pode auditar.
Isso cria um problema de design diferente. Um assistente de IA precisa de uma maneira de aprender com a execução, recuperar o conhecimento relevante posteriormente e explicar como esse conhecimento influenciou as suas ações. Ao mesmo tempo, não pode tratar todas as informações anteriores como globalmente reutilizáveis. O que ele lembra e o que pode usar devem respeitar os mesmos limites que regem o trabalho subjacente.
Na prática, isso significa que a memória se torna parte da nossa arquitetura de colaboração de nível empresarial. Ela conecta aprendizado, recuperação, controle de acesso e transparência em um único sistema.
A versão mais simples de um assistente de IA começa do zero todas as vezes. Você dá um comando, talvez anexe alguns arquivos, e ele tenta ajudar dentro dessa única interação. Isso pode funcionar para solicitações isoladas, mas falha rapidamente em fluxos de trabalho de equipe de longa duração.
Um colaborador humano não responde apenas à mensagem atual. Ele se lembra do processo preferido da equipe, dos exemplos que definem um bom resultado, dos documentos importantes, do feedback recebido na semana anterior e do contexto do projeto que determina como o trabalho deve ser realizado. Para que os assistentes de IA pareçam colaboradores de verdade, eles precisam de uma maneira de acumular o mesmo tipo de conhecimento prático.
Para nós, isso significava construir uma camada de memória unificada que abrangesse todo o ciclo de vida do conhecimento:
Como as memórias são criadas
Como elas são recuperadas durante execuções futuras
Como elas são vinculadas ao Work Graph — o modelo de dados estruturados da Asana que conecta tarefas, projetos, pessoas e metas em toda a organização
Como os usuários inspecionam e controlam o que o colega de equipe aprendeu
Esse último ponto é mais importante do que parece à primeira vista. Um sistema de memória poderoso que ninguém pode inspecionar ou corrigir não gera confiança. Ele cria um novo modo de falha.
Uma das primeiras escolhas de design que fizemos foi identificar os momentos certos para um colega de equipe gerar memórias.
Uma classe de memória é inferida durante ou após a execução. À medida que um colega de equipe trabalha em uma tarefa, ele encontra instruções, lê recursos, realiza ações e recebe feedback. Algumas destas informações são transitórias. Outras são duradouras e vale a pena reutilizá-las. Por exemplo, um usuário pode dar um feedback como “sempre copiar o revisor do modelo de dados nestas tarefas”. Como outro exemplo, quando um colega de equipe lê um projeto, ele pode aprender coisas sobre o propósito do projeto (p. ex.: O Projeto X contém recursos sobre as boas práticas de campanha de marketing da organização). Essas são fortes candidatas à memória durável.
Outra classe de memória é a explícita. Os usuários podem fornecer orientações diretamente, em vez de esperar que o sistema as deduza. Isso é especialmente importante quando a Meta não é capturar uma lição de um trabalho anterior, mas ensinar o colega de equipe a se comportar em um contexto de trabalho mais amplo ou a usar um recurso específico.
Esse caminho explícito se torna especialmente poderoso para a memória vinculada a recursos. Um usuário pode dar a um colega de equipe acesso a um documento e, em seguida, explicar qual função esse recurso deve desempenhar. É um documento de processo que explica como a equipe se comunica? Um documento de referência contendo conhecimento do domínio? Um modelo que deve moldar o trabalho futuro? A distinção é importante porque o mesmo material de origem pode ser usado de formas muito diferentes, dependendo da intenção do usuário.
Sempre que uma memória é criada, criamos “Associações de Memória”, que são essencialmente referências aos objetos do Work Graph aos quais a memória se refere ou para os quais é relevante. Por exemplo, pode ser o projeto que a memória está descrevendo ou um recurso do Documento Google que um usuário carregou. Como descreveremos mais adiante neste artigo, essas associações são fundamentais para a forma como recuperamos memórias e garantimos o controle de acesso adequado.
Um sistema de memória é tão bom quanto o seu modelo de recuperação. Armazenar aprendizados úteis não é suficiente se o conhecimento certo não aparecer no momento certo.
Para os assistentes de IA, a recuperação funciona como um sistema de duas vias.
A primeira via é a recuperação no início da execução. Quando um colega de equipe começa a trabalhar em uma tarefa, ele recebe um conjunto de memórias relevantes antes de começar a tomar decisões. Isso pode incluir instruções fixadas que devem sempre ser aplicadas, aprendizados anteriores que correspondam ao trabalho atual ou conhecimento de nível superior que pareça relevante com base na busca ou na similaridade semântica.
A segunda via é a recuperação contextual durante a execução. Quando um colega de equipe lê uma tarefa, projeto ou outro objeto específico, ele também recebe memórias associadas a esse objeto. Isso é importante porque, em geral, alguns conhecimentos não são relevantes em termos abstratos. Ele se torna relevante porque o colega de equipe agora está olhando para uma parte específica do Work Graph.
Essa combinação confere ao sistema um equilíbrio útil. O colega de equipe pode começar com um amplo conjunto de trabalho de conhecimento provavelmente relevante e, em seguida, obter um contexto mais preciso à medida que se aprofunda no trabalho.
Uma das escolhas de design mais importantes foi representar a memória como algo operacional, e não místico. No nosso modelo de dados, a memória é um objeto concreto com conteúdo, metadados e associações.
Uma Associação de Memória captura um Objeto do Work Graph ao qual a memória se refere ou para o qual é relevante. Isso nos permite contextualizar explicitamente uma memória no Work Graph mais amplo, em vez de termos memórias desvinculadas do contexto que a memória está capturando.
Os sistemas de memória corporativos ficam muito mais difíceis no momento em que múltiplas pessoas, projetos e permissões estão envolvidos.
Uma IA de assistente pessoal muitas vezes pode tratar a memória como uma simples extensão do histórico de um usuário. No entanto, um colega de equipe que trabalha em trabalhos compartilhados e pode ser acionado por várias pessoas não pode fazer isso com segurança. Qualquer memória que o sistema crie é derivada do trabalho real subjacente: tarefas, comentários, documentos, projetos e execuções anteriores. Se a memória pudesse flutuar livremente, desvinculada dessas fontes, ela poderia se tornar um canal para o vazamento de informações para além dos limites de permissão.
É por isso que a memória nos assistentes de IA tem que herdar a mesma lógica de controle de acesso do trabalho de onde ela veio.
Cada recuperação de memória é limitada à pessoa que desencadeou a execução. O colega de equipe só pode acessar uma memória se essa pessoa tiver visibilidade sobre o trabalho que a produziu — as tarefas, comentários, documentos ou projetos envolvidos. A mesma regra se aplica às associações: se uma memória faz referência a um objeto da Asana, como uma tarefa ou um projeto, ela só aparece quando o usuário que acionou a execução também pode ver esse objeto. Em outras palavras, um assistente de IA nunca vê nada que a pessoa que o acionou já não pudesse ver.
A peça final é a visibilidade. Se um colega de equipe usa a memória para orientar uma ação, os usuários precisam de uma forma de entender essa influência.
Isso começa com a própria memória inspecionável. Os usuários devem poder visualizar as memórias que um colega de equipe possui e excluir memórias que possam estar imprecisas ou desatualizadas. Além disso, quando um colega de equipe executa uma ação, o sistema pode mostrar quais memórias foram passadas para o contexto de execução e quais foram criadas no decorrer da execução.
Em vez de perguntar “por que a IA fez isso?” de forma abstrata, um usuário pode rastrear o comportamento até uma instrução específica aprendida, uma memória de recurso ou um objeto de contexto associado. A correção se torna concreta: editar a memória, removê-la, atualizar a fonte ou adicionar uma orientação melhor.
Por exemplo, se um colega de equipe formata um relatório de maneira diferente do esperado, um usuário pode verificar as memórias dele para ver se ele aprendeu uma preferência de formatação com o feedback de outro membro da equipe na semana passada e atualizar ou remover essa memória para alterar o comportamento.
É por isso que a memória e a transparência precisam ser projetadas em conjunto. Um colega de equipe que aprende ao longo do tempo é mais poderoso. É mais difícil confiar em um colega de equipe que aprende de forma invisível.
No nosso post anterior, exploramos como os assistentes de IA atuam de forma transparente em espaços compartilhados da equipe. A memória é a camada que torna essa colaboração composta: o sistema aprende com o trabalho compartilhado, recupera esse conhecimento quando é necessário e faz isso dentro dos mesmos limites de confiança que regem o trabalho em si.
A lição mais profunda é que a IA com escopo de equipe precisa de mais do que uma janela de contexto maior. Ela precisa de um modelo para transformar a colaboração em conhecimento durável, reutilizável e administrável.
Na próxima publicação, veremos como avaliamos e selecionamos os modelos de linguagem que impulsionam esse raciocínio.
Este artigo foi escrito por Anant Tibrewal, engenheiro da equipe de assistentes de IA, onde trabalha para desenvolver e dimensionar o produto de IA colaborativa e agentiva da Asana.