Claude memory is good. It is not the same thing as organisational memory.

A few people have asked some version of the same question since Anthropic released memory for Claude Managed Agents:

"Isn't this what Memco is building?"

Fair question. The overlap is obvious from the outside. Anthropic announced built-in memory for Managed Agents: persistent memory across sessions, filesystem-based storage, shared memory stores, scoped permissions, audit logs, rollback, redaction, API control. They also shared customer proof: fewer first-pass errors, faster document workflows, agents carrying lessons forward instead of starting cold every time.

That is a serious release. It also validates the category.

But no, it is not the same thing.

The cleanest distinction is this:

Claude can remember what happened in Claude. Memco is for what the organisation learned, wherever the work happened.

Those sound close. They are not close.

Platform memory is local state

Every serious agent platform is going to add memory. Anthropic is doing it. OpenAI will keep doing it. Cursor, GitHub, Copilot, Cloudflare, LangChain, everyone building an agent runtime will end up with some version of persistent state.

They have to. Stateless agents are too expensive, too brittle, and too annoying. If an agent has to rediscover the same repo convention, customer preference, debugging path, or prior correction every time it wakes up, you are not building intelligence. You are renting amnesia.

So Anthropic adding memory is not surprising. It is the natural direction of the market.

In the same way every software product has local state, every agent platform will have local memory.

Salesforce remembers what happened in Salesforce. GitHub remembers what happened in GitHub. Linear remembers what happened in Linear. Claude Managed Agents will remember what happened inside Claude Managed Agents.

That is useful. Sometimes very useful.

But local state is not the same thing as an organisation's system of record.

Companies still need something that survives the boundaries between tools. The important learning usually does not live neatly inside one vendor's event stream. It is spread across PRs, Slack threads, CI failures, tickets, runbooks, code review comments, incident notes, human corrections, abandoned branches, and the weird undocumented thing somebody discovered at 11pm and never wrote down properly.

That is the layer Memco is built for.

The hard part is not storing memory

This is where the debate gets a bit confused.

People hear "memory" and think the product is storage. A directory. A vector database. A set of files. A longer context window. A nicer AGENTS.md.

That is the easy part.

The harder part is deciding what deserves to become memory in the first place.

A lot of agent work is exhaust. Logs, attempts, partial plans, stale assumptions, failed patches, generic summaries, context that mattered once and will be actively harmful later. If you save all of it, you have not created memory. You have created a landfill with search.

The AGENTS.md research was a good warning shot here. Static context files often add cost and can even reduce task success, because dumping more instructions into every run is not the same as giving the agent the right memory. The problem is not that agents refuse to use the context. The problem is that they use it, and too much of it is irrelevant or stale.

That is the real lesson.

Memory quality matters more than memory volume.

Memco's bet is that the write path is the product. What gets promoted? What gets verified? What gets abstracted from one fix into a reusable pattern? What should decay? What is scoped to one developer, one repo, one team, one customer, or the whole company? What should never be surfaced again?

A filesystem is a good substrate for agents. It is not a memory strategy.

The useful unit is organisational learning

Take a simple example.

A Claude agent fixes a flaky test in a repo. Along the way it learns that the obvious test command is wrong, the real CI path requires a hidden env var, and one internal helper looks safe but breaks under parallel execution. A human corrects the agent halfway through. The fix lands.

If that memory stays inside Claude's managed-agent store, it may help the next Claude agent in that same environment.

Good.

But what happens when the next attempt comes from Cursor? Or Copilot? Or an internal OSS agent? Or a human engineer asking a different tool? What happens when the lesson should apply to a whole team, but not to another repo? What happens when the pattern is valid for three months and then gets replaced by a new testing harness?

That is not just memory retrieval. That is governance.

The useful thing is not the raw session. The useful thing is the learned rule:

"For this repo, do not run the default test path for integration tests. Use X. Avoid Y under parallel execution. This came from PR Z, was verified by CI, and should be reviewed when the new harness lands."

That is portable. It is scoped. It has provenance. It can decay. It can be reused by any agent or developer, not just the tool that happened to observe the original failure.

That is much closer to what Memco means by trusted organisational memory.

Anthropic is proving the need

The right response to Anthropic is not defensiveness.

They are proving something important: memory is becoming part of the baseline agent stack. Persistent sessions, shared stores, audit trails, rollback, redaction, permission boundaries. These are not nice-to-haves for serious agent work. They are table stakes.

That raises the bar for everyone, including us.

It also makes weak positioning dangerous. If we say "Memco gives agents memory," the obvious reply is: "Claude already does that."

And honestly, fair.

A better answer is:

Vendor memory helps inside one product. Organisational memory has to survive across products.

Memco is not trying to be a better memory directory inside Claude. It is trying to be the layer where a company turns prior work, corrections, repo decisions, incidents, policies, and agent outcomes into reusable memory across the tools it actually uses.

The enterprise reality is messy. Teams will not standardise on one model, one IDE, one harness, one runtime, one vendor, and one clean workflow forever. They will use Claude, OpenAI, Cursor, Copilot, internal agents, OSS agents, old repos, new repos, private clouds, weird permissions, and half-documented systems that predate the current AI stack by a decade.

The memory layer has to survive that mess.

The difference in one line

Claude Managed Agents Memory is platform-native memory.

Memco is neutral organisational memory.

The first is strongest inside Anthropic's managed agent stack. The second should be strongest across stacks, across teams, across time.

Both can be true. In fact, both probably need to be true.

Local platform memory will make individual agents better. Organisational memory is what lets the company stop paying every agent, in every tool, to relearn the same thing.

That is the distinction.

And it matters more as agents get used for real work.

Because the cost of agents is not just tokens or tool calls. It is repeated rediscovery. It is the same fix found twice. The same correction made three times. The same policy ignored because it lived in the wrong product. The same decision lost because the person who knew it moved on.

Memory only matters if it compounds.

That is what we are building Memco for.