Memory and State

Memory is what makes agents feel intelligent across interactions. Without memory, every conversation starts from zero. With the right memory architecture, an agent gets better over time.

Memory Taxonomy

Short-term Memory

The current conversation. Everything in the context window. Disappears when the session ends.

Examples: the current chat messages, tool call results, intermediate reasoning.

Working Memory

Information loaded for the current task but not generated in this conversation. Pulled from external sources.

Examples: when Claude Code reads your knowledge/projects.md to understand Comfama's context. The file existed before the conversation — it's loaded as working memory.

Long-term Memory

Persistent across sessions. Survives restarts. Forms the agent's accumulated knowledge.

Examples: your CLAUDE.md, soul.md, knowledge/ directory, memory graph. These persist and shape every future interaction.

Your Workspace IS a Memory Architecture

Look at what you've built:

Short-term:    Current conversation with Claude Code
Working:       knowledge/ files loaded per task
               Obsidian notes pulled for context
               Calendar events checked for prep
Long-term:     CLAUDE.md (rules, behaviors)
               soul.md (identity, values)
               knowledge/ directory (domain + procedural)
               Memory graph (entities, relations)
               Obsidian vault (279+ meeting notes)

This isn't accidental. You've built a multi-layered memory system. The insight: your knowledge/INDEX.md → progressive loading pattern is a memory retrieval system. It decides what to load based on the task, not dumping everything into context.

Memory for Multi-Agent Systems

When multiple agents share work, memory coordination becomes critical:

Shared database: All agents read/write to the same store. Simple, but watch for conflicts. Example: a Supabase table where Agent A writes data and Agent B reads it.

Message queue: Agents communicate via structured messages. Agent A finishes and puts a message on the queue. Agent B picks it up. No conflicts, but adds latency.

File system: The simplest shared state. Agent A writes to a file, Agent B reads it. Your Obsidian vault works this way — the post-meeting skill writes, the prep skill reads.

What to Remember, What to Forget

Not everything should be memorized. A good memory system:

• Remembers patterns, preferences, corrections, relationships between entities
• Forgets (or archives) specific conversation details, debugging traces, intermediate computations
• Updates outdated information rather than accumulating contradictions

Your knowledge/ERRORS.md does this well: deterministic errors get concluded immediately, infrastructure errors get logged and pattern-matched over time. Conclusions graduate into the relevant knowledge file.

The anti-pattern: saving everything. An agent with 10,000 memories is slower and more confused than one with 100 well-curated memories.