External Memory Series: A Practical Guide to AI Session Continuity

Every AI session starts cold. The model does not remember your deploy rules, your product boundaries, or what you decided last Tuesday. Vendors sell longer context and product memory; both help. Neither gives you an inspectable, portable system you own when tools change.

This page is the hub for the External Memory series: a file-based approach I use for production software (AI as primary implementer), personal productivity, and program governance. Read it first for the map; then dive into the part that matches your role.

Who this series is for

Reader	Start with
Developers and eng leads shipping with agents	Part 1 — AI-first development
Anyone using multiple AI tools for life and work	Part 2 — Personal productivity
People comparing approaches (STM / LTM diagrams)	Part 3 — Why files beat the diagram
Program owners, leads, audit/compliance	Part 4 — Deliberate file memory

Background on this site: The AI Memory Problem (tool landscape) · Your Brain Was Not Built for This (why Obsidian) · What I Learned Directing AI as My Primary Engineer (leadership angle) · Publishing Obsidian Drafts (how these articles reach petralian.com)

The problem in one paragraph

When people say the AI forgot, they usually mean one of three things: no session thread from yesterday, no operational record of open loops and deploy state, or no conceptual truth for what the product is allowed to do. A bigger context window only expands short-term buffer. It does not replace handoffs, evergreen notes, or rules that survive tool churn.

The four layers (map of the series)

flowchart TB
  L1[Layer 1 — Chat and session]
  L2[Layer 2 — Operational handoffs]
  L3[Layer 3 — Evergreen product and life notes]
  L4[Layer 4 — Rules hooks and feedback]
  L1 --> L2
  L2 --> L3
  L1 --> L4
  L4 --> L1
  L3 --> L1

Layer	What it holds	Where it lives
1 — Short term	Current chat, todos, live repo state	In the tool
2 — Operational	Resume next session: summaries, bridge, NEXT_SESSION	Obsidian `Operations/` + repo handoff files
3 — Evergreen	What the product or domain is	`Features/`, `Architecture/`, `00_Brain`
4 — Feedback hardened	Lessons that must not repeat	Agent instructions, hooks, session footer

Part 1 walks through implementation—including session-start hooks and git post-commit updates to Feature notes (reference stacks: Gravio, petralian.com). Part 2 applies the same logic to strategic initiatives, client work, and your task app—not only code. Part 3 argues why this is different and often better than the popular three-circle STM/LTM/feedback diagram. Part 4 covers audit, solo shipping, teams, and tool churn.

How the parts connect

Three Layers of External Memory for AI-First Development — The builder playbook: bootstrap order, Obsidian dual vault, automation at session start and commit time.
Beyond Chat History: Layered Obsidian for Personal Productivity — Same architecture when the output is a decision or a cleared queue, not a deploy.
Why File Memory Beats the Three-Layer AI Diagram — Better, different, or worse—and when chat-only memory is enough.
Why Deliberate File Memory Beats Hoping Agents Remember — Audit trails, governance, and feedback that writes files—not vibes.

What you can do in one afternoon

Without the full stack:

Add a ten-line NEXT_SESSION.md to one active repo (priority, open loops, next three steps).
Add Operations/Session Summaries.md in Obsidian with one line per work block.
Paste a session-end footer into your agent instructions (deploy state, files changed, next priority).

If session four needs less re-explanation, add Part 1 automation next—not more notes.

Reader action

Pick your role from the table above and open one part. If you are unsure, read Part 3 for the philosophy, then Part 1 for the mechanics.

When all four parts are published, this hub stays the entry point—bookmark it, link your team to it, and treat the series as a single curriculum rather than four isolated posts.