Deconstructing the AI Stack: From Classical Logic to Agentic AI A six-layer view of the AI stack, from rule-based logic and learned patterns to generative systems and autonomous tool-using agents. Introduction Artificial intelligence is often described as if it were one giant invention: a single machine that suddenly learned to talk, draw, code, plan, and reason. That framing is convenient, but it hides the most useful truth about AI. Modern AI is not one monolithic technology. It is a layered stack. Each layer was built on earlier breakthroughs, and each layer changed what computers could do. The easiest way to understand today's AI systems is to stop asking, "What is AI?" and start asking, "Which layer of AI are we talking about?" Classical AI used explicit human rules. Machine learning shifted the work from writing rules to training algorithms on data. Neural networks introduced flexible architectures inspired by biologi...
Get link
Facebook
X
Pinterest
Email
Other Apps
AI Memory Tools Inventory
Get link
Facebook
X
Pinterest
Email
Other Apps
-
AI Memory Tools Inventory
Inventory of agent memory services, short-term state, semantic memory, long-term storage, and graph/database-backed memory layers.
Introduction
AI Memory Tools Inventory is an inventory page, so its purpose is to help readers scan a tool category, compare candidates, and decide which items deserve deeper review. Inventory of agent memory services, short-term state, semantic memory, long-term storage, and graph/database-backed memory layers. The introduction sets expectations clearly: the list is a structured discovery surface, not a permanent ranking and not a substitute for checking current vendor documentation.
The most useful way to read this page is to separate stable comparison criteria from fast-moving product details. Terms such as memory, docs, state, vector, recall, agent indicate the evaluation surface: fit, integration model, operational burden, refresh sensitivity, and links to related concepts or entity pages. A reader should leave the introduction knowing why the inventory exists, how it supports shortlist creation, and why mature tools may later be promoted into dedicated entity or synthesis pages in the LLM Wiki.
This inventory tracks tools and stores used for conversational memory, agent state, semantic recall, episodic memory, user profiles, and durable workflow context.
Vector store often used for local memory and retrieval.
Refresh Notes
Track what kind of memory each tool supports: short-term state, semantic memory, episodic memory, user profile, graph memory, or workflow state.
Avoid calling a vector database a full memory layer unless it also covers lifecycle, write policy, and retrieval semantics. ^[inferred]
Enriched Comparison Matrix
Use this matrix to separate memory services from underlying storage primitives. A memory layer should define write policy, recall policy, update/delete behavior, and provenance.
Tool
Memory Role
Storage Pattern
Write Policy Support
Recall Semantics
Best Fit
Watchouts
Mem0
agent/user memory service
service plus vector/metadata backing
service-defined
semantic/user memory
assistants needing managed memory abstraction
verify deletion, privacy, and drift controls
Zep
conversational long-term memory
service/store backing
service-defined
conversation/user memory
chat assistants with user/session continuity
hosted/service fit and retention policy
Letta
memory-centered agent runtime
runtime-managed memory
framework-defined
agent self-editing memory patterns
stateful agents that expose memory as core primitive
complexity and governance
LangGraph Memory
state/memory pattern in orchestration
app/store-defined
app/framework-defined
short-term and long-term graph memory
graph/stateful agent workflows
requires deliberate state schema
Redis
cache/session memory
key-value/vector search
app-defined
fast state/cache recall
short-term state and low-latency memory
persistence and semantic quality limits
PostgreSQL
durable structured memory
relational/vector extension
app-defined
structured facts and audit records
durable user/task/project memory
schema and retrieval design burden
Neo4j
graph memory
graph database
app-defined
relationship/entity recall
entity-rich relationship memory
graph modeling overhead
Chroma
semantic vector memory
vector store
app-defined
semantic recall
local/simple semantic memory
not full memory lifecycle by itself
Memory Design Checklist
Question
Why It Matters
What is allowed to be remembered?
Prevents retaining sensitive or inferred facts accidentally
Who can edit/delete memory?
Required for correction, privacy, and user trust
Is memory episodic, semantic, profile, or task state?
Each type needs different storage and recall behavior
How is stale memory detected?
Old preferences or project context can degrade answers
For the AI Memory Tools Inventory, practical implementation means using an AI memory policy to make shortlisting concrete. The page should help readers compare candidates for the decision about what the system is allowed to remember and reuse, using criteria that stay useful even as product names, limits, pricing, and integrations change.
Compare candidates through retention scope, retrieval trigger, and privacy boundary.
Refresh items when stored fact, expiry rule, or user-visible recall changes.
Use the maintenance flow: classify memory, store with source, then audit retrieval.
Promote a candidate into an entity or synthesis page when memory retrieval improves continuity without exposing sensitive content must be tracked over time.
Implementation note: this AI memory policy should shortlist candidates through retention scope, retrieval trigger, and privacy boundary, then push readers toward the proof point that memory retrieval improves continuity without exposing sensitive content.
Reference Implementation Pattern
For the AI Memory Tools Inventory, the reference implementation is an AI memory policy. It should help readers shortlist candidates for what the system is allowed to remember and reuse by comparing stable criteria, not by presenting a static ranked list.
| Candidate | Retention Scope | Retrieval Trigger | Refresh Watch |
|---|---|---|---|
| Candidate A | Prioritize when retention scope is the gating concern | Inspect evidence for stored fact | Recheck user-visible recall |
| Candidate B | Compare when retrieval trigger drives architecture fit | Inspect evidence for expiry rule | Validate privacy boundary |
Refresh workflow:
1. Classify memory.
2. Store with source.
3. Audit retrieval.
In a real vault, this keeps the inventory useful as a discovery surface while preventing it from becoming the only place where vendor-specific knowledge lives. A tool should be promoted into an entity page when memory retrieval improves continuity without exposing sensitive content becomes important enough to track over time.
Key Takeaways
Treat the source page as distilled knowledge, then add enough implementation context for a standalone reader.
Make trade-offs visible: reliability, observability, governance, cost, and maintenance burden all matter.
Use structured headings, tables, examples, and explicit warnings to help readers scan and apply the material.
Operational Depth
Inventory Freshness
AI Memory Tools Inventory should operate as an AI memory policy. Because the page supports the decision about what the system is allowed to remember and reuse, its refresh rhythm should prioritize the criteria that actually change shortlist quality: retention scope, retrieval trigger, and privacy boundary.
Shortlist Signals
Operational review should inspect stored fact, expiry rule, and user-visible recall. A candidate that repeatedly matters to those signals should be promoted into an entity page or fed into a synthesis decision.
Validation Run
The inventory is useful when a maintainer can classify memory, store with source, and audit retrieval. The proof point is that memory retrieval improves continuity without exposing sensitive content.
Review Cadence
Review this page whenever source material changes, linked pages are promoted, or a reader would make a different decision because of new information. The review should check content accuracy, link integrity, and whether the operational proof still matches the current LLM Wiki graph.
Reader Outcome
A reader should leave with a shortlist and a verification plan, not with an unsupported ranking.
Frequently Asked Questions
How should a reader use AI Memory Tools Inventory?
Use it to compare a tool category, identify candidates for deeper review, and decide which options should become entity pages or feed a synthesis decision.
Is this inventory a ranked list?
No. It is a structured discovery surface. Readers should verify current details, especially around memory, docs, state, before treating any candidate as preferred.
When should an inventory item be promoted?
Promote a tool into an entity page when it becomes strategically important, appears across multiple decisions, or needs durable source tracking.
Conclusion
AI Memory Tools Inventory concludes as a shortlist-building tool. The inventory helps readers scan a category, compare common options, and identify which tools deserve deeper review, but it should not be treated as a permanent ranking because product details, pricing, limits, and integrations change quickly.
The next action is to verify the most relevant candidates against official sources, promote important tools into entity pages when they need durable tracking, and use synthesis pages when the decision depends on trade-offs across memory, docs, state, vector. That keeps the inventory useful without overloading it with every implementation detail.
Wiki Index A practical technical guide generated from the LLM wiki knowledge base. Full series Next: LLM Wiki Usage Guide Introduction This landing page is the starting point for the LLM Wiki Blog Series, a guided set of articles about building and maintaining an Obsidian-based knowledge environment for AI-assisted work. It introduces the vault as more than a folder of notes: Obsidian provides the Markdown foundation, the obsidian-wiki skills define repeatable agent workflows, and the generated articles show how concepts, entities, references, inventories, and synthesis pages work together as a navigable knowledge graph. Readers should use this page as the table of contents and orientation layer before jumping into individual topics. The series covers both the LLM Wiki operating model and the AI ecosystem content currently stored inside the vault, including foundation models, agents, retrieval, vector databases, embeddings, observability, memo...
LLM Wiki Usage Guide Practical guide for using this vault with LLM Wiki skills, Codex chat, Obsidian, and the obsidian-wiki setup CLI. Full series Previous: Wiki Index Next: Agent Development Frameworks Introduction LLM Wiki Usage Guide is the practical starting point for readers who want to operate an LLM Wiki environment instead of only reading about the idea. Practical guide for using this vault with LLM Wiki skills, Codex chat, Obsidian, and the obsidian-wiki setup CLI. The introduction focuses on the working setup: where the vault lives, which tasks belong in an agent chat, which tasks belong in Obsidian, and which terminal commands are only for setup or inspection. This page matters because many first-time users confuse the installed obsidian-wiki CLI with the day-to-day wiki skills. A clean setup separates those responsibilities. Obsidian provides the Markdown knowledge base, the agent runs workflows such as status, ingest, capture, qu...
Deconstructing the AI Stack: From Classical Logic to Agentic AI A six-layer view of the AI stack, from rule-based logic and learned patterns to generative systems and autonomous tool-using agents. Introduction Artificial intelligence is often described as if it were one giant invention: a single machine that suddenly learned to talk, draw, code, plan, and reason. That framing is convenient, but it hides the most useful truth about AI. Modern AI is not one monolithic technology. It is a layered stack. Each layer was built on earlier breakthroughs, and each layer changed what computers could do. The easiest way to understand today's AI systems is to stop asking, "What is AI?" and start asking, "Which layer of AI are we talking about?" Classical AI used explicit human rules. Machine learning shifted the work from writing rules to training algorithms on data. Neural networks introduced flexible architectures inspired by biologi...
