Agents Are Cron Jobs and Markdown Files

"The big thing everybody needs to remember about agents is that they are cron jobs and markdown files."

Ryan Carson said this in a conversation with Peter Yang about running his startup solo with AI agents. He runs a two-agent stack: OpenClaw for business development and Devin for engineering. They ship 10-20 PRs a day, generate real sales meetings from automated prospecting, and manage Google Ads through a CLI built by an agent.

He does all of this alone.

This is the most honest description of what agents actually are. Not magic. Not AGI. Schedulers that read instructions from plain text files and execute them. The abstraction maps directly to concepts developers already understand.

The Cron Job Model

The core insight is that agents work best when treated like infrastructure. You write a file, set a schedule, and the system executes. No chat windows. No prompts. No sessions.

Carson's OpenClaw skill for automated prospecting runs daily. It searches for divorce attorneys via the Firecrawl API, scrapes their LinkedIn profiles, logs the data to a Google Sheet CRM, drafts a cold email from his domain, and sends it. It generated 10-20 meetings in a couple weeks entirely on its own.

The same pattern applies to Devin. Weekly full case coverage: an automation that walks through the entire user experience from sign-up to completing a divorce case. It runs using a playbook that encodes the testing flow as deterministic steps. It works because it is not creative. It follows a script.

This matches what I have been building with my agent loops. My orchestrator dispatches work to agents on a schedule. Each job reads from a markdown-based instruction set. The difference is I built my own harness while Carson uses stock OpenClaw with custom skills and crons. He made a deliberate choice not to build custom infrastructure.

"There's this temptation to build your own. Then you end up maintaining it instead of working. I've decided: out-of-the-box OpenClaw with custom skills and custom crons, and just call it a day."

That tension is real. I spend time maintaining my orchestrator. He spends that time on his business. Which approach wins depends on whether you are building agent infrastructure as a product or using agents as a tool to run something else.

The Markdown File as the Universal Interface

The markdown file is the most underrated piece of this stack. Instructions, skills, system prompts, style guides, test plans, deployment runbooks all belong in markdown.

I wrote about this in Everything Is Markdown Now. The reason markdown works is it is version-controllable, diffable, composable, and model-agnostic. An instruction written in markdown today works with Claude, works with GPT, and will work with whatever comes next. A skill encoded as a chat conversation inside one vendor's UI is trapped there.

Carson pushed this further than I have seen anyone else do. His Devin playbook for weekly case coverage tests the real application from end to end. His content marketing pipeline interviews experts via Descript, chops the recording into 60-second clips, has Gemini describe the video, has an OpenAI model generate cover art, and posts to social via the Publer API. Every step in that pipeline is encoded as instructions.

The Google Ads CLI is another example. Rather than use the Google Ads UI, Carson had Devin build a CLI tool. Now he manages campaigns by chatting with an agent. The agent becomes the interface to the system, and the underlying API is abstracted away.

Reversing the Startup Playbook

"In startups we used to say just do the bare minimum to get the MVP out. Do not spend time on systems or processes or documentation. That's literally reverse now."

This reverses the old startup playbook. The old advice assumed human labor was the bottleneck. Documentation cost more than it saved because nobody would read it. Processes slowed you down. Systems were overhead.

With agents in the loop, that calculus inverts. Documentation is not overhead. It is the instruction set your agents execute. Processes are not drag. They are the pipeline your work flows through. Systems are the factory floor.

The founders who treat documentation and systems as investments rather than costs will have an asymmetric advantage. They can onboard and retrain an agent in seconds. "It's almost easier to onboard and train agents than to train humans. It's a million times easier."

Carson paid a designer for initial branding then used those assets as reference images plus a design.md to produce unlimited branded imagery through an image model. One investment in the system, infinite output.

Where I Push Back

I do not agree with everything Carson does. His decision to avoid building any custom harness works for him because OpenClaw and Devin cover his use cases. My orchestrator handles patterns that off-the-shelf tools do not support: cross-repository worktrees, quality gates that run before PR creation, and a self-learning loop that updates its own instructions based on feedback.

The right answer depends on what you are building. If your agent workflows are straightforward cron-skill pairs, buy the off-the-shelf tool. If you need non-standard orchestration patterns, you will eventually need to build.

The distinction that matters is not buy versus build. It is whether your agent stack treats instructions as infrastructure. Carson chose buy. I chose build. Both of us chose markdown files and schedules. That is the pattern worth adopting regardless of which vector you pick.

What This Means

The rate at which solo founders and small teams can operate is changing. Carson ships 10-20 PRs a day alone. He runs sales prospecting without touching a tool. He manages ads through a conversation with an agent.

Take the time to set up the system to do the work. You suddenly are unlocked and you are doing the work of 10 people.

The barrier is not technology. It is the willingness to invest in systems before you need them. Pick documentation over speed and the factory over the feature.

If you are building agent workflows today, start with the simplest possible abstraction: a schedule and a markdown file. That is enough to ship. You will figure out the rest when you need it.