Houve um pequeno atraso nesta parte final da série dos 19 sistemas, mas antes tarde do que nunca.
Os seis padrões universais nos 19 sistemas que venho explorando são a espinha dorsal desta série. Investimento na qualidade no momento da escrita. Proveniência viajando com o fato. Recuperação híbrida fundida com RRF. Armazenamento em camadas com promoção baseada em calor. Orçamentos de contexto explícitos. Ferramentas, não injeções, na superfície do agente. Cada um mereceu seu próprio artigo porque três ou mais sistemas chegaram à mesma disciplina de forma independente.
Os padrões universais param por aqui. A partir daí, os emergentes começam.
Este artigo é sobre oito padrões que estão abaixo do limiar, vivendo em um ou talvez dois sistemas, onde a implementação aborda um problema real de forma tão clara que é difícil acreditar que permanecerão raros. Sete aparecem em exatamente um sistema. Um aparece em dois e está a uma adoção de se formar. O primeiro recebe o tratamento mais profundo porque é o mais importante.
Estar cedo significa que alguns destes não se universalizarão. Estar tarde é pior: você constrói um sistema em 2026 que é lançado sem autorização na camada de armazenamento porque uma síntese chamou isso de peculiaridade isolada, e você recebe uma demonstração de injeção de prompt no Hacker News em 2027.
O mecanismo de armazenamento é a única autoridade que se sustenta
o artigo anterior argumentou que o agente deveria segurar as ferramentas. Dê a ele uma ferramenta SQL e a questão se torna imediata: o que o impede de consultar a tabela que não deveria?
As abordagens ingênuas são bem conhecidas e todas erradas.
Instrução no nível do prompt: "Você não tem permissão para ler a tabela de conversas." Funciona contra um modelo cooperativo. Falha contra qualquer modelo que interprete mal a instrução, decida que a proibição não se aplica à sua tarefa atual ou esteja operando sob um jailbreak.
Filtro no nível da aplicação: a ferramenta sql_query envolve o SQL do modelo, analisa-o em busca de referências de tabelas proibidas e rejeita a consulta antes de passá-la ao banco de dados. Funciona contra um modelo ingênuo. Falha contra qualquer modelo que cite nomes de tabelas, use ATTACH, explore uma incompatibilidade de análise entre o wrapper e o banco de dados, ou roteie através de uma view definida em outro lugar.
Acesso apenas mediado por ORM: o agente nunca toca em SQL bruto, ele chama métodos tipados. Funciona até que o sistema ganhe uma ferramenta de depuração, uma ferramenta de análise, uma ferramenta de migração ou um recurso "deixe o agente juntar duas tabelas", momento em que a regra quebra e a quebra passa despercebida.
Simplificando: nada disso é aplicação. São dicas. Um sistema que deseja um verdadeiro isolamento de subagente tem que pedir ao próprio mecanismo de armazenamento que recuse a leitura, não à camada acima dele. Esta é a disciplina que a segurança baseada em capacidades impõe aos recursos do sistema operacional: o kernel diz não, não a aplicação. É também a disciplina que a segurança em nível de linha do PostgreSQL impõe ao SaaS multi-inquilino: a política vive no banco de dados, não no ORM, porque "o engenheiro que construiu o novo microsserviço esqueceu de aplicar o filtro de inquilino" é uma classe de bug que apenas uma política do mecanismo de armazenamento pode eliminar.
second-brain é o primeiro exemplo prático do corpus. Seu banco de dados com escopo tem três camadas, cada uma necessária, nenhuma suficiente por si só.
Uma nova conexão SQLite em memória por agente com escopo. O construtor abre :memory: e anexa o banco de dados real em modo somente leitura. A conexão do agente não tem esquema principal real, não há nada para ler exceto o que a próxima camada coloca lá.
TEMP VIEWs no esquema principal redirecionando para tabelas permitidas na fonte. As definições de view vêm do perfil do agente e podem codificar redação em nível de coluna ou filtros em nível de linha. Um validador de nome de view impede a injeção de nomes de tabelas maliciosos através do perfil.
Um hook de autorizador da API C do SQLite negando qualquer leitura do esquema fonte que não passe por uma view. O hook é acionado para cada leitura que o SQLite está prestes a realizar, antes mesmo de o otimizador resolver o nome da tabela. Uma leitura dentro do corpo de uma view é permitida, a view é o filtro de escopo. Uma leitura de nível superior é verificada em relação ao conjunto de nomes de view que o escopo criou. Qualquer leitura diretamente contra o esquema fonte é negada sem exceção.
O LLM pode escrever qualquer SQL que quiser. Pode citar nomes de tabelas, usar UNION, usar ATTACH, usar a gramática completa do SQLite. Não pode conseguir ler uma linha de uma tabela que não está na lista de permissões, porque o autorizador intercepta a leitura na camada C antes de o nome da tabela ser resolvido. O filtro no nível da aplicação é contornável. A autorização do mecanismo de armazenamento não é.
Cerca de 50 linhas de Python stdlib. Nenhuma dependência extra, nenhum processo extra, nenhuma migração de esquema. A sobrecarga por consulta é um callback C por leitura, invisível contra o custo da própria consulta. O padrão se compõe de forma limpa com tudo o mais: o registro de ferramentas do agente ainda pode ser controlado por recursos, as definições de view ainda podem codificar redação em nível de coluna, o histórico de conversas ainda pode ser redigido no momento da escrita. Nenhuma dessas camadas é enfraquecida pela aplicação na camada de armazenamento. Elas são reforçadas por ela.
O enquadramento é importante. Todos os outros padrões de segurança nos 19 sistemas são dicas. O mecanismo de armazenamento é a autoridade.
Mais três que merecem ser nomeados
Proteção de condição de corrida em limpeza assíncrona (llm-wiki)
A manutenção de memória em segundo plano é fundamentalmente propensa a condições de corrida com ações do usuário em primeiro plano. Uma varredura que começou contra o projeto A e termina contra o projeto B corrompeu ambos. Moveu as decisões de A para o repositório de revisão de B, ou marcou os itens de B como resolvidos com base nos dados de A. Esta é uma classe de bug fácil de introduzir, difícil de detectar e impossível de recuperar de forma limpa porque o estado corrompido parece legítimo.
llm-wiki executa um loop de revisão em segundo plano de dois estágios e, em cada ponto de retorno, verifica novamente dois sinais de proteção de corrida: um sinal de aborto disparado pelo manipulador de troca de projeto e uma comparação de caminho contra o projeto atual na interface do usuário. Se qualquer uma das verificações falhar, a varredura retorna no meio do voo sem aplicar as decisões. O handshake de troca de projeto no lado da fila completa o quadro: ele libera o estado do projeto ativo para o disco antes de limpar a memória, reverte os itens em processamento para pendentes, aborta tanto a chamada LLM em voo quanto o julgamento da varredura em voo, e só então escreve no caminho do projeto pausado.
O meta-padrão é a conclusão: determinístico onde puder, LLM onde for necessário, abortável em todos os lugares. A estrutura de dois estágios mantém o LLM fora de casos que verificações simples de existência podem tratar. A proteção de corrida mantém ambos os estágios abortáveis. A combinação é um modelo para qualquer loop de manutenção de memória em segundo plano em qualquer sistema.
O construtor de no-op degradado automaticamente (graymatter)
O design de API de bibliotecas tem uma tensão recorrente. O "hello world" mais simples quer que a biblioteca funcione imediatamente, uma linha para construir, uma para chamar. A postura de produção mais defensável quer que ela falhe ruidosamente na construção com um erro estruturado que o chamador não pode ignorar.
graymatter escolhe falhar silenciosamente, mas com uma disciplina que torna a troca produtiva. O construtor nunca retorna um erro. Se a inicialização falhar, bbolt está bloqueado, o diretório de dados é gravável, o armazenamento vetorial não pode ser aberto, ele registra em stderr e retorna uma Memory degradada cujos métodos são todos no-op. Chamadores em produção verificam através de Healthy() antes de confiar no handle. A biblioteca é go get-ável, importável em três linhas e funciona na demonstração. Healthy() é o imposto da disciplina de produção.
O padrão torna a biblioteca segura para incorporar em harnesses de agente que têm sua própria cerimônia de inicialização. Um harness de agente que chama [graymatter.New](https://graymatter.new/)(...) durante a inicialização, ignora o caminho de erro porque não há caminho de erro e continua, obtém uma camada de memória funcional no caminho feliz e um fallback sem memória quando o diretório de dados é somente leitura. De qualquer forma, o harness inicializa. Esse é um tipo específico de composição defensiva que construtores de falha ruidosa não podem oferecer sem tratamento explícito de erros em cada local de incorporação.
Detecção de duplicatas em modo sombra (mem9)
Todo sistema que envia supressão de duplicatas tem que escolher um limite de similaridade de cosseno. Acima de 0,95 é quase certamente uma duplicata. Abaixo de 0,7 é quase certamente que não. O espaço intermediário é contestado, e o corte certo depende do modelo de incorporação, do domínio, da distribuição de consultas e do custo de falsos positivos versus falsos negativos neste sistema específico.
A tentação é esmagadora de escolher um com base na intuição e enviar. mem9 não faz isso. Ele executa a consulta de detecção de duplicatas para cada fato, registra a pontuação de cosseno em um histograma Prometheus e não toma nenhuma ação. O limite é adiado até que os dados de produção o justifiquem. "Envie a observação, não a heurística."
A mesma lógica se aplica a toda decisão baseada em limite em todo sistema de memória. Limite de reclassificação. Limite de confiança de recall. Portão de calor de promoção de camada. Limite de similaridade de mesclagem de insight. A maioria dos sistemas nos 19 envia esses valores adivinhados. mem9 envia com o valor adiado. A disciplina é rara e o resultado é melhor.
Mais quatro, mais concisos
Isolamento de banco de dados físico por inquilino (mem9).
Em vez de um filtro WHERE tenant_id = ? em um armazenamento compartilhado, mem9 provisiona um cluster TiDB separado por inquilino através do TiDB Zero. O isolamento é do lado do mecanismo de armazenamento. A aplicação não pode consultar acidentalmente entre inquilinos porque não há armazenamento compartilhado para consultar. É uma versão de granularidade mais grossa do mesmo estado final que a autorização da camada de armazenamento: isolamento aplicado no mecanismo, não na aplicação. O custo de infraestrutura que historicamente tornava isso impraticável se foi. TiDB Zero provisiona automaticamente. Neon faz o mesmo para PostgreSQL. Cloudflare D1 faz o mesmo para SQLite.
Decoração de turno de origem com orçamento de contexto explícito (mem9).
Uma memória recuperada é uma string. "Usuário prefere Postgres." Correto, conciso, impossível de fundamentar sem contexto. mem9 anexa os turnos de conversa de origem como decoração, pontuados contra a consulta e limitados por um orçamento triplo: pontuação mínima, limite por memória, limite total. O agente lendo "Usuário prefere Postgres" obtém o turno onde o usuário disse "tentamos MongoDB, mas as junções nos mataram, então mudei para Postgres no trimestre passado." Nenhuma segunda chamada de ferramenta necessária. A fundamentação está no resultado. Os pré-requisitos já são universais: proveniência mais recuperação híbrida. A maioria dos sistemas nos 19 poderia implementar isso em dois dias.
purpose.md como um quarto arquivo (llm-wiki).
O padrão LLM Wiki de Karpathy tem três arquivos canônicos: fontes brutas, o conjunto de trabalho do wiki e schema.md para regras estruturais. llm-wiki adiciona um quarto: purpose.md, preenchido pelo usuário, embutido em toda chamada LLM que o sistema faz. Todo prompt de ingestão, todo prompt de geração, toda consulta de chat o lê. O efeito é uma prioridade direcional estável que condiciona todo comportamento downstream. O LLM vai ler o prompt do sistema de qualquer maneira. Adicionar a intenção do usuário não custa nada e eleva tudo. A ausência na maioria dos outros sistemas é mais difícil de explicar do que sua presença no llm-wiki.
AGENTS.md como contrato de agente autoritativo (Tolaria, OpenContext). A maioria dos repositórios com um AGENTS.md ou CLAUDE.md o trata como um arquivo de dica. Tolaria e OpenContext o tratam como um contrato, apoiando cada cláusula vinculante com uma verificação mecânica que falha na construção se o agente a violar. "Não pule ganchos de pré-confirmação" não é um pedido educado, é uma regra que o CI aplica. "A cobertura de teste deve permanecer acima do limite" não é uma diretriz, é uma barra na qual o executor de teste aborta. Uma dica pode ser ignorada. Um contrato apoiado por uma verificação não pode. Dois sistemas já fazem isso. Mais um e ele se forma.
Quais se universalizarão a seguir
A autorização da camada de armazenamento se universalizará primeiro. Esta é a previsão mais confiante na análise da fonte. Todo sistema de memória que dá a um subagente acesso SQL está a uma injeção de prompt de uma violação de confidencialidade sem aplicação na camada de armazenamento. A infraestrutura já está em vigor. SQLite tem set_authorizer desde o início dos anos 2000. PostgreSQL RLS é mainstream. LanceDB e ClickHouse têm seus próprios ganchos de política. A barreira não é técnica, é de conscientização. second-brain forneceu o exemplo prático. A próxima geração de APIs gerenciadas copiará a disciplina porque a alternativa é indefensável.
A decoração de turno de origem se universalizará em segundo lugar. Os pré-requisitos já são universais. A implementação são duas consultas mais um orçamento. O ganho de informação do lado do agente é grande o suficiente para que quem o enviar primeiro em uma API gerenciada seja visivelmente melhor em fundamentar respostas no diálogo de origem do que quem o enviar em segundo. A pressão para copiar é alta. graymatter tem a fonte por fato. supermemory tem linhagem. Hindsight tem proveniência conversacional completa. Qualquer um deles está a um PR do padrão.
O construtor de no-op degradado automaticamente se universalizará em terceiro lugar, e em uma linguagem diferente. As condições culturais de Go tornam o padrão seguro. O próximo adotante provavelmente não será Python, a cultura é muito ansiosa por exceções, mas pode ser Rust. É uma escolha de design de API de biblioteca, não uma escolha de memória, e se espalhará onde quer que "estética de demonstração mais disciplina de produção" seja a troca certa.
A implantação em modo sombra é o cavalo escuro. Tecnicamente trivial, culturalmente difícil. Se um segundo sistema instrumentar um limite antes de bloqueá-lo, o padrão se forma imediatamente, e o terceiro e o quarto seguem dentro de um ciclo de lançamento porque a ergonomia de engenharia é incontestável uma vez demonstrada.
Os quatro restantes são cada um condicionais a uma forma de implantação específica se tornar mais comum. A proteção de corrida se universaliza quando mais sistemas crescem paralelismo de múltiplas conversas. O isolamento físico por inquilino se universaliza quando clientes empresariais regulamentados começam a pedi-lo. purpose.md se universaliza quando o paradigma LLM Wiki de Karpathy obtém sua terceira ou quarta implementação. AGENTS.md como contrato se universaliza quando o enquadramento "agentes são colegas" se torna a metáfora de harness dominante. Nenhum é implausível. Nenhum é certo.
Uma Conclusão
O fio unificador em todos os oito é a mesma posição: a camada de aplicação não é um limite de isolamento confiável. A autorização da camada de armazenamento é a expressão por agente. Os bancos de dados físicos por inquilino são a expressão por inquilino. AGENTS.md como contrato é a expressão por comportamento do agente. A próxima iteração deste corpus conterá, nesta previsão, um novo padrão universal com esse nome.
O artigo anterior defendeu que o agente deveria segurar as ferramentas e decidir o que recuperar. Este é sobre o que se sustenta quando o agente vira essas ferramentas para algum lugar que você não esperava. Os seis padrões universais são consenso. Os oito aqui são os indicadores principais de para onde o consenso se move a seguir. A autorização da camada de armazenamento é a ponta de lança da ponta de lança, e o custo de perdê-la é o tipo de custo que aparece no Hacker News.
