Edição Markdown

AI-translated from English; not yet reviewed by a fluent editor.

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

> Guarde um registo de memória tipado e aprovado pela fonte, forneça os seus bytes exatos revistos a duas sessões autorizadas e verifique uma atualização condicional e a resolução de conflitos.

By BIG CHANGE Editorial

Published: 2026-10-20T13:57:38.593Z
Updated: 2026-10-20T13:57:38.593Z
Canonical: https://bigchange.ai/blog/managed-agents-reviewed-memory-snapshot-guide

![Conceptual charcoal illustration of two separate laptops on a round table, each displaying the same five abstract text strokes with the third row orange.](https://bigchange.ai/api/media/file/reviewed-memory-two-sessions-hero-v3.png)
AI-generated conceptual illustration by BIG CHANGE.

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](https://platform.claude.com/docs/en/managed-agents/memory) 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.

```json
{
  "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](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/create) e o manual de memória mostram esta forma do SDK; compare o SDK instalado com a referência atual:

```python
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](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/retrieve) 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](https://platform.claude.com/docs/en/managed-agents/sessions) da Anthropic documenta separadamente a criação e o envio de `user.message`:

```python
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](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/update) documentada é:

```python
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](https://bigchange.ai/blog/claude-managed-agents-reviewed-dream-memory-guide) 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.

## Sources

- [Manual de memória de Anthropic Managed Agents](https://platform.claude.com/docs/en/managed-agents/memory) — Documenta cabeçalhos beta, armazenamentos de texto do espaço de trabalho, montagens mutáveis, versões e limites. Não autentica o utilizador final, valida a verdade de afirmações nem fixa um armazenamento montado a uma revisão aprovada.
- [API da Anthropic para criar uma memória](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/create) — Documenta criação por caminho e conteúdo e identidade devolvida. Não se executou criação para este guia; validação e aprovação da aplicação são distintas.
- [API da Anthropic para listar memórias](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/list) — Documenta path_prefix, paginação next_page e resultados básicos sem conteúdo. Continua a ser necessária uma leitura direta completa do registo escolhido.
- [API da Anthropic para obter uma memória](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/retrieve) — Documenta a obtenção completa da memória escolhida para leitura de conteúdo e hash; exatidão da fonte e âmbito são verificações da aplicação.
- [API da Anthropic para atualizar uma memória](https://platform.claude.com/docs/en/api/beta/memory_stores/memories/update) — Documenta a precondição exata UTF-8 content_sha256 e HTTP 409 memory_precondition_failed_error. A resolução humana de conflitos é a política de aplicação proposta no guia.
- [Anthropic: iniciar uma sessão](https://platform.claude.com/docs/en/managed-agents/sessions) — Documenta criação de sessão com agente e ambiente e user.message através de events.send. O guia não executou sessões; imagem privada sem montagem e diário de mensagens são controlos da aplicação.
- [BIG CHANGE: reveja um armazenamento de memória de Claude Managed Agent com um Dream](https://bigchange.ai/blog/claude-managed-agents-reviewed-dream-memory-guide) — Guia relacionado de revisão de uma saída. Não demonstra o ciclo tipado de imagem exata para dois agentes deste artigo.