The session crashed and I lost three weeks of in-RAM context, right before flying out to Milan. When I came back four days later, I had two hours to figure out where I had left things before a customer call. What saved me was not memory in the human sense, and not chat history either. It was a hundred small markdown files and a dozen versioned skills.
This is the part of working with an AI that nobody tweets about. Not the model, not the prompt, not the agent. The notebook. The thing the model reads before it reads your message.
What we used to do
Before, every conversation with an AI was a fresh start. You opened the chat, you pasted in the relevant files, you re-explained who the customer was, what version of Odoo was in production, why the last patch had to look the way it did. Twenty minutes of re-loading context before any actual work. And the moment the chat closed — by accident, by overflow, by network blip — all of that was gone. Again.
Senior consultants of any kind have always worked around this with notebooks, wikis, project files. The good ones spend half their week writing things down so the other half can move fast. With Claude Code we just made the notebook native: two layers of persistent context that the AI loads automatically before every session.
Layer one: memories
Memories are the unstructured ledger. One markdown file per learning, all under a single folder, indexed by a file called MEMORY.md that the AI reads at the top of every conversation.
A typical memory looks like this:
--- name: livekit-sip-zadarma description: Three bugs we hit on day one of the Maria deployment type: feedback --- When connecting livekit-sip to a Zadarma trunk behind home NAT: 1. status=486 reason="flood" does NOT mean rate-limited. It means the inbound INVITE matched no trunk and the policy is Drop. Fix: trunk must filter by source IP, not by number. 2. nat_1_to_1_ip AND media_nat_1_to_1_ip are both required. use_external_ip is mutually exclusive — pick one. 3. The Zadarma SIP URI user does NOT need to be the phone number. Filtering anywhere on it produces silent drops.
That file took fifteen minutes to write the day it cost me three hours of debugging. It will never cost me three hours again, on any project, ever — not because I will remember (I won't), but because the AI reads it every time I touch a SIP problem.
We have a hundred of these. Some are durable: how to deploy Odoo modules in production without breaking translations, what the legal regime is for a Spanish autónomo, how to wire a payment gateway in es_ES context. Some are ephemeral: who I am working with this week, what a particular customer prefers in their POS receipts, where the SSH key for a specific container lives.
The discipline is small but real: any time the AI and I solve a problem that took more than half an hour, one of us writes a feedback memory. By the next time, neither of us has to remember it consciously — the notebook will hand it back at the right moment.
Layer two: skills
Skills are the structured layer. Where memories are "what we learned", skills are "how we work". A skill is a small package of files — a manifest, an entrypoint, references — that teaches the AI a complete domain: how to deploy an Odoo container, how to audit an ICT engineering project, how to talk on the phone as the receptionist of Lemon Tree Cloud.
We currently maintain about thirty skills. A few illustrate the range:
oca-expert— knows the 2,985 OCA addons available for Odoo 16. When a customer asks "is there a module for X?", the AI invokes this skill and answers in seconds.oci-creator— knows how to deploy a fresh Odoo container on Proxmox with the right localization, the right tax setup, the right post-deploy checklist. New customer in a new vertical takes a day, not a week.voip-expert— the technical playbook for any inbound voice AI agent: SIP trunks, NAT traversal, voice/STT/TTS choices, call recording into the CRM. Reusable for any future client, not just for us.maria-ltc— created this week. The personality and business layer of our own voice agent: who Maria is, what services LTC sells, how she escalates a hot lead to me by Telegram during a call. Pairs withvoip-expert: technical playbook + business identity.
Skills live in git, alongside the rest of our code. They are versioned, they are diff-able, they are reviewable like any other artefact. When we improve a skill, the change is visible to every project that uses it — including future ones we have not started yet.
The split between voip-expert and maria-ltc matters. The first is reusable: any customer who wants their own voice AI can adopt it as is. The second is specific to us, and we will never share it. Keeping them separate is the difference between a consultancy that resells one product and one that builds a product per customer on a shared foundation.
The third leg: Odoo
Memories are what we learned. Skills are how we work. The third leg is what we did, and that lives in Odoo.
Every meaningful piece of work — a new module, a deployment, a customer audit, a blog post — opens an Odoo task. The chatter of that task collects every commit, every report, every screenshot, every note. The AI is set up to read those tasks too: when it does not know the state of a project, it queries Odoo, reads the latest chatter messages on the relevant task, and resumes from there.
This is the leg that turns AI sessions into a business. Memories sit on a developer machine; skills sit in git; Odoo sits where the customer can see, where invoices live, where engineers and accountants and Maria all share the same source of truth.
The two-hour reconstruction
So back to the laptop after Milan. The session was dead, the chat history gone, the previous in-flight tasks unfinished. What I actually did to recover:
- Opened a fresh Claude Code session. The AI loaded
MEMORY.mdautomatically — five seconds of indexing. - Asked it: "What was the state of the voip-agent project as of last week?". It cross-checked memories tagged
voip-expert, the skill of the same name, and the open Odoo tasks under project Varios. Reply in under a minute, with citations to specific files. - One of the open tasks pointed to a draft of a new business-layer skill that we had discussed but never built. We built it together in ninety minutes — the next time the conversation crashes, the new skill will already be on disk and in git.
What did not happen: I did not have to re-explain the Zadarma three-bug story. I did not have to re-list LTC services. I did not have to remember which Odoo project ID the tasks lived under. The notebook had it all.
Why this matters for an SME consultant
If you sell hours of expertise, the worst time of your week is the first half hour after a meeting, when you have to re-load the context of every other open project. If you adopt AI without persistence, you have automated nothing — you have just moved the re-loading to the chat window.
If, instead, every meeting closes with a one-line memory, every recurring workflow gets packaged into a small skill, and every customer outcome lives in Odoo, then the value of your consultancy stops depending on whether you remember things. It depends on whether you wrote them down. The AI does the rest.
For us, this stopped being a productivity hack and started being the actual product. We sell open-source IT consultancy that does not cost what Salesforce or SAP cost — and we are able to charge less because the cost of running each customer drops as the notebook grows. Every memory written is a future hour saved across every customer that touches that domain. Every skill committed is a deployable capability we did not have last week.
If you are running an IT consultancy of any size, the question worth asking is: what is your team's notebook, and is it on a shared shelf? If it is in everyone's head, that is the most expensive single fact about your business.
We picked Claude Code because the notebook is part of the tool — not a feature you bolt on, but the substrate. But the principle is older than any AI: the difference between an expert and a beginner is not what they know, it is what they wrote down.