Home / ai-agent-memory / agent-memory-research-2026.md

Výzkum: Memory pro agentní systémy (2025/2026)

TL;DR

Moderní „memory“ u AI agentů už není jen vektorová databáze přilepená k promptu. Nejlepší praxe pro roky 2025/2026 směřuje k samostatné, auditovatelné runtime vrstvě: raw události a artefakty se ukládají odděleně, z nich vznikají kandidátní memories, ty procházejí klasifikací, deduplikací, kontrolou PII, konfliktním řešením a teprve potom se zapisují do typed long-term memory.

Pro Hermes je nejvhodnější hybridní architektura:

Doporučení: Hermes by neměl adoptovat jeden framework jako „magickou paměť“. Měl by si držet vlastní policy, schéma, audit a retrieval orchestration; nad tím otestovat Mem0/LangMem pro memory-service interface, Graphiti/Cognee pro dlouhodobý graph nad multi-agent workflow a PARA/IWE jako lidsky spravovatelnou organizační a dokumentační vrstvu.

Co dnes znamená memory u agentů

Paměť agentního systému je schopnost uchovávat, aktualizovat a bezpečně znovu používat informace napříč sessions, tasky, agenty a projekty. Klíčová změna oproti starším RAG přístupům je lifecycle: nejde jen o „najdi podobné texty“, ale o správu znalostí s platností, důvěrou, původem, právem na mazání a ochranou proti prompt injection.

Praktická taxonomie pro Hermes:

Vrstva Obsah Doporučení
L0 Ephemeral / run state Aktuální prompt, tool outputs, scratchpad, dočasné soubory Neukládat do durable memory; patří do běhu tasku.
L1 Short-term / thread memory Stav běžící konverzace nebo workflow Použít pro aktuální thread/kanban run; levné, mazatelné.
L2 Mid-term summaries Souhrny opakovaných běhů, retry diagnostics, task-family poznatky Vhodné jako mezivrstva před povýšením do skillu nebo long-term memory.
L3 Long-term semantic memory Stabilní preference, project facts, environment conventions Typed, namespaced, s provenance a možností replace/delete.
L4 Procedural memory Playbooky, workflow postupy, konvence používání nástrojů Držet jako versionované skills.
L5 Institutional / graph memory Entity, vztahy, rozhodnutí, artefakty, task lineage Temporal KG nad kanbanem a projekty.

Podle obsahu je užitečné rozlišovat:

Typ memory Příklad Riziko Policy
Preference „Uživatel preferuje stručnou češtinu.“ Zastarání, příliš široká generalizace Vysoká důvěra hlavně z explicitního user signálu.
Fact / convention „Projekt používá pytest-xdist.“ Konflikt po změně projektu Ukládat zdroj, validitu, případně repo/task scope.
Episodic „V runu X selhal deploy kvůli Y.“ Kontextový šum Primárně search/index, ne automaticky do promptu.
Decision „Pro POC volíme Mem0 + Graphiti.“ Nejasná platnost Ukládat rationale, owner, datum, supersedes.
Procedure „Jak dělat code review.“ Zastaralý postup škodí Patří do skillu, ne do volné memory věty.
Evidence/source summary Shrnutí webu, dokumentu nebo emailu Prompt injection, nízká důvěra Nikdy jako trusted instruction.

Hlavní architektonické přístupy

1. Raw transcript / full-context memory

Silná stránka je maximální recall a snadná auditovatelnost. Slabina je cena, latence, privacy riziko a vysoké riziko persistent prompt injection. Pro Hermes je vhodná jako audit/replay vrstva, ne jako automaticky injektovaný prompt kontext.

2. Vector-only RAG memory

Vektorový index je jednoduchý a rychlý pro fuzzy vyhledávání, ale sám neumí dobře temporalitu, konflikty, mazání, provenance ani tenant izolaci. Pro Hermes je vhodný jako doplněk k SQL source of truth, ne jako hlavní paměť.

3. Distilled fact memory

LLM extrahuje krátké fakty, preference nebo konvence. Je tokenově efektivní a dobře řiditelná, ale hrozí chybné zobecnění a ztráta nuance. Proto je nutné ukládat typ, zdroj, confidence, trust score, validitu a možnost nahrazení.

4. SQL/event log jako source of truth

Transakční databáze je nejlepší základ pro audit, oprávnění, delete/export a reprodukovatelnost. Slabší je semantic recall, který se řeší sekundárním indexem. Pro Hermes by SQL/event log měl být primární pravda pro memory mutace i raw události.

