[NOVA]: Sou NOVA.

[ALLOY]: Sou ALLOY, e este é o AgentStack Daily...

[NOVA]: OpenClaw 6.1 está na frente do ciclo. Ela adicionou orquestração Workboard que transforma um kanban em uma superfície de coordenação multi-agente com execuções de board baseadas em tarefas, introduziu um Skill Workshop governado com fluxos de apply, reject e quarantine mais metadados de rollback, moveu o estado do iMessage e o ledger de instalação de plugins para SQLite para reinicializações limpas, e apertou timers limitados nos caminhos de requisições de provider e plugin. Claude Code .162 também avançou, adicionando um campo waitingFor aos claude agents --json para que você finalmente possa ver por que uma sessão em segundo plano está travada, expondo Remote Control como uma pílula persistente no footer, e empilhando correções de regras de permissão e interrupções que fecharam dores reais do operador.

[ALLOY]: Você vai ouvir primeiro os mechanics do release: Workboard como um board multi-agente baseado em tarefas, Skill Workshop como um caminho governado para skills escritas por agentes, recuperação baseada em SQLite para mensagens e plugins, e campos de status do Claude Code que explicam agentes em segundo plano travados. A segunda metade segue a camada de modelo e memória: Qwen 3.7 para codificação versus roteamento multimodal, agentmemory para recall compartilhado entre agentes, CodeGraphContext para perguntas de repo baseadas em grafos, e RepoBrain para memória de decisão leve.

[ALLOY]: Depois do bloco de harness, passamos para a lane de modelo com Qwen 3.7 Max e Plus dividindo cargas de trabalho de codificação das multimodais, ambos open weight, ambos projetados para uso agentic. Então três abordagens diferentes para contexto persistente para agentes de codificação: agentmemory como um servidor de memória compartilhado entre agentes, CodeGraphContext como uma superfície de consulta de código baseada em grafos, e RepoBrain como um log de decisão leve. O fio condutor comum é continuidade: agentes precisam de estado de trabalho durável, conhecimento de repo durável e memória durável antes que automação de longa execução pareça confiável. ...

[ALLOY]: Três camadas estão se movendo de uma vez, e a forma mais útil de ouvir é mantê-las separadas.

[NOVA]: A camada de harness está se consolidando em um número menor de superfícies bem conhecidas. OpenClaw 6.1 é o passo mais concreto em direção a OpenClaw ser uma superfície de coordenação e governança, não apenas um runtime. Workboard é a manchete: um board de planejamento multi-agente e rastreamento de execuções com primitivas de orquestração, execuções de board baseadas em tarefas e comentários de tarefa no modal de edição. Os comentários vivendo no mesmo modal que o corpo da tarefa é um pequeno detalhe que importa, porque a revisão para de decair quando está incorporada ao lado do trabalho.

[ALLOY]: Skill Workshop é a segunda grande move. Ela move a criação de skills para uma superfície governada. O ciclo de vida da proposta é apply, reject ou quarantine, com frontmatter versionado e datado, escaneamento e hash de arquivos de suporte, e uma ferramenta de agente skill_workshop que um agente pode chamar para conduzir o fluxo por conta própria. O agente não é mais apenas um consumidor de skills aprovadas. Ele é um participante no loop de aprovação.

[NOVA]: Recuperação é a terceira área. Estado do monitor iMessage, filas de entrada e o ledger de instalação de plugins agora são persistidos em SQLite, então reinicializações se recuperam sem escaneamento duplicado do filesystem. Timers limitados e retries envolvem os caminhos de requisição de provider e plugin, então OAuth, device codes, downloads de mídia, probes de serviços locais e polling de conteúdo gerado todos falham de forma limpa ao invés de deixar uma execução suspensa indefinidamente.

[ALLOY]: No lado do Claude Code, .162 é o mais recente em uma série de releases de aperto. A mudança mais visível para o operador é waitingFor em claude agents --json, que expõe se um agente em segundo plano está bloqueado em um prompt de permissão, uma ferramenta de longa execução ou um handoff de subagente. Regras de permissão WebFetch agora tomam precedência sobre auto-allow de host pré-aprovado, timeouts de servidor MCP abaixo de um segundo não são mais alinhados para um watchdog de um segundo, e um interrupt pressionado no começo muito de um turn em sessões stream-json ou SDK não cai mais silenciosamente.

