Paweł Huryn's Post

Paweł Huryn · article · 2026-08-01 Reader 🖥️

Agent Memory Agent Skills Agent Context Files (CLAUDE.md / AGENTS.md)Context Engineering Knowledge Base Retrieval & RAG

For most AI agents, the four functional types of memory — working, semantic, episodic, and procedural — map cleanly onto a context window plus a handful of git-versioned files (markdown for facts/rules, a CSV for history, more markdown for reusable skills), making vector databases and graph databases unnecessary defaults, appropriate only as 'escape hatches' when a corpus genuinely becomes too large to read.

practical · mixed — Primarily practical — the terminal claim is an action recommendation ('you probably don't need a vector database'). But it is built on a theoretical scaffold: a four-part taxonomy of agent memory (working/semantic/episodic/procedural) that classifies and defines before it prescribes. An embedded infographic (a hand-drawn-style whiteboard image titled 'A practical four-part model') carries additional structural detail not present in the post text: named example files (strategy.md, rules.md, principles.md, examples.md, learnings.md) fanned out from an index.md, a worked context-window transcript for working memory, and a worked CSV example for episodic memory, plus the explicit design instruction 'Start with a file. Structure it when you need to filter or count.'

Structure

Part	Role
Opening hook: a PM repeatedly asks which vector database to use; the author's habitual answer is 'a folder of files.'	context
Four-part taxonomy: working, semantic, episodic, procedural memory, each given a one-line functional definition and a concrete implementation.	evidence / core exposition
Recap line: 'Three of those are just files in git... The fourth is the context window. You probably don't need a vector database either.'	conclusion, restated
Two 'escape hatches' named and scoped: vector store (similarity search at collection scale) and graph database (typed relationship queries at scale) — with the counter-claim 'your linked markdown is already a graph the agent walks by reading.'	qualifies the claim / pre-empts the obvious counterargument
Personal case: 'markdown files plus one CSV... It sharpens every week because the agent writes its own lessons back into the files.'	concrete proof-of-concept / narrative evidence
Two promotional CTAs (video series, infographic subscription).	promotional, not argumentative

Key terms

Working memory Agent Memory
What the agent is holding right now: the context window plus the goals and scratchpad it tracks. Explicitly 'not built,' only 'managed' — it is not a persistence artifact at all, it is runtime state that vanishes when the session closes.
Semantic memory
Facts and knowledge: strategy, rules, what 'good' looks like. Implemented as markdown files read before a task, versioned in git. Per the infographic, structured as an index.md fanning out to named files (strategy.md, rules.md, principles.md, examples.md, learnings.md).
Episodic memory
What happened before: past runs, decisions, outcomes. Implemented as a CSV in git, explicitly 'not a database.' Per the infographic, the recommended build path is 'start with a file, structure it when you need to filter or count' — i.e. a plain append-only log, escalated to a table only on demonstrated need.
Procedural memory
How the agent does things: reusable steps loaded on a trigger. Implemented as 'skills, which are also files.'
Escape hatch
A deliberately narrow framing device for vector stores and graph databases: tools reserved for when a memory problem outgrows 'too much to read' at ordinary agent scale, not defaults to reach for up front.

Propositions

explicitAgent memory decomposes into exactly four functional types: working, semantic, episodic, and procedural.conf: high
supportsThe Production Gap: 5 Patterns for Building Long-Running AI Agents · p8 — Turing Post's principle that 'long-term and working memory must be architecturally distinct stores, not a single memory pool' is exactly what Huryn's four-part taxonomy operationalizes, with two further distinct long-term stores (semantic vs. episodic vs. procedural).
explicitWorking memory is not built but managed — it is the context window plus the goals and scratchpad it tracks, and it disappears when the session closes.conf: high
explicitcorroboratedSemantic memory (facts, strategy, rules, standards of quality) is best implemented as markdown files, versioned in git, read before a task.conf: high
extendsPrompting Claude Fable 5 · p12 — Fable 5 guidance says 'a Markdown file, one lesson per file' is enough for a persistent memory store; Huryn extends this into a fuller structural taxonomy differentiating semantic memory (markdown/rules) from episodic memory (CSV/history) rather than treating all persisted lessons as one undifferentiated store.
supports ←Adrien Taravant's Post · p5 — GBrain, Sylph, and DIY-Claude-Code+Git corroborate git-versioned markdown as the default, engineer-favored Company Brain architecture, matching Huryn's file-based-semantic-memory thesis but naming it as shipped products rather than a single practitioner's setup.
explicitcontestedEpisodic memory (past runs, decisions, outcomes) is best implemented as a CSV file in git, not a database.conf: high
contradictsTony Seale's Post · p4 — Direct disagreement on which memory type markdown serves: Huryn maps markdown to semantic memory and a CSV to episodic memory, while vault-ld maps markdown to episodic memory (events/decisions/notes) and a separate ontology layer to semantic memory (identity/type/relationship). Same building blocks, opposite assignment.
explicitProcedural memory (reusable steps loaded on a trigger) is implemented as 'skills,' which are themselves files.conf: high
explicitMost agents do not need a vector database.conf: high
supportsSomeone just built the exact tool Andrej Karpathy said someone should build · p5 — Both converge on 'no vector database needed' for a personal knowledge/memory tool — independent practitioners reaching the same conclusion.
supportsShould You Still Become a Software Engineer in 2026? GitHub VP · p11 — Both argue engineers habitually reach for database/infrastructure complexity they don't actually need, when simpler file-based or in-memory approaches suffice.
explicitcontestedVector stores and graph databases are 'escape hatches' appropriate only when there is genuinely too much content to read directly — e.g. similarity search across a million documents, or typed relationship queries at scale — not defaults for ordinary agent memory.conf: high
contradictsAI 101: Agentic Vector Databases – What Is That? · p5 — Huryn frames vector databases as a niche 'escape hatch' most agents don't need; the vector-database extraction argues the vector database market is bifurcating into layers (agentic search, agentic memory, knowledge engines) becoming core agentic infrastructure, not an edge case.
refines ←Adrien Taravant's Post · p6 — Huryn frames vector/graph stores as 'escape hatches' for when there's 'genuinely too much to read'; Zep/Graphiti's validity-dated graph gives a more specific answer — the escape hatch is warranted for distinguishing current from superseded facts, not just corpus size.
explicitdevelopedA set of linked markdown files already forms a graph that an agent can traverse simply by reading and following links, making a dedicated graph database redundant for most cases.conf: high
extends ←Adrien Taravant's Post · p5 — Names three products (GBrain, Sylph, DIY Claude Code + Git) built on exactly the 'linked markdown is already a graph the agent can walk' premise, extending it from a single-practitioner pattern into a recognized product category — while also surfacing its limit (wrong for teams needing broad, non-engineer contribution).
explicitA file-based memory system can improve over time without external tooling, because the agent writes its own lessons back into the same files it reads.conf: high
supportsLoop Engineering · p9 — Both identify persisting state outside the conversation, in files the repo keeps, as the mechanism that lets an agent 'remember' and improve across runs the model itself cannot.
implicitMemory infrastructure should be built demand-driven rather than anticipatorily: episodic memory should start as a plain flat file and only be restructured into a queryable table once there is an actual need to filter or count, not before.conf: medium

Arguments

Most agents don't need a vector database.

Explicit premises:

Agent memory has exactly four functional needs: working, semantic, episodic, procedural.
Each of the four can be satisfied by the context window plus git-versioned files (markdown, CSV).
Vector stores solve a different problem: similarity search across a collection too large to read (the author's example is 'enterprise search').

Implicit premises:

The scale of a typical individual agent's memory (one practitioner's strategy, rules, and history) is small enough to be read directly rather than requiring similarity search.
An agent reading/greeping files retrieves 'well enough' compared to vector similarity search for this use case — recall/precision tradeoffs are not a binding constraint at this scale.
The instinct to reach for a vector database is driven by pattern-matching to enterprise-search-scale problems rather than an actual scale analysis of the agent's own memory.

Inferences:

The argument implies a scale-dependent switch point ('too much to read') at which a vector store does become appropriate, but the author never quantifies where that threshold is.
The argument is implicitly scoped to a single practitioner's personal agent; it does not address whether the calculus changes for multi-agent or multi-tenant setups where aggregate memory across many agents/users could reach the scale the author concedes vector stores ARE for.

A dedicated graph database is unnecessary for most agents. strength: medium