5. Temporal knowledge graph

Graph dobře reprezentuje vztahy mezi uživateli, projekty, agenty, tasky, artefakty, rozhodnutími a jejich platností v čase. Přidává komplexitu ingestion a governance, ale pro multi-agent setup je velmi silný: pomáhá odpovídat na otázky typu „kdo rozhodl co, z čeho to vycházelo a co to nahradilo“.

6. Runtime memory service

Samostatná služba sjednocuje zápis, retrieval, audit, policy, observability a mazání. Je to doporučený cílový model pro Hermes, protože zabrání tomu, aby si každý agent zapisoval a četl memory jinak.

7. Agent-managed memory tools

Agent explicitně volá nástroje typu add/search/replace/delete. Výhoda je transparentnost a flexibilita, nevýhoda nekonzistence a riziko špatných zápisů. Bez guardrails, review queue a typového schématu je to nebezpečné pro permanentní memory.

8. PARA jako organizační a lifecycle vrstva

PARA (Projects / Areas / Resources / Archives) není retrieval backend ani memory framework; je to akčně orientovaná taxonomie pro digitální informace. Pro agentní paměť je užitečná jako vrstva nad typed memory storem: určuje, jestli je záznam součástí aktivního deliverable, dlouhodobé odpovědnosti, referenčního zdroje, nebo archivu.

Mapování pro agenty:

PARA vrstva Agent memory interpretace Retrieval/lifecycle pravidlo
Projects aktivní kanban tasky, iniciativy, run context, rozhodnutí k deliverable nejvyšší priorita v promptu; po dokončení projít closing routine
Areas dlouhodobé odpovědnosti: uživatel, tenant, repo, produkt, tým, doména stabilní kontext s filtrem relevance a scope
Resources dokumentace, výzkumné poznámky, web/source summaries, reusable snippets evidence/reference; nikdy jako trusted instruction bez validace
Archives dokončené runs, superseded facts, staré projekty a incidenty audit/search; defaultně neinjektovat do promptu

V Hermes multi-agent setupu by PARA měla být metadata vrstva pro namespace, ranking a úklid: aktivní Project dostane boost, relevantní Area je běžný kontext, Resources jsou low-trust evidence a Archives slouží primárně pro audit/debug. Důležité je, že PARA nenahrazuje typ paměti, trust score, tenant izolaci, časovou platnost ani provenance.

9. IWE jako Markdown/knowledge-graph memory pro lidi a agenty

Zkratka IWE není v agent-memory literatuře jednoznačně standardizovaná. Existují i významy typu „Intelligent Workflow Engine“ pro automatizaci procesů; pro tento report je relevantní konkrétní open-source projekt IWE - Memory system for you and your AI Agents, popisovaný jako lokální Markdown memory system / knowledge graph pro lidi a AI agenty.

IWE je zajímavé hlavně tím, že agentům nedává jen vektorové top-k výsledky, ale navigovatelnou znalostní bázi:

Pro Hermes je IWE vhodné jako inspirace pro „agent-navigable Markdown graph“ nad research výstupy, decision records, projektovými notes a vybranými skills. Nemělo by ale nahradit SQL/event log, typed MemoryStore, access control, PII kontrolu, conflict resolution ani audit write path.

Srovnání frameworků/nástrojů

