8 KiB
Obsidian as AI Memory — Strategy
Why Obsidian for AI Memory
Obsidian is a local-first, markdown-based knowledge base. This makes it the ideal AI memory layer because:
- Markdown is AI-native — Every AI model reads/writes markdown natively. No format conversion needed.
- Local-first — Your data stays on your infrastructure, not in someone else's cloud.
- Graph structure — Obsidian's
[[wikilinks]]create a knowledge graph that mirrors how AI context works — interconnected nodes of information. - Git-syncable — Vaults are just folders of
.mdfiles. Push to Forgejo for backup and versioning. - Plugin ecosystem — Community plugins for AI integration, templating, and automation.
- Searchable — Full-text search + tags + frontmatter metadata = fast retrieval.
Architecture
┌─────────────────────────────────────────────┐
│ Obsidian Vault │
│ (Docker on casa / synced to Forgejo) │
│ │
│ 📁 Memory/ │
│ ├── sessions/ ← AI conversation logs│
│ ├── decisions/ ← Why we chose X │
│ ├── infrastructure/ ← Network, servers │
│ ├── agents/ ← Agent definitions │
│ ├── runbooks/ ← How-to procedures │
│ └── incidents/ ← What broke & fixes │
│ │
│ 📁 Projects/ │
│ ├── oracle-dc-tech/ │
│ ├── samjam-tech/ │
│ └── homelab/ │
│ │
│ 📁 Templates/ │
│ ├── session-log.md │
│ ├── decision-record.md │
│ ├── incident-report.md │
│ └── agent-definition.md │
│ │
│ 📁 Daily/ ← Daily notes │
│ └── 2026-05-04.md │
└─────────────────────────────────────────────┘
│ │
▼ ▼
Forgejo Repo AI Agent reads
(git backup) (context injection)
Memory Types
1. Session Memory (Short-term)
What: Logs of AI conversations with key decisions and outcomes. When: After each significant AI session. Format:
---
date: 2026-05-04
tags: [session, infrastructure, casaos]
agents: [kiro, harbor]
---
# Session: Fix cloud connectivity + deploy code-server
## Context
Cloud server unreachable from internet...
## Decisions
- Fixed keepalived health check (ping -I flag broken)
- Changed cloud gateway to VIP 192.168.122.1
- Deployed code-server on casa
## Artifacts
- [[harbor]] agent created
- [[casa-app-workflow]] documented
## Follow-up
- [ ] Make libvirt default network persistent
- [ ] Investigate casaos guest agent
2. Decision Records (Long-term)
What: Why a specific technical choice was made. Why: So future-you (or future-AI) doesn't re-debate settled questions. Format:
---
date: 2026-05-04
tags: [decision, networking]
status: accepted
---
# Decision: Use VIP as default gateway for all bridge hosts
## Context
Cloud server was pointing at pre's base IP (.2) instead of VIP (.1).
## Options
A. VIP (.1) — automatic failover ✅
B. Direct (.2) — no failover
C. Dual routes — overcomplicated
## Decision
Option A. VRRP exists for this exact purpose.
3. Infrastructure Memory
What: Current state of all systems, IPs, services, configs.
Why: Single source of truth that AI can reference.
Maps to: Your existing steering/infrastructure.md but richer with Obsidian links.
4. Agent Memory
What: Agent definitions, capabilities, deployment history.
Why: Agents can reference their own history and learn from past deployments.
Maps to: agents/harbor/ etc.
5. Incident Memory
What: What broke, root cause, fix applied. Why: Pattern recognition — if the same symptom appears, AI finds the prior fix. Format:
---
date: 2026-05-04
tags: [incident, networking, dns]
severity: high
systems: [cloud, pre, netbird]
---
# Incident: Cloud server unreachable from internet
## Symptoms
- NetBird disconnected on cloud
- DNS resolution failing
- Incoming traffic dead
## Root Cause Chain
1. Pre's ping binary changed from iputils to inetutils (no -I flag)
2. Keepalived health check always failing → VIP never assigned
3. Cloud DNS stub resolver (127.0.0.53) broken
4. NetBird can't resolve management server → tunnel down
## Fix
- Removed -I flag from check_internet.sh
- Changed cloud gateway to VIP
- Pointed resolv.conf at 127.0.0.54
- Restarted NetBird
## Prevention
- Monitor keepalived VIP assignment
- Alert on NetBird peer count drops
Implementation Plan
Phase 1: Deploy Obsidian (Week 1)
- Deploy
linuxserver/obsidianDocker container on casa via Harbor workflow- Or use Obsidian Livesync (CouchDB-based) for multi-device sync
- Or simply use a git-synced vault folder
- Create vault structure (Memory/, Projects/, Templates/, Daily/)
- Migrate existing steering docs into vault
- Set up Forgejo repo
sam/vaultfor git backup
Phase 2: AI Integration (Week 2)
- Kiro steering files → symlink or copy from vault
.kiro/steering/*.mdcan be generated from vault content
- Session logging → After each AI session, save a session note
- Context injection → Before starting work, AI reads relevant vault notes
- Harbor manifest → Lives in vault, updated after each deployment
Phase 3: Automation (Week 3)
- Git auto-sync — Cron job or Obsidian Git plugin pushes to Forgejo daily
- Template automation — Templater plugin auto-fills dates, tags
- AI search — Use Obsidian's Smart Connections plugin or similar for semantic search across notes
- Cross-reference — Link incidents to infrastructure notes, decisions to sessions
Key Plugins
| Plugin | Purpose |
|---|---|
| Obsidian Git | Auto-commit and push to Forgejo |
| Templater | Auto-fill templates for sessions, incidents |
| Dataview | Query notes like a database (list all incidents, open follow-ups) |
| Smart Connections | AI-powered semantic search across vault |
| Kanban | Track follow-up tasks from sessions |
Sync Strategy
Obsidian (casa Docker) ←→ Forgejo (sam/vault)
↕ ↕
Local editing Backup + versioning
(browser via NPM) (git history)
↕
AI reads vault
(steering files / context injection)
Option A: Git-based (simplest)
- Vault lives at
/DATA/AppData/obsidian/vault/ - Cron or Obsidian Git plugin pushes to
sam/vaulton Forgejo - Other machines clone the repo
Option B: Livesync (real-time)
- Deploy CouchDB alongside Obsidian
- Real-time sync between devices
- Still git-backup to Forgejo periodically
Recommendation: Start with Option A. Git sync is simple, reliable, and you already have Forgejo. Add Livesync later if you need real-time multi-device editing.
What Goes Where
| Content | Vault Location | AI Access |
|---|---|---|
| Server IPs, configs | Memory/infrastructure/ |
Steering files |
| Agent definitions | Memory/agents/ |
Agent context |
| Deployment history | Memory/agents/harbor/manifest.md |
Harbor workflow |
| Session logs | Memory/sessions/ |
On-demand lookup |
| Decisions | Memory/decisions/ |
On-demand lookup |
| Incidents | Memory/incidents/ |
Pattern matching |
| Daily notes | Daily/ |
Recent context |
| Project docs | Projects/ |
Project-specific |