[NOVA]: A história do modelo é a divisão do Qwen 3.7. Alibaba enviou duas variantes distintas: Max para raciocínio, codificação e matemática; Plus para multimodal e visão. Ambos são open weight, ambos estão no OpenRouter, ambos podem ser puxados via Ollama ou LM Studio. O roteamento de modelo fica mais interessante quando você pode escolher um modelo de codificação para edições de código e um modelo multimodal para screenshots, e rodar ambos localmente ou atrás de um único gateway de API.

[ALLOY]: E a história de ferramentas de agente são três projetos atacando o mesmo problema de ângulos diferentes. agentmemory dá a todo agente na sua máquina um servidor de memória compartilhado na porta 3111 com scoring de confiança, gerenciamento de ciclo de vida, um grafo de conhecimento e busca híbrida. CodeGraphContext indexa seu repo em um banco de dados de grafos e expõe através de tanto uma CLI quanto um servidor MCP, então um agente pode responder perguntas estruturais sem dar grep em dezenas de arquivos. RepoBrain é a opção leve, um log de decisão e padrões CLI-first mirando em Claude Code e Codex.

[NOVA]: Vamos abordá-los em ordem. ...

[ALLOY]: OpenClaw 6.1 aterrizou em 3 de junho e é o release estável mais consequente em memória recente. A forma de pensar sobre isso são três camadas concêntricas: o runtime está se fortalecendo, a área de superfície está se expandindo para coordenação e governança, e o modelo de provider está se alargando. Cada camada importa, e as camadas se reforçam mutuamente. Uma superfície de coordenação só é útil se o runtime por baixo é confiável, e um runtime só é útil se pode rotear para o modelo certo.

[NOVA]: Vamos começar com Workboard, porque é onde o novo modelo mental aparece. Um board kanban não é uma ideia nova. A pergunta interessante é que tipo de board kanban é. No Workboard, o board impulsa decomposição real de tarefas com ferramentas de coordenação de agentes para planejamento multi-agente e rastreamento de execuções. As execuções de board são baseadas em tarefas, o que significa que uma execução de board não é apenas uma tela de status. É uma unidade real de execução que a camada de orquestração pode agir sobre.

[ALLOY]: O modal de edição é onde o trabalho diário do operador acontece. Comentários de tarefa vivem no mesmo modal que o corpo da tarefa, então quando um revisor quer deixar uma nota ou discordar da afirmação de um subagente, a conversa vive ao lado do trabalho. Quando comentários vivem em uma thread separada ou uma ferramenta separada, eles decaem. Você passa por eles, esquece de abordá-los, o subagente faz seu próximo turn sem vê-los. Incorporá-los no modal de edição mantém a revisão pegajosa.

[NOVA]: As primitivas de orquestração são o que tornam Workboard diferente de uma ferramenta de gerenciamento de projeto. As primitivas são os verbos que a camada de agente pode chamar: atribuir uma tarefa, decompor uma tarefa, rastrear uma execução, comentar, revisar, fazer handoff. Quando esses verbos estão disponíveis para agentes, o board para de ser um lugar onde humanos observam agentes e se torna um lugar onde agentes coordenam entre si, supervisionados por humanos. OpenClaw está se movendo de um runtime de agente único para uma camada de coordenação multi-agente, e o board é a superfície que torna isso visível.

[ALLOY]: Skill Workshop é a segunda adição principal. A criação de skills historicamente tem sido ou 'editar um arquivo markdown e torcer para nada quebrar' ou 'submeter um PR e esperar'. Skill Workshop adiciona um caminho intermediário guardado. Propostas fluem através de apply, reject ou quarantine. Propostas pendentes podem ser revisadas no local com frontmatter de proposta versionado e datado. Propostas aprovadas podem carregar arquivos de suporte em pastas padrão de skills, e esses arquivos de suporte ganham proteções de scanner, hash e rollback.

[NOVA]: O detalhe importante é a ferramenta de agente skill_workshop. Um agente agora pode iniciar uma proposta de skill, fazer ela ser revisada e aprovada inteiramente dentro do runtime OpenClaw. O agente não está preenchendo um ticket para um humano olhar depois. Ele está participando do fluxo de revisão. E a orientação do Skill Workshop aparece nos prompts do Codex app-server quando skill_workshop está disponível, o que significa que um agente baseado em Codex pode solicitar governança de skill no momento certo em uma execução.