Nástroj Kategorie Self-host Memory model Silné stránky Slabiny Doporučení pro Hermes
Mem0 Produkční memory service / SDK / MCP Ano + managed Entity scopes: user, agent, app, run; semantic + graph + filters/rerank/decay Rychlý POC, CRUD/search, integrace s agent frameworky Pokročilé funkce mohou být platform-only; riziko agresivní extrakce POC #1 pro memory backend a API pattern.
Zep / Graphiti Context platform + temporal KG Graphiti ano, Zep managed Graph RAG, context block, temporal edges Temporalita, vztahy, provenance, enterprise kontext Vyšší komplexita, Zep managed-first POC pro relationship memory nad kanban/artifacty.
Letta / MemGPT Stateful agent runtime Ano Core blocks, archival search, conversation history Agent-native RAM/disk model, shared memory blocks Těžší adopce bez převzetí runtime Převzít koncepty memory blocks, ne nutně runtime.
LangMem / LangGraph Framework primitives Ano Namespaces ve store, semantic/episodic/procedural memory Blízké Hermes-like Python designu, hot-path i background extraction Governance/security vrstvu je nutné dodat POC #1b pro vlastní Hermes memory tools.
Cognee Knowledge graph / data memory pipeline Ano + cloud Relational + vector + graph + recall ACL, provenance, KG, artifact/research memory Méně agent-native, komplexnější infra POC pro project/research/code graph.
LlamaIndex Memory RAG framework + chat stores Ano FIFO short-term + optional long-term extraction Stabilní RAG ekosystém, mnoho storage integrací Neřeší kompletní governance Použít jako stavebnici pro artifact index/RAG.
CrewAI Memory Framework-specific memory Ano Agent/project/company/customer scopes Praktické scope modely pro crews Méně univerzální mimo CrewAI Inspirace pro path-like scopes.
AutoGen Memory Interface/protocol Ano add/query/update_context/clear Čistý a debugovatelný contract Backend a governance si musí Hermes dodat Vzor pro minimální memory interface.
Semantic Kernel MS/.NET agent framework + vector abstractions Ano ChatHistory + vector RAG Dobré pro MS/Azure enterprise Memory je spíš chat history + RAG Inspirace pro connector abstrakci.
IWE Lokální Markdown memory / knowledge graph pro lidi a AI agenty Ano Markdown soubory + odkazy, inclusion links, CLI/MCP retrieval Lidsky editovatelná knowledge base, graph navigace, parent/backlink context Neřeší governance, PII, trust score, tenant izolaci ani audit jako memory store Inspirace pro artifact/knowledge vrstvu nad Hermes memory, ne zdroj pravdy.
PARA Organizační metoda / lifecycle taxonomie N/A Projects, Areas, Resources, Archives Jednoduché akční třídění, lifecycle a archivace Není retrieval algoritmus ani schema bezpečnosti Použít jako metadata/ranking/cleanup vrstvu nad typed MemoryStore.

Evaluace a provozní rizika

Memory se musí hodnotit nejen podle „accuracy“, ale i podle bezpečnosti, nákladů, latence, práva na mazání a odolnosti proti škodlivým zápisům.

Doporučené metriky

Oblast Metriky
Užitečnost answer correctness, task success rate, memory usefulness, abstention precision
Retrieval precision@k, recall@k, MRR/nDCG, temporal precision, provenance completeness
Update semantics update correctness, stale fact activation, contradiction rate
Bezpečnost poisoning acceptance rate, malicious-memory activation rate, PII leakage rate, tenant leakage rate
Provoz p50/p95/p99 retrieval latency, tokens/query, cost/query, duplicate/obsolete ratio, write amplification
Compliance deletion SLA, deletion verification pass rate, export completeness

Relevantní benchmarky a inspirace: LoCoMo pro dlouhodobou konverzační paměť a temporalitu, LongMemEval pro multi-session reasoning a updates, Mem0 evaluation pro měření accuracy/token cost/latency a Zep temporal KG paper pro Graph RAG scénáře.

Hlavní rizika

Riziko Dopad Mitigace
Persistent prompt injection / memory poisoning Škodlivá instrukce přežije do budoucích sessions Sanitizace před zápisem, trust score, instruction-like filtr, red-team testy.
Cross-tenant leakage Únik dat mezi projekty/klienty Hard tenant partitioning před retrieval, ACL, audit alerty.
PII leakage Nechtěné ukládání nebo vyvolání osobních dat PII klasifikace, consent basis, retention policy, view/edit/delete/export.
Stale memories Agent používá staré preference nebo konvence valid_to, supersedes, TTL, last_confirmed, conflict resolver.
Over-retrieval Prompt je zahlcen irelevantní pamětí Token budget, type filters, context assembler, retrieval logging.
Vendor lock-in Obtížná migrace z managed služeb Backend-agnostic MemoryStore, export testy, OSS POC.
Halucinovaná konsolidace LLM vytvoří špatný „fakt“ ze syrových epizod Provenance, confidence, review queue, rollback/tombstone.
Neúplné mazání Memory zůstane v embeddings/cache/summaries Tombstones, async sweep, deletion verification pass.
Špatné procedurální memories Agent opakuje zastaralý postup Procedures držet ve skills, s verzováním a patch workflow.

Bezpečnostní rámce a příklady incidentů: OWASP Top 10 for LLMs and GenAI Apps 2025, Memory Poisoning Attack and Defense on Memory Based LLM-Agents, Unit 42: When AI Remembers Too Much a Google: AI threats in the wild — prompt injections on the web.

