RUNLOCALAIv38
->Will it run?Best GPUCompareTroubleshootStartLearnPulseModelsHardwareToolsBench
Run check
RUNLOCALAI

Independently operated catalog for local-AI hardware and software. Hand-written verdicts. Source-cited claims. Reproducible commands when we have them.

OP·Eruo Fredoline
DIR
  • Models
  • Hardware
  • Tools
  • Benchmarks
TOOLS
  • Will it run?
  • Compare hardware
  • Cost vs cloud
  • Choose my GPU
  • Prompting kits
  • Quick answers
REF
  • All buyer guides
  • Learn local AI
  • Methodology
  • Glossary
  • Errors KB
  • Trust
EDITOR
  • About
  • Author
  • How we make money
  • Editorial policy
  • Contact
LEGAL
  • Privacy
  • Terms
  • Sitemap
MAIL · MONTHLY DIGEST
Get monthly local AI changes
Monthly recap. No spam.
DISCLOSURE

Some links on this site are affiliate links (Amazon Associates and other first-class retailers). When you buy through them, we earn a small commission at no extra cost to you. Affiliate links do not influence our verdicts — there are cards we rate highly that we don't have affiliate relationships with, and cards that sell well that we refuse to recommend. Read more →

© 2026 runlocalai.coIndependently operated
RUNLOCALAI · v38
  1. >
  2. Home
  3. /Learn
  4. /Courses
  5. /OpenCLaw: Building a Personal AI Agent
  6. /Ch. 5
OpenCLaw: Building a Personal AI Agent

05. SQLite for Short-Term

Chapter 5 of 24 · 15 min
KEY INSIGHT

SQLite provides ACID-compliant storage with minimal overhead, making it ideal for short-term memory where reliability matters more than concurrent write performance. SQLite handles short-term memory storage efficiently for single-process agents. The database provides transactional guarantees without requiring a separate server process. Embedded operation eliminates network latency and simplifies deployment. Schema Design Short-term memory stores conversation turns, working context, and transient state. The schema reflects these use cases with tables optimized for recent data access patterns. ```sql CREATE TABLE conversations ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, started_at DATETIME DEFAULT CURRENT_TIMESTAMP, last_activity DATETIME DEFAULT CURRENT_TIMESTAMP, context_summary TEXT, is_active BOOLEAN DEFAULT TRUE ); CREATE TABLE messages ( id INTEGER PRIMARY KEY AUTOINCREMENT, conversation_id INTEGER NOT NULL, role TEXT NOT NULL CHECK(role IN ('user', 'assistant', 'system')), content TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, metadata JSON, FOREIGN KEY (conversation_id) REFERENCES conversations(id) ); CREATE INDEX idx_messages_conversation_time ON messages(conversation_id, created_at DESC); CREATE TABLE working_memory ( key TEXT PRIMARY KEY, value TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, expires_at DATETIME, access_count INTEGER DEFAULT 0 ); ``` Failure Handling SQLite handles many failure scenarios automatically through its journal mechanism. Incomplete transactions roll back cleanly on restart. Corrupted databases can often be recovered from WAL (Write-Ahead Logging) archives. However, SQLite is not immune to all failures. Disk full conditions require proactive monitoring. Database locks can block operations during high-concurrency scenarios. Large databases may experience performance degradation without regular maintenance. Maintenance Operations Regular maintenance keeps the database healthy. The VACUUM command reclaims deleted space and rebuilds indexes. The ANALYZE command updates query planning statistics. These operations should run during low-activity periods. ```sql -- Clean up expired working memory DELETE FROM working_memory WHERE expires_at IS NOT NULL AND expires_at < CURRENT_TIMESTAMP; -- Archive old conversations INSERT INTO conversations_archive SELECT * FROM conversations WHERE last_activity < datetime('now', '-30 days'); -- Reclaim space VACUUM; ```

EXERCISE

Write a Python function that uses SQLite to store a message in a conversation, updating the conversation's last_activity timestamp in the same transaction. Handle the case where the conversation does not exist.

← Chapter 4
Persistent Memory
Chapter 6 →
Vector Store for Long-Term