Além dos Prompts: A Abordagem da Anthropic em Memória de Agentes, Sonhos e Fluxos de Trabalho com Grafos

name: deploy-production
description: Validar e implantar o aplicativo no ambiente de produção.

1. Leia o checklist.md.
2. Execute a suíte de testes completa.
3. Confirme o plano de migração.
4. Execute o scripts/verify-release.sh.
5. Pare e solicite aprovação humana antes da implantação.

O mecanismo importante é a divulgação progressiva.

O Claude vê uma descrição curta que o ajuda a decidir se uma determinada habilidade é relevante. O corpo completo da habilidade e os arquivos de suporte são carregados somente quando o processo é necessário.

Mukta compara isso a uma estante de livros.

Uma pessoa não precisa memorizar todos os livros antes de iniciar uma conversa. Ela só precisa saber qual livro pode conter informações relevantes e retirá-lo da estante no momento adequado.

As habilidades ajudam a resolver o problema do "arquivo de contexto em crescimento contínuo":

• Fatos estáveis e de alto nível podem ser mantidos no CLAUDE.md.
• Processos detalhados podem ser movidos para habilidades.
• Materiais de suporte podem permanecer fora do contexto ativo até serem necessários.

A documentação oficial de habilidades da Anthropic sugere criar habilidades quando as equipes repetidamente colam as mesmas instruções, listas de verificação ou processos de várias etapas nas conversas, ou quando uma seção do CLAUDE.md evoluiu de um fato conciso para um processo.

As habilidades ainda exigem gestão humana

As habilidades são reutilizáveis, mas ainda é necessário que alguém decida:

• Quais fluxos de trabalho merecem ser transformados em habilidades
• Como o processo deve ser estruturado
• Quais arquivos devem ser incluídos
• Quando uma habilidade está desatualizada
• Quem tem permissão para editá-la

Os agentes podem ajudar a escrever e manter habilidades, mas o sistema ainda depende parcialmente da gestão humana.

Isso leva à quarta abordagem.

Quarta geração: Tratar o sistema de arquivos como memória

Mukta descreve a memória baseada em arquivos como o padrão que a Anthropic atualmente prefere em muitos sistemas de memória de agentes.

A justificativa é bastante pragmática.

Os agentes já são bons em:

• Listar arquivos
• Pesquisar nomes de arquivos
• Executar grep
• Ler Markdown
• Navegar em diretórios
• Editar texto
• Comparar versões

Em vez de inventar uma interface de memória altamente especializada, as equipes podem organizar a memória como arquivos e fornecer aos agentes ferramentas comuns de sistema de arquivos.

Um possível layout é o seguinte:

memory/
├── organization/
│   ├── principles.md
│   ├── terminology.md
│   └── security-policy.md
├── teams/
│   ├── engineering/
│   │   ├── architecture.md
│   │   └── release-process.md
│   └── support/
│       ├── escalation-rules.md
│       └── response-style.md
├── projects/
│   └── billing-redesign/
│       ├── decisions.md
│       ├── known-issues.md
│       └── current-status.md
└── agents/
└── agent-104/
└── scratchpad.md

Esse layout suporta diferentes níveis de memória:

• Regras organizacionais
• Conhecimento da equipe
• Contexto do projeto
• Preferências do usuário
• Notas de trabalho de agentes específicos

Ele também incorpora a divulgação progressiva.

O agente pode pesquisar nos diretórios e carregar apenas os arquivos relevantes para a tarefa atual.

Arquivos são a interface, não necessariamente o armazenamento físico

A interface estilo sistema de arquivos não exige que toda memória empresarial exista como arquivos não gerenciados em um laptop.

A implementação subjacente ainda pode usar:

• Bancos de dados
• Armazenamento de objetos versionado
• Serviços de controle de acesso
• Índices de pesquisa
• Logs de auditoria
• APIs transacionais

O ponto essencial é que o agente recebe uma abstração simples e navegável.

Na sessão de perguntas e respostas, um participante perguntou se isso equivalia a reinventar o banco de dados.

Mukta reconheceu que essa arquitetura retorna a princípios familiares de engenharia de software. Uma vez que as equipes entendem quais comportamentos devem ser determinísticos, elas podem movê-los para uma estrutura de controle, em vez de deixar o modelo improvisar a cada vez.