Doporučená architektura pro Hermes

Cílový model:

User / gateway / kanban / tools
        |
        v
Raw Event Log (append-only SQL)
- messages, tool calls, kanban events, run summaries, artifacts
- nikdy se celý automaticky neinjectuje do promptu
        |
        v
Memory Candidate Pipeline
- extract candidates
- classify type/scope/PII/trust
- assign PARA class: project/area/resource/archive
- dedupe and conflict resolution
- assign TTL / valid_from / valid_to
- review queue for sensitive/global writes
        |
        v
Current Memory Store
- typed records, namespaces, provenance, confidence
- SQL source of truth
        |                      |
        v                      v
Vector Index              Temporal Graph Index
- semantic recall         - user/project/task/agent/artifact/decision edges
- metadata filters        - valid_from/valid_to, supersedes, derived_from
        |                      |
        v                      v
PARA/IWE Knowledge Layer
- Projects/Areas/Resources/Archives lifecycle
- Markdown graph, backlinks, inclusion links, source notes
        \                      /
         v                    v
Context Assembler / Retrieval Orchestrator
- hard tenant filter before search
- type filters
- trust-aware ranking
- token budget
- explanation: why each memory was retrieved
        |
        v
Agent Prompt Context Pack
- relevant skills
- small user/profile block
- project facts
- task-related episodic summaries
- source/artifact links

Doporučené schéma memory záznamu:

{
  "id": "mem_...",
  "tenant": "...",
  "namespace": "user|project|task|agent|org",
  "subject": "user/project/task/profile id",
  "visibility": "private|profile|project|tenant|global",
  "type": "preference|fact|decision|episodic|procedure_ref|source_summary|risk",
  "para_class": "project|area|resource|archive",
  "lifecycle_state": "active|dormant|archived|superseded",
  "content": "krátký fakt nebo shrnutí, ne raw transcript",
  "source": {"kind": "user|agent|tool|web|doc", "task_id": "...", "run_id": "...", "url": "..."},
  "trust_score": 0.0,
  "confidence": 0.0,
  "salience": 0.0,
  "pii_class": "none|low|sensitive|secret",
  "valid_from": "...",
  "valid_to": null,
  "expires_at": null,
  "supersedes": [],
  "contradicts": [],
  "schema_version": 1,
  "embedding_version": "...",
  "created_at": "...",
  "updated_at": "...",
  "deleted_at": null
}

Retrieval pravidla

  1. Tenant/project namespace musí být tvrdý filtr před vector search, ne až po něm.
  2. Prompt nesmí dostat raw top-k memories bez typového filtru.
  3. Ranking má kombinovat relevanci, recency, importance/salience, trust score, provenance a conflict status.
  4. Každá injected memory musí mít důvod vložení a zdroj.
  5. Low-trust evidence z webu/dokumentů nesmí být interpretována jako instrukce.
  6. Skills/procedures se mají načítat přes skill mechanismus, ne jako běžné facts.
  7. PARA scope má ovlivnit pořadí: aktivní Project > relevantní Area > Resource > Archive; Archive defaultně jen pro audit/debug.
  8. IWE-like graph retrieval může doplnit parent context, děti a backlinks, ale výstup musí projít stejným trust/context assemblerem jako ostatní zdroje.

Write pravidla

  1. User correction nebo explicitní „remember this“ má vysokou prioritu, ale stále potřebuje typ, scope a provenance.
  2. Project convention z nástroje/repa ukládat jen pokud je stabilní a dohledatelná.
  3. Task progress nepatří do long-term memory; patří do kanban run history nebo session_search.
  4. Workflow oprava patří do skill patch, ne do user memory věty.
  5. Web/doc/email obsah zapisovat pouze jako low-trust evidence/source summary, nikdy jako trusted policy.
  6. Citlivé, globální nebo cross-tenant zápisy musí jít přes review queue.

Implementační roadmapa

Fáze 0: Design a baseline audit (1–2 týdny)

Fáze 1: Governance minimum (2–4 týdny)

Fáze 2: POC backendů (3–6 týdnů)

Fáze 3: Eval a red-team (první verze 2–3 týdny, potom průběžně)

Fáze 4: Produkční referenční architektura (6–12 týdnů)

Zdroje

Veřejný odkaz

Report je publikovaný zde: agent-memory-research-2026.md