Markdown files and skills are two different things, and neither one is memory. How it actually works solo on Claude Desktop or across a Claude Code and Cursor team, what it saves you in tokens and duplicated work, and why your memory should belong to you and not the model provider
I build SenseLab, so I spend a lot of my week talking to people about how they feed context to their agents. Almost everyone starts the same way: a CLAUDE.md, some .cursor/rules, maybe a SKILL.md. I did too. It's the obvious first move and it's the right one.
But a few weeks in I keep seeing the same thing. The files grow, the agent somehow gets slower and dumber, and nobody can explain why it did the thing it just did. I want to be concrete about why that happens and, more importantly, show you exactly how memory works in the two setups people actually run: one person on Claude Desktop, and a team split across Claude Code and Cursor. Because once you see the mechanics, the choice is easy, and you can make it on day one instead of rebuilding later.
To be clear, this is not "delete your files." SenseLab makes your files and skills better. I'll get to that too.
People lump these together and they really shouldn't, because they do different jobs and they break in different ways.
A markdown context file (CLAUDE.md, .cursor/rules, AGENTS.md) is static text stapled to the top of every prompt. It's fine for conventions and house style. But it's always on and never changes on its own. It pays a token tax on every single call whether it's relevant or not, it has no idea whether anything in it is still true, and the only way it updates is you editing it by hand. So it bloats, it goes stale, and last spring's bad advice sits next to today's good advice with identical weight.
A skill is a different animal. A skill is a stable procedure the agent pulls in when it's relevant. Ours is a set of decision rules: when to write, always commit the outcome, keep beliefs under 0.9 confidence. That's policy, and policy should be stable. But here's what a skill fundamentally cannot do: it doesn't know one single thing about your system. It can tell an agent how to behave in general. It can't tell it that your checkout service already threw a race condition last month, or that the retry limit someone tried on Tuesday took down prod.
Neither of those is memory. Memory is what your agents actually know about your system, and how much to trust it right now. A file is a string. It doesn't know who wrote a line, when, whether it held up, or what happened the last time somebody trusted it. That is the entire difference between context and memory, and it's the gap everybody falls into: trying to make markdown do a job it structurally can't.
So keep the three straight. Files are static instructions. Skills are stable procedures. Memory is living, trusted, evolving knowledge. SenseLab is the third one, and it slots in under the other two.
Let me make this real instead of hand-wavy, because "it's easy to start" means nothing until you see how your agent actually reads and writes.
SenseLab ships an MCP server. Claude Desktop speaks MCP. So you connect them once and Claude gets a set of memory tools it can call mid-conversation, the same way it calls any other tool. The one-line installer detects Claude Desktop and writes the config for you:
curl -sSL https://raw.githubusercontent.com/raia-live/amfs/main/install-mcp.sh | bash -s -- --client claude-desktop --api-key sk-your-key
If you'd rather do it by hand, it's a few lines in claude_desktop_config.json pointing at hosted SenseLab:
{
"mcpServers": {
"amfs": {
"command": "uvx",
"args": ["amfs-mcp-server-pro@latest"],
"env": {
"AMFS_HTTP_URL": "https://amfs-login.sense-lab.ai",
"AMFS_API_KEY": "sk-your-key"
}
}
}
}
Restart Claude Desktop and that's the whole setup. Now here's what actually happens when you use it.
You ask Claude to help you plan a migration for your billing code. Before it answers, it calls amfs_set_identity to say who it is this session (or the server auto-detects it as claude-desktop/<you>), then amfs_briefing("billing") to pull everything already known about that area. The first time, that briefing is empty and it just works normally. But it also calls amfs_write to record the decisions you land on, with a confidence score and provenance attached, and amfs_commit_outcome when something resolves. You don't orchestrate any of this. The MCP server injects the instructions telling the agent to do it, and the SKILL.md reinforces the good habits.
The magic is the second time. A week later you open a fresh chat, maybe even switch to Cursor, and ask about billing again. This time amfs_briefing comes back with the decisions and gotchas from last week, ranked by confidence, and the agent starts from there instead of from zero. That's the difference between a chat that forgets everything at the end and one that's building on itself. A CLAUDE.md can't do that, because you'd have had to remember to write last week's insight into it by hand, and you didn't.
The reads and writes are just tool calls. amfs_read and amfs_search and amfs_retrieve to pull knowledge, amfs_write to store it, amfs_recall for the agent's own past notes, amfs_commit_outcome to close the loop and move confidence around. Your knowledge lives in your SenseLab account, so it's the same brain whether you're in Claude Desktop, Cursor, or Claude Code tomorrow.
This is where files stop merely underperforming and start actively lying to you, and it's also where SenseLab earns its keep.
Say Bruno works in Cursor and Alice works in Claude Code. With files, they each have their own CLAUDE.md and .cursor/rules, and those never touch. If they try to share a context.md in the repo, it's last-write-wins: one of them silently stomps the other and there's no record they ever disagreed.
With SenseLab, both of them point their MCP config at the same hosted account. In Cursor it's the same amfs block in .cursor/mcp.json; in Claude Code it's the same block in the Claude config. Same AMFS_HTTP_URL, same account, different API keys so each person is distinct:
{
"mcpServers": {
"amfs": {
"command": "uvx",
"args": ["amfs-mcp-server-pro@latest"],
"env": {
"AMFS_HTTP_URL": "https://amfs-login.sense-lab.ai",
"AMFS_API_KEY": "sk-alices-key"
}
}
}
}
Now they share one brain across two tools, two machines, and two people. Here's the loop that plays out:
Bruno reviews a checkout PR in Cursor. His agent writes amfs_write("myapp/checkout", "risk-race-condition", "...") and, when the PR ships with a hiccup, amfs_commit_outcome("PR-456", "minor_failure"). That outcome nudges the confidence on the race-condition entry up, because knowledge tied to something that went wrong is knowledge you want to surface louder.
The next morning Alice starts working on checkout in Claude Code. Her agent calls amfs_briefing("myapp/checkout") and Bruno's risk signal is right there, with boosted confidence and his name on it. She avoids the bug he already found. When her agent reads his entry, that read is recorded as a real learned_from link, not a copy-paste. Those links form a graph, and the Cortex runs community detection over it to notice that Bruno's and Alice's agents keep working the same surface and are effectively a team. The similarity it uses comes from behavior, not from a config anyone maintains by hand:
ent_sim = jaccard(entity_sets[aid_a], entity_sets[aid_b])
type_sim = cosine(type_vecs[aid_a], type_vecs[aid_b])
collab_overlap = 1.0 if (
aid_b in collab_sets[aid_a] or aid_a in collab_sets[aid_b]
) else 0.0
sim = 0.5 * ent_sim + 0.2 * type_sim + 0.3 * collab_overlap
if sim > self._sim_threshold:
G.add_edge(aid_a, aid_b, weight=sim)
The problems that solves are the ones that actually hurt teams. Nobody re-solves a bug a teammate already figured out, because it's in the shared briefing. Nobody silently overwrites shared knowledge, because every entry knows who wrote it and the critic package flags it when two agents assert different values for the same thing. And when you want control over what becomes team canon, Pro gives shared memory a Git-style workflow: an agent proposes a change on a branch and the owner reviews the diff before it merges. You can't express "review this before the whole team believes it" in a markdown file. There's nowhere to put it.
The same account works for your non-interactive agents, and this is where the missing feedback loop turns into real risk. A deploy bot or a nightly triage agent connects with an explicit identity via AMFS_AGENT_ID (say deploy-bot) so its work is attributed and separate from the humans.
A static rule can't learn. A skill that says "roll back if error rate goes above X" says that forever, even if the last three rollbacks were the wrong call. SenseLab closes that loop: amfs_commit_outcome back-propagates onto the entries the agent read, and over in packages/ml a ranker trains on those outcome-labeled decision chains so retrieval itself gets better from your real production results. When the bot does something surprising, you don't shrug, you call amfs_explain and read the exact chain of what it knew, what it checked, what it decided, and how it turned out. Pro signs those traces with HMAC and can ship them to Datadog or Jaeger. It also prunes its own cruft with the critic and distiller, and screens ingested data for secrets and memory poisoning so one compromised source can't quietly corrupt the rest. None of that has an equivalent in a file.
This is the part I care about most, because it's where people assume they have to choose and they don't.
A skill is the stable "how to think." Memory is the living "what we know." The skill's whole job becomes teaching the agent to use the memory well: get a briefing before you start, write findings with a confidence score, always commit the outcome. Our own skill is literally that, a guide for using SenseLab. It stays constant and reliable while the knowledge underneath it keeps changing.
Then the loop closes on itself. The agent reads memory, does work, and records what happened. Outcomes flow back and re-weight the knowledge, so patterns that keep working rise and ones that don't fade out. Your skill never changed, but the agent following it keeps getting sharper because the memory it stands on keeps getting sharper. That's improvement you don't have to babysit, and a static file cannot produce it.
It even runs the other direction. Because memory tracks what actually works across your fleet, the patterns it surfaces are the raw material for improving your skills and rules. Your SKILL.md stops being a guess about best practice and starts being informed by what your agents have genuinely learned.
Here's a point that took me a while to appreciate. When you lean on a provider's built-in memory or chat history, your learnings are trapped in their box. Your accumulated context about your own systems lives inside Anthropic, or OpenAI, or whoever, in a format you can't export, query, or move. The day you want to try a cheaper model, or run some agents on GPT and some on Claude, or drop in a local model for the cheap stuff, all that hard-won knowledge stays behind.
SenseLab keeps memory in your account, not the model's. It's reachable over MCP and plain SDKs, so it's model-agnostic by design. Your Claude agents, your GPT agents, and your local models all read and write the same brain. Switch providers whenever you want and your knowledge comes with you, because it was never theirs to begin with. On a team that mixes models, this is the difference between one shared understanding and five siloed ones. You own the compounding asset. The model is just the engine you happened to plug in this week.
I like a clean story but I like a spreadsheet more, so here's the rough ROI. These are back-of-envelope numbers. Plug in your own and the shape holds.
Start with tokens. Your standing context (a CLAUDE.md, some rules, a couple of skills) is easily 4,000 to 6,000 tokens, and it rides along on basically every step of an agent loop. A single real task can fire 100+ model calls once you count tool use and retries. So you're re-sending something like:
5,000 tokens of standing context
× 150 calls in a working session
= ~750,000 input tokens per session, mostly irrelevant to any given step
× 20 working days
≈ 15M tokens / month / developer just carrying context around
Prompt caching shaves the repeat cost, sure, but you still pay across sessions and cache misses, and more importantly you're spending the model's attention on 5k tokens of noise when maybe 400 tokens are relevant to the step in front of it. A briefing flips that: the agent pulls a small, ranked, relevant slice when it needs it instead of stapling everything to everything. Better answers and a lighter bill, at the same time.
Now the bigger line item, which is duplicated work. This is the cost nobody logs because it's smeared across the week. Two engineers whose agents both rediscover the same gotcha. A fresh session re-deriving something you figured out on Tuesday. A deploy bot relearning a lesson from last month's incident. Say each rediscovery burns 30 minutes of agent-plus-human time, and it happens a handful of times a week per person:
5 engineers
× 3 rediscoveries / week
× ~30 min each
≈ 7.5 hours / week of redundant work
≈ 30+ hours / month your team pays for and gets nothing new from
That's the one that actually stings, and it's exactly what a shared, outcome-weighted memory removes. The first agent that solves something writes it down with confidence and provenance; every agent after that starts from the answer. You stop paying, over and over, for lessons you already learned.
Here's the thing that makes me push people. This is a compounding asset, and the clock started the day your agents began working.
Every week you run on markdown, your agents solve the same problems and forget the answers the moment the session ends. You're not just missing some convenience. You're deleting the exact thing that would make next month easier. The confidence scores, the outcome history, the traces, the graph of which knowledge led to good results, all of it gets more useful the longer it runs. A team that turned this on three months ago has agents that are measurably sharper than yours, and you cannot backfill history you never recorded. The cost of waiting isn't zero. It's the compounding you skipped.
And the cost to start is genuinely small: one install line, keep every file and skill you already have, and your agents begin remembering from the next session forward.
Files tell your agent the rules. Skills tell it how to work. Memory is what it knows, and right now that memory is getting thrown away at the end of every session. Keep your files, keep your skills, and give your agents something to actually remember.
Free tier. No credit card. Connect in minutes.