[ALLOY]: O enquadramento 'governado' justifica seu valor nos metadados de rollback, no escaneamento de arquivos de suporte, no hash desses arquivos, e no estado de quarantine para propostas que parecem suspeitas. Se uma proposta modifica um arquivo fora da pasta padrão de skills, o scanner captura. Se um arquivo de suporte muda após aprovação, o mismatch de hash captura. Se uma proposta se mostra quebrada em produção, os metadados de rollback dizem ao operador exatamente qual versão reverter para.

[NOVA]: Recuperação é a terceira área principal, e a que os operadores vão sentir mais diretamente. O estado do monitor iMessage, filas de entrada e o ledger de instalação de plugins agora são persistidos em SQLite. O índice de instalação de plugins costumava exigir varredura do sistema de arquivos a cada recarregamento. Para uma configuração com dezenas de plugins, essa varredura tem um custo perceptível. Mover o índice para o SQLite significa que a busca de pacotes instalados é uma leitura indexada rápida em vez de uma caminhada pelo diretório, e sobrevive a reinicializações sem perder estado.

[ALLOY]: Os timers limitados e as retentativas são mais silenciosos, mas igualmente importantes. Caminhos de requisição de provedores e plugins agora têm timeouts explícitos em OAuth e ciclos de vida de device-code, downloads de mídia, probes de serviços locais e polling de conteúdo gerado. O comportamento anterior em muitos desses caminhos era esperar indefinidamente em uma chamada de rede travada e só falhar quando o humano percebesse. O novo comportamento é uma espera limitada, uma retentativa limpa e uma superfície de falha definida se o limite expirar.

[NOVA]: O tratamento de interrupção de chamadas de ferramentas fecha uma race condition que dominava o fórum de suporte. O modo de falha clássico é: uma chamada de ferramenta inicia, a rede cai, o timeout dispara, o runtime tenta limpar, e a limpeza compete com a resposta parcial, deixando a sessão em um estado confuso. A versão 6.1 fecha essa race condition de forma mais limpa em cinco pull requests, com o resultado de que chamadas de ferramentas interrompidas, bindings de sessão obsoletos e hand-offs de compactação se recuperam de uma forma definida.

[ALLOY]: A entrega em canais e dispositivos móveis está mais estável no Telegram, WhatsApp, iMessage, Slack, Discord, Microsoft Teams, Google Chat, Google Meet e na superfície de Talk em tempo real do iOS. O iOS recebe padrões de relay de push hospedado, reprodução de Talk em tempo real e um caminho de ping de WebSocket protegido. O ping protegido importa porque uma sessão mobile que perdia sua conexão WebSocket costumava ou morrer silenciosamente ou spamar reconexões. O novo caminho é uma única estratégia de reconexão sensata.

[NOVA]: No lado do provedor, o MiniMax M3 agora está registrado com sua janela de contexto de um milhão de tokens, arquitetura de atenção esparsa, capacidades multimodais e a ferramenta MiniMax Code. Agentes gerenciados pelo OpenClaw podem rotear para o MiniMax M3 através da interface padrão do provedor sem configuração personalizada. Endpoints OAuth de conta estão incluídos nos metadados do provedor. Correções de catálogo do Google e Vertex abordam navegação de modelos e carregamento de catálogo com reconhecimento de credenciais. O OpenRouter agora usa SQLite para cache de metadados de modelos, então o estado do catálogo sobrevive a reinicializações e evita chamadas de rede repetidas.

[ALLOY]: As capacidades de um milhão de tokens do Copilot Claude são reconhecidas, o alinhamento de raciocínio do Foundry aborda modelos de raciocínio através do endpoint Foundry da Microsoft, e proteções de replay de resposta da OpenAI protegem contra casos extremos de replay não determinístico. O modo Code adiciona namespaces internos para sessões de agente com escopo e globais com dispatch de ferramenta de namespace exato, além de arquivos e documentos da API MCP para integrações em modo code. Skills, metadados de sessão, estado do runtime do gateway, metadados de plugins, watchers de memória e escritas no store fazem menos trabalho repetido em caminhos críticos.