Quatro salvaguardas para memória de nível de produção

Uma pasta cheia de arquivos Markdown pode funcionar para um único usuário.

Mas quando milhares de agentes podem atualizar a memória organizacional compartilhada, isso se torna perigoso.

Mukta destacou quatro princípios de produção:

1. Controle de versão
2. Controle de concorrência
3. Gerenciamento de permissões
4. Portabilidade

1. Versionar cada alteração de memória

Cada atualização de memória deve ter um histórico.

Metadados úteis incluem:

• Versão anterior
• Nova versão
• Carimbo de data/hora
• Autor humano ou agente
• Sessão de origem
• Registros de conversa de apoio
• Motivo da alteração
• Status de aprovação

Entradas de memória sem rastreabilidade de origem são difíceis de confiar.

Suponha que um agente adicione:

- Implantações de produção às sextas-feiras não exigem aprovação.

Sem origem, revisor e histórico de revisão, outro agente pode tratar essa declaração como autoritativa.

O controle de versão suporta:

• Revisão
• Reversão
• Auditoria
• Comparação
• Análise de causa raiz

Um sistema de memória versionado deve ser capaz de responder facilmente:

Qual interação deu origem a essa regra?

1. Evitar que agentes concorrentes se sobrescrevam

Dois agentes podem ler a mesma memória às 10:00.

O agente A grava uma atualização às 10:02.

O agente B, sem saber dessa alteração, grava sua própria versão às 10:03 e exclui acidentalmente a atualização do agente A.

Mukta descreveu um padrão de concorrência baseado em hash:

Agente lê a memória e registra o hash A
↓
Agente elabora a atualização
↓
Agente lê a memória novamente e registra o hash B
↓
Se hash A == hash B:
Confirma a atualização
Caso contrário:
Recarrega, rebaseia e tenta novamente

Isso é controle de concorrência otimista.

O modelo pode decidir qual alteração propor, mas a estrutura de controle deve impedir, de forma determinística, que gravações desatualizadas substituam versões mais recentes.

1. Distinguir permissões de leitura e escrita

Nem todo agente deve ter permissão para editar toda memória.

Um modelo de permissão razoável pode ser:

Um agente não deve ser capaz de transformar uma observação incerta em uma regra organizacional abrangente.

Os limites de permissão também precisam ser aplicados ao Dreaming. As tarefas de integração só podem receber registros de conversa e memórias que sua identidade tenha autorização para acessar.

1. Tornar a memória portátil

A memória pode se tornar um dos ativos de IA mais valiosos de uma organização.

Ela contém:

• Decisões
• Correções
• Fluxos de trabalho
• Preferências
• Modos de falha
• Conhecimento de ferramentas
• Instruções específicas de domínio

Mukta acredita que as equipes devem evitar projetar esse ativo para funcionar apenas dentro de um único produto.

Um sistema de memória portátil deve ter:

• APIs claras
• Formatos exportáveis
• Esquemas documentados
• Identificadores estáveis
• Controle de acesso padrão
• Rastreabilidade de origem independente de ferramenta

A portabilidade permite que o mesmo contexto bem organizado suporte:

• Claude Code
• Agentes hospedados do Claude
• Ferramentas internas
• Outros sistemas de agentes
• Fluxos de trabalho de documentação humana

Por que a memória dentro da sessão não é suficiente

Mesmo ferramentas de memória bem projetadas têm duas limitações estruturais.

Limitação um: Agentes se distraem facilmente

O agente precisa concluir a tarefa e organizar a memória ao mesmo tempo.

Escrever na memória consome recursos que poderiam ser usados para o objetivo atual.

O agente pode:

• Salvar demais
• Salvar de menos
• Armazenar conclusões não verificadas
• Pular o trabalho de memória sob pressão de tempo
• Focar apenas em detalhes locais em vez de padrões mais amplos

Limitação dois: o agente só vê uma sessão

Um agente pode notar que um comando falhou uma vez.

Ele não consegue ver que o mesmo comando falhou em outras 300 sessões.

Um agente de suporte pode ver um cliente confuso sobre uma política.

