Como dar aos seus assistentes de IA uma só memória partilhada

Explica a sua stack, os seus clientes, as suas restrições a um assistente. Duas semanas depois muda para outro modelo porque é melhor naquilo de que precisa agora — e recomeça do zero. A memória que construiu não lhe pertence: vive dentro de um produto.

É esse o verdadeiro problema. Não é que os assistentes se esqueçam: a maioria retém bastante bem hoje em dia. É que cada um retém separadamente, num armazenamento que não consegue ler, mover nem apontar para outro lado.

Memória integrada versus uma memória que lhe pertence

As memórias nativas são práticas e não custam nada. Têm também três propriedades que convém olhar de frente: é o fornecedor que decide o que é retido, os dados ficam dentro desse fornecedor, e nada o acompanha quando sai. Para um uso ocasional, o negócio é bom. Para um trabalho que constrói ao longo de anos, é um aprisionamento que escolheu sem dar por isso.

A alternativa é manter a memória fora de todos os assistentes e deixar cada um ler a partir dela. Isso exige um protocolo em que ambos os lados estejam de acordo — e é aí que entra o MCP.

O que é realmente o MCP

O Model Context Protocol é uma norma aberta para ligar um assistente a ferramentas e dados exteriores. Foi a Anthropic que o publicou, e desde então foi adotado muito para além do Claude. Do ponto de vista do modelo, um servidor MCP é apenas um conjunto de ferramentas invocáveis: guarda isto, procura aquilo.

Um servidor de memória expõe algo como quatro ferramentas — escrever uma memória, procurar nas memórias, listar um projeto, trazer à superfície o que é relevante agora — e o assistente invoca-as por iniciativa própria quando a conversa o exige. Não é preciso colar contexto: o modelo vai buscá-lo.

Os servidores MCP existem em duas formas, e essa diferença conta mais do que qualquer comparação de funcionalidades:

• Local (stdio). O servidor corre como um processo na sua máquina. Rápido, privado, gratuito — e invisível para tudo o que não seja uma aplicação de secretária nessa máquina. Nem o telemóvel, nem um separador do navegador.
• Remoto (HTTP + OAuth). O servidor vive num URL. Qualquer cliente que suporte conectores remotos pode autenticar-se e usá-lo, a partir de qualquer dispositivo.

Se quer uma memória partilhada entre assistentes e dispositivos, é a segunda forma que precisa. Se quer uma memória num único portátil de onde nunca sai, a primeira é sinceramente a melhor resposta — e é gratuita.

Como se liga uma memória remota

Não há nada para instalar. Um servidor MCP remoto é um URL mais uma autenticação OAuth, exatamente o mesmo gesto que ligar um calendário a uma aplicação:

1. Cole o URL do servidor nas definições de conectores do seu cliente.
2. O cliente obtém os metadados OAuth do servidor e regista-se sozinho.
3. Autoriza o acesso numa janela do navegador, uma vez.
4. As ferramentas aparecem. O assistente começa a invocá-las quando é pertinente.

Repita o primeiro passo num segundo cliente e ambos passam a ler e escrever na mesma memória. O truque está todo aí: a memória é um serviço, não um ficheiro. A nossa versão passo a passo, com capturas de ecrã por cliente, está no guia de ligação.

Guardar é fácil. O produto é encontrar.

Qualquer coisa sabe acrescentar texto a uma base de dados. O difícil é responder, meses mais tarde e no meio de uma conversa sem relação, quais das suas quatro mil notas contam agora. Falhe nisso e construiu um arquivo que ninguém lê.

Duas maneiras de falhar, ambas comuns:

• A pesquisa só por palavras-chave falha tudo o que esteja formulado de forma diferente daquilo que escreveu.
• A pesquisa só vetorial devolve coisas vagamente dentro do tema e falha os nomes exatos, os códigos de erro e os identificadores — precisamente os detalhes de que precisava.

As implementações sérias correm as duas e fundem as classificações — a reciprocal rank fusion é o método habitual — e depois reavaliam a lista curta com um modelo de reranking que lê mesmo a pergunta e o candidato em conjunto. Custa mais por consulta e é a diferença entre uma memória e um monte.

Se trabalha em mais do que uma língua, verifique este ponto em particular. Uma cadeia afinada em embeddings ingleses degrada-se silenciosamente em francês ou alemão, e a avaria é invisível: obtém apenas piores resultados e assume que escreveu mal a nota.

Cinco perguntas antes de se comprometer

1. Local ou remoto? Decida isto primeiro. Num sentido ou no outro, elimina a maior parte do mercado.
2. Onde estão os dados, e sob que jurisdição? Se a resposta não está no site, parta do princípio de que não vai gostar dela.
3. Consegue tirá-los de lá? Exportação num formato utilizável, a pedido, sem escrever ao suporte.
4. Pesquisa híbrida e reranking, ou simples pesquisa vetorial? Pergunte; raramente é anunciado.
5. O que acontece no limite do plano gratuito? Apagado, congelado ou em leitura apenas: três desfechos muito diferentes.

Onde se situa o Pryzm

O Pryzm Memory é do segundo tipo: um único ponto de acesso alojado, autenticação OAuth, partilhado por todos os clientes que ligar. Corre em servidores na Alemanha, sob jurisdição da UE, cifrado em repouso, com um esquema e um papel de base de dados por cliente impostos pelo próprio PostgreSQL. A pesquisa é híbrida, com um reranker multilingue, em oito línguas.

Também não é open source e não o pode auto-alojar hoje — o que é desqualificante para algumas pessoas, e preferimos dizê-lo aqui a deixar que o descubra depois de se inscrever. Mantemos uma comparação honesta com as alternativas, incluindo as que nos batem exatamente nesses dois pontos.