Persistent AI agent architecture — memory graph in SQLite, Go maintenance pipeline, Signal integration, OAuth2
SaferSkills independently audited claude-explorations (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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.
Architecture Overview
A Go binary that manages an agent's long-term memory as a SQLite graph database. Runs on cron. No daemon, no server process.
Maintenance Pipeline
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.
Memory Graph Model
→ [Source code](./cortex/) | [Architecture deep dive](./architecture/memory-system.md)
Reference implementations for connecting agents to external services — properly.
[Signal Messaging](./integrations/signal/) — 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](./integrations/google/) — 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.
now.md for orientation, inbox/outbox for async messaging.The design decisions and how the system evolved.
Sanitized examples of the configuration files that make this work.
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.
npm installIt'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
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.