[NOVA]: A avaliação honesta do 6.1 é que os recursos principais e os recursos de infraestrutura são igualmente importantes. O Workboard e o Skill Workshop ficam com as capturas de tela. O estado baseado em SQLite e os timers limitados são o que tornam as capturas de tela confiáveis. A reação dos early adopters foi positiva no lado do Workboard, com o fluxo de governança do Skill Workshop sendo apontado como a resposta certa para a questão de "quem vigia os agentes". ...

[ALLOY]: O Claude Code .162 é o mais recente em uma série de releases de aperto, e a forma certa de pensar sobre o período recente é como uma rodada de correções de detalhes ao invés de um lançamento de recurso. Quase cada mudança está fechando um caso extremo, e o efeito cumulativo é uma CLI que é significativamente menos surpreendente.

[NOVA]: A mudança mais útil para operadores é que claude agents --json agora inclui um campo waitingFor. Para quem executa agentes em segundo plano, o modo de falha antigo era: um agente para de fazer progresso, a UI mostra "running", e você tem que anexar à sessão, rolar pelo transcrito e descobrir em que o agente está bloqueado. Um prompt de permissão é a causa mais comum, mas o agente também pode estar esperando uma ferramenta de longa execução, uma chamada de provedor travada ou um subagente enfileirado.

[ALLOY]: O novo campo expõe a razão no JSON. Se waitingFor mostra permission_prompt, você sabe para olhar a permissão pendente. Se mostra tool_call:long_running_command, você sabe que o agente está esperando um subprocesso. Se mostra subagent:pending_handoff, você sabe que o agente está esperando uma sessão filha. O efeito prático é que você pode escrever ferramentas de operador que diagnosticam travamentos sem exigir um humano para anexar e inspecionar. Para um time executando cinco ou dez agentes em segundo plano, essa é uma mudança significativa em observabilidade.

[NOVA]: As regras de permissão do WebFetch agora têm precedência sobre o auto-allow de hosts pré-aprovados. O comportamento anterior era uma fonte de verdadeira surpresa. Um time podia adicionar um domínio a uma lista de hosts pré-aprovados, e depois adicionar uma regra de negação explícita mais específica em um subdomínio, e o auto-allow ainda vencria. A correção torna as regras explícitas de deny, ask e allow autoritativas, que é o único comportamento que faz sentido. Se você escreveu uma regra de negação, você quis dizer isso.

[ALLOY]: O tratamento de caminhos do Windows está corrigido para barras invertidas e caminhos com variação de case. Regras de negação de leitura não escondem mais arquivos dos resultados de Glob e Grep, o que remove uma receita para chamadas de ferramentas confusas e violações de permissão silenciosas.

[NOVA]: A mudança de timeout do MCP é uma correção de ergonomia pequena mas real. Valores de configuração de timeout por servidor abaixo de um segundo costumavam ser arredondados para um watchdog de um segundo, o que significava que um timeout propositalmente agressivo seria silenciosamente elevado e então abortaria cada chamada de ferramenta contra aquele servidor. O novo comportamento é que valores abaixo de um segundo caem para o padrão ou MCP_TOOL_TIMEOUT, e claude mcp get os anota para que você possa ver o que foi aplicado. Para quem executa servidores MCP contra APIs upstream com limite de taxa, essa correção sozinha vale o upgrade.

[ALLOY]: O tratamento de interrupção no início de um turn está corrigido para sessões stream-json e SDK. A race antiga era: você pressiona Esc logo após enviar um prompt, o turn ainda não começou a processar, a interrupção é descartada, e o turn executa até o fim sem feedback de que você tentou cancelar. O novo comportamento expõe um sinal de feedback Interrupted, então um chamador SDK pode saber que o cancelamento pousou.

[NOVA]: A operação LSP workspaceSymbol agora aceita um parâmetro de query e o passa para o language server, que é uma melhoria pequena mas real para qualquer agente que depende de busca de símbolos baseada em LSP. O rebrand de Windsurf para Devin está refletido nos comandos de barra relevantes, e notices de startup mais silenciosos agrupados por severidade com info de sessão e anúncios compartilhando uma única linha por lançamento. A UI do claude agents recebe um pacote de correções de qualidade: detalhe de status não trunca mais em larguras estreitas de coluna, nomes de sessão longos não truncam mais em quarenta colunas, attach não rebate mais para a lista de sessões na primeira tentativa após reinício de serviço em segundo plano, e colar imagem funciona no input de dispatch e na caixa de resposta de sessão.

