Summary of Today’s Gen AI Agents Session: Rows in a File – A Custom SQLite Session Store (31 Oct 2026)

Thursday the agent forgot the order ID, on purpose. Today we gave it somewhere to remember.

1. Memory Needs Storage

Short-term memory means the agent carries the current conversation forward. That has to live somewhere: a database or a file.

We chose SQLite for one reason — nothing to install. It’s a file on disk with a SQL interface. Swap it for Postgres later and the agent code doesn’t change, which is the whole point of doing it this way.

2. What the SDK Gives You

The Claude Agent SDK defines a SessionStore protocol — a set of methods your store must provide. In Python it’s a Protocol, so you can either subclass the base or simply implement the methods. Satisfy the shape and the SDK will use it.

What exists already:

• InMemorySessionStore ships with the SDK. It works, and it dies with the process.
• S3, Redis and Postgres adapters are published as copyable reference examples in the TypeScript SDK repository. They’re code to adapt, not a package to install.

Why write your own anyway? Because your organisation won’t be using the example. If your stack is Azure Blob Storage or Cosmos DB, nobody has written that adapter for you. Writing the SQLite one teaches you the shape so you can write the one you actually need.

3. The Implementation

class SQLiteSessionStore:
    """Session storage backed by a local SQLite file."""
    def __init__(self, path: str = "sessions.db"):
        ...

Three tables, which map neatly onto the SDK’s own concepts:

Our table	SDK concept	Holds
keys	SessionKey	Which session is which
entries	SessionStoreEntry	The transcript, appended as it grows
summaries	SessionSummaryEntry	Condensed history

The methods: append, load, list sessions, list summaries, delete.

Default file: sessions.db in the project directory.

4. Wiring It In

The store goes into the agent through make_options() — the same single place that holds the system prompt, the tools and the MCP servers. One function to change when the configuration changes.

5. What Went Wrong, and Where to Look

First run: nothing persisted. A bug in the store implementation. Fixed, and we confirmed rows were landing in sessions.db.

But the agent still couldn’t answer from previous turns. Rows in a file are necessary, not sufficient. Two things to check before Monday:

1. Are you passing resume with the session ID on the next call? Writing the transcript doesn’t make the SDK read it — you have to ask for that session by ID.
2. Are you running from the same working directory? The store’s project key encodes the working directory, so a resume launched from elsewhere won’t match the session you saved.

This is the most instructive bug of the module. Everything looks correct — the file exists, the rows are there — and the agent is still a stranger.

6. Short-Term and Long-Term

Short-term is the conversation you’re in. Every major framework — Claude, OpenAI, LangChain — supports it with a base class you extend.

Long-term is the one that needs design. To pick up a customer’s history after three months, you need to store the session ID against the user and look it up. Which is exactly the mapping problem we flagged earlier in this track.

✅ Exercises

1. Reimplement the session store in a different backend. Pick one:
   • MongoDB — document storage instead of relational
   • YAML files in a .session folder — no database at all
2. Debug the recall problem. Check resume and the working directory first.
3. Confirm your rows are actually written before you blame the agent.

Logistics: a trial offline class is planned for Monday.

⏭️ Next up: making recall work, and moving from short-term to long-term memory.