Observational Memory: Durable Decision Logs Across Context Rotations

Talon’s context-management system has always handled the problem of long conversations: when the transcript approaches the provider’s token limit, the daemon compresses the history into a summary and starts a fresh session. That summary is injected into the new session so the agent never sees the boundary.

The default session-summarizer does this with a single structured blob: key topics, decisions, open questions, relevant facts. It works, but each rotation overwrites the previous summary. After ten rotations, the agent only sees the most recent compression. Earlier decisions are gone unless they were lucky enough to be re-summarized into the current blob.

PR #189 introduces an alternative: observational memory. Instead of overwriting, it appends.

How it works

When you set summarizer: session-observer, each context rotation produces a dated observation entry rather than a replacement summary:

Date: 2026-04-08
- 🔴 20:12 User wants docs updated for PRs #179, #189, and #176
- 🟡 20:18 Existing main worktree has unrelated edits; use a separate worktree
- 🔴 20:31 Providers, memory, and context docs updated together

Each entry carries:

• Priority markers (🔴 critical, 🟡 important, 🟢 informational) so the agent can scan for what matters
• currentTask — what the thread was working on when rotation happened
• suggestedContinuation — what the next step should be

When the observation log grows past a consolidation threshold, session-reflector merges and prunes older entries so the log stays dense enough to keep injecting.

Why append-only is better for long threads

The overwrite model loses information by design. If a decision was made in rotation 3 and never re-mentioned, rotation 10’s summary probably dropped it. Observational memory preserves the full trail. The agent can scan backward through dated entries and see not just what was decided, but when and in what order.

This matters most for:

• Multi-day tasks where the agent works on the same issue across many sessions
• Debugging sessions where the sequence of attempts matters
• Project management where priorities shift and the agent needs to know what is still open

Configuration

Observational memory requires two sub-agents in the persona’s subagents list:

personas:
  - name: assistant
    subagents:
      - session-observer
      - session-reflector
      - memory-groomer
      - memory-retriever

agentRunner:
  providers:
    claude-code:
      contextManagement:
        enabled: true
        triggerMetric: cache_read_input_tokens
        thresholdRatio: 0.5
        recentMessageCount: 10
        summarizer: session-observer

The session-observer sub-agent generates observation entries at rotation time. The session-reflector sub-agent compacts the log when it grows too large. Without both in the persona’s subagent list, Talon falls back to the legacy session-summarizer path.

Ollama and OpenAI-compatible providers

Observational memory is especially useful with cheaper models that need more context help to stay coherent across long threads. The OpenAI-compatible provider (Ollama Cloud, GLM-5.1, etc.) pairs well with session-observer because the dense decision log compensates for a smaller effective context window.

One caveat: Ollama does not currently expose cached token counts, so use triggerMetric: input_tokens instead of cache_read_input_tokens when running through an Ollama endpoint.

Comparison

Mode	Behavior	Best for
session-summarizer	Overwrites one summary blob	Short threads, simple tasks, Claude Max subscribers
session-observer	Appends dated observations	Long threads, multi-day tasks, debugging, project tracking

Migration

Switching is a config change. Set summarizer: session-observer, add the sub-agents to the persona, and restart the daemon. Existing memory items are not converted — the new mode takes over on the next rotation. You can switch back to session-summarizer at any time by reverting the config.

For the full configuration reference, see the Context Management guide.