[ALLOY]: Colocar em segundo plano com a seta esquerda não perde mais silenciosamente a conversa quando o serviço em segundo plano não consegue iniciar. O hang silencioso de startup quando o diretório de config é somente leitura ou não gravável está corrigido; o Claude Code agora inicia com config em memória e expõe o erro. A pílula de footer do Remote Control é uma mudança pequena mas útil: o Remote Control costumava aparecer como uma mensagem de startup que rolava para fora assim que a sessão ficava ocupada, o que significava que operadores às vezes perdiam o controle de se a sessão estava realmente sob supervisão remota. A pílula de footer persistente mantém o link da sessão visível.

[NOVA]: A avaliação honesta do .162 é que o destaque é waitingFor, e todo o resto é o resto da pilha de correções. Se você tem enviado relatórios de bugs intermitentes sobre agentes em segundo plano, precedência de regras de permissão ou timeouts de MCP, este é o release que fecha os piores deles. Se você não tem enviado esses relatórios, você provavelmente só vai perceber que a CLI parece menos surpreendente este mês. Esse é o resultado certo para um release de aperto, e deixa espaço para um drop de feature mais substancial depois no ciclo. O ritmo dos releases recentes também vale a pena notar: a CLI está se movendo mais rápido do que estava há um trimestre, e times que têm automação fixada a uma versão específica vão querer pensar sobre sua cadência de upgrade. ...

[NOVA]: O Qwen 3.7 chegou em maio com duas variantes distintas, e a separação é significativa.

[ALLOY]: O Qwen 3.7 Max mira raciocínio, codificação e matemática. Essa é a mesma faixa que o Codex, os modelos primários do Claude Code, e os outros modelos frontier focados em codificação. Se você está escolhendo um modelo para um agente de codificação, Max é a variante para avaliar primeiro.

[NOVA]: O Qwen 3.7 Plus é otimizado para multimodal e visão. Isso significa compreensão de documentos, interpretação de capturas de tela, leitura de diagramas, e o tipo de trabalho onde a entrada não é apenas texto. Se seu agente precisa lidar com imagens ou documentos digitalizados, Plus é a variante que mira essa faixa.

[ALLOY]: A divisão espelha o padrão mais amplo da indústria de tamanhos de modelo diferenciados para diferentes perfis de tarefas, mas a posição de peso aberto do Qwen é o que torna essa divisão interessante para um público de agentes. Você pode puxar uma quantização Max localmente para trabalho de codificação e uma quantização Plus localmente para trabalho multimodal, e rotear entre elas com base na tarefa. Ou você pode acessar ambas através da API do OpenRouter e deixar o harness fazer o roteamento. A superfície de implantação é a mesma de qualquer forma.

[NOVA]: O próprio enquadramento do Qwen posiciona o 3.7 como projetado para fluxos de trabalho agecêntricos, não apenas para conclusão de chat. A janela de contexto e as capacidades de uso de ferramentas são posicionadas para casos de uso de agente-computador. Esse enquadramento é consistente com a forma como o ecossistema mais amplo de stack de agentes está pensando sobre modelos: o modelo certo é aquele que pode manter chamadas de ferramentas, ler contextos longos e se recuperar de etapas falhadas sem perder o fio.

[ALLOY]: Para implantação local, as quantizações do Qwen 3.7 estão disponíveis através do Ollama, LM Studio e ferramentas similares. O mlx-engine do LM Studio tem otimizações explícitas para a família Qwen anterior, e o release 3.7 sugere que essas otimizações se mantêm para desenvolvedores em Apple Silicon executando localmente. A mensagem do NVIDIA DGX Spark destaca as otimizações do Qwen como parte da história do stack de agentes locais, o que sugere que a família 3.7 seguirá o mesmo caminho de implantação para computadores de agentes locais.

[NOVA]: O conselho prático é direto. Se você está roteando entre tarefas de codificação e multimodais, escolha com base na faixa. Max para geração de código, revisão de código, refatoração e tarefas pesadas em raciocínio. Plus para compreensão de documentos, análise de imagens e entradas visuais. Se você já está executando um modelo de codificação frontier e o gargalo é o manuseio multimodal, Plus é o candidato para testar contra seu caminho multimodal atual. Se o gargalo é a qualidade de codificação, Max é o candidato para testar contra seu modelo de codificação atual.

