Engram pro Claude Code: jak funguje dlouhodobá paměť napříč relacemi

Plugin před odpovědí načítá související vzpomínky a po dokončeném tahu ukládá novou výměnu. Přínos i rizika závisejí na nastavení rozsahu paměti.

9. října 2026 Redakce aidevelopers.cz

Soubor CLAUDE.md se hodí pro pravidla projektu, ale není ideálním místem pro historii práce. Nepatří do něj každý zamítnutý návrh, důvod volby knihovny ani podrobnosti o endpointu vytvořeném minulý týden. Plugin Engram od Weaviate se snaží zachytit právě tuto vrstvu: průběžně ukládá vybrané informace z relací Claude Code a později je vrací jako kontext.

Nejde o lokální poznámkový soubor ani o novou vestavěnou funkci Claude Code. Plugin komunikuje s externí službou Weaviate Engram. To přináší paměť přes více relací a při správném nastavení také přes více repozitářů či členů týmu. Současně to znamená, že je potřeba vědět, co plugin odesílá, pod jakou identitou a v jakém rozsahu se uložené informace znovu načítají.

Co se děje před a po každé odpovědi

Plugin se podle popisu Weaviate zapojuje do dvou okamžiků relace.

Před odpovědí prohledá Engram podle právě zadaného promptu. Nalezené vzpomínky přidá Claude do kontextu. Nevrací celé staré konverzace, ale kratší poznámky, které Engram vytváří z uložených výměn pomocí embeddingů a LLM zpracování. Pokud Claude některou vzpomínku použije, má to v odpovědi uvést.

Po dokončení odpovědi plugin odešle Engramu uživatelskou zprávu i odpověď Claude. Služba z výměny vybere informace, které odpovídají nastaveným tématům, a uloží je pro pozdější vyhledávání. Uživatel nemusí zadávat příkaz typu „zapamatuj si“. Zachytávání probíhá automaticky pomocí hooků.

Ukládání je asynchronní a funguje v režimu best effort. Pokud chybí síť, API klíč není platný nebo je konfigurace chybná, relace Claude Code má pokračovat bez paměti. Plugin pouze přidá krátkou poznámku Engram · … na začátek odpovědi. Výpadek Engramu tak nemá zablokovat samotnou práci.

Paměť napříč repozitáři není automaticky bez hranic

Marketingový příklad Weaviate popisuje situaci, kdy backendový vývojář vytvoří endpoint a Claude si na něj vzpomene při pozdější práci ve frontendovém repozitáři. Technická dokumentace ale ukazuje, že rozsah závisí na nastavení témat a vlastností.

Ve výchozí konfiguraci se paměti označují názvem repozitáře a identifikátorem relace. Vyhledávání je standardně zúžené na aktuální repozitář. Pro načítání informací napříč codebase je potřeba vytvořit vhodné téma nebo upravit vyhledávací rozsah například v globálním souboru ~/.engram/config.json či v projektovém .engram.json.

Stejná podmínka platí pro týmové sdílení. Ne každá vzpomínka se automaticky zpřístupní všem. Témata v projektu Engram určují, co se extrahuje a podle jakých vlastností se paměť odděluje. Identita uživatele ve výchozím nastavení vychází z git config user.email; proměnná ENGRAM_USER_ID ji může přepsat.

Toto nastavení je důležité nejen pro užitečnost, ale i pro oddělení dat. Příliš úzký rozsah nepřinese očekávané propojení projektů. Příliš široký rozsah může naopak vracet kontext z jiné codebase nebo jiného týmu tam, kde není žádoucí.

Instalace vyžaduje Engram projekt a dva příkazy

Nejdřív je potřeba vytvořit projekt v konzoli Weaviate Engram a získat API klíč. Ten lze nastavit jen pro aktuální shell nebo uložit do profilu, například ~/.zshenv:

export ENGRAM_API_KEY=...

Uvnitř Claude Code se následně přidá marketplace a nainstaluje plugin:

/plugin marketplace add weaviate/engram-plugins
/plugin install engram@weaviate-engram

Paměť se má zapojit od následujícího promptu. Weaviate uvádí bezplatnou úroveň do 1 000 běhů měsíčně. Před širším nasazením je vhodné ověřit aktuální ceník a především to, co služba považuje za jeden běh.

Co prověřit před použitím ve firemním kódu

Automatické ukládání je pohodlné, ale mění datovou hranici vývojového prostředí. Každý dokončený tah může obsahovat části neveřejného kódu, názvy interních služeb, technická rozhodnutí nebo text vložený z ticketu. Plugin tuto výměnu posílá do spravované služby Engram, aby ji mohla zpracovat a uložit.

Před zapnutím v pracovním prostředí bych proto prověřil:

  • jaká data se v relacích Claude Code běžně objevují a zda smějí opustit firemní prostředí;
  • kdo má přístup k projektu Engram a jak jsou odděleni jednotliví uživatelé a týmy;
  • která témata se ukládají a podle jakých vlastností se omezuje jejich pozdější načítání;
  • jak lze chybnou nebo zastaralou vzpomínku najít, opravit či odstranit;
  • zda se tajné hodnoty filtrují už před odesláním a jaké retenční podmínky platí pro uložená data.

Veřejný repozitář pluginu alespoň umožňuje zkontrolovat hooky a konfiguraci. Samotný blog ale nepřináší nezávislé měření přesnosti vyhledávání, dopadu na kvalitu kódu ani četnosti chybných vzpomínek. Nelze z něj proto vyvodit, že Engram automaticky sníží chybovost nebo zlepší spolupráci každého týmu.

Kdy může Engram dávat smysl

Největší přínos vidím u práce rozdělené mezi více relací a repozitářů: společné API kontrakty, opakované architektonické volby, návaznost frontendu na backend nebo návrat k rozhodnutí, jehož důvod už není v aktuálním kontextu. U takových úloh může dobře zvolená vzpomínka ušetřit nové vysvětlování i opakované pročítání kódu.

Plugin ale nenahrazuje dokumentaci ani projektová pravidla. Stabilní požadavky stále patří do repozitáře, kde je lze verzovat a kontrolovat v code review. Engram je vhodnější pro pracovní historii a kontext, který může být užitečný později, ale není sám o sobě závazným pravidlem.

Praktický test by měl začít na jednom neprodukčním projektu. Stačí několik relací s jasně pojmenovaným rozhodnutím a následný pokus o jeho vyvolání v jiné relaci či repozitáři. Teprve z toho lze zjistit, zda nastavená témata ukládají správné informace, zda se paměť vybaví ve vhodnou chvíli a zda nepřenáší kontext příliš široce.

Engram tedy řeší skutečný problém Claude Code, ale jeho hodnota nestojí jen na instalaci pluginu. Rozhoduje nastavení témat, hranic a identity — a také ochota posílat obsah vývojových relací externí paměťové službě.