Run an autonomous agent that publishes your app's content, on a Mac you never use

A friend asked me how I run my agents. I answered with fourteen minutes of messages. Then I reread it, and it was unreadable.

The problem is that I had never written the procedure down. I rebuild it from memory every time, in an order I reconstruct on the spot. So here it is in full, in order, with the two rules that actually matter at the end.

First, an admission

I’m useless with VPSes. Everything I describe here runs locally, on a Mac I barely use anymore. No container, no orchestrator, no cloud.

That sounds like a weakness. It’s mostly the reason I can talk about it: if this works on a machine that’s just sitting there, the barrier isn’t infrastructure. It’s somewhere else, and I’ll get to it.

The hardware

A computer you don’t use much. A Mac does the job, a VPS too if you know your way around one. A terminal. That’s it.

Everything below is driven in plain language, through Claude Code. You’re not going to write an install script.

Step 1: the base

You open a terminal on the dormant machine, launch Claude Code, and tell it:

install the latest version of Hermes with home path ~/Tech/auto-content-evolum/, run a clean git init inside it, and push to a private repo

It figures it out. This is exactly the kind of task it’s good at: many steps, no decisions.

Then you go check on GitHub that everything is actually there. This looks like a formality. It isn’t. A base you can’t re-clone somewhere else isn’t a base, it’s a workstation. The day the machine dies, you want to start from a clone, not from memory.

Step 2: the brand context

You launch a second Claude Code, in ~/Tech/, and have it clone the repo of the app itself. For Evolum, that’s evolum_app/.

Why the app’s repo when we’re talking about content? Because it holds the branding, the art direction and the landing page.

This is the part nobody notices, and it’s the most important one in the whole procedure:

Your content capability doesn’t start from a tone-of-voice prompt. It starts from the product repo.

An agent you tell to “write in a warm, expert tone” invents a brand. An agent that reads your landing page, your colors, your store screenshots and your existing copy has nothing to invent. The quality gap between the two isn’t marginal, it’s total.

For access, you generate a personal access token with restricted scope. It goes into neither a commit nor a message.

Step 3: the interactive setup

At some point the installer tells you it’s an interactive interface and waits for answers. That’s not a crash.

You open a new terminal, answer the questions, and come back to the first one. It’s the only part of the procedure that isn’t automatable end to end, and it takes two minutes.

Step 4: Telegram

Back to the first agent. You ask it:

start Telegram, give me the gateway, and give me all the steps

At the end, you have a Telegram bot wired to your agent. You can talk to it from your phone, by text or by voice.

This is the moment it becomes real, and it’s also the moment most people make the mistake I describe below. Keep this sentence in mind: what you just plugged in is a remote control. Not a workshop.

Step 5: the morning cron

create a cron every morning that runs whatever is in auto-content-evolum/

In that folder, you put an AGENTS.md declaring what the agent is allowed to use: skills, scripts, browser, external APIs. If you ask it to use that file before it exists, it will tell you it doesn’t and offer to initialize it. Accept, then read what it wrote. This is the file that defines its scope. You don’t let it write its own scope unread.

From there, the machine wakes up on its own in the morning.

Step 6: build the capability, by hand

This is the last step and the only one where you actually build something.

You go into the folder and say:

I want to create content for Evolum using Google AI Studio (the API key goes into a gitignored .env) and a cross-platform publishing API

For publishing I use upload-post, which exposes its documentation as llm.txt (docs.upload-post.com/llm.txt), so the agent reads it directly instead of you copying it over.

And then you build the thing together. You don’t delegate this step. Which brings me to the two rules.

Rule 1: from Telegram, you create nothing

The rule I hold myself to, and the only one that has survived over time:

From Telegram, you create nothing. You only modify .md files or code. To create, you go to the computer, with an architecture. If it’s an app, with an SDD.

The phone modifies. The computer creates.

This isn’t about trusting the model. It’s that creating means laying down a structure everything else will inherit, and a structure laid without an architecture is debt you only see the day it costs you. Modifying is reversible, and it reads back as a diff.

The real value of putting it this way is that it’s verifiable from the outside. A rule written into a prompt is an intention: it dilutes as the context grows, and nobody can confirm it was respected. A channel can be. You look at which channel the request came through and you know which permission applies.

And it survives being tired. At 11pm, on a phone, you don’t ask yourself whether your request is reasonable. You just notice it’s coming through the wrong channel.

Rule 2: one guardrail per output type

The advice I’d give someone starting out, and I’d give it before anything else:

Be as deterministic as you can. For every type of AI output, keep a guardrail. Template the structure, vary the combinations.

The structure is fixed and testable: the template, the fields, the lengths, the format. The variation lives in the combinations: which angle, which proof, in what order.

An output that varies in its structure isn’t creative, it’s unverifiable. You can’t write a test against “good content”. You can write one against a template.

And a guardrail rejects. If all it does is flag, it isn’t a guardrail, it’s a log. A log nobody reads protects nothing.

Why I insist: the Faros report on real teams shows pull requests up 98%, but also incidents per pull request up 242.7%, bugs per developer up 54%, review load up 441%, and final delivery metrics flat.

Translated for what we’re building here: a machine that produces without guardrails doesn’t save you time, it manufactures volume for you to check by hand. That’s the exact opposite of what you were after.

What I don’t know yet

This procedure works, it runs, and I’ve never presented it as finished.

What it’s missing is an honest inventory of what it has broken. A capability nobody can name a failure for isn’t reliable, it’s just poorly watched. I’m keeping that log now, and it’s probably the next article.

In the meantime, if you’re building yours: start with rule 1. Everything else installs in an evening, but that rule is what decides whether in six months you have a capability or a pile of files nobody dares touch.