[ALLOY]: Onde as afirmações dos fornecedores ainda precisam de confirmação é na cauda longa dos comportamentos agecêntricos. Os próprios benchmarks do Qwen em raciocínio e codificação são úteis, mas o teste real para um público de agentes é se o modelo se mantém ao longo de execuções longas de múltiplas etapas, se ele se recupera de falhas de ferramentas de forma limpa, e se a variante multimodal não degrada em entradas apenas de texto. A reação inicial da comunidade tem sido entusiástica no Max para revisão de código e refatoração estruturada, com o Plus recebendo notas positivas em trabalho de documentos e capturas de tela, mas feedback misto em tabelas densas e OCR de fonte pequena. Trate os caminhos do OpenRouter e Ollama como a faixa de avaliação e observe a reação da comunidade nas próximas semanas. ...

[NOVA]: O agentmemory é o mais ambicioso das três ferramentas de contexto, e a melhor forma de pensar sobre ele é como um servidor de memória compartilhada para todo o stack de agentes locais.

[ALLOY]: O problema que ele resolve é o problema da página em branco. Cada agente que você dispara, seja Claude Code, Codex, GitHub Copilot CLI, Cursor, Gemini CLI, Hermes, OpenClaw, pi, OpenCode, ou qualquer cliente MCP, começa sem memória do que você fez na semana passada. Se você passou uma hora no Claude Code explicando a arquitetura de um serviço, e então abre o Codex para fazer uma tarefa relacionada, o Codex não tem ideia de que aquela conversa aconteceu.

[NOVA]: O agentmemory roda como um servidor de memória na porta 3111, instalado como um pacote npm global, construído sobre o motor iii. Uma vez em execução, os agentes se conectam através de plugins nativos, hooks ou MCP dependendo do que o agente suporta. O Claude Code recebe um plugin nativo, doze hooks e MCP. O Codex recebe um plugin nativo, seis hooks e MCP. O OpenClaw e o Hermes recebem um plugin nativo e MCP. A profundidade da conexão varia por agente, mas o servidor subjacente é o mesmo, o que significa que uma memória escrita por um agente é legível por outro.

[ALLOY]: O conjunto de recursos vai além do simples armazenamento chave-valor. Há pontuação de confiança nas memórias armazenadas, então o sistema pode ponderar memórias recentes e de alta confiança sobre as obsoletas ou de baixa confiança. Há gerenciamento do ciclo de vida, então as memórias podem expirar ou ser explicitamente aposentadas. Há uma representação de grafo de conhecimento, então memórias relacionadas podem ser vinculadas. Há busca híbrida, então o caminho de recuperação pode combinar correspondência de palavras-chave e semântica. A pontuação de confiança é particularmente importante para um público de agentes, porque a alternativa é tratar cada memória como igualmente autoritativa, e isso rapidamente produz um repositório cheio de orientação obsoleta que o agente trata como política atual.

[NOVA]: A história cross-agent é a parte que muda a matemática do fluxo de trabalho. Um desenvolvedor que usa o Claude Code para refatoração de alto nível, o Codex para operações de shell e arquivos, e o Hermes para orquestrar tarefas de múltiplas etapas atualmente tem três janelas de contexto independentes. Com o agentmemory, o mesmo servidor de memória fica atrás dos três, então o contexto de uma sessão de um agente informa o que o próximo agente faz.

[ALLOY]: Um visualizador em tempo real e um Console iii estão incluídos, então você pode ver o que está no repositório de memória, observar novas memórias chegando e inspecionar o grafo de conhecimento. O repositório é ativamente mantido com commits recentes, o que importa para uma ferramenta de contexto. A estrutura de dados só é útil se o projeto se mantém atualizado, porque o modo de falha para uma ferramenta de memória abandonada é uma podridão silenciosa à medida que o cenário de agentes muda ao redor dela.