Ele não consegue ver que a mesma confusão se repete em toda a região.

Um mecanismo de aprendizado em todo o sistema requer um processo com visibilidade mais ampla.

Esse processo é o que a Anthropic chama de "Sonho" (Dreaming).

Sonho: um processo fora da banda para consolidar memórias

O Sonho é um processo assíncrono que revisa o histórico do agente após a conclusão do trabalho normal.

Nas notas de versão atuais da API da Anthropic, o recurso de "Sonho" para agentes hospedados da Claude é descrito como uma prévia de pesquisa.

Um "Sonho" lê:

• O armazenamento de memória existente
• Registros de sessões anteriores

Em seguida, ele cria um armazenamento de memória de saída reorganizado, no qual é possível:

• Mesclar entradas duplicadas
• Substituir informações desatualizadas
• Trazer à tona insights ausentes
• Reorganizar o conteúdo
• Propor memórias aprimoradas

Isso não é um re-treinamento do modelo.

Os pesos do modelo subjacente não mudam.

A melhoria vem da alteração do contexto persistido, para que sessões futuras possam recuperar esse conteúdo.

Analogia da escola

Mukta usou uma escola para explicar a diferença entre memória comum e "Sonho".

Imagine:

• Os alunos fazem as tarefas.
• Os professores corrigem cada tarefa.
• Um coordenador pedagógico analisa os resultados gerais de toda a escola.

Um professor pode ajudar um aluno a corrigir um erro.

O coordenador pedagógico pode notar que todos os alunos de geografia cometem o mesmo erro no mesmo tópico, porque esse conteúdo simplesmente não está incluído no currículo.

A correção no nível do sistema não é corrigir prova por prova.

É atualizar o currículo.

Termos no contexto dos agentes:

• Tarefa do aluno = Sessão individual
• Feedback do professor = Atualização de memória dentro da sessão
• Currículo da escola = Armazenamento de memória compartilhado
• Revisão do diretor = Processamento do Sonho (Dreaming)
• Atualização do currículo = Mudanças de memória propostas

Isso permite que o sistema aprenda com padrões que um único agente não consegue perceber.

Mecânica do processamento do Sonho

O pipeline simplificado do processamento do Sonho é o seguinte:

Fluxograma TD
A[Armazenamento de memória existente] --> D[Orquestrador do Sonho]
B[Registros de sessão] --> D
C[Chamadas de ferramentas e metadados] --> D
D --> E1[Agente revisor 1]
D --> E2[Agente revisor 2]
D --> E3[Agente revisor 3]
E1 --> F[Aggregador de padrões]
E2 --> F
E3 --> F
F --> G[Mudanças de memória propostas]
G --> H{Aprovação humana}
H -->|Aceito| I[Armazenamento de memória atualizado]
H -->|Rejeitado| J[Preservar memória existente]

O processo de revisão pode examinar conteúdos que vão além das mensagens do usuário e do assistente.

Evidências úteis incluem:

• Chamadas de ferramentas
• Falhas de ferramentas
• Número de tentativas
• Metadados de execução
• Correções humanas
• Pontuações de avaliação
• Saídas aceitas e rejeitadas
• Uso de habilidades
• Versão do modelo
• Latência e custo

O agente do Sonho então procura padrões como:

• O mesmo comando falhando repetidamente.
• Vários agentes interpretando mal um termo interno.
• Uma entrada de memória que não é mais válida.
• Dois arquivos contendo regras duplicadas.
• A equipe corrigindo repetidamente o mesmo problema de formatação.
• Uma configuração de ferramenta causando erros em vários projetos.
• A falta de uma política, forçando os agentes a adivinhar.

Mukta mencionou que o design da Anthropic pode incluir exemplos de registros de sessão relevantes e estatísticas que mostram a frequência do padrão.

Essas evidências ajudam os humanos a julgar se a mudança de memória proposta é razoável.

O processamento do Sonho deve propor sugestões, não reescrever tudo silenciosamente

O processo do Sonho tem amplo acesso e pode afetar o comportamento futuro de todo um cluster de agentes.

Isso torna atualizações automáticas e sem supervisão arriscadas.

Um fluxo de trabalho mais seguro é:

