title: "Your agents forget everything between sessions. Here is the fix." slug: "agents-forget-everything" dek: "Every AI session starts from zero. The fix isn't a smarter model — it's one shared company memory in git that agents read and write as diffs." audience: "Solo founders and tiny teams running their company with AI agents" tags: [ai-agents, git, memory, founder-tools, infrastructure]

The same conversation, every morning

A founder on r/AI_Agents asked the question plainly: "has anyone actually solved the memory problem". Not which vector database to use — whether anyone has actually solved this, in production, for real work. The replies are the usual grab bag: RAG pipelines, nightly summarization jobs, a folder of markdown someone calls a "context vault," embeddings with a decay function bolted on. No consensus. Everyone is patching the same hole a different way.

Over on r/ClaudeAI the complaint gets more specific: "your AI coding agent forgets everything about you" — every session, you re-explain your stack, your conventions, the decision you made last week and why. Switch from Claude to GPT to Gemini mid-project and you lose even the context you built up that same day. Close the laptop for the weekend and Monday starts from zero.

IndieHackers has the same conversation under a different title: how do you handle the fact that your AI forgets everything between sessions. Across all three threads the pattern repeats — someone hand-rolls a MEMORY.md, pastes it into every new chat, and hopes to remember to keep it updated. It works until the file drifts from what's actually true and nobody is sure which copy is current. One reply on that IndieHackers thread said the quiet part out loud: "You wouldn't code without git. Why would you use AI without persistent state?"

That's the real diagnosis. The problem was never context window size. Code has a durable, versioned record of itself that every tool and every person reads and writes through the same mechanism. AI agents working on your company have no equivalent. Each one keeps its own private, lossy notion of what's going on — if it keeps one at all.

What "shared memory" actually means

Lycato's answer isn't a cleverer retrieval algorithm. It's a place: one git repo per company, plain markdown, checked in like code. A local CLI (lycato) and a local web Cockpit sit on top of it, but the substrate underneath is files you could cat from any terminal:

Every agent you point at the company reads this repo before doing anything, and writes back to it the way a developer writes code: as a diff. Because it's plain markdown in a repo you host yourself, the memory isn't tied to whichever model you used to write it. Switch from Claude to GPT to Gemini next quarter and the record doesn't move with a vendor — there's nothing to export, no import script that has to map your schema correctly.

The write path is the actual mechanism, not a footnote. An agent doesn't get a background channel to edit your company's memory. It proposes a change — a diff against decisions.md, a new ledger row, an edited KPI snapshot — and that diff sits until a person looks at it. You review it the way you'd review a pull request. You merge it, edit it, or reject it. Nothing lands in shared memory unreviewed.

--- a/decisions.md
+++ b/decisions.md
@@ -12,3 +12,6 @@
 ## 2026-06-30 — Switched payroll provider to Gusto
 Reason: Rippling delayed onboarding twice. No hard blocker, just slow.
+
+## 2026-07-06 — Paused paid ads
+Reason: CAC rose above target for two straight weeks. Revisit after landing page rewrite ships.

That's what a proposal to the decisions log looks like. Once it's merged, the next agent that reads decisions.md — next week, next quarter, on whatever model you're running by then — sees the same decision, in the same place, with the same reasoning attached. It isn't re-derived, re-summarized, or quietly dropped between sessions. It's just there, the same way code you wrote six months ago is just there in the repo.

What this doesn't fix

Worth being direct about the limits. A shared git memory doesn't make agents smarter, and it doesn't remove the need for review — if anything it makes review a permanent, explicit step. Lycato does not let an agent commit to the company repo unattended. That's deliberate. If you want zero-touch automation, this is the wrong tool.

It also won't structure your business for you. decisions.md only helps if decisions actually get written there instead of living in your head or a Slack thread no agent can see. The system gives you a place to put things and a mechanism for agents to propose changes to that place. It doesn't enforce the discipline of using it.

And it doesn't replace the specialized systems underneath. Adapters pull from Mercury, GitHub, Stripe, Plain — the memory layer doesn't replace your bank or your issue tracker. It's the layer that remembers what those systems meant to you at the time, which the source systems themselves were never built to track.

The takeaway

The forgetting problem isn't a model limitation you wait out until context windows get bigger. It's an architecture gap: no durable, shared, versioned place for a company's operating memory to live, that both humans and agents read and write through the same mechanism. Git already solved durable, shared, and versioned for code. Fixing agent memory doesn't need a cleverer retrieval system. It needs the same substrate, and the same review discipline, applied to the rest of the company.