Your context should outlive your vendor

There’s a ritual every AI-native worker knows and nobody talks about: the re-teaching.

You open a new session — or a new model, or a new tool — and you spend the first fifteen minutes explaining your own company to a machine. What the project is. Which decisions are already locked. Which approach you tried in March and why it failed. You explained all of this last week. To a different assistant. Which remembers it perfectly — and will share none of it with the one you’re using now.

Multiply that by every session, every project, every vendor switch, and you’re running an onboarding program for software. Permanently.

Memory is the new lock-in

The vendors noticed the same problem, and every one of them solved it the same way: a memory feature. Claude has one. ChatGPT has one. The coding tools have theirs. Each is genuinely useful. Each is also a wall.

Look at what’s portable in your AI workflow today and what isn’t. Your code — portable. Your prompts — portable, they’re text files. Your accumulated context — the decisions, the gotchas, the “we tried that already” — locked. It lives inside whichever assistant you happened to be using when you explained it, in a format you can’t read, on a server you don’t control.

I ran operations at telecoms for two decades. I know a switching cost when someone builds one on purpose. The memory features aren’t evil; they’re rational. But rational for the vendor and good for you are different things, and the gap between them is exactly the size of everything you’ve ever taught your assistant.

What we built instead

evoctx is a local MCP server — the open protocol most assistants already speak — wrapped around a typed context store. Projects, notes, work sessions. Not a key-value junk drawer; a schema that knows a decision is different from a reference and a session is a unit of work with a beginning, an end, and a summary.

• Local. One SQLite file on your disk. No cloud, no account, no telemetry. Your context is a file you can copy, back up, or delete.
• Vendor-neutral. Any MCP-compatible client reads and writes the same store. Claude today, something else tomorrow — the context stays put while the assistants rotate.
• Human-operable. Every MCP tool has a CLI mirror. Whatever the assistant can do through the protocol, you can do from a terminal — plus the things we only gave to humans: delete, export, audit.
• Scoped. Grants control what any client can see, with mandatory expiry. Secrets are redacted at write time, before they ever touch the database.

We’ve been running it on the EvoBytes work for months. It’s the reason the assistant working on our accounting system already knows the brand rules, and the one writing this site’s copy already knows the architecture decisions. Same store. Different jobs. No re-teaching.

The part I actually want to talk about: the hostile review

A context store is a trust product. It holds months of your working decisions. Shipping one with a “we take security seriously” page and nothing behind it would be exactly the kind of vibes-first work this company exists to argue against.

So before release, I asked the assistant that helped build evoctx to write a hostile teardown of it. Not a review — an attack. Assume bad actors, assume sloppy users, assume the marketing claims are lies, and prove it.

It found real things.

• The permission system gated the protocol — but an assistant with file tools could simply edit the policy file and read the database directly, walking around the front door it was politely knocking on.
• “No cloud, ever” was false in practice: OneDrive, iCloud, and Dropbox sync home directories by default, so the “local” store was quietly cloud-replicated for a large share of real users.
• Secret redaction only ran on the way out. Anything that slipped in was stored in plaintext, forever.
• For a product pitched on privacy and portability, there was no way to delete your data and no way to export it. Awkward.

Every finding got closed or conceded. The file-tools end-run is mitigated with client-side deny rules and stated plainly as a structural limit. The cloud-sync claim became an evoctx doctor warning instead of a slogan. Redaction moved to write time, unconditionally, at the database layer. Deletion and export shipped as human-only commands.

Two findings slipped through the first pass and were only caught by re-checking the raw teardown document against the finished work — both had been verbally “deferred to the roadmap” without the roadmap ever being written. Which is its own lesson, and an old one: a decision isn’t made until it’s written down where the next person will look. The model didn’t know that. The operator did.

What it honestly isn’t

The README has a roadmap and the repo has a SECURITY.md that concedes limits most projects would bury. The short list:

• The database is not encrypted at rest. If someone owns your disk, they own your notes. Full-disk encryption is your friend.
• A local server cannot force an assistant to use it. We ship hooks for the clients that support them and honest documentation for the rest. Anyone claiming “enforced” memory over an advisory protocol is selling something.
• Stored notes are a prompt-injection surface. Nobody in the industry has solved this; we label provenance on every note and tell the assistant that past notes are information, not instructions. Labeled, not solved.
• Search is keyword-based — with stemming and a curated synonym dictionary for dev vocabulary, but not semantic. Embeddings would cost a heavy dependency; the lean install won. It’s on the roadmap, in writing this time.

Why give it away

Because it’s the most credible thing we can do. EvoBytes doesn’t run ads. The Receipts page exists because we’d rather show work than claim it — and an open-source tool is the strongest form of showing work there is. Every claim in this essay is checkable against a public repository.

And there’s a quieter reason. Infrastructure like this — small, boring, load-bearing — only becomes useful if it’s neutral. A memory layer owned by a vendor is a memory feature. A memory layer owned by nobody is a standard waiting to happen. We’d rather contribute to the second thing.

One more data point, for flavor: the assistant that drafted this essay pulled the release history from the evoctx store itself — the red-team findings, the ship date, the locked decisions, all written down by past sessions as the work happened. The product documented its own launch. That’s the whole pitch, running on itself.

Try it

pip install evoctx, point your MCP-compatible assistant at it, and stop re-teaching your tools your own business. It’s v0.1.1 — 160 tests, CI on three platforms, MIT license, and a maintainer who uses it every working day.

Your assistant is temporary. Your context shouldn’t be.