Maio de 2026 · 11 min de leitura · Fran Olivares, fundador da OlivaresAI
Gestão de projetos é majoritariamente trabalho de memória. Quem é dono dessa stream? O que combinamos sobre a janela de migração? Por que dropamos o rate limiter? Quando a revisão jurídica bloqueia o release? Um agente que tem que reperguntar essas coisas toda manhã não é um agente — é um intern um pouco mais rápido. A forma de mudar isso é dando ao modelo uma camada de memória persistente que ele possa ler e escrever entre turnos, populada automaticamente a partir da conversa. Este guia percorre a arquitetura de referência e o código de integração, usando a API Anthropic Claude como LLM e a REST API da Alma como camada de memória.
Três razões estruturais. Primeiro, as entidades que um PM rastreia (pessoas, decisões, deliverables, SLAs, riscos) são em si de longa duração — elas sobrevivem a qualquer conversa única por definição. Segundo, o estilo conversacional é de alta frequência e baixo esforço: mensagens curtas de standup, esclarecimentos rápidos, perguntas "o que falamos sobre X?". Carregar a fatia certa de contexto barato importa. Terceiro, o custo de esquecer é alto: uma decisão perdida vira um release perdido, uma dependência esquecida vira um blocker.
Uma conversa Claude stateless lida bem com uma única sessão de planejamento. Assim que o usuário quer continuidade ("ontem combinamos…", "o que tá bloqueando o time de auth essa semana?"), a conversa tem que ou re-rodar o histórico completo para dentro da janela de contexto (caro, eventualmente impossível) ou se apoiar numa camada de memória fora do modelo.
Quatro partes móveis:
messages.create padrão do Anthropic SDK com um system prompt project-aware. Tool use é habilitado para que o modelo possa pedir à camada de memória entidades por nome quando precisar.stakeholder, decision, sla, risk) e um score de importância. Episodes capturam standups diários comprimidos; procedures capturam fluxos recorrentes ("a forma como lidamos com hotfixes").Cinco categorias cobrem a maioria dos times: stakeholder (pessoas com role + responsabilidades), decision (o que foi combinado, quando, por quem, com o racional), sla (compromissos com outros times ou clientes), risk (issues abertas com owner + mitigação), milestone (data alvo + escopo + status). Cada memory carrega um score de importância para que o montador possa priorizar itens de alta importância na recuperação.
A categoria não é só para organização — é parte do sinal de recuperação. Quando o usuário pergunta "o que decidimos?", o montador pondera memories da categoria decision mais alto. Quando perguntam "quem tá bloqueado?", memories da categoria risk sobem. A montagem de contexto da Alma expõe pesos de boost por categoria exatamente para esse caso de uso.
Três fases por mensagem do usuário. O pseudo-código abaixo usa Node.js com o Alma SDK e o Anthropic SDK, mas a mesma forma funciona em Python ou qualquer outro stack:
const { systemPrompt } = await alma.context.assemble({ query: userMessage, environmentId: projectId });const stream = anthropic.messages.stream({ model: 'claude-opus-4-7', system: systemPrompt, messages: [{ role: 'user', content: userMessage }] });await alma.memories.extract({ text: lastTurn, environmentId: projectId });A Fase 3 roda em background — o usuário vê a resposta streamada imediatamente, e a extração acontece no próximo ~1 s sem bloquear. Novas memories são deduplicadas, contradições são detectadas contra entradas existentes e o armazenamento fica limpo automaticamente. Referência completa do SDK: @olivaresai/alma-sdk; equivalentes HTTP na documentação da REST API.
Use environments da Alma: um environment por projeto. Cada environment tem suas próprias memories, episodes, procedures e blocos Soul, completamente isolados dos outros. O agente passa environmentId em toda chamada de memória; a API impõe o limite. Consultas cross-projeto simplesmente não são possíveis sem uma troca explícita de environment — que é o default correto para uma ferramenta de PM onde vazar decisões do projeto A para o projeto B é um problema real.
Para PM agents de time inteiro (vários humanos interagindo com o mesmo agente), use o resource teams da Alma: cada team tem memories compartilhadas visíveis a todos os membros, mais memories por usuário para preferências pessoais. Controle de acesso baseado em role controla quem pode escrever o quê.
Mensagem do usuário: "standup: time de backend, Maria está desbloqueando a migração hoje, José tá no rate limiter; decidimos empurrar o release GA para sexta porque legal ainda está revisando o DPA". O fluxo do agente:
Arqueologia de decisão. "Por que dropamos o rate limiter?" — o agente recupera a memory de decisão mais o episode em torno e a memory de risk que ela referenciou. Devolve a resposta com citações aos registros, para que o usuário possa entrar na conversa se precisar.
Lookup de stakeholder. "Quem é dono da migração?" — consulta direta de memory contra a categoria stakeholder, devolve o registro. Se a resposta está stale (o role mudou semana passada), a detecção de contradição pega na próxima conversa que mencionar o novo owner.
Geração de relatório recorrente. "Gere um relatório de status para a stream de auth dessa semana" — o agente monta uma janela de contexto de episodes, decisions e risks tagueados para aquela stream, depois rascunha o relatório a partir dessa fatia curada. Isso é significativamente mais barato e mais preciso do que pedir ao Claude para resumir histórico bruto de chat.
Orçamentos padrão de tokens no montador: ~2 K tokens para memories, ~1 K para episodes, ~500 para procedures, ~500 para blocos Soul. Total ~4 K — bem abaixo do orçamento de contexto de qualquer modelo, e os cache hits são amortizados ao longo da conversa. Se seu projeto é pequeno (<100 memories ativas), você pode baixar o orçamento ainda mais. Se é grande (10 K+ memories), o montador fica em ~4 K porque a recuperação limita o número de registros incluídos mesmo quando o armazenamento é grande.
Duas coisas importam operacionalmente: os blocos Soul (a identidade do agente) devem ser cacheados como um prefixo estável de system prompt para que chamadas repetidas não repaguem os tokens de input; e o contexto dinâmico (memories + episodes) deve ficar depois do cache breakpoint para que cada chamada só re-suba a porção mudada. A documentação de prompt-caching da Anthropic cobre a colocação do breakpoint.
Num fluxo típico de time de PM (~20 mensagens/dia por usuário, majoritariamente standups + esclarecimentos), o custo marginal é dominado pelas próprias chamadas de LLM. A camada de memória adiciona: uma chamada de assemble (alguns KB de leitura + recuperação, ~30 ms), uma chamada de extract (Haiku, ~$0.001 por turno). Overhead total de memória por dia por usuário ativo: bem abaixo de um centavo. Compare com o valor do time de PM não perder decisões — e a conta é óbvia.
O plano Starter da Alma ($14/mo) é o tier de entrada e inclui a camada de memória persistente. Cadastre-se em alma.olivares.ai, gere uma chave de API em Settings e clone o starter do SDK da página de developers. Conecte o loop de três fases no código do seu agente, aponte para um único projeto de teste e rode por uma semana. O armazenamento vai popular naturalmente a partir das conversas; você vai ver decisões, stakeholders e risks acumularem sem entrada de dados manual. Dali é só aumentar as categorias e ajustar o montador.
Leitura relacionada: Memória persistente para IA: guia completo 2026 · Como dar memória persistente à IA · Arquitetura de memória em três camadas · Documentação de montagem de contexto · Environments.