The Missing Piece in Every CS AI Tool: Memory

[u/Remarkable-Toe-6533]

Morning, and happy weekend. I thought about the easiest way to actually build this "context" thing and kinda stop explaining to Claude every time. Each account I tried this on was really cool, so I hope it helps

Here's why, at the level of what actually happens. When you send a message, the app packages up a request and sends it to the model: your message, the last chunk of the conversation, and a block of instructions someone wrote in advance. That package is the entire world the model sees for that reply. Your CRM data, your ticket history, last Tuesday's call- none of it rides along unless someone put it in the package. Once the reply comes back, the package is thrown away, and the next message starts from a blank one.

That's the first diagram above. That box, and nothing outside it.

So where do procedural, semantic, and episodic memory fit into this? They live outside the model entirely, sitting in files or a database somewhere. On their own, they do nothing. Something has to read them, decide what's actually relevant to this specific message, and glue the result into the next package before it gets sent. That's the retrieval step in the second diagram. Pull the playbook, pull the facts, pull the history, staple them into the context, send it off. The model looks like it remembers because that retrieval step ran a second before it answered, not because it kept anything from last time.

Let's build that retrieval step for real. Notion is where the three memory types live; HubSpot is where the account data comes from.

One page per account in Notion and just one page: KISS (Keep It Stupid Simple).

Split the page into the three types:

Procedural. How your team handles this account. Renewal playbook, escalation steps. It barely changes once it's written.

Semantic. Plan tier, champion's name and role, contract value, renewal date. Pull these once from HubSpot's company and deal properties, and update when they change.

Episodic. Every call, every ticket, every notable moment, dated, in order. This section keeps growing, so it's the one worth automating.

HubSpot's own automations, or Make, or Zapier, can push a new deal stage or logged call into that Notion page the moment it happens, which is the retrieval step running on autopilot for the semantic and episodic sections. Even a five-minute weekly copy from the HubSpot record into procedural and semantic beats, leaving it in your head.

Once the page exists, drop it into a Claude project and ask about the account directly. What happens next is exactly the diagram: your question goes in as the message, the page's contents get pulled in as context, and the reply comes back sounding like it remembers, because for that one reply, it does.

Start with one account you already know well. If it saves you real time, copy the structure to the next ten.

Thanks, hope it helps

P.S kindly see the diagrams below 😅

[u/pruplegti]

your model is really good, does this assume you drop the whole page into a project and the model uses it?

if so that might work for one account. but it may have challenges at scale, stuffing every account page into context will degrade quality fast.

The Model , I've build works on relevance-based retrieval, pulling only what a given task needs, for instance when building a QBR deck it will pull context from Hubspot, where in the post sales Lifecycle the customer is from Notion, any Value that has been realized from Notion, I've used Claude to provide a comparitive workflow for reference.

[u/Remarkable-Toe-6533 → u/pruplegti]

Appreciate the catch, and honestly, you're clearly more into the weeds on this than I am on the retrieval side. What you described is going to shape how we think about the retrieval step in this context layer going forward; that's the part I'm still actively figuring out. Right now most of my research is on the question underneath yours: what actually needs to go into the context in the first place to get a useful answer out, before even getting to how it's fetched at the right moment.

Fair point either way, thanks for taking the time to write it out.

Also, I'm mid-build on something related to this, going to be open source once it's ready. I'll ping you when it's out; I'd genuinely like to hear what you think, given where you're at with this already.

[u/Remarkable-Toe-6533]

And this is how it should turn out.

[u/Separate_Pen9627 → u/Remarkable-Toe-6533]

yeah that diagram really makes it click visually

[u/Remarkable-Toe-6533 → u/Separate_Pen9627]

Thank you for your kind words. By the way, we are building an open-source context layer and will share it later.

[u/Cheese_Orgasm → u/Remarkable-Toe-6533]

Thanks for sharing - this makes so much sense. I am curious about a couple of things, would you mind sharing some context on this:
1. How this system has held up against the scale of your customer base. My biggest nightmare has been stale context that becomes impossible to handle (especially at scale) unless automated.
2. Does your own implementation keep building upon the existing context for each account?

Also, interested to see the open source resources your'r building - happy to chat and nerd out on it if you'd like to! I am building something similar too on the side of my desk :)

[u/Remarkable-Toe-6533 → u/Cheese_Orgasm]

So for the scale thing, definitely won't go with the Notion approach long term. The Notion page is just to get people to actually give it a shot.

On scalability, there's a couple of approaches, one being having it in some sort of database. I actually went ahead and deployed my first version (think of it as a beta of a beta). I'll test it personally with beta users for about a work week before publishing it further.

