Maio 2026 · 11 min de leitura · Fran Olivares, Fundador da OlivaresAI
A gestão de projetos é maioritariamente trabalho de memória. Quem é o responsável por este stream? O que acordámos sobre a janela de migração? Porque é que removemos o rate limiter do escopo? Quando é que a revisão legal bloqueia o release? Um agente que tem de voltar a perguntar isto todas as manhãs não é um agente — é um estagiário ligeiramente mais rápido. A forma de mudar isso é dar ao modelo uma camada de memória persistente que 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 Claude API da Anthropic como LLM e a REST API da Alma como camada de memória.
Três razões estruturais. Primeiro, as entidades que um PM segue (pessoas, decisões, deliverables, SLAs, riscos) são elas próprias de longa duração — 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 dissemos sobre X?". Carregar a fatia certa de contexto a baixo custo importa. Terceiro, o custo de esquecer é alto: uma decisão perdida torna-se um release perdido, uma dependência esquecida torna-se um bloqueador.
Uma conversa Claude sem estado lida bem com uma única sessão de planeamento. Assim que o utilizador quer continuidade ("ontem acordámos…", "o que está a bloquear a equipa de auth esta semana?"), a conversa tem de reproduzir o histórico completo na janela de contexto (caro, eventualmente impossível) ou depender de uma camada de memória fora do modelo.
Quatro partes em movimento:
messages.create do SDK Anthropic com um system prompt consciente do projeto. O uso de ferramentas está ativado para que o modelo possa pedir à camada de memória entidades pelo nome quando necessário.stakeholder, decision, sla, risk) e uma pontuação de importância. Os episódios capturam standups diários comprimidos; os procedimentos capturam fluxos de trabalho recorrentes ("a forma como tratamos hotfixes").Cinco categorias cobrem a maioria das equipas: stakeholder (pessoas com papel + responsabilidades), decision (o que foi acordado, quando, por quem, com a fundamentação), sla (compromissos com outras equipas ou clientes), risk (problemas em aberto com responsável + mitigação), milestone (data alvo + escopo + estado). Cada memória carrega uma pontuação de importância para que o montador possa priorizar itens de alto risco na recuperação.
A categoria não é apenas para organização — é parte do sinal de recuperação. Quando o utilizador pergunta "o que decidimos?", o montador pondera memórias de categoria decision mais alto. Quando perguntam "quem está bloqueado?", memórias de categoria risk sobem. A montagem de contexto da Alma expõe pesos de boost por categoria exatamente para este caso de uso.
Três fases por mensagem do utilizador. O pseudocódigo abaixo usa Node.js com o SDK Alma e o SDK Anthropic, mas a mesma forma funciona em Python ou qualquer outra 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 corre em segundo plano — o utilizador vê a resposta transmitida imediatamente, e a extração acontece no ~1 s seguinte sem bloquear. Novas memórias são deduplicadas, contradições são detetadas contra entradas existentes, e o armazenamento mantém-se limpo automaticamente. Referência completa do SDK: @olivaresai/alma-sdk; equivalentes HTTP na documentação da REST API.
Use environments Alma: um environment por projeto. Cada environment tem as suas próprias memórias, episódios, procedimentos e blocos Soul, completamente isolados uns dos outros. O agente passa environmentId em cada chamada de memória; a API impõe a fronteira. Consultas entre projetos são simplesmente impossíveis sem uma troca explícita de environment — o que é o defeito certo para uma ferramenta de PM onde vazar decisões do projeto A para o projeto B é um problema real.
Para agentes de PM de toda a equipa (vários humanos a interagir com o mesmo agente), use o recurso teams da Alma: cada equipa tem memórias partilhadas visíveis a todos os membros, mais memórias por utilizador para preferências pessoais. Os controlos de acesso baseados em papéis controlam quem pode escrever o quê.
Mensagem do utilizador: "standup: equipa backend, a Maria está a desbloquear a migração hoje, o José está no rate limiter; decidimos empurrar o release GA para sexta-feira porque a equipa legal ainda está a rever o DPA". O fluxo do agente:
Arqueologia de decisões. "Porque é que removemos o rate limiter do escopo?" — o agente recupera a memória de decisão mais o episódio circundante e a memória de risco que referenciou. Devolve a resposta com citações para os registos, para que o utilizador possa aprofundar na conversa se necessário.
Consulta de stakeholders. "Quem é responsável pela migração?" — consulta direta de memória contra a categoria stakeholder, devolve o registo. Se a resposta estiver obsoleta (o papel mudou na semana passada), a deteção de contradições apanha-o na próxima conversa que mencionar o novo responsável.
Geração de relatórios recorrentes. "Gera um relatório de estado para o stream de auth desta semana" — o agente monta uma janela de contexto de episódios, decisões e riscos etiquetados para esse stream, depois redige o relatório a partir dessa fatia curada. Isto é significativamente mais barato e mais preciso do que pedir ao Claude para resumir histórico de chat em bruto.
Orçamentos de token defeito no montador: ~2 K tokens para memórias, ~1 K para episódios, ~500 para procedimentos, ~500 para blocos Soul. Total ~4 K — bem abaixo do orçamento de contexto de qualquer modelo, e os cache hits são amortizados pela conversa. Se o seu projeto é pequeno (<100 memórias ativas), pode baixar mais o orçamento. Se é grande (10 K+ memórias), o montador fica em ~4 K porque a recuperação limita o número de registos 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 do system prompt para que chamadas repetidas não voltem a pagar os tokens de input; e o contexto dinâmico (memórias + episódios) deve sentar-se depois do cache breakpoint para que cada chamada apenas volte a enviar a porção alterada. A documentação de prompt caching da Anthropic cobre a colocação do breakpoint.
Num fluxo típico de equipa de PM (~20 mensagens/dia por utilizador, maioritariamente standups + esclarecimentos), o custo marginal é dominado pelas próprias chamadas ao LLM. A camada de memória adiciona: uma chamada assemble (alguns KB de leitura + recuperação, ~30 ms), uma chamada extract (Haiku, ~$0,001 por turno). Overhead total de memória por dia por utilizador ativo: bem abaixo de um cêntimo. Compare com o valor da equipa de PM não perder decisões — e a matemática é óbvia.
O plano Starter ($14/mês) da Alma é o nível de entrada e inclui a camada de memória persistente. Registe-se em alma.olivares.ai, gere uma chave de API em Settings, e clone o starter do SDK da página de programadores. Ligue o loop de três fases no código do seu agente, aponte-o para um único projeto de teste, e corra-o durante uma semana. O armazenamento vai popular naturalmente a partir das conversas; verá decisões, stakeholders e riscos a acumular sem entrada manual de dados. A partir daí é apenas 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.