Os armazenamentos de memória de Managed Agents da Anthropic podem manter texto entre sessões. Para um aplicativo que precisa dar o mesmo fato revisado a dois agentes, persistir é apenas o primeiro passo. O aplicativo deve decidir de quem é o registro, conferir a evidência original, selecionar uma revisão armazenada e preservar seus bytes exatos antes de qualquer agente vê-los. Este guia é para desenvolvedores com acesso autorizado à versão beta de Managed Agents e controle da autenticação do aplicativo, seleção de armazenamentos e configurações de agentes. Ele se baseia na documentação atual de memória da Anthropic e nas referências de API verificadas em 20 de outubro de 2026; a BIG CHANGE não executou testes de conta nem de modelo.
A grande mudança
- O que mudou: Uma memória JSON tipada e revisada pode persistir em um armazenamento de Managed Agents. O aplicativo confere a fonte e os bytes exatos armazenados, congela um retrato privado e envia os mesmos bytes aprovados a duas sessões autorizadas separadas sem anexar o armazenamento de memória.
- Por que importa: Uma edição posterior no armazenamento não altera as entradas já construídas para essas sessões.
- O que observar: A exatidão da fonte, a autorização do usuário e a qualidade das respostas ainda exigem verificações separadas.
Antes de começar
Tenha um fato real, preferência ou regra de projeto com um original que você possa usar, ID de fonte estável e revisão, e um responsável que aprove armazenar e divulgar aos dois papéis de agente. Defina um prazo de validade adequado para a revisão desse registro antes de revisá-lo. Confirme acesso à versão beta de Managed Agents, chave API privada, espaço de trabalho autorizado, dois IDs de agente configurados, ambiente e modelo permitido na conta. Confira o uso e os preços atuais antes de permitir as quatro sessões consumidoras delimitadas deste procedimento. Mantenha a chave fora de mensagens e comprovantes.
Seu aplicativo precisa mapear a identidade autenticada para o escopo. No estado confiável do aplicativo, vincule essa identidade a um ownerScopeId aprovado, ID do espaço de trabalho, ID do armazenamento e os dois IDs de agente permitidos. Use armazenamentos separados para usuários ou projetos privados com regras de acesso diferentes. Uma chave API do espaço de trabalho não autentica o usuário final, um caminho não é um limite entre clientes e um prompt não remove ferramenta nem credencial. Verifique que as duas configurações consumidoras não têm armazenamento anexado nem conector, credencial de ambiente ou caminho de ferramenta para o armazenamento mutável. Se não estabelecer esse limite, pare antes de enviar o registro.
1. Aprove o registro contra sua fonte
Use este modelo estrutural, substituindo cada valor entre sinais angulares por evidência real aprovada. Não é um fato de exemplo nem um resultado declarado. Serialize o objeto preenchido em um texto JSON UTF-8 exato antes de aprovar. O validador deve aceitar exatamente esses campos e tipos, rejeitar campos desconhecidos, exigir strings que não sejam vazias nem apenas espaços e horários UTC válidos, restringir kind a fact, preference ou project_rule, e restringir status a active, disputed ou superseded. Somente registros active podem ser injetados. A afirmação aprovada deve corresponder ao original citado, incluindo data de vigência e escopo.
{
"schemaVersion": "memory-record/v1",
"recordId": "<opaque stable record ID>",
"ownerScopeId": "<trusted mapped scope ID>",
"kind": "<fact | preference | project_rule>",
"claim": "<precise source-supported claim>",
"sourceId": "<private original-source ID>",
"sourceRevision": "<original revision or exact source hash>",
"sourceQuoteOrPointer": "<minimal permitted quote or stable pointer>",
"validFrom": "<UTC timestamp>",
"checkedAt": "<UTC timestamp>",
"status": "active",
"reviewerId": "<approved human reviewer ID>",
"reviewedAt": "<UTC timestamp>"
}O comprovante privado de aprovação do aplicativo deve identificar a pessoa que realmente aprovou, a permissão do responsável, fonte original e revisão, escopo e agentes permitidos, regra de atualidade e SHA-256 desses bytes JSON UTF-8 exatos. Ele registra uma decisão humana sobre a afirmação real. Uma string reviewerId no registro não é autenticação. Não persista um registro com contradição não resolvida ou permissão ausente. A Anthropic armazena texto; não valida esse esquema nem comprova a veracidade da afirmação.
2. Persista o registro e releia
Crie ou escolha um armazenamento de memória restrito no espaço de trabalho autorizado e registre seu ID real memstore_.... Use um caminho não sensível, como /records/{opaque-record-id}.json. Antes da solicitação, registre usuário, horário UTC, revisão da fonte, hash dos bytes aprovados, armazenamento e caminho, e estado pending. Nas chamadas diretas ao armazenamento, use agent-memory-2026-07-22; as chamadas de sessão usam managed-agents-2026-04-01. Segundo a Anthropic, combinar esses cabeçalhos beta em uma solicitação ao armazenamento retorna HTTP 400. A referência de criação e o manual de memória mostram esta forma do SDK; compare o SDK instalado com a referência atual:
mem = client.beta.memory_stores.memories.create(
store.id,
path="/records/<opaque-record-id>.json",
content=approved_json_text,
)Criar não sobrescreve um caminho existente. Salve o ID mem_... retornado e liste /records/ no armazenamento delimitado, usando cada next_page como próximo page. A listagem básica padrão omite o conteúdo. Recupere a memória selecionada por ID para obter o texto completo; compare ID do armazenamento, ID da memória, caminho, conteúdo e content_sha256 com os bytes aprovados. Registre a resposta e a releitura direta no diário e no cadastro. A resposta de criação sozinha não confirma a conclusão. Se for incerta, examine o caminho exato e o registro direto antes de decidir o que aconteceu; a ausência de resultado na busca não justifica repetir a criação.
3. Congele a revisão escolhida
Em cada execução posterior, autentique o chamador e resolva escopo, armazenamento e ID do registro escolhido pelo cadastro confiável. Se precisar localizar, liste todas as páginas do prefixo delimitado e recupere diretamente o mem_... selecionado. Calcule SHA-256 sobre a codificação UTF-8 do conteúdo retornado, compare com o content_sha256 do provedor e o hash exato aprovado pela pessoa e valide o JSON novamente. Confira ID do registro, escopo do proprietário, revisão da fonte, estado active, atualidade da fonte e prazo de validade predeterminado. Se alguma verificação falhar, não envie nada.
Grave os bytes exatos recuperados uma única vez em armazenamento privado endereçado pelo hash, usando criação exclusiva, como open(path, "xb") em Python. Releia o arquivo e calcule seu hash imediatamente e antes de cada envio. Nunca sobrescreva um retrato existente. Um arquivo parcial ou arquivo existente com outros bytes naquele endereço exige suspensão e conciliação. Preserve aprovação original, ID de armazenamento, ID de memória, hash do provedor, hash do retrato e decisão de escopo em um comprovante privado de recuperação. Esse retrato de gravação única é um projeto do aplicativo, não uma montagem da Anthropic fixada a uma versão.
4. Forneça os mesmos bytes a duas sessões novas
Crie uma sessão nova para o agente A com seus IDs reais e autorizados de agente e ambiente, e sem entrada de armazenamento de memória em resources. Confirme que os recursos da sessão retornada e as ferramentas e credenciais efetivas do agente não deixam outro caminho para o armazenamento. O guia de sessões da Anthropic documenta separadamente a criação e o envio de user.message:
session = client.beta.sessions.create(
agent=approved_agent_id,
environment_id=approved_environment_id,
)
client.beta.sessions.events.send(
session.id,
events=[{"type": "user.message", "content": [{"type": "text", "text": message_text}]}],
)Antes de events.send, releia o retrato privado e calcule seu hash. Construa message_text de forma determinística com um rótulo explícito de “dados revisados”, os identificadores de registro, fonte e revisão humana, o texto JSON inalterado e seu SHA-256, seguidos de uma pergunta específica que a fonte original possa responder. Os campos mostrados são um formato de mensagem do aplicativo, não campos de resposta do provedor. Antes de enviar, registre os bytes UTF-8 completos e o hash da mensagem, hash do retrato escolhido, ID de agente autorizado, ID da sessão e estado de envio. Guarde o resultado e o ID real do evento enviado ou a releitura da lista de eventos, quando disponível. Um resultado desconhecido exige ler eventos, não reenviar às cegas.
Crie uma segunda sessão nova para o agente B com seu ID aprovado separadamente e a mesma ausência de acesso ao armazenamento. Releia o mesmo retrato de gravação única, verifique seu hash de bytes, construa e registre a mensagem completa de B e envie. As mensagens podem ter perguntas ou metadados de destinatário diferentes; verifique que os bytes JSON incorporados e o hash aprovado do registro são idênticos. Confira cada resposta e eventos de ferramenta contra a fonte original. Uma resposta plausível ou citação não comprova que o modelo se apoiou internamente no texto injetado; os comprovantes de mensagem e evento do provedor demonstram o que o aplicativo forneceu. Se qualquer sessão tiver montagem ativa ou outro acesso ao armazenamento, não envie para ela.
5. Atualize somente após nova revisão da fonte
Quando o original mudar, recupere diretamente a memória atual e compare evidências antigas e novas com o responsável. Uma pessoa deve aprovar bytes JSON exatos de substituição com ID estável do registro, afirmação ou referência de fonte corrigida, nova revisão da fonte e horários de verificação e revisão. Preserve comprovante e hash anteriores. Registre o ID mem_..., o content_sha256 atual lido diretamente, hash de substituição pretendido, usuário, aprovação e estado pendente. A atualização condicional documentada é:
client.beta.memory_stores.memories.update(
memory_id=memory_id,
memory_store_id=store_id,
content=approved_replacement_json_text,
precondition={"type": "content_sha256", "content_sha256": fresh_old_hash},
)O provedor calcula o hash do conteúdo UTF-8 exato sem normalização. Uma divergência retorna HTTP 409 memory_precondition_failed_error. Nessa resposta ou em resultado de rede incerto, recupere novamente a memória ativa e examine o histórico de versões se necessário. Compare revisões de fonte conflitantes e peça ao responsável que combine, rejeite ou aprove uma nova substituição exata; nunca repita às cegas a gravação desatualizada. Após sucesso, a recuperação direta deve confirmar caminho, texto completo de substituição, hash e ID da versão da memória antes de o diário passar a confirmed.
Congele um novo retrato aprovado da revisão verificada. Inicie sessões A e B novas e autorizadas, sem montagens do armazenamento, e repita os dois envios e as verificações de fonte. Não altere retratos antigos nem diga que mensagens já enviadas se atualizam sozinhas. Marque o retrato anterior como inelegível para futuras injeções. Se o responsável retirar um registro, pare novos envios e aplique a política de retenção e remoção de dados: excluir a memória atual não remove necessariamente versões retidas. Arquivar ou excluir o armazenamento inteiro é outra decisão.
O que conta como concluído
Os comprovantes privados devem ligar permissão original e revisão da fonte ao hash JSON exato aprovado; identidade real de espaço de trabalho, armazenamento, caminho e mem_... e releitura direta após a criação; um retrato imutável; dois IDs distintos de sessão autorizada sem montagem, com hashes de mensagens enviadas e respostas verificadas na fonte; e atualização condicional aprovada com nova releitura direta e verificações de sessões novas. Se qualquer ligação for desconhecida, marque o exercício inteiro como incompleto e preserve o motivo preciso. Se executar, registre o uso real de sessões e ferramentas e o custo específico da conta; este guia documental não mediu economia nem desempenho do modelo.
Para trabalho relacionado, mas diferente, revisar uma saída de Dream para uma sessão posterior trata de uma proposta gerada para o armazenamento. Este processo começa com um registro de fonte aprovado pelo responsável e fixa exatamente o que dois consumidores recebem.
