When to reach for it
- The agent must utilise domain-specific knowledge long-term.
- Facts and preferences are reused.
- Relationships between entities are crucial.
/pattern/semantic-memory/
Long-term knowledge is stored structurally, as embeddings, or as entities and relations, independently of single conversations. Match the store to the access pattern and start simple: vector DBs for similarity recall, key-value (Redis) for fast exact lookup, relational for structured/auditable querying, and graph DBs only once vector-plus-relational becomes the bottleneck.
In practiceA support assistant stores the fact that a customer is on the Enterprise plan, and recalls it in a conversation weeks later without the user repeating it.
When to reach for it
When it backfires
The tradeoff
Reusable, highly structured knowledge is gained against significant updating, modelling, and ranking challenges.
Durable facts outlive any single run.
Embeddings score by surface similarity. A high-similarity match can be a year-old answer to a question whose ground truth has since changed.
Fix · Include a freshness signal in ranking and reject documents past a recency cutoff. Re-embed when the source updates, not on a schedule.
Each write appends. The store ends up holding both 'the customer is on Free' and 'the customer is on Enterprise', and retrieval may surface either, so the agent contradicts itself between sessions.
Fix · Upsert facts by a stable entity key rather than appending, and resolve conflicts on write (latest-wins or explicit reconciliation) instead of at read time.
Keep going
Search patterns, frameworks, and pages.