cd /news/ai-agents/my-peripheral-brain-the-cold-memory-… · home topics ai-agents article
[ARTICLE · art-35570] src=pub.towardsai.net ↗ pub= topic=ai-agents verified=true sentiment=↑ positive

My Peripheral Brain: The Cold Memory Layer for My Coding Agents

A developer built a cold memory layer for coding agents using a Claude Code skill that automatically creates Jira tickets and saves design documents to an Obsidian vault synced via Google Drive, solving the problem of context loss between agent sessions. The system allows saving and retrieving project context from within the agent workflow without breaking flow, preventing the need to manually reconstruct context or search across separate tools.

read7 min views1 publishedJun 21, 2026

Everyone is building their second brain for their coding agents and rightly so. In the agentic development era, I also found it particularly difficult to keep track of all my in-progress ideas and projects, sometimes too many things are moving at once. Some projects have completed development but are pending thorough testing. Low-priority items keep getting pushed aside to make way for burning items. And somewhere in between, few ideas get lost.

The loss is not dramatic. You do not forget a project exists. You just forget where you left it. You forget what you had decided about the implementation, which edge case you were stuck on, or why you had deprioritized it in the first place. By the time you return, you spend 20 minutes reconstructing context that should have been one read away.

Pre-agentic notetaking approach doesn’t work anymore. Notes created manually, outside the agent context, break the loop. The problem was never the format. Saving happened in one place, work happened in another. Retrieval meant launching a search expedition. Neither felt worth the interruption, so I skipped both. Which meant the context existed nowhere except my head, which is the least reliable storage layer I have.

Coding agents lose context when sessions end. I built a cold memory layer using a Claude Code skill that automatically creates a Jira ticket and saves a structured design doc to an Obsidian vault synced via Google Drive. Save happens at the end of every planning session, one command. Retrieval happens from inside any future agent session, one prompt. Both ends live inside the workflow so neither gets skipped.

I wanted a non-volatile, persistent cold memory layer, something that lives outside the context window but is reachable from within any agent session. A place where I could park:

So whenever I need implementation details for one of my projects, the status of any item, or I need to pick something up from this pool, I have all the information at my fingertips inside the agent session. No searching across artifacts and notes, no digging through chat history, no trying to remember what I named that .md file three weeks ago.

The memory system had to be native to the agent workflow. Both ends of it had to live inside the session.

If saving required me to switch tools, copy context manually, and structure a note on my own, I would skip it when I was in flow. I know this about myself. Every note-taking system I have tried collapsed for exactly this reason. The friction at save time is invisible until it accumulates, and then one day you check your notes and they are two months out of date. The retrieval side had a symmetric problem. If pulling context meant leaving the agent session, searching a separate app, copying something back in, and then re-orienting the agent, the cost was high enough that I would often just try to reconstruct from memory instead. Which meant I was back to the original problem.

Both steps needed to be prompt-shaped. Something I could trigger from inside a Claude Code session without breaking the work.

The workflow came together around a simple trigger: as soon as I am happy with the planning phase for a work item, I ask Claude Code to create a Jira ticket for it with a problem statement and proposed solution baked in. That ticket becomes the canonical record for the work item from day one.

Alongside the ticket, Claude saves the design document or the RCA document for bugs as a .md file and stores it in a Google Drive synced Obsidian vault. Every work item now has two things: a trackable Jira ticket and a human-readable artifact living in my vault.

The repetitive prompt that kicks all of this off create ticket, write doc, save to vault is wrapped into a skill. Once my planning is done, I run the skill instead of re-typing the same instructions every time.

The retrieval side is just as simple. Later in any coding session, I can ask the agent to refer to my Obsidian vault as a brain dump. It fetches the relevant design doc, checks the status, picks up where I left off. The vault acts as the cold memory layer I wanted outside the context window, but fully reachable from within any agent session.

Jira tracks the work item with problem statement and proposed solution. Obsidian stores the design doc or RCA as a .md artifact. Google Drive syncs the vault to the cloud, making the brain portable across machines. A Claude Code skill wraps the save workflow into a single command. Agent retrieval means any Claude Code session can query the vault on demand.

Note: The architecture is tool-agnostic. What matters is that the save side is structured enough for the retrieval side to work cleanly. Tools shown above (Jira, Obsidian, Google Drive) are for reference only. You can use any similar tool of your preference.

I finish a planning conversation with the agent about a new feature. Instead of ending the session, I tell Claude Code to run the memory skill. It creates the Jira ticket, writes the design doc with the decisions we just made, and saves it to the vault. The session ends with the context preserved, not lost.

Three weeks later, I pick up some enahancements on the mentioend feature. I start a new session and ask the agent to pull the design doc for that work item from the vault. It comes back with the full context. The edge cases I already knew about. The approach I decided on and why. The Jira ticket link. I have started implentation within five minutes, not excavating.

For bugs, the pattern is the same. I hit a production issue, investigate, fix it. Before closing the session, the RCA goes to the vault. Next time I see similar symptoms, make changes it the fix or add a new test case, I ask the agent to search the vault for anything related. It finds the RCA from three months ago. That kind of retrieval used to require remembering which Slack thread or which commit message had the relevant note. The design doc is not a transcript of the conversation. It is a structured artifact the agent writes at the end of the planning phase, capturing the key decisions, rejected alternatives, open questions, and next steps.

For feature work, the doc typically includes a one-paragraph problem statement, the proposed solution with the specific approach I chose, any edge cases already identified, and the Jira ticket ID. For bugs, the RCA doc captures the symptom, the root cause, the fix, and any related production context that took effort to discover. That last category is the most valuable one in the long run. The structure matters because retrieval has to work without me guiding it. If I later ask the agent to search for anything related to rate limiting or anything related to the payment processor timeout, it needs enough signal in the doc to find the right file. Vague notes do not retrieve cleanly. Structured ones do.

The only thing that matters in a memory system is whether you actually use it. Most note-taking workflows collapse because the save step is manual and the retrieval step is disconnected from where you work. This one survives because both steps happen inside the agent session.

The vault is not a parallel system I maintain separately. It is something the agent reads in the same session where I am doing the work. The distance between “I need context” and “I have context” is one prompt.

Most people will build a notes system and abandon it because the friction is too high on either end. The ones who keep it running are the ones who made both ends live inside the workflow itself.

If you have a similar setup or a completely different approach to agent memory, drop it in the comments. I’m genuinely curious what others have landed on. My Peripheral Brain: The Cold Memory Layer for My Coding Agents was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

── more in #ai-agents 4 stories · sorted by recency
── more on @claude code 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/my-peripheral-brain-…] indexed:0 read:7min 2026-06-21 ·