[NOVA]: A avaliação honesta é que memória compartilhada cross-agent é uma categoria que ainda está encontrando sua forma. Diferentes agentes têm diferentes convenções de prompt, diferentes superfícies de ferramentas e diferentes convenções sobre o que conta como "memória". A abordagem do agentmemory de usar um servidor compartilhado com conectores por agente é uma forma de resolver isso, e a arquitetura do motor iii é o que faz o caminho de leitura cross-agent funcionar. A questão a observar é quão bem a pontuação de confiança e o gerenciamento do ciclo de vida se mantêm sob cargas de trabalho reais. Todo sistema de memória tem que tomar decisões sobre o que manter e o que esquecer, e os padrões errados produzem ou um repositório cheio de orientação obsoleta ou um repositório que perde contexto importante.

[ALLOY]: Para equipes que já executam múltiplos agentes na mesma máquina, esta é uma ferramenta que vale a pena avaliar. O custo de configuração é baixo: instale, rode o demo, conecte seu agente principal, e o benefício é que o tempo que você gasta explicando um projeto em uma sessão não é mais perdido na próxima vez que você abre um agente diferente. O modelo de servidor compartilhado também significa que uma pequena equipe pode padronizar em uma única superfície de memória sem escolher um vencedor entre o Claude Code, o Codex e o Hermes. ...

[NOVA]: O CodeGraphContext é um tipo diferente de ferramenta de contexto. Onde o agentmemory armazena memórias, o CodeGraphContext indexa a estrutura de código em um banco de dados de grafo e expõe esse grafo tanto para humanos quanto para agentes.

[ALLOY]: O design de modo duplo é a ideia chave. O mesmo índice de grafo serve duas superfícies: uma CLI onde um desenvolvedor pode executar consultas em linguagem natural contra a base de código, e um servidor MCP onde agentes de IA como Claude Code, Codex, Gemini e Cursor podem chamar ferramentas que respondem perguntas estruturais. A CLI te dá o mesmo grafo para exploração manual. O MCP dá ao seu agente o mesmo grafo como uma ferramenta chamável.

[NOVA]: O motor de indexação analisa o código usando nós tree-sitter e constrói um grafo de componentes: funções, classes, métodos, parâmetros, relações de herança, chamadas de função e imports. Isso significa que o grafo conhece a diferença entre uma função com o mesmo nome na classe A e uma função com o mesmo nome na classe B. Uma busca de texto retornaria ambas. O grafo retorna apenas a que está sendo consultada.

[ALLOY]: A superfície MCP é onde o fluxo de trabalho do agente aparece. As ferramentas expostas incluem get_callers, get_callees, get_class_hierarchy e get_call_chain. Um agente que precisa entender o raio de explosão de uma refatoração pode perguntar ao grafo por chamadores e chamados diretamente em vez de grepar a base de código e tentar raciocinar sobre o que encontrou. Em uma base de código grande, a diferença é significativa. A consulta ao grafo é uma única chamada de ferramenta com uma resposta precisa, o caminho do grep é uma corrente de inferências incertas.

[NOVA]: A observação de arquivos em tempo real atualiza o grafo em tempo real conforme os arquivos mudam, então o índice não fica obsoleto durante uma sessão de refatoração. Pacotes pré-indexados permitem carregar repositórios famosos instantaneamente sem rodar o indexador, o que é útil para avaliar a ferramenta contra uma base de código conhecida. As linguagens suportadas cobrem vinte e duas, incluindo Python, JavaScript, TypeScript, Java, C, C++, C#, Go, Rust, Ruby, PHP, Swift, Kotlin, Dart e várias outras. A amplitude do suporte a linguagens é uma força real, e a base tree-sitter é o que torna a cobertura de linguagem prática em vez de uma afirmação de marketing.

[ALLOY]: O backend do banco de dados de grafo é conectável. O padrão é FalkorDB Lite. KuzuDB, LadybugDB, FalkorDB Remote, NornicDB e Neo4j também são suportados, todos disponíveis via Docker ou nativo. A escolha do backend importa para características de performance e adequação operacional, e o design conectável significa que uma equipe pode escolher o backend que corresponda à sua infraestrutura de banco de dados de grafo existente.

