Run Your Company on the Command Line

I spend my days running an AI agency, building autonomous systems for clients. We often start with the industry standard stack: a powerful LLM connected to a Postgres database, perhaps mediated by something modern like a Supabase MCP Server [1].

It sounds robust. In practice, it is a nightmare of friction.

When you force an agent to interact with a database, you force it to play a guessing game. It has to understand schemas, manage connection pools, navigate foreign key constraints, and format rigid SQL queries. If the schema changes, the agent breaks. If the agent hallucinates a column name, the pipeline crashes.

I realized there is a better way. It requires unlearning the last decade of SaaS architecture and embracing a simpler truth: coding agents work best with files.

The ‘CMS’ Folder Pattern

While experimenting with local tools, I discovered a data structure that works incredibly well for autonomous agents. I call it the ‘CMS’ folder. It looks like this:

cms
├── client-notes
│   ├── 001-jdoe.md
│   └── 002-acme-corp.md
├── clients
│   ├── 001-jdoe.md
│   ├── 002-acme-corp.md
│   └── 003-jsmith.md
├── invoices
│   ├── 001-jdoe.md
│   ├── INV-JDOE-0001.pdf
│   └── INV-JDOE-0002.pdf
├── projects
│   ├── 001-website-redesign.md
│   └── 002-mobile-app.md
└── suggested-replies
    └── 001-jdoe.md

This isn’t just a directory of text files. It is a database optimized for Large Language Models.

The secret lies in the file format: Markdown with YAML Frontmatter.

The Goldilocks Format

In a traditional database, you have structured data (columns like id, name, email). In a document store, you have unstructured text. Real business data is a messy hybrid of both.

A client isn’t just a row in a table. They have an ID and an email (structured), but they also have a history of conversations, specific preferences, and nuance (unstructured).

Frontmatter-Markdown bridges this gap perfectly.

---
id: "001-jdoe"
name: "John Doe"
status: "active"
rate: 150
---

# Client Context
John prefers weekly updates via email. We are currently prioritizing the invoice automation agent.
**Note:** Do not deploy on Fridays.

This format is native to LLMs. They are trained on it. They understand that the top section is metadata (the ‘database’ part) and the bottom section is context (the ‘knowledge’ part).

Why Files Beat Databases for Agents

In my recent post on Agentic Tools, I argued that code is the only tool an agent needs. This extends to data storage.

When I task an agent with ‘updating the client roster,’ I don’t want it wrestling with an INSERT statement via an abstract API. I want it to use tools it intuitively understands: File Search, File Modify, and File Save.

1. Flexibility: If an agent needs to add a note about a client’s vacation, it doesn’t need a schema migration. It just appends a line to the Markdown file.
2. Visibility: The agent can read the entire file to get full context before making a decision. It sees the relationship between the metadata and the notes instantly.
3. Simplicity: There are no connection strings. No timeouts. No authentication headers. Just read() and write().

The ‘Git’ Safety Net

Moving from a database to the file system unlocks the ultimate safety feature for Agentic Companies: Version Control.

If an agent executes a bad UPDATE query on a production Postgres database, you have a crisis. You are restoring backups and praying.

If an agent overwrites a file in a Git-backed CMS folder, you have a minor inconvenience. You run git revert.

This allows me to give my agents a level of autonomy that would be terrifying in a database-driven environment. I can let an agent manage invoices, edit website copy, or update project status files because every action is a commit. The history is the audit log.

Inspiration from the Trenches

I am not alone in this thinking. I recently watched a talk by Rene Schallner, who demonstrated running his entire business using a custom CLI tool and a Git repository [2]. He generates invoices, manages clients, and tracks expenses without a single traditional database.

While he built a custom Zig binary for his specific needs, the underlying philosophy validates exactly what I’ve found running my agency:

1. State is Text: Human-readable, machine-parseable.
2. Interface is CLI: Deterministic input, structured output.
3. Storage is Git: Versioned, distributed, secure.

The Architecture of the Future

The future of the agentic enterprise isn’t a smarter ERP system. It’s a smarter file system.

The industry is currently excited about protocols like MCP to help agents talk to databases. But this is just a better pipe to the same brittle destination.

By moving business logic into CLI tools and business data into frontmatter-markdown files, we lower the cognitive load for our agents. We remove the layers of abstraction that cause errors. We treat our company operations with the same rigor and flexibility as our software codebases.

If you want to build truly reliable agents, stop giving them database credentials. Give them a file path.

References

1. Supabase MCP Server
2. Running your Company on the Command-Line with Zig, LaTeX, Git, and ZAP!