Session history and memory for AI coding agents

AR Labs gives its Claude Code sessions a memory that outlasts each session. A Claude Code session forgets everything when it ends or is cleared. Our repository holds the durable knowledge (see a git repository as a second brain), but a lot of useful history lives only in conversations: why a choice was made, what was tried first, what a session was in the middle of. This page is for anyone running coding agents who wants that history back. Three tools turn conversation history into something an agent can query and the planning system can learn from: an event log with search, a link between sessions and tracked work, and a weekly consolidation cycle we call dreaming, after the Dreaming feature in OpenClaw whose design it adapts.

How it works

flowchart LR
    S["Agent sessions"] -->|"hooks"| L["Daily event logs"]
    L --> Q["History search"]
    L --> D["Weekly dreaming cycle"]
    S -->|"link-session"| B["Tracked work item"]
    D --> R["Weekly dream document"]
    D --> C["Strategy agent's review"]
    B -->|"resume by name"| S

Capturing every session

Claude Code hooks (scripts run automatically around an agent's actions, which can block them; Claude Code runs them on lifecycle events such as a prompt being submitted or a tool finishing) write each event of each session to a dated log file on disk, one JSON object per line: every user prompt in full, every tool call and its parameters, every tool result, and every web search. Assistant replies are captured less completely, so session summaries are preferred for full conversations where they exist. The logs sit outside any context window and are read by tools, never loaded wholesale into a session.

Searching history with zero context

The history-query skill lets any session, including one just cleared, answer "did we already discuss this?" or "what did we decide about that?" by searching the logs directly. It chooses between three tools by the shape of the question:

Tool	Used for
Session search	Which sessions mentioned a topic, when, and how often
Topic extraction	The complete thread on a topic, formatted as a readable document with prompts, searches and tool uses
Advanced query	Matches with surrounding turns, date ranges, a single session, or JSON output for further processing

The usual pattern is to start with the quick search to find the sessions, then pull context from only those. For a decision, the skill looks for decision language around the matches and presents the decision with its context, then asks whether that is the one being recalled.

Linking a session to tracked work

We track work in Beads, Steve Yegge's open-source issue tracker for coding agents, which stores its records in git; one tracked task is a bead. The link-session skill (see Beads skills) ties the current conversation to a bead. It records on the bead the session's name and identifier, when the link was made and which terminal the session was running in, and it appends a comment so earlier links are preserved when a session is re-linked. Links go to task-level beads only, never to epics (containers of other beads), because a session works on specific work.

Returning to that work later means looking up the bead, reading the stored session name, and resuming that exact conversation by name, which reloads its full history. A bead can carry several sessions over time, and one session can be linked to several beads. Reverse lookups answer "which bead was this session about?" and "which beads have a session attached?".

The dreaming cycle

Once a week, the Dream skill consolidates the week's sessions into a short memory document, in three phases named after stages of sleep:

1. Light sleep: survey. A script compresses the week's raw logs, typically tens of megabytes, into a signal-dense outline: sessions, the full list of prompts, files touched, sub-agents used and closing summaries. Raw logs are never read into the main session.
2. REM: extract. A sub-agent per week reads the outline and pulls deeper detail on only the most significant threads, reading and releasing rather than accumulating.
3. Deep sleep: score and promote. Each candidate memory is scored on weighted signals (relevance to active work, how many sessions it recurred in, recency, the variety of contexts it surfaced in, how many topics it connects, and novelty). A candidate is promoted only if it clears a score threshold, appeared in at least two sessions and is not already captured.

The output is a weekly document with fixed sections: a short narrative of the week, recurring themes, decisions made, unfinished threads, insights worth keeping, projects active and risks. A synthesis of it, including the decisions already made so the next review does not reopen them and a numbered list of flags, is passed to the strategy agent as input to its weekly review.

We name the design's failure modes: summarisation drift, silent staleness, context poisoning, a pipeline that fails without anyone noticing, and archives that grow without limit. The counters are to keep the survey outline verbatim, cite where every claim came from, and prefer specific detail to compression.

What exists today

Event capture, the three history tools and session linking are in use. The dreaming cycle runs as a skill invoked for a week or a range of weeks, producing one dated document per week and an input to the weekly review.