Persistent AI agent architecture for Claude Code.
I keep building persistent AI agents and people keep asking how. So here's the architecture — memory graph in SQLite, maintenance pipeline in Go, Signal integration, proper OAuth2. Started with markdown files, ended up here.
Not a package. Not a template. Just working code and the thinking behind it.
A Go binary that manages an agent's long-term memory as a SQLite graph database. Runs on cron. No daemon, no server process.
The data model: typed memory nodes (identity, insight, pattern, thread, preference, event) connected by weighted edges (updates, related_to, contradicts, supports). Full-text search via FTS5. Vector similarity via stored embeddings. Hybrid retrieval for the bulletin.
→ Source code | Architecture deep dive
Reference implementations for connecting agents to external services — properly.
Signal Messaging — A Go client wrapping signal-cli's HTTP daemon. JSON-RPC for sending, SSE for receiving. No webhooks, no third-party relay services, no API keys in plaintext. Your agent gets a phone number and can send/receive Signal messages.
Google OAuth2 + Calendar — Proper OAuth2 with local callback server, CSRF state validation, token persistence in SQLite, and auto-refresh that survives process restarts. The calendar client gives agents read access to today's events or upcoming schedule.
How sessions work, how agents think between conversations, how async communication flows.
- Session Protocol — The start/run/end lifecycle.
now.mdfor orientation,inbox/outboxfor async messaging. - Autonomous Thinking — Cron-based cognition. Memory maintenance, inbox processing, reflection — agents don't need to be "always on" to think.
The design decisions and how the system evolved.
- Memory System — Graph model, pipeline design, emotional metadata, hybrid search.
- Evolution — From flat markdown files → living memory templates → graph database. What broke at each stage and why we moved on.
Sanitized examples of the configuration files that make this work.
- CLAUDE.md — How to give an agent identity and session continuity
- MEMORY.md — What a generated bulletin looks like
- now.md — Session state format
The original starter files from the flat-file era. Still useful for getting started before you need the full graph.
Memories decay like human memories. Importance fades over time. What's emotionally significant or structurally connected persists. Everything else gracefully disappears.
Generated output > accumulated output. A synthesized bulletin stays coherent. A document that only grows eventually collapses.
SQLite for everything. One file, no server, trivial backups. Memories, tokens, sessions, embeddings — all in the same database. You only need Postgres when you have multiple concurrent writers.
Security isn't optional. OAuth2 with proper token management. Signal via signal-cli (E2E encrypted). No API keys in environment variables piped through shell scripts. No webhook relays through third-party services.
Local-first. Embeddings via Ollama. Search via FTS5. The only external API call is Haiku for bulletin synthesis and consolidation decisions. Everything else runs on your hardware.
- Go — Cortex engine, Signal client, Google OAuth2
- SQLite — Memory graph, token storage, FTS5, embedding storage
- Ollama — Local embeddings (all-MiniLM)
- Claude Haiku — Bulletin synthesis, consolidation decisions
- Claude Code — The agent runtime
- signal-cli — Signal messaging daemon
- cron — Scheduled maintenance
- A framework you install with
npm install - A chatbot template
- A turnkey solution
It's a working architecture. Read the code, understand the patterns, adapt what makes sense for your agent. The cortex engine is buildable Go. The integrations are reference implementations. The docs explain the thinking.
MIT