Remembering why
How do decisions, evidence, and intent survive agents, branches, and time?
A session log explains what happened. A task graph explains what remains. Neither automatically preserves why a consequential decision was taken.
What do we need to remember after the agent leaves?
Carry context across runs
Retain information that would otherwise vanish as agents, tasks, and sessions turn over.
Trade-off: Persistent context can become stale or contradictory.
The comparison: a task graph records commitments; session history records activity. Decision rationale needs another layer.
WHAT TO WATCHTasks reopened because a dependency was forgotten.
What practitioners say
Everything on remember in the research log →3.25.6 field report: daemon ↔ MCP last-writer-wins still drops MCP-session writes
github.com · Comment on issue #2621, The write drop is reproducible in ~30 lines
“Every one of the 50 writes returned success: true, and the DB stays integrity_check: ok. One process's entire batch was obliterated.”
Two processes wrote 25 rows each; all 50 writes were acknowledged and 25 rows remained. The test forced the sql.js fallback path, so it doesn't apply to every backend. The remaining race moved to #2878, closed in August 2026.
- Remember
Agent pull requests are everywhere. Here’s how to review them.
github.blog · 2. Code reuse blindness
“The cost of leaving duplicated logic is that agents will find it as prior art and replicate it further.”
An agent’s local context misses what already exists elsewhere in the repository, so duplication compounds.
- Remember
AgentDB (sql.js) corruption: 185MB memory.db malformed under concurrent daemon+MCP writes
github.com · Issue #2584, Summary
“This is a data-durability bug in the AgentDB persistence layer: a long-running store should not be one interrupted/concurrent flush away from total loss.”
A shared memory database with about 16,700 entries became unreadable, then broke again about half an hour after a restore. PR #2585 added atomic flushes; cross-process locking was left for later.
- Remember
Building an Autonomous Engineering Org - Angie Jones, Agentic AI Foundation
youtube.com · Angie Jones · from 14:52
“the agents need to understand where everything lives and what depends on what. So, we built a company world modeled based on the entirety of our 25,000 repo code base”
Alongside it, Block built its own orchestrator, Builder Bot, to coordinate the agents. Quoted from YouTube’s auto-generated captions.
- Remember
- Coordinate
daemon-state.json write-race: background daemon flush overwrites runCount increments
github.com · Issue #1637, Summary
“Persisted state after the background flush shows runCount=432. This creates the misleading impression that the CLI trigger did not execute, when in fact it did.”
Two writers for the same state make finished work look undone. Fixed by PR #1655 in v3.5.82.
- Remember
Devin’s 80% Moment: Background Agents, 7x PRs, & End of Hand-Held Coding — Walden Yan & Cole Murray
youtube.com · Walden Yan, Cognition · from 45:53
“I think we found that the state-of-the-art in December was you could probably run this for about two weeks. By the end of those two weeks, you’d find that, hey, you want to like change a color of a button. Well, turns out this button is implemented in like 10 different places”
An internal experiment: agents building on each other’s work with auto-merge and no code review. The speaker is inferred from context; quoted from YouTube’s auto-generated captions.
- Remember
- Verify
Durable state anchored to raw process.cwd(): agent cwd drift silently resets autopilot/neural/metrics/memory
github.com · Issue #2633, Summary
“The result is that state is written to whichever subdirectory the session drifted into, and then never read again. Nothing errors.”
On one 12-repository workspace this left 109 state directories (97 stray) and about 25 daemons. Fixed in the reporter's fork; the upstream issue is still open. A 2025 issue (#765) describes the same root cause.
- Remember
- Isolate
Effective harnesses for long-running agents
anthropic.com
“The core challenge of long-running agents is that they must work in discrete sessions, and each new session begins with no memory of what came before. Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.”
- Remember
Fix: Agents creating duplicate .claude-flow and .swarm folders in subdirectories
github.com · Issue #765, Problem
“Agents are creating duplicate .claude-flow and .swarm folders in subdirectories instead of using the main workspace root folders.”
An early sign of sessions quietly no longer sharing memory. The v2 code it describes is gone, though the issue is still open.
- Remember
Gas Town, Beads, and the Rise of Agentic Development
softwareengineeringdaily.com · Transcript, 0:15:01
“There's a JSON file, one line per issue, and it has merge conflicts all the time, and it gets xlerped into the database, and there's a daemon, and it gets stale.”
This describes the early Beads storage, which the move to Dolt replaced. It isn't how Beads works today.
- Remember
- Coordinate
Gas Town, Beads, and the Rise of Agentic Development
softwareengineeringdaily.com · Transcript, 0:28:41
“It's so wild because like 8 out of 10 get done, and 2 out of 10 get lost.”
A rough personal estimate. In the same answer he says lost designs sometimes have to be redone from scratch.
- Remember
Gas Town: from Clown Show to v1.0
steve-yegge.medium.com · Beads: Ready for v1
“The inherent fragility of the v0.x Beads architecture, with its bidirectional sync, 3-way merge, two sources of truth, race conditions, and tombstone hell — that's all gone now.”
- Remember
Harness engineering: leveraging Codex in an agent-first world
openai.com · Entropy and garbage collection
“Our team used to spend every Friday (20% of the week) cleaning up “AI slop.” Unsurprisingly, that didn’t scale.”
Agents copy whatever patterns already exist, so drift compounds. The replacement for the Friday cleanup was recurring agents that open small refactoring PRs.
- Remember
I put Temporal around my software factory. Here’s what it fixed, and what it didn’t.
medium.com · Pull quote under the subtitle
“A durable work record is not the same thing as a durable procedure.”
A task that survives a crash in the tracker can still lose the process working on it. She has contributed hundreds of PRs to Gas City and runs it on itself.
- Coordinate
- Remember
memory_retrieve serves stale or deleted values when two MCP servers share a store (per-process cache)
github.com · Issue #3360, Summary
“When two ruflo MCP servers share one memory store, memory_retrieve on one server keeps returning a value after the other server has updated or deleted it.”
Shown with a two-process reproducer: a per-process cache served old values for up to five minutes while the database held the right one. Fixed by PR #3361 in September 2026.
- Remember
The Tower Keeps Rising
lucumr.pocoo.org
“Each change can be reasonable in isolation but since it’s frictionless, none of us necessarily has to talk to the others or familiarize ourselves with the code we are changing.”
The friction that used to force people to coordinate is gone. In his words, construction can continue after shared understanding has already collapsed.
- Coordinate
- Remember
Welcome to Gas Town
steve-yegge.medium.com · WARNING DANGER CAUTION
“Some bugs get fixed 2 or 3 times, and someone has to pick the winner. Other fixes get lost. Designs go missing and need to be redone.”
- Coordinate
- Remember
worker-daemon.js:saveState() race on a shared .tmp filename
github.com · Issue #2782, Relationship to #1637
“the maintainer's fix prevents cross-process corruption, but does not prevent two saveState() calls within the same process from racing on the shared <file>.tmp name.”
The fix for the run-count race introduced a new one: about 56,000 errors in one daemon log. The damage was log noise, not lost data. Fixed by PR #2788.
- Remember
Tools filed under remember
- agent-memory-engineA local MCP server that gives coding agents persistent project memory: architecture, constraints, past incidents and source context retrieved before complex tasks.
- agentdiffRecords which AI agent wrote which line, signs each attribution and stores it in the Git history.
- agenticowCopy-on-write branching for vector memory, so many agents can fork a shared memory base cheaply and query their own edits on top.
- CASCoding-agent system exploring continuity and traceability of work.
- cgxTurns a Git repository and its history into a queryable knowledge graph, served to agents over MCP.
- codecontextInline annotations for constraints and the reasons behind code, enforced by linting and freshness checks so later agents must read them.
- CodeGraphXA local code graph engine and MCP server that answers structural questions such as blast radius, dependency cycles and whether a symbol exists.
- Context Delta EngineBuilds inspectable, replayable context packets for coding agents, local-first.
- Engram MCPMemory infrastructure for context that needs to survive sessions.
- EntireKeep context around agent-generated work and coding sessions.
- GrapePackages repository context so agents stop rereading the same files, rules, decisions and failures across chats and tools.
- groundcrewRetrieval-augmented "chat with your code" over a repository, for maintenance, documentation and onboarding.
- MemforksBranch-aware shared memory for agents, with merge policies and recorded provenance for resolutions.
- qarinahCited project memory shared across coding agents: decisions, code relationships, tool outcomes and worktree history, handed to each new session.
- RookeryAn approach to preserving and organizing agent-work context.
- TreeWorkA tree-guided workflow skill that keeps a long-running agent's plan and decisions visible across sessions and handoffs.