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 actor:
Resulting layout:
| Path | Purpose |
|---|---|
/SKILL.md | Top-level store description |
/log/ | Conversation logs (auto-populated by EventLogWriter) |
/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.
Tip
Pair EventLogWriter with DefaultBootstrap to get a ready-to-use persistent actor state. The writer targets /log/ which the bootstrap has already described via SKILL.md.
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}.