1. Analisar registros de sessão autorizados.
2. Identificar padrões recorrentes.
3. Associar os padrões às sessões de suporte.
4. Redigir mudanças de memória propostas.
5. Estimar a abrangência do problema.
6. Solicitar aprovação de um revisor humano ou controlado por políticas.
7. Submeter atualizações aprovadas com registro de origem.
8. Medir se houve melhoria no desempenho futuro.

Por exemplo:

## Atualização de memória proposta

**Alvo:** `teams/engineering/test-process.md`

**Problema observado:**
Os agentes usaram o comando de teste unitário para executar testes de integração em 18 das 63 sessões relevantes.

**Evidências:**
Sessões `s-102`, `s-111`, `s-118`, `s-124`, ……

**Adição proposta:**
- Usar `npm run test:integration` para todos os testes que exigem contêiner de banco de dados.
- Não usar `npm test` para arquivos em `tests/integration/`.

**Confiança:** Alta

**Decisão humana:** Pendente

Isso preserva a supervisão humana e permite que o cluster de agentes realize a maior parte do trabalho analítico.

Por que o processamento do Sonho, embora use mais tokens, pode reduzir custos

O processamento do Sonho exige chamadas adicionais de modelo.

À primeira vista, isso parece um custo desnecessário.

Mukta acredita que um armazenamento de memória mais limpo reduz o custo total, porque os agentes futuros têm mais probabilidade de concluir a tarefa corretamente na primeira tentativa.

Na primeira tentativa.

Uma comparação econômica útil é:

Custo de sonhar
vs.
Custo de falhas repetidas, tentativas, retrabalho e contextos excessivamente longos

As economias potenciais podem vir de:

• Menos tentativas
• Menos explicações repetidas
• Menos contexto irrelevante
• Melhor seleção de ferramentas
• Maior precisão na primeira tentativa
• Integração mais rápida de novos agentes
• Menos correções humanas repetidas

A Anthropic ainda não publicou um benchmark genérico que indique quanto cada organização pode economizar. O valor específico depende:

• Do grau de repetição das tarefas
• Da qualidade da memória
• Do custo dos erros
• Do número de sessões
• Do design da revisão
• Do preço dos modelos e ferramentas

O "Sonho" tende a gerar retorno quando um grande número de agentes executa trabalhos relacionados e encontra repetidamente os mesmos padrões.

Um fluxo semanal simples de Sonho sem agente hospedado

Uma equipe não precisa esperar pela integração completa da plataforma para testar esse conceito.

Uma versão manual pode ser executada uma vez por semana.

Passo 1: Exportar sessões relevantes

Coletar apenas os registros de conversa que os revisores têm permissão de ver.

Organizar por:

• Projeto
• Equipe
• Fluxo de trabalho
• Escopo de permissões
• Período de tempo

Passo 2: Fornecer a memória atual

Incluir:

• CLAUDE.md
• Habilidades relevantes
• Arquivos de memória do projeto
• Instruções da equipe
• Documentos de problemas conhecidos

Passo 3: Solicitar propostas baseadas em evidências

O prompt pode ser assim:

Revise esses registros de sessão autorizados e os arquivos de memória atuais.

Identifique falhas recorrentes, correções repetidas do usuário, instruções desatualizadas,
processos ausentes e entradas duplicadas.

Para cada alteração proposta:
1. Aponte o arquivo de destino.
2. Forneça os IDs das sessões de suporte.
3.

Explique a frequência com que esse padrão ocorre.
4. Elabore a modificação mínima eficaz.
5. Não edite os arquivos diretamente.

Etapa 4: Revisar a proposta

Rejeite as seguintes modificações:

• Baseadas em um único evento vago
• Sem evidências que as sustentem
• Escopo amplo demais
• Que envolvam questões sensíveis à segurança
• Que estejam fora da alçada do revisor
• Mais adequadas para implementação com código determinístico

Etapa 5: Enviar as modificações aprovadas

Use controle de versão e inclua as evidências da origem no registro de commit ou auditoria.

Etapa 6: Medir os resultados

Acompanhe se as mesmas falhas diminuem nas sessões seguintes.

Sem medição, "sonhar" se torna um trabalho de geração de documentos, e não um sistema de aprendizado.