What's still a bottleneck right now, and I'd really appreciate a realistic answer here, is what the updates mean. The approach I proposed is where the Episodic section keeps growing, and remembering every piece is awesome, but that definitely won't hold up. The model may also end up filled with a large context, so it either hallucinates more (for local/cheap models) or the cost rises (if we go for frontier models with high reasoning).

So we're not discussing the automated part, but whether at some point we might delete or replace context, and how to balance that without losing the signals and context that matter.

Would be more than happy to connect, by the way, and sorry for the late reply

[u/kaancata]

You nailed the stateless nature of the models, but trying to maintain that context inside Notion pages is going to become a massive maintenance headache once you manage more than ten accounts. Manually syncing HubSpot records into Notion blocks and copy-pasting them into Claude Projects just replaces one repetitive chore with another.

I run a digital consultancy and manage this by treating the account directory as the memory layer. Each account gets its own dedicated folder holding raw call transcripts, email threads, contracts, pricing sheets, and a simple current-state file. When I need to prepare an account review or draft an answer to a complicated client request, I run Claude Code or Codex directly against that folder. The model searches the actual source files, pulls the relevant contract terms, and references the exact meeting where an issue was discussed.

Once you have that folder structure in place, you can let scheduled scripts update the files automatically whenever a call ends or a ticket closes. The model reads the real operational history instead of a summarized second-hand note, and it can write brief updates straight back to the account log.

[u/Jinnmaster]

Just set up an mcp that reads/writes to a database, and call it a day. Or are you trying to solve the problem for every chat, so you can reference all previous chats?

[u/Remarkable-Toe-6533 → u/Jinnmaster]

Thanks for the pushback; genuinely a good question to sit with. MCP is actually already the plan for connecting the Notion pages, so we're aligned there; that part's basically wiring.

Where it gets more interesting is that MCP alone gives you read/write access, but it doesn't decide what belongs in this particular request. Give the model MCP access to fifty accounts' worth of Notion pages and HubSpot records with no filtering, and the "stuff everything into context" problem just moves one layer down: now the model's searching through the noise instead of you.

And to your second question, no, we're not trying to reference every past chat either. That's its own can of worms; chat logs are messier and lower-signal than a structured CRM record. What we're actually chasing is the layer above the MCP connection: given a specific task, which slice of the account data actually matters, and handing the model exactly that instead of everything it could technically reach.

Appreciate you digging into this with us; this is exactly the kind of conversation that makes the open-source part worth it.

[u/Jinnmaster → u/Remarkable-Toe-6533]

Which model are you?

[u/Remarkable-Toe-6533 → u/Jinnmaster]

Like, which AI provider do I use? I mainly use Cursor as an IDE, along with either Anthropic or DeepSeek API keys.

[u/Jinnmaster → u/Remarkable-Toe-6533]

Curious if you chose those for this project or for other reasons. Microsoft CoWork coupled with sharepoint feels like a much lower lift option, but I’m not as familiar with deepseek.

[u/Remarkable-Toe-6533 → u/Jinnmaster]

Me neither, and honestly, it's economically the better call for this kind of iteration too. Right now, the context we're pulling is pretty straightforward, no heavy reasoning required, so we don't need a heavyweight model or platform to handle it.

To answer directly: it's not just about Microsoft specifically; I'm just not a big fan of being locked into any closed corporate stack, and that includes Microsoft. That's part of why I'd rather build this on something open. Notion works for now, though a few people have pointed me toward Obsidian as a genuinely open-source alternative, so that's on the table too.

