Short answer: Declarative memory can be stated as facts or descriptions. Non-declarative memory shows up only in how the agent behaves.
Borrowed from cognitive science, this split separates sayable knowledge from skill-like knowledge. Preferences and event summaries are often declarative. Procedures and habits are often non-declarative. Mixing them in one store blurs how each should be written and retrieved.
Cognitive science offers one more useful split, and it cuts across everything covered so far in a different direction than short-term versus long-term. Declarative memory covers anything that can be stated outright, as a fact or a description, in a sentence someone could simply say. Non-declarative memory covers everything that only shows up in behavior itself, never fully captured by any statement about it. This distinction, knowing that versus knowing how, turns out to explain something important about which parts of an agent’s experience are actually easy to write down as memory, and which parts fundamentally resist it.
What Actually Makes Something Declarative Rather Than Non-Declarative?
Declarative memory can be stated directly: “the user prefers dark mode,” or “we tried the first approach and it failed because the data was incomplete.” Both of these are complete, sayable facts or descriptions, nothing about them depends on demonstrating anything through action. Non-declarative memory is different in kind. It shows up only in performance, in how something actually gets done, and no single sentence fully captures it the way a plain statement captures a fact.
The clearest human analogy is knowing how to ride a bicycle. You can describe balance, pedaling, and steering in words, but the actual skill isn’t reducible to that description, and reading the description doesn’t transfer the skill the way reading “the meeting is at 3pm” transfers that fact completely and exactly. The distinction is real, not just a technicality: some knowledge lives entirely in a statement, and some knowledge only ever lives in the doing.
Where Do Episodic, Semantic, and Procedural Memory Fall on This Split?
Episodic and semantic memory both sit comfortably on the declarative side. A past event and a standing fact can each be captured completely in a sentence, without losing anything essential in the process of writing it down. “The database went down at 2am and a missing index turned out to be the cause” and “the user is a vegetarian” are both fully declarative: nothing about either one depends on demonstrating it through behavior rather than simply stating it.
Procedural memory sits mostly on the other side. Much of what makes a particular method actually work is embedded in how it gets executed, not fully reducible to any clean written rule, even when part of it can be approximated in words. A rule like “use the dedicated category field instead of a generic text search” captures something real and useful, but it’s a compressed proxy for a richer, more situational competence that doesn’t fully transfer through that one sentence the way a plain fact does.
Is Any Procedural Knowledge Actually Usable as Stored Memory, Given It Resists Being Stated?
It is, with an important caveat worth being honest about. What typically gets captured as a stored “procedural memory” isn’t the full, embodied skill itself, it’s a declarative approximation of it: a rule extracted from actual experience, written down in a form that can be stored and retrieved like any other fact, even though it’s standing in for something genuinely richer than the sentence itself contains.
This approximation is still useful, often extremely useful, the same way a written description of how to ride a bicycle genuinely helps someone learning, even though reading it alone won’t make them capable of riding one. The honest framing matters because it sets the right expectation: a stored procedural rule is a compressed, statable proxy for a skill, not the skill in its entirety, and treating it as a complete substitute for the underlying competence is where things eventually go wrong.
Does the Gap Between a Skill and Its Statable Approximation Cause a Practical Problem?
It does, in a specific and predictable way. A stored procedural rule is only as good as how well it was distilled from the actual experience that produced it, and any edge case that didn’t make it into that written approximation simply won’t be covered by it, even in situations where a more thoroughly developed version of the same skill would have handled things correctly. This is different from how a semantic fact typically behaves, where getting it right once is usually enough until circumstances genuinely change.
Procedural memory needs a different kind of ongoing attention: periodic revision and refinement as more experience accumulates, rather than being treated as a finished, one-time capture. A rule that worked well for the first ten cases it was drawn from might need updating the moment an eleventh case reveals a situation the original rule never accounted for.
How Does Weaviate Engram Handle Capturing Declarative Approximations of Non-Declarative Skill?
Weaviate Engram’s reconciliation step, the same mechanism that keeps a semantic fact current as circumstances change, applies just as directly to refining a procedural rule as more experience with it accumulates. Consider a technical-support chatbot for a software product that gradually gets better at diagnosing a specific class of bug report through repeated rounds of correction:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"When a user reports the app freezing after logging in, check for a stale cached session token before assuming a server-side issue.",
group="diagnostic-experience",
)
Weeks later, after handling more cases that this original rule didn’t fully account for, an updated version can reconcile against it rather than sitting alongside it as a separate, competing entry:
client.memories.add(
"Stale session tokens cause freezing only on mobile clients — on desktop, the same symptom usually points to a corrupted local cache instead, which needs a different fix.",
group="diagnostic-experience",
)
results = client.memories.search(
query="What should be checked first when a user reports the app freezing after login?",
group="diagnostic-experience",
)
What comes back reflects the current, refined understanding, not the original, incomplete version of the rule sitting there uncorrected. This is exactly what treating procedural memory honestly looks like in practice: not a perfect, finished statement captured once, but a written approximation that keeps getting revised as the underlying, harder-to-state skill keeps developing through continued use.
Declarative and non-declarative memory describes what kind of knowledge something is and how easily it can be put into words. It says nothing about who that knowledge belongs to, whether it’s private to one person’s relationship with an agent or something worth sharing across everyone the agent serves. Our next chapter, What is the difference between shared memory and private memory?, turns to exactly that question.