Every AI session I start begins with amnesia. The model is brilliant and knows nothing about me: not the incident we debugged on Tuesday, not the three thousand conversations I've had with ChatGPT, not who I follow or what I starred on GitHub last week. So I spend the first five minutes of every session pasting context, and the context I paste is whatever I happen to remember.
I work on Vana, where the whole idea is that your data should belong to you and travel with you. So I tried the obvious thing: export everything I own into a server on my own laptop, refresh it every morning, and let Claude read it over MCP. This is how that setup works, what it cost to get Slack into it, and where the data actually ends up.
Three commands
The tool is vana-cli. It runs connectors: small programs that sign in to a source the way you would, or read files the source left on disk, and turn what they find into typed records. The records go into a Personal Server, which is a local process that stores them, indexes them, and serves them back with permissions.
The whole setup is three commands:
vana server start --localstarts the server on this machine onlyvana connect <source>collects one source and stores itvana schedule addrepeats every connected source once a day
What one morning collects
This is the latest run of each source. Most of them take seconds because they're incremental: a connector remembers where it stopped and only reads what's new.
The server ends up holding 53 MB. Three quarters of it is ChatGPT. That surprised me more than anything else in this project: the single largest record of what I've been thinking about isn't my email or my notes, it's my chat history with another model.
Slack was the hard one
Most sources had a connector already. Slack didn't, at least not one I could use: the existing one wants you to dig a session token and a cookie out of your browser's developer tools and paste them in. Regular workspace members can't export their own history from Slack either, which is the whole reason this needed solving.
The connector I ended up with does what the Slack web app does. It opens Slack in its own browser profile, I sign in once with Google, and from then on it calls Slack's API from that signed-in page, with the same session the web app uses. The token never leaves the page.
The first version taught me two things. The first was humbling. I checked the export against Slack's own search, found all 32 of my messages, and called it done. 32 is a strange number for someone who lives in Slack, and it was: the window was seven days. Every number in an export means nothing until you know the window it was counted in.
The second was about speed. The first full run of the rewrite took over two hours. My account belongs to 422 conversations, and the connector walked every one of them, most of them direct messages nobody had touched in months. Halfway through, the browser window it was working in got closed, and instead of stopping, the connector retried each remaining conversation six times before moving on.
The fix was to stop asking every conversation and start asking Slack what changed. The web client has an endpoint that returns the latest message time of every open conversation in a single call, and search can list every message written since a date, including replies to old threads. Together they say exactly which conversations are worth opening.
Minutes instead of hours. 31 conversations had any activity that week. A closed browser page now ends the run at once with a message saying what happened, and nothing is half-saved: a run that stops early moves no cursors, so the next one simply reads the window again.
Where the data actually goes
This is the question I kept asking myself, so I checked the server's config instead of trusting the docs. With --local, sync to Vana's storage is off, the tunnel that would make the server reachable from outside is off, and the server is never registered on-chain. Everything sits in a folder under my home directory.
Two things do talk to the outside. Signing in to Vana and confirming once that the server is mine, which sends an identity and a signature, not data. And the CLI's own telemetry, which is on by default and goes away with vana telemetry disable.
One thing I didn't expect: local isn't permanent. If I later start the same server without --local, it uploads everything it ever collected locally, every version, encrypted, to my own storage. That's the right behavior for a backup and the wrong one if you assumed local meant private forever. If something should never leave the machine, keep it in a server that never goes public.
Using it
Claude Code talks to the server over MCP. It can list what I've granted, read a source, or search across all of them. The first real question I asked was about an incident from that week, phrased the way I'd ask a colleague. It came back in about a second with the actual thread: who noticed, what broke, what we did about it.
That's the part that changes how I work. I paste a lot less context now. Questions like "what did I promise to do this week" or "what did I tell ChatGPT about this architecture back in March" get answered from my own records, as fresh as the last morning run.
What I took away
Freshness beats completeness. A perfect export from last month is worth less than a decent one from this morning. The daily schedule and incremental connectors are what make this useful, not the size of the archive.
Know the window before you trust the count. My "32 out of 32" was correct and meaningless. Any export should say what it covered and what it didn't, in the output, not in the docs.
Most of your data is quiet. 391 of my 422 Slack conversations hadn't changed in a week. The fastest way to read a big account is to ask the source what changed and read only that.
Local by default, public on purpose. The setup that keeps everything on the laptop is one flag away from the one that syncs it. Decide which one you want before the first run, not after.
The Slack connector is open for review at PDP-Connect/data-connectors, and everything else here ships in vana-cli.