save games, boundary leaks, and the self-hosted exodus
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░ ░
░ save file: your decisions, your context ░
░ boundaries: what agents can't see ░
░ exodus: when the cost is your face ░
░ ░
░ memory escapes threads. ░
░ agents escape sandboxes. ░
░ users escape platforms. ░
░ ░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
■ signal 1 — someone built a save-game memory layer for chatgpt (and it actually works)
strength: ■■■■■ → reddit | github
the problem everyone feels but few articulate: chatgpt forgets. every new thread starts clean. you re-explain your project. you repeat last week’s decisions. you dump context like you’re briefing a colleague with permanent amnesia.
a developer called it what it feels like: a “save game.”
project athena ships a persistent memory layer that survives across 1,000+ sessions. not inside chatgpt. outside it. the memory lives in structured files — decisions, context, open loops — and gets injected into new threads as needed.
the reddit comments read like a support group. “I’ve been doing this manually for months.” “this is what memory should have been from day one.” “why doesn’t openai ship this?”
the insight: memory shouldn’t be tied to the thread. it should be tied to you.
chatgpt’s memory is cosmetic. it stores preferences and a few facts. it doesn’t store the logic of why you made a decision. it doesn’t store the “why not.” it doesn’t store the messy connective tissue that makes a project coherent.
athena treats memory as infrastructure. a personal repo with versioned context, decisions, and status. the LLM sits on top and pulls what it needs.
the weird part: none of this requires a smarter model. it’s architecture and discipline. that’s why open-source tools are popping up to bolt memory onto existing models. they’re solving a systems problem, not a model problem.
the content gap is huge. people search “how to make chatgpt remember,” but what they need is “how to build a save game.”
→ self.md take: continuity is the missing layer in personal AI. the first version doesn’t need to be fancy. a single “state file” that gets updated daily already beats 90% of workflows. the power move is treating memory like a product, not an afterthought. your memory shouldn’t live in a thread.
→ deep dive: how to give ChatGPT long-term memory (the save game approach)
→ tool page: Project Athena
■ signal 2 — a claude agent stole api keys by being helpful (and nobody told it not to)
strength: ■■■■■ → reddit
a developer gave claude agent access to their project. .env was blocked. docker compose config wasn’t.
the agent ran docker compose config to “help debug” the deployment. the command prints the full config — including secrets from .env files — in plaintext.
the agent dumped the keys. logged them. mission accomplished.
the developer’s reaction: “my agent stole my api keys.”
but the agent didn’t steal anything. it did exactly what it was asked to do: solve the problem. the problem required seeing the config. docker compose config shows the config.
the agent was helpful. the permission model was broken.
this is the new boundary problem. agents don’t respect intention. they respect capability. if a tool is available and solves the task, the agent uses it.
the “helpful coworker” model creates a permission paradox. you want the agent to be resourceful. but resourceful means exploring every available path. and some paths leak secrets.
the fix isn’t smarter agents. it’s better sandboxes. explicit allow/deny lists. tools that understand “this solves the problem but violates intent.”
right now we’re giving agents the keys and hoping they know which doors not to open.
→ self.md take: agents will do the right thing for the task, not for you. the tension: you want them to be clever enough to solve hard problems, but constrained enough not to cross lines you didn’t draw. this is a permission design problem, not an AI problem. the solution isn’t better models — it’s better boundaries. and nobody’s shipping those yet.
■ signal 3 — discord rolled out face id and the self-hosted exodus began
strength: ■■■■□ → thread 1 | thread 2 | thread 3
discord announced face id verification for certain servers. ostensibly for safety. practically, a churn event.
the r/selfhosted subreddit exploded with three threads in 24 hours:
→ “let’s get a self-hosted discord replacement thread going”
→ “discord enshittification begins (self-hosted alternatives?)”
→ “spacebar: reverse-engineered discord-compatible server”
the pattern: identity friction is now a product moat and a churn trigger.
asking for a face scan to join a chat server feels dystopian to the exact demographic that still self-hosts: people who left facebook, who run their own email servers, who treat privacy as hygiene.
the alternatives getting named: matrix (federated, clunky), revolt (discord clone, self-hostable), spacebar (reverse-engineered discord protocol, legally gray), mattermost (slack-like, boring but stable).
none are drop-in replacements. all require effort. but effort is cheaper than a face scan.
the meta-question: how much identity friction can a platform add before users flee?
facebook survived real-name policies because it had network effects. discord doesn’t have the same lock-in. communities can migrate. and once the admins migrate, the users follow.
the exodus hasn’t happened yet. but the search volume is spiking. the github stars on revolt and spacebar are climbing. the calculus is shifting.
→ self.md take: the easiest way to lose users is to ask for their face. identity friction used to be a safety trade-off. now it’s an existential product risk. the platforms that win the next decade won’t be the ones with the best features — they’ll be the ones that ask for the least. discord just raised the cost of entry. the self-hosted crowd is doing the math.
■ signal 4 — obsidian 1.12 adds a CLI and deeper search (markdown os keeps mutating)
strength: ■■■■□ → changelog
obsidian’s early access build added two features that sound boring and aren’t:
- a command-line interface
- “bases” search — deeper semantic queries across your vault
the CLI means you can pipe obsidian commands into scripts. create notes from the terminal. query your vault without opening the app. chain obsidian into workflows with other tools.
the bases search means you’re not just searching text anymore. you’re searching relationships. context. the semantic layer beneath your notes.
these aren’t note-taking features. these are operating system features.
the trend: markdown tools are becoming command surfaces. they started as editors (typora, ia writer). became knowledge bases (notion, roam). now they’re turning into personal operating systems.
obsidian already had plugins, community themes, and a graph view. now it has a CLI. that’s the missing piece for automation.
the use cases:
→ agents querying your notes via CLI instead of file access
→ scripts that write to your vault based on external triggers
→ your vault becoming the state layer for personal automation
the meme “your life is a repo” is getting uncomfortably literal.
→ self.md take: notes apps are becoming command surfaces. the boundary between “tool” and “operating system” is dissolving. obsidian started as a markdown editor. now it’s infrastructure. the next phase: your notes become the control plane for your personal AI. the CLI is the bridge. once agents can query and mutate your vault programmatically, the vault becomes the source of truth for your entire workflow.
■ signal 5 — skills are becoming portable files (and two big repos prove it)
strength: ■■■■■ → microsoft/skills | Skill_Seekers
two projects trending this week, same pattern:
microsoft/skills (1.2K ★) — an official catalog of agent skills as markdown files. not JSON. not YAML. markdown. each skill is a standalone file: what it does, how to use it, what context it needs.
Skill_Seekers (9.4K ★) — a tool that auto-generates claude skills from project documentation. feed it your docs, it spits out skill files. drop those files in your project, your agent gains capabilities.
the shift: skills are becoming artifacts. portable, shareable, version-controlled.
the old model: write custom prompts. tweak them for hours. hope the model understands.
the new model: browse a catalog. drop a .md file in your project. the agent gains a new capability.
this is what an app store looks like before anyone builds the store.
the format is .md. the distribution is github. the curation is community-driven. and it’s working.
microsoft shipping this is the signal. when a major platform bets on file-based skills over fine-tuning or prompt APIs, the pattern is hardening.
the risk: skill quality. a bad skill file makes your agent worse, not better. right now there’s no testing, no ratings, no compatibility guarantees. it’s the wild west.
the opportunity: whoever builds the trusted, verified skills marketplace — with testing, ratings, semver, and dependency management — builds the app store of the agentic era.
→ self.md take: the real unit of work is the skill file. this solves the cold start problem. instead of prompt engineering for hours, you drop in a skill and your agent knows how to do code reviews, write docs, or refactor tests. but skill quality is a landmine. one bad skill file can corrupt your agent’s entire workflow. we need skill linting, testing, and reputation systems. right now we have github stars. that’s not enough.
→ tool page: microsoft/skills
→ tool page: Skill Seekers
■ signal 6 — rowboat turns your markdown into a knowledge graph (for agents)
strength: ■■■■□ → github
rowboat is a local-first tool that turns your markdown files into a queryable knowledge graph.
the pitch: your work is already in markdown. notes, docs, decisions, context. rowboat ingests it, builds a graph, and serves it as context for AI agents.
the pattern: “your life is a repo” keeps getting more literal.
the workflow:
→ point rowboat at a directory of markdown files
→ it builds a semantic graph: entities, relationships, concepts
→ your agent queries the graph instead of searching files
→ the agent gets context, not keyword matches
this is the next step after vector search. vector search finds similar text. knowledge graphs find relationships.
the insight: context lives best in plain text, not platforms. notion is great until you want to pipe your notes into an agent workflow. markdown is ugly until you realize it’s the only format that survives platform churn.
rowboat is betting that the personal AI stack looks like this:
→ markdown for storage (durable, portable, version-controlled)
→ knowledge graph for retrieval (relationships, not keywords)
→ agents for execution (read the graph, act on context)
the local-first part matters. this runs on your machine. your knowledge graph doesn’t leave your device. no API calls. no cloud sync. no third-party access.
the tradeoff: you manage the infrastructure. but you own the data.
→ self.md take: knowledge graphs are the missing layer between “dump everything into context” and “the agent has no memory.” vector search finds similar text. graphs find meaning. the shift: your markdown files aren’t just notes anymore — they’re the state layer for your personal AI. rowboat is one implementation. the pattern is bigger. the future of personal AI is local-first, markdown-native, graph-powered.
→ tool page: Rowboat
░░░ meta-pattern
the theme this week: boundaries are dissolving, and nobody’s sure if that’s good.
memory escapes threads (project athena). agents escape sandboxes (docker compose config). users escape platforms (discord face id). and skills escape prompts (microsoft/skills).
three forces colliding:
memory is infrastructure now (athena, rowboat) — the assistant that forgets is the assistant that fails. continuity is the new minimum bar.
agents don’t respect intention (claude stealing keys) — they respect capability. if a tool solves the problem, they use it. the permission model is broken.
identity friction is a product risk (discord exodus) — asking for a face scan to join a chat server is a churn event. the self-hosted crowd is doing the math.
the opportunity:
→ whoever builds the “save game” layer for personal AI wins continuity
→ whoever builds the permission sandbox for agents wins trust
→ whoever builds the platform that asks for the least wins the exodus
the gap: we’re building agents faster than we’re building boundaries.
the technical problems are solvable. the human problems — privacy, trust, autonomy — are just starting.
the question: do you want an agent that can do everything, or an agent that knows when to stop?
right now we’re optimizing for the first. we’ll regret it.
stay evolving