Denny Sam

From Goldfish to Engineer: Designing an AI Assistant That Remembers

Submitted Oct 9, 2026

One-line summary: AI coding agents are brilliant for work but they forget things fast. Months later, nobody remembers why a fix/change was made. This session shows how we extended Claude Code’s built-in memory with a git-versioned task tracker, per-task detailed MD files and deterministic scripts, so any piece of work can be traced back months later.

What problem are you addressing?

A bug surfaced in December 2025, we fixed it and moved on. Months later the same bug came back. The engineer who wrote it had moved on, nothing was written on Jira, and Claude, which helped write the fix, remembered nothing.

The same loss happens daily at a smaller scale. Every new session starts with no idea what you were working on or where you left off. You either carry that context yourself or pay tokens and time for the agent to re-scan the repos. Also task and due-date tracking lives in a separate system.

Claude Code already has its own memory mechanisms, but they have their issues:

Barely configurable: you can’t say where a memory should live.
Not traceable: finding one means walking through all the prior created memory files.
Search is grep: keyword matching with no surrounding context.

Who is the intended audience?

Developers, Platform engineers who are using AI coding agents day to day

Level: Beginner

Practical takeaways

  1. Don’t fight the memory, extend it. Build on CLAUDE.md and auto-memory instead of replacing them.
  2. The ladder: Ask if a script can do it? If not, a skill? Only then, a prompt.

What will you share?

Architecture: Beads, a graph-based issue tracker built for coding agents and backed by Dolt (a git-versioned SQL database), used as Claude’s structured memory.

Implementation details: the CLAUDE.md rules and scripts that make this automatic. Claude creates and closes beads, flushes context before switching tasks.

Live demo:
Will show a demo of how it works on a live project (sandboxed to avoid leaking project details)

What is your experience with this problem?

Production system (daily use since March 2026)

What approaches failed, disappointed, or created unexpected problems?

  1. Plain markdown plans and todo files were not effective in terms of tracking tasks. They were replaced by beads plus story files.
  2. Relying on prompts alone to get the task done, instead of using scripts wherever possible.

What will you do differently today?

Apply the script → skill → prompt ladder from day one instead of starting with prose rules.

What trade-offs did you consider?

  1. Extend vs replace built-in memory: we chose to extend it. Working with the grain of CLAUDE.md and auto-memory helps; a parallel memory system would fight them.
  2. Beads vs markdown plans vs Jira-only: beads gives structured, scriptable and searchable records with git-style history. Markdown plans don’t scale or search well. Jira is client-facing, so internal working notes may not belong there.

How can this help other practitioners?

This will help other harness users as well (like Cursor users) if they take the principles and apply it on their end.

Current state

Production experience: in daily use since March 2026 on a client data platform, and shared with the team as a plugin

Tags

#developerworkflow #agents #platformengineering #aimemory #demo #devex

Comments

{{ gettext('Login to leave a comment') }}

{{ gettext('Post a comment…') }}
{{ gettext('New comment') }}
{{ formTitle }}

{{ errorMsg }}

{{ gettext('No comments posted yet') }}

Hosted by

We care about site reliability, cloud costs, security and data privacy