Forneça a dois agentes o mesmo registo de memória revisto

Os armazenamentos de memória de Managed Agents da Anthropic podem conservar texto entre sessões. Numa aplicação que deve dar o mesmo facto revisto a dois agentes, a persistência é apenas o primeiro passo. A aplicação tem de decidir a quem pertence o registo, verificar a prova original, escolher uma revisão guardada e preservar os bytes exatos antes de qualquer agente os ver. Este guia destina-se a programadores com acesso autorizado à versão beta de Managed Agents e controlo da autenticação da aplicação, seleção de armazenamentos e configurações de agentes. Baseia-se 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 ou modelo.

A grande mudança

• O que mudou: Uma memória JSON tipada e revista pode persistir num armazenamento de Managed Agents. A aplicação verifica a fonte e os bytes exatos guardados, fixa uma imagem privada e envia os mesmos bytes aprovados a duas sessões autorizadas separadas sem anexar o armazenamento de memória.
• Porque importa: Uma edição posterior no armazenamento não pode alterar as entradas já construídas para essas sessões.
• A que estar atento: A exatidão da fonte, a autorização do utilizador e a qualidade das respostas continuam a exigir verificações separadas.

Antes de começar

Tenha um facto real, preferência ou regra de projeto com um original que possa utilizar, identificador de fonte estável e revisão, e um responsável que aprove guardar e divulgar aos dois papéis de agente. Antes da revisão, defina um prazo de validade adequado para a revisão desse registo. Confirme acesso à versão beta de Managed Agents, chave API privada, espaço de trabalho autorizado, dois identificadores de agente configurados, ambiente e modelo permitido na conta. Verifique a utilização e os preços atuais antes de permitir as quatro sessões consumidoras delimitadas do procedimento. Mantenha a chave fora de mensagens e comprovativos.

A aplicação precisa de mapear a identidade autenticada para o âmbito. No estado de confiança da aplicação, associe essa identidade a um ownerScopeId aprovado, identificador do espaço de trabalho, identificador do armazenamento e os dois identificadores de agente permitidos. Utilize armazenamentos separados para utilizadores ou projetos privados cujas regras de acesso diferem. Uma chave API do espaço de trabalho não autentica o utilizador final, um caminho não é uma fronteira entre clientes e um pedido ao modelo não remove ferramentas nem credenciais. Verifique que ambas as configurações consumidoras não têm armazenamento anexado nem conector, credencial de ambiente ou percurso de ferramenta para o armazenamento mutável. Se não conseguir estabelecer esse limite, pare antes de enviar o registo.

1. Aprove o registo face à fonte

Utilize este modelo estrutural, substituindo cada valor entre sinais angulares por provas reais aprovadas. Não é um facto de exemplo nem um resultado declarado. Serialize o objeto preenchido num único texto JSON UTF-8 exato antes da aprovação. O validador deve aceitar precisamente estes campos e tipos, rejeitar campos desconhecidos, exigir cadeias não vazias nem compostas apenas por espaços e datas e horas UTC válidas, restringir kind a fact, preference ou project_rule, e restringir status a active, disputed ou superseded. Só podem ser injetados registos active. A afirmação aprovada deve corresponder ao original citado, incluindo a data de produção de efeitos e o âmbito.

{
  "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 comprovativo privado de aprovação da aplicação deve identificar quem realmente aprovou, a permissão do responsável, a fonte original e revisão, o âmbito e agentes permitidos, a regra de atualidade e o SHA-256 destes bytes JSON UTF-8 exatos. Regista uma decisão humana sobre a afirmação real. Uma cadeia reviewerId no registo não é autenticação. Não guarde um registo com contradição por resolver ou permissão em falta. A Anthropic guarda texto; não valida este esquema nem comprova a verdade da afirmação.

2. Guarde e volte a ler

Crie ou escolha um armazenamento de memória restrito no espaço de trabalho autorizado e registe o seu identificador real memstore_.... Utilize um caminho não sensível, como /records/{opaque-record-id}.json. Antes do pedido, registe utilizador, hora UTC, revisão da fonte, hash dos bytes aprovados, armazenamento e caminho, e estado pending. Em chamadas diretas ao armazenamento, utilize agent-memory-2026-07-22; as chamadas de sessão utilizam managed-agents-2026-04-01. Segundo a Anthropic, combinar estes cabeçalhos beta num pedido ao armazenamento devolve 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,
)

A criação não substitui um caminho existente. Guarde o identificador mem_... devolvido e liste /records/ no armazenamento delimitado, usando cada next_page como o próximo page. A lista básica predefinida omite o conteúdo. Obtenha a memória selecionada pelo identificador para obter o texto completo; compare identificador do armazenamento, identificador da memória, caminho, conteúdo e content_sha256 com os bytes aprovados. Registe a resposta e a leitura direta no diário e no registo central. A resposta de criação, só por si, não comprova a conclusão. Se for incerta, examine o caminho exato e o registo direto antes de decidir o que aconteceu; a ausência de resultado na pesquisa não justifica repetir a criação.

3. Fixe a revisão escolhida