Da memória acumulada ao longo do tempo à estrutura dentro da tarefa

A memória responde a:

O que o agente deve lembrar do trabalho anterior?

A engenharia de estrutura em grafo responde a uma pergunta diferente:

Quais partes da tarefa atual realmente dependem umas das outras?

O artigo de origem do BAAI conecta o tópico da memória a um guia de engenharia de grafos que circula na comunidade de desenvolvimento de IA.

O argumento central desse guia é que muitos "fluxos de trabalho" já são, essencialmente, grafos — só que mal projetados.

Fluxos de trabalho escritos como listas tendem a ser artificialmente transformados em processos seriais:

Pesquisa
↓
Resumo
↓
Comparação
↓
Verificação de fatos
↓
Redação

Algumas dessas etapas podem, de fato, depender da saída da anterior.

Outras podem estar esperando desnecessariamente.

Nós, arestas e fluxo real de dados

No grafo de fluxo de trabalho:

• Nó representa uma tarefa.
• Aresta representa uma dependência real.
• Os dados fluem ao longo das arestas.

Por exemplo:

O nó de pesquisa produz os resultados da pesquisa.

O nó de redação consome esses resultados e produz um rascunho.

O nó de verificação consome o rascunho e produz um resultado revisado.

Essas setas fazem sentido porque cada nó downstream precisa da saída do nó upstream.

O teste da pseudo-aresta

O guia comunitário de grafos propõe um teste simples para cada seta:

A próxima tarefa realmente precisa da saída da tarefa anterior?

Se a resposta for não, essa dependência é uma pseudo-dependência.

Considere o seguinte fluxo de trabalho:

Pesquisar concorrente A
↓
Pesquisar concorrente B
↓
Pesquisar concorrente C
↓
Escrever relatório comparativo

Pesquisar o concorrente B geralmente não precisa da saída da pesquisa do concorrente A.

Pesquisar o concorrente C geralmente não precisa da saída da pesquisa do concorrente B.

Essas tarefas podem ser executadas em paralelo:

flowchart TD
A[Definir critérios de comparação] --> B1[Pesquisar concorrente A]
A --> B2[Pesquisar concorrente B]
A --> B3[Pesquisar concorrente C]
B1 --> C[Escrever relatório comparativo]
B2 --> C
B3 --> C

Remover pseudo-arestas reduz o tempo de espera.

Se as três tarefas de pesquisa levarem 10, 12 e 15 minutos, respectivamente:

• Execução sequencial leva cerca de 37 minutos.
• Execução paralela espera cerca de 15 minutos, mais a sobrecarga de orquestração.

O grafo não torna nenhum agente individual mais rápido.

O que ele muda é o agendamento.

O padrão losango

Depois de remover as pseudo-arestas, uma forma comum aparece:

1. Uma tarefa se divide em vários ramos independentes.
2. Esses ramos são executados em paralelo.
3. Os resultados convergem.
4. Um nó final sintetiza os resultados.

Isso é geralmente chamado de losango.

Um exemplo de pesquisa poderia ser assim:

flowchart TD
A[Pergunta de pesquisa] --> B1[Dados de mercado]
A --> B2[Evidências de clientes]
A --> B3[Análise de concorrentes]
B1 --> C[Verificador]
B2 --> C
B3 --> C
C --> D[Síntese final]

O tempo total é determinado principalmente pelo ramo mais lento, e não pela soma de todos os ramos.

Trabalho paralelo exige um verificador

O paralelismo introduz um novo risco.

Um thread de trabalho pode produzir uma saída fraca, desatualizada ou sem suporte.

Se o sistema mesclar tudo sem validação, um ramo ruim pode contaminar a resposta final.

Por isso, o guia de grafos coloca um verificador antes da síntese.

Um verificador pode perguntar:

• Essa afirmação tem suporte?
• A fonte está atualizada?

O resultado está em conformidade com o formato solicitado?

• O thread de trabalho concluiu as tarefas atribuídas?
• O código passou nos testes?
• O resultado está em conflito com outros ramos?
• Existem dados sensíveis?
• Esta saída pode prosseguir com segurança?

Um verificador útil deve ter critérios de aceite claros.

Por exemplo: