Knowledge Store
A KnowledgeStore is a virtual, path-based key-value store with filesystem-like semantics. It gives agents a durable place to persist conversation logs, artifacts, working memory, and any other content that should outlive a single agent.ask() call.
All implementations share the same protocol, so you can swap an in-memory store for a SQLite file or Redis instance without changing callers.
The protocol#
The KnowledgeStore protocol (importable from autogen.beta) defines the full API every implementation satisfies:
Paths follow Unix conventions: absolute (/dir/subdir/file.txt), directories are implicit, and list() returns immediate children with / suffixes for directories.
The append / read_range pair supports WAL-style workloads: append returns the byte offset, which you can later hand to read_range to retrieve just the newly written slice.
Choosing an implementation#
| Implementation | Use when |
|---|---|
MemoryKnowledgeStore | Tests, ephemeral sessions, or when persistence isn't needed |
SqliteKnowledgeStore | Single-process durability on disk — the pragmatic default |
DiskKnowledgeStore | Files need to be human-readable on disk (artifacts, logs) |
RedisKnowledgeStore | Multi-process or cross-host sharing |
LockedKnowledgeStore | Wraps another store to serialize concurrent writers |
Basic usage#
Memory store — fastest, non-persistent#
Sqlite store — persistent across process restarts#
Disk store — files on the filesystem#
Append and read_range#
These two methods support WAL-style event logs, turn-by-turn transcripts, and any append-only workload where you want to retrieve only new content.
Warning
read_range returns UTF-8 text but operates on byte offsets. If you append multi-byte characters, align offsets to character boundaries yourself.
Change subscriptions#
Callers can react to writes via on_change. Backends that observe changes efficiently (DiskKnowledgeStore using watchdog) call the callback directly. Backends that cannot (MemoryKnowledgeStore, SqliteKnowledgeStore) return a NoopChangeSubscription — the caller is expected to poll.
DefaultBootstrap#
DefaultBootstrap populates a store with a standard layout and SKILL.md files that explain each directory to an LLM reader. It's designed to be called once per agent:
Resulting layout:
| Path | Purpose |
|---|---|
/SKILL.md | Top-level store description |
/log/ | Conversation logs — auto-populated by EventLogWriter after each ask() unless KnowledgeConfig.write_event_log=False |
/artifacts/ | User files, downloads, reference material |
/memory/ | Working memory and conversation summaries |
Implement your own StoreBootstrap if you need a different layout.
EventLogWriter — persist stream history#
EventLogWriter serializes a Stream's events to a KnowledgeStore as JSONL, and can reconstruct them later. Useful for replay, audit, or multi-run aggregation.
Persisted events land at /log/{stream_id}.jsonl. Events of types that cannot be deserialized (e.g. a removed class) come back as UnknownEvent — no data is lost.
When an Agent is given a KnowledgeConfig, it runs this persist(...) step for you at the end of every ask() — so you only call EventLogWriter directly in a custom harness. Set KnowledgeConfig.write_event_log=False to turn the automatic write off (e.g. when the store is purely user-facing memory rather than a transcript archive); if the writer raises, the turn still returns its reply and an EventLogFailed event is emitted on the stream.
Tip
Pair EventLogWriter with DefaultBootstrap to get a ready-to-use persistent agent state. The writer targets /log/ which the bootstrap has already described via SKILL.md. If you set KnowledgeConfig.expose_tool=False, the Agent passes DefaultBootstrap(mention_tool=False) so the generated SKILL.md doesn't tell the LLM about a knowledge tool it can't call.
LockedKnowledgeStore — serialize writers#
LockedKnowledgeStore wraps any KnowledgeStore to serialize concurrent writes. It delegates locking to a user-provided object implementing acquire(name, ttl) / release(name) — typically a distributed lock (Redis, database advisory locks, etc.) so multiple processes sharing the same store can coordinate.
Note
Reads are not locked (safe for concurrent access on all backends). Only write, delete, and append acquire the lock. Lock keys are of the form store:write:{path}.