Em cada execução posterior, autentique o chamador e resolva âmbito, armazenamento e identificador do registo escolhido a partir do registo de confiança. Se precisar de descobrir, liste todas as páginas do prefixo delimitado e obtenha diretamente o mem_... escolhido. Calcule SHA-256 sobre a codificação UTF-8 do conteúdo devolvido, compare com o content_sha256 do fornecedor e o hash exato aprovado pela pessoa, e volte a validar o JSON. Verifique identificador do registo, âmbito do proprietário, revisão da fonte, estado active, atualidade da fonte e prazo predeterminado. Se alguma verificação falhar, não envie nada.

Escreva os bytes exatos obtidos uma única vez num armazenamento privado endereçado pelo hash, com criação exclusiva, como open(path, "xb") em Python. Volte a ler o ficheiro e calcular o hash imediatamente e antes de cada envio. Nunca substitua uma imagem existente. Um ficheiro parcial ou ficheiro existente com bytes diferentes nesse endereço exige suspensão e conciliação. Preserve a aprovação original, identificador do armazenamento, identificador da memória, hash do fornecedor, hash da imagem e decisão de âmbito num comprovativo privado de obtenção. Esta imagem de escrita única é uma conceção da aplicação, 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 os seus identificadores reais e autorizados de agente e ambiente e sem entrada de armazenamento de memória em resources. Confirme que os recursos da sessão devolvida e as ferramentas e credenciais efetivas do agente não permitem outro acesso ao 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, volte a ler a imagem privada e calcular o hash. Construa message_text de forma determinística a partir de um rótulo explícito de «dados revistos», identificadores do registo, fonte e revisão humana, texto JSON inalterado e respetivo SHA-256, seguidos de uma pergunta concreta a que a fonte original possa responder. Os campos apresentados são um formato de mensagem da aplicação, não campos de resposta do fornecedor. Antes de enviar, registe os bytes UTF-8 completos e o hash da mensagem, hash da imagem escolhida, identificador do agente autorizado, identificador da sessão e estado de envio. Preserve o resultado e o identificador real do evento enviado ou a leitura da lista de eventos, quando disponível. Um resultado desconhecido exige leitura dos eventos, não reenvio às cegas.

Crie uma segunda sessão nova para o agente B com o seu identificador aprovado separadamente e a mesma ausência de acesso ao armazenamento. Volte a ler a mesma imagem de escrita única, confirme o hash dos bytes, construa e registe a mensagem completa de B, e envie. As mensagens podem ter perguntas ou metadados de destinatário diferentes; confirme que os bytes JSON incorporados e o hash aprovado do registo são idênticos. Compare cada resposta e quaisquer eventos de ferramentas com a fonte original. Uma resposta plausível ou citação não comprova que o modelo se apoiou internamente no texto injetado; os comprovativos da mensagem e dos eventos do fornecedor estabelecem o que a aplicação forneceu. Se alguma sessão tiver uma montagem ativa ou outro percurso para o armazenamento, não lhe envie nada.

5. Atualize apenas após nova revisão da fonte

Quando o original mudar, obtenha diretamente a memória atual e compare provas antigas e novas com o responsável. Uma pessoa deve aprovar bytes JSON exatos de substituição com identificador estável do registo, afirmação ou referência de fonte corrigida, nova revisão da fonte e horas de verificação e revisão. Preserve comprovativo e hash anteriores. Registe o identificador mem_..., o content_sha256 atual lido diretamente, hash de substituição pretendido, utilizador, 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 fornecedor calcula o hash do conteúdo UTF-8 exato sem normalização. Uma divergência devolve HTTP 409 memory_precondition_failed_error. Perante essa resposta ou resultado de rede incerto, obtenha novamente a memória ativa e examine o histórico de versões se necessário. Compare revisões de fonte concorrentes e peça ao responsável que una, rejeite ou aprove uma nova substituição exata; nunca repita às cegas a escrita desatualizada. Após sucesso, a obtenção direta deve confirmar caminho, texto completo de substituição, hash e identificador da versão da memória antes de o diário passar a confirmed.

Fixe uma nova imagem aprovada da revisão verificada. Inicie sessões A e B novas e autorizadas sem montagens do armazenamento e repita os dois envios e verificações da fonte. Não altere imagens antigas nem afirme que as mensagens enviadas se atualizam sozinhas. Marque a imagem anterior como inelegível para futuras injeções. Se o responsável retirar um registo, pare novos envios e aplique a sua política de retenção e expurgo de dados: apagar a memória atual não remove necessariamente versões retidas. Arquivar ou apagar todo o armazenamento é outra decisão.

O que conta como concluído

Os comprovativos privados devem ligar a 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 leitura direta após criação; uma imagem imutável; dois identificadores de sessão distintos, autorizados e sem montagem, com hashes de mensagens enviadas e respostas verificadas na fonte; e atualização condicional aprovada com nova leitura direta e verificações de novas sessões. Se alguma ligação for desconhecida, marque todo o exercício como incompleto e preserve o motivo exato. Se executar, registe a utilização real de sessões e ferramentas e o custo específico da conta; este guia documental não mediu poupanças ou desempenho do modelo.

Para trabalho relacionado, mas distinto, rever uma saída de Dream para uma sessão posterior aborda uma proposta gerada para o armazenamento. Este processo começa num registo de fonte aprovado pelo responsável e fixa exatamente o que dois consumidores recebem.