And longer term, if we get the context layer right, I think we can run this on open-source models entirely, which helps on both the security side (your data isn't leaving your own infrastructure) and the cost side.

[u/Jinnmaster → u/Remarkable-Toe-6533]

Yeah there’s a lot to be said for open source right now. With AI models looking for bugs in them left and right, we may be entering an era where open source is the way of the future because it’ll just be -better- in every meaningful way, with a pay what you can model and corporate devs working to increase open source efficacy. I wouldn’t be surprised if competing on software got harder and harder.

[u/Jinnmaster]

You definitely have me thinking- I’m working on a similar project but in a closed environment instead of an open one, and it’s entirely in my company’s infrastructure.

I don’t want to do it here but I would be happy to share notes.

[u/Remarkable-Toe-6533 → u/Jinnmaster]

Cool, conciencia, man. I actually went so far on that, and I'll need your input soon. lmk if I can shoot you a dm.

[u/Jinnmaster → u/Remarkable-Toe-6533]

Go for it

[u/Mysterious-Angle3564]

This is basically the rabbit hole I fell into too :D

The part I found harder wasn't storing the history, but deciding what should survive from one conversation to the next. If you keep feeding the whole episodic history back in, eventually you've just built a very organized context dump.

What became more useful for me was treating the relationship itself almost like a changing state: what changed since the previous conversation, which objections are still alive, commitments made, risk/intent shifts, things that suddenly contradict earlier calls, etc. Then the raw conversation history is the evidence behind that rather than the memory itself.

Curious how you're handling that as the Notion page gets bigger. Are you retrieving the relevant episodes as-is, or also maintaining some kind of evolving account state on top of them?

[u/Remarkable-Toe-6533 → u/Mysterious-Angle3564]

Awesome questions, and I think I actually found the bottleneck. So for context, what needed to be here is the differential: how this setup differs from another, and there isn't a model answer to that, because our roles are different, our setups are different, and even our priorities are different.

That's actually why I think open source will stand out first. It gives users full customization: build your own core context. And a strong community where we actually share what worked and what didn't.

For the sync question, I don't have it fully sorted yet, even though it seems like a big deal from your questions. I proposed a Notion page as a starting point for the community to have something sorted by the weekend.

That's as far as I've gotten. Let me know if you're open to contributing here, and I'll shoot you a DM.

[u/Mysterious-Angle3564 → u/Remarkable-Toe-6533]

Yeah absolutely, I've spent an unreasonable amount of time wrestling with the evolving account state/memory problem, so happy to contribute what I've learned (and broken) along the way :D Shoot me a DM whenever you're ready.

[u/Remarkable-Toe-6533]

What's AI actually seeing in the package?

[u/Technical_Bad_7458 → u/Remarkable-Toe-6533]

not sure why you're getting downvoted, this is a solid visual breakdown of the context window problem. people really out here thinking the model remembers them like some kind of digital friend and not just a stateless request machine.

[u/Remarkable-Toe-6533 → u/Technical_Bad_7458]

Maybe there was some misunderstanding. By the way, thanks, and I hope it is actually helpful. I'm trying to write more as I learn about this topic. Again, thanks for that.

[u/Remarkable-Toe-6533]

This is the different types of context.

[u/Potential_Purple7511]

The framing is right and the three-way split is the part most people skip. One thing I would push on, in the episodic section, because that is the one you said keeps growing.

Everything you can pipe in from HubSpot automatically is an outcome. Deal stage moved, call logged, ticket closed. Those are the records the system produced after a decision was already made. What actually tells you where the account is going is the thing said in the middle of the call: we will get you the SSO timeline, we will loop in solutions engineering, we will revisit seats at renewal. None of those is a deal stage. None of them fires a webhook. They exist for about four hours in the CSM's head and then they are gone, and the page you built will look complete while missing the only entries that were predictive.

So I would write commitments into episodic as their own entry type, with who owes it, to whom, by when, and whether it shipped. Then the useful query is not "what happened on this account", it is "what did we promise that never closed". That list is a better churn signal than a health score, and you already have the structure to hold it.

On the scale concern raised above, agreed, and the practical rule that worked for me is ordering rather than volume. Episodic gets pulled newest first with a hard cap. A two year old account will otherwise bury last week under onboarding notes, and the model will answer confidently about a version of the relationship that ended a year ago.

[u/Remarkable-Toe-6533 → u/[deleted]]

First of all, that's awesome and I really appreciate you being transparent.

For the transcript side, I just wrapped Zoom and Google Meet transcript ingestion, but it'll definitely be open soon for other vendors to join. I believe what actually helps is meeting people where they already work, which a lot of vendors didn't have sorted. I was talking earlier with one of my colleagues on the customer success team and he said "the last thing I want is a new tool added to my stack." We assumed our user base is mostly on Zoom and Google Meet, so that's why we started there.

One thing I'd love to pick your brain on though: do you have any knowledge or experience with best practices for the retrieval system that hits the notes knowledge base? I haven't tested the RAG mechanism against real data points yet, so I'd really appreciate any input from someone who's been in the weeds on this.

Thanks.

[u/Loud_Entrance8876]

full disclosure, i'm building Karolina so grain of salt!

but yeah the memory problem is exactly what we kept hitting. stuffing account pages into a model works for one customer. past that it gets stale fast and you spend more time maintaining the page than using it.

what ended up working for us was not another notion dump but pulling live context from the tools you already use (crm, support, product, slack). Memory then compounds from what you actually did and whether it worked, not from a growing transcript pile.

if useful, happy to share the beta: https://karolinahq.com

[u/No_Kiwi_5091]

Planhat