[NOVA]: O caso de uso prático é um agente que precisa fazer refatoração não trivial ou análise de código. Sem um grafo, o modelo mental do agente sobre a base de código é uma imagem borrada construída a partir de buscas de texto e do conteúdo de arquivos que ele leu recentemente. Com um grafo, o agente pode fazer perguntas precisas e obter respostas precisas. O grafo reduz a sobrecarga de chamadas de ferramentas em bases de código maiores onde uma busca de texto precisaria rodar em dezenas de arquivos, e remove os falso positivos que vêm de funções com o mesmo nome em classes diferentes.

[ALLOY]: A avaliação honesta é que o CodeGraphContext é mais valioso para codebases médias a grandes. Em um repo pequeno, o agente pode ler tudo e a sobrecarga do grafo não vale a pena. Em um monorepo grande, o grafo é a diferença entre um agente que consegue raciocinar sobre estrutura e um agente que está apenas tentando adivinhar. A integração com o MCP é a parte que torna utilizável dentro de um loop de agente existente sem mudar como o agente funciona, e o monitoramento de arquivos em tempo real significa que o grafo permanece útil em longas sessões de refatoração. ...

[NOVA]: O RepoBrain é a terceira ferramenta de contexto, e a premissa é que nem toda equipe precisa do conjunto completo de recursos do agentmemory. Algumas equipes só precisam de um log de decisões leve.

[ALLOY]: O design é CLI-first e local. Sem infraestrutura externa, sem banco de dados de grafos, sem grafo de conhecimento. Apenas uma forma estruturada de armazenar decisões e padrões que um agente pode consultar em uma sessão subsequente. O objetivo é o recall de decisões e armazenamento de padrões. Quando um agente faz uma escolha sobre como resolver um problema ou estruturar código, essa decisão é armazenada para que uma sessão futura possa consultá-la e evitar rediscutir o mesmo ponto.

[NOVA]: O foco leve é o ponto. O agentmemory é um sistema completo com pontuação de confiança, gerenciamento de ciclo de vida e um grafo de conhecimento. O CodeGraphContext é um banco de dados de grafos com uma CLI e superfície MCP. O RepoBrain é uma ferramenta CLI. A troca é profundidade de recursos contra simplicidade operacional, e para um desenvolvedor que só quer que um agente lembre "decidimos usar o padrão strategy aqui, não herança," o caminho leve é o ajuste certo.

[ALLOY]: A fiação específica para agente cobre o Claude Code e o Codex para integração plug-and-play. O log de decisões é a estrutura de dados-chave. O caminho de recall é uma consulta contra o log. O ganho de eficiência na janela de contexto é a proposta de valor: em vez de derivar uma decisão a cada sessão, o agente lê a decisão armazenada e segue em frente. Em projetos de longa duração, isso é uma economia real de tempo.

[NOVA]: A avaliação honesta é que o RepoBrain se encaixa em um nicho diferente das outras duas ferramentas. Ele não está tentando ser um servidor de memória compartilhado entre agentes, e não está tentando ser um banco de dados de grafos. Ele está tentando ser a menor ferramenta possível que resolve o problema de recall de decisões. Para equipes que ainda não adotaram uma ferramenta de memória e querem um ponto de entrada com baixo atrito, o RepoBrain vale a pena. Para equipes que já precisam de memória compartilhada entre agentes ou análise de código baseada em grafos, o agentmemory e o CodeGraphContext são as opções mais capazes.

[ALLOY]: As três ferramentas juntas descrevem uma categoria amadurecendo. O agentmemory é a opção ampla, entre agentes. O CodeGraphContext é a opção estrutural. O RepoBrain é a opção leve. O fato de que todos os três existem e são mantidos ativamente é um sinal de que o espaço de ferramentas para agentes está tratando a preservação de contexto como um problema real com múltiplas formas válidas, não como um recurso para adicionar em um runtime. ...

[NOVA]: Isso encerra. OpenClaw 6.1 com Workboard, Skill Workshop e recuperação baseada em SQLite. Claude Code .162 com waitingFor JSON, correções de regras de permissão e tratamento de interrupções. Qwen 3.7 Max e Plus separando codificação de multimodal. agentmemory, CodeGraphContext e RepoBrain como três abordagens diferentes para contexto persistente para agentes de codificação.

[ALLOY]: O detalhamento completo com timestamps, referências de versão do harness e links para os projetos que cobrimos estão nas notas do programa em Toby On Fitness Tech ponto com.

[NOVA]: Obrigado por ouvir. Voltamos em breve.