SmartMemory
Concepts

Expertise vs Knowledge

Expertise vs Knowledge

Most "memory for AI" today stores knowledge — facts derivable from documents, chat history, or source code. That's table stakes, and SmartMemory does it well.

The harder, scarcer thing is expertise: the choices that were made, the alternatives that were rejected, the constraints that were discovered the hard way, the opinions that hardened over time, the reasoning that justified a contested call. None of that is recoverable from a corpus. It only exists because someone decided, tried, failed, learned.

SmartMemory treats expertise as a first-class layer with its own memory types, its own capture API, and its own recall channel.

The distinction in one sentence

Knowledge is what's true. Expertise is what to do — and what not to do.

A retrieval system that only returns knowledge tells the agent what is the case. An expertise layer also tells it what was rejected, what was constrained, what bit you last time, what you came to believe.

The mapping

Every memory type SmartMemory supports falls cleanly on one side of the line:

SideMemory typeWhat it capturesCapture API
KnowledgesemanticDurable factsadd()
KnowledgeepisodicWhat happened, whenadd() (episodes)
KnowledgeproceduralHow to do somethingadd_plan() / procedural ingest
KnowledgezettelLinked notes, ideas-in-progressadd() (zettel)
ExpertisedecisionA choice made — with rejected alternatives, rationale, constraintsadd_decision()
ExpertiseconstraintA hard rule discovered (or imposed)add_constraint()
ExpertiselearnedA lesson the hard wayadd_learning()
ExpertiseopinionA held belief, with confidenceadd_opinion()
ExpertisereasoningA reasoning trace — premises → conclusionadd_reasoning()
ExpertiseobservationAn attested fact about the world or selfadd_observation()

Each expertise type has its own Manager + Queries + lifecycle (supersession, reinforcement, contradiction handling) — they aren't just metadata tags on a generic memory item.

Recall: the expertise channel

Default search() returns a flat list ranked by hybrid retrieval — knowledge and expertise mixed together. When the agent is reasoning about a decision — "what's our position on X", "have we tried Y before", "what's the constraint here" — flat search isn't the right shape. Expertise needs to come back partitioned by type.

from smartmemory import SmartMemory

mem = SmartMemory()

# Capture
mem.add_decision(
    "Adopt FalkorDB as the graph substrate",
    rejected_alternatives=["Neo4j (license)", "Memgraph (ops weight)"],
    rationale="Smallest ops surface; vector-native; permissive license.",
    constraints=["Must support Cypher subset"],
)
mem.add_constraint("Never store PII in graph properties — always reference IDs.")
mem.add_learning("Mocking the database in integration tests masks migration bugs.")

# Recall — typed-dict, bucketed by expertise type
results = mem.search("graph database choice", expertise=True)
# {
#   "decision":    [Decision(...)],   # the FalkorDB choice + rejected alternatives
#   "constraint":  [Constraint(...)], # the PII rule
#   "learned":     [Learned(...)],    # the mocking lesson (if relevant)
#   "opinion":     [],
#   "reasoning":   [],
#   "observation": [],
# }

The recall channel ranks each bucket independently with a recency × confidence boost over the base hybrid score, then returns up to top_k items per bucket. The shape is stable: all six keys are always present, even when empty.

What this is not

  • Not a reasoning system. SmartMemory stores reasoning traces; it does not generate new ones. That's the agent's job.
  • Not a contradiction detector. Contradictions across decisions and opinions are surfaced via the supersession lifecycle, not derived automatically.
  • Not a replacement for semantic memory. Knowledge and expertise are complementary. Most agents need both.
  • Not free. Expertise has to be captured — the wrappers exist for exactly this reason. An agent that only ever calls add() will accumulate knowledge but never expertise.

Where to next

On this page