Start with files, get database guarantees for free. TigerFS gives agents the filesystem interface they already know, backed by one shared, transactional source of truth: files are real PostgreSQL rows, and every write is an atomic transaction. Agents and humans, local or distributed across many machines, share that same state: changes are visible to everyone immediately, logged, and reversible.
A workspace is a table you create by declaring its type. From then on it's just a directory: write markdown or plain text, organize it into folders, and reach for any tool that speaks files. YAML frontmatter becomes columns and the body becomes the row's content, so every file is a real PostgreSQL row and every write is an atomic transaction.
Because writes are atomic database transactions, concurrent agents and humans always see consistent state. And when you add the history feature, as above, every change becomes reversible. That's what the rest of this page is about.
Bookmark a state, let agents work, then roll back any change — a single edit, everything since a savepoint, or just one agent's work — in one atomic operation.
Workspaces opt into versioning with the history feature. From then on every write — create, edit, rename, delete — is captured in an operation log with timestamp and user identity, exposed as ordinary files. Four capabilities follow.
Every snapshot of a file is a timestamped path under .history/. Read one to see exactly what the file looked like at that point. No undo required.
The operation log records who changed what, and when. Filter by recency, user, or operation type, and diff any individual edit through its before/current/after virtual files.
Create a named bookmark, try changes, preview what an undo would touch, and roll back if it doesn't pan out. Auto-savepoints (--auto-savepoint-interval, default 30m) also record bookmarks at session-boundary inactivity gaps, so there's always a recent checkpoint.
Reverse one operation by log id, everything since a log id, or everything since a savepoint, and filter any of it by user, so agents are reversible independently in a shared workspace.
Undo operations are themselves logged and reversible: changing your mind about an undo is just one more .apply.
You don't have to run any of those commands yourself. Once TigerFS is mounted, just talk to your agent. The skills teach it the patterns, and because the log is structured and queryable through the filesystem, it reasons about composite operations on its own. A few exchanges:
why-postgres.mdfile_id filter only shows one of the two edits, since atomic renames change file_id per edit, so I read the full recent log. Each edit is a 3-entry atomic-rename group; to restore the pre-savepoint content I apply 6 undos newest-first:
Edit #2: added the TigerFS bullet to extensions
Under the hood: the skill starts from the file's stable id (cat .history/why-postgres.md/.id), but atomic renames rotate that id on every save, so a .log/.by/file_id/ filter only catches part of the trail.
So it reads the recent log window (cat .log/.last/20/.export/json) instead, recognizes each save as a create-temp → delete → rename trio, and reverses the whole run with one touch .undo/to-id/<log_id>/.apply anchored just before it.
working-with-views.md, and putting why-postgres.md back. Reverted. Workspace is back to the original 5 files:
blog/
├── hello-world.md
├── deep-dives/
│ ├── why-postgres.md
│ └── working-with-views.md
└── tutorials/
├── getting-started-with-sql.md
└── markdown-tips.md
Under the hood: .undo/to-savepoint/<name>/ is a virtual directory showing what the workspace would look like after the rollback. Diffing it against the live tree (diff -ru .undo/to-savepoint/<name>/ ./) previews exactly which files the undo would change, before anything happens.
A touch .undo/to-savepoint/<name>/.apply then restores them all in one transaction.
type=undobefore-second-batch: 7 entriesUnder the hood: listing is just reading (cat .log/.last/20/.export/json).
The skill is taught to reason about related operations as batches, so a run of type=undo rows from a single .apply reads as one logical operation rather than twenty raw entries.
type=undo, so reversing one is just another undo. I'll anchor at the rename entry just before the undo group and reapply all 7 in order. That re-applies the second batch: the internals/ directory move, wal-explained.md back to draft: false, and the removed sections. Your savepoints all still exist.Under the hood: because every undo is itself logged as type=undo, reversing one is just another undo, anchoring .undo/to-id/<log_id>/ just before the undo's own entries and touching .apply.
The skills also drop a savepoint before any large undo: not strictly required (to-id works on any entry), but it leaves a clean, named checkpoint that a human can see and return to.
The skills teach the patterns; you stay in natural language.
Multiple agents operate on the same knowledge base at once. Every edit is versioned, so if one agent overwrites another's work, you can diff against .history/ and recover it, with no shared drive, file-lock protocol, or snapshot pipeline.
todo/, doing/, and done/ are your three directories, and mv is your only API. Moves are atomic database operations, so two agents can't claim the same task.
Point a whole swarm at one workspace, each agent in its own directory, all writing at once with full ACID isolation. No branches to fork or merge: split a job across agents and combine the parts, or race competing drafts and keep the winner. Every write is logged, so nothing collides and a dead end is one undo away.
Other tools give agents files, or versioning, or concurrency: rarely all three, and never with a real database underneath.
| Capability | TigerFS | Local files | Git | S3 | Hosted versioned-FS |
|---|---|---|---|---|---|
| Concurrent writers, no locks | ✓ | ✗ | ✗ | ✗ | ✓ |
| Immediate visibility (no pull/push/merge) | ✓ | ✓ | ✗ | ✓ | ~ |
| Automatic version history | ✓ | ✗ | ✓ | ✗ | ✓ |
| Atomic undo / rollback | ✓ | ✗ | ✓ | ✗ | ✓ |
| Per-user undo | ✓ | ✗ | ✗ | ✗ | ✗ |
| Real ACID transactions | ✓ | ✗ | ✗ | ✗ | ✗ |
| SQL escape hatch | ✓ | ✗ | ✗ | ✗ | ✗ |
| Durable, backed up like a database | ✓ | ✗ | ~ | ✓ | ~ |
| Available now / open / self-host | ✓ | ✓ | ✓ | ✓ | ✗ |
TigerFS keeps one shared source of truth and makes recovery selective and per-user, instead of forking into branches you later have to merge.
Install in under 60 seconds and give every file a history and an undo button.