Why your workspace should be plain files
The Satora team
6/4/2026
"Export anytime" usually means a worse cage
Most tools answer the lock-in question the same way: a JSON export buried in settings. It technically gets your data out — into a shape nothing else can read. You're free to leave with a file you can't actually use.
We didn't want a better export button. We wanted the thing you'd export to be the thing you were using all along.
Markdown is the substrate, not a feature
In Satora, every task, project, and note is a plain markdown file with YAML frontmatter. That's not a view or a sync target — it's how the data is stored, on a Postgres control plane that keeps everything fast and queryable.
Two things fall out of that decision:
- Agents can read and write it. Plain, structured files are legible to an MCP client. That's what lets Claude or Cursor act on your workspace directly instead of through a chat window.
- You can walk away with it. Export the workspace as a ZIP and open it in Obsidian, VS Code, or git. It already looks like notes a human keeps, because it is.
The honest version of "no lock-in"
No-lock-in isn't a marketing line for this audience — it's a precondition for trust. The promise only holds as long as your canonical data stays in a format you and your agents can both read. So that's the line we hold: if a feature works for humans but hides the structure from MCP, that's a regression, not a release.
Your work, as plain files your agents can act on. That's the whole idea.