Building With AI Agents: Why the Filesystem Is the Interface
AI agents work best when you meet them where they already are — the filesystem. Here's why otageLabs chose markdown files over a CMS, and what it means for how we build and publish.
There's a moment in every project where you choose between the tool that looks right and the tool that works right. For content publishing, that choice usually lands on a CMS — something with an admin panel, a database, a WYSIWYG editor. The whole stack.
We went a different direction.
The problem with traditional publishing
A CMS adds operational overhead that scales with complexity, not with value. You get database migrations, admin authentication, content tables, editor maintenance. Every layer is another thing that can break, another thing that needs updating, another thing between you and the words on the page.
For a solo engineering practice, that overhead isn't justified. But there's a deeper issue: AI agents can't use admin panels.
Meeting agents where they are
Claude Code — the AI agent I use daily — is exceptional at working with files. It reads them, writes them, understands their structure. Ask it to create a blog post, and it can write a markdown file with valid frontmatter in seconds. No API integration. No browser automation. No authentication flow.
The filesystem is the interface.
content/blog/2026-02-10-building-with-ai-agents.md
That's it. One file. Frontmatter for metadata, markdown for content. Commit and deploy. The post is live.
What this looks like in practice
Every blog post is a markdown file in content/blog/. The naming convention — YYYY-MM-DD-slug.md — gives you chronological ordering for free. The frontmatter handles everything else:
- title — what appears on the page
- slug — the URL path
- date — when it was published
- tags — for categorisation
- summary — for the index page and SEO
- published — the on/off switch
Set published: true, push to main, and the build system does the rest. Static generation means zero runtime overhead. No database queries. No API calls. Just HTML.
The builder's choice
This isn't the sophisticated choice. It's the practical one. The same principle that drives every decision at otageLabs: build what works, not what impresses.
A markdown file in a git repository is version-controlled, diffable, portable, and works with every tool in the development chain. It's the kind of unsexy infrastructure that quietly makes everything else easier.
The best tool is the one that disappears into the workflow.
That's what we're building here. Not a publishing platform. A publishing workflow — one that humans and AI agents share equally.