Memory & Context
Memory is how Codebolt agents accumulate, retain, and retrieve knowledge — across turns, across sessions, and across projects. Context is what gets selected from memory and handed to the LLM each turn.
Two sides of the same system
| Side | What it does | Direction |
|---|---|---|
| Read path | Context Assembly Engine selects from storage and composes the prompt | Storage → LLM |
| Write path | Memory Ingestion pipeline captures, processes, and stores new information | Events → Storage |
Both sides operate on the same set of storage backends. Understanding which layer to use — and how to configure retrieval and ingestion — gives you direct control over what your agents know and how quickly they learn.
Storage layers at a glance
| Layer | Lifetime | Best for |
|---|---|---|
| Working memory | Single turn | Scratchpad, intermediate notes |
| Episodic memory | Single run | Turn history, short-term coherence |
| KV store | Persistent | Preferences, flags, small values |
| JSON store | Persistent | Structured records, config objects |
| Markdown notes | Persistent | Human-editable long-form notes |
| Knowledge graph | Persistent | Entities, relationships, code structure |
| Vector store | Persistent | Semantic recall, similarity search |
| Event log | Persistent | Audit trail, searchable history |
In this section
- Memory layers — what each store holds and when to use it
- Context assembly — how the read path composes a prompt each turn
- Context rules — the JSON DSL for controlling what gets included
- Persistent memory — declarative retrieval pipelines
- Memory ingestion — the write path: triggers, processors, routing
- Event log — the append-only audit trail, treated as a memory layer
See also
- Context and Memory concept — architectural deep-dive