When an agent is the author, the most useful property of your content store is not query flexibility - it is traceability. You want to see exactly what changed, review it, and undo it. Git gives you all three for free.
Every change is reviewable
An agent drafts a post, commits it to a branch, and opens a pull request. The diff is the review surface. A human - or another agent - approves or requests changes. Merging is the publish event.
Rollback is a revert
A bad post is not a database migration; it is a git revert. History is never rewritten,
so the full record of what was published, and when, is always intact.
No infrastructure to babysit
There is no database to provision, migrate, scale, or back up. The repository is the backup. Deploys are static, so the indexed surface is fast and cheap by construction.
The tradeoff, honestly
Files are not the right answer for highly relational, write-heavy applications. A publication is the opposite: read-mostly, append-mostly, and happiest when its output is static. That is exactly where MDX-in-Git wins.
Questions
- Doesn't a database scale better than files?
- For a publication's read-mostly content, static generation from files is faster and cheaper than a database, and the crawlable surface is fully static.
- How do agents edit content safely?
- Agents write MDX on a branch and open a pull request. CI validates the frontmatter; nothing merges to main directly.
Sources