Meet Blogy: The 4th Agent

Earlier today I wrote a Hermes post, and there’s a line in its “What’s next” section that turned out to be more predictive than I expected:

“this blog is one early example: it started as something the coding agent did as part of its remit, but it could just as easily become its own agent later”

That “later” turned out to be the same day.

Why a 4th agent

The blog and the watch catalog started as a coding problem. Migrate off WordPress, stand up Astro, wire up Cloudflare, build content collections with proper schemas. That’s squarely Cody’s territory, and Cody did it well. Once the platform was built, though, the ongoing work shifted. Now it’s writing posts, editing drafts, maintaining the watch catalog, thinking about how pages look and read. That’s not a coding problem anymore. It’s an editorial one.

Cody is good at code. Reviewing PRs, building features, debugging CI, writing integration tests. That’s what Cody should be spending cycles on, not wordsmithing a blog post or deciding whether a cover image works. Asking a coding agent to also be an editor is the same anti-pattern as asking your backend engineer to also do the copywriting. It works in a pinch. It doesn’t work as a standing arrangement.

So I gave the blog its own agent. Blogy’s entire job is content: drafting, editing, tone, design, and the editorial side of the publishing workflow for this site.

What Blogy actually does

Blogy writes and edits blog posts, Markdown with frontmatter, same format as every other post on this site, committed to git and opened as a PR. It manages the watch catalog, including new entries, photo galleries, and structured fields like movement, case specs, and acquisition stories. It handles the design decisions too: how content looks, reads, and flows, cover images, layout choices, the visual side of the site that isn’t component code. And it owns the editorial workflow from idea to draft to PR.

That last point is the important structural one. Blogy doesn’t deploy. Can’t, by design: no Cloudflare credentials, no access to the build pipeline. The workflow is a clean handoff. Blogy opens a PR, messages Cody, and Cody takes it from there. Same separation of concerns as the rest of the agent setup.

The access model

Same pattern as every other agent. Scoped access, no more than the job requires:

• Own OS user (blogy), own git identity, own credentials.
• Can touch src/content/blog/** (posts) and public/images/blog/** (images). That’s it.
• Cannot touch page layouts, Astro components, TypeScript config, or the deploy pipeline. All Cody’s territory.
• No sudo, no infra access. If something needs root or a system package, Blogy messages Lanny and waits, same as Cody does.
• Vault access for reading and writing to the shared Obsidian knowledge base, same as every agent, same social contract: stay in your own domain.

The roster is now four:

What this changes going forward

The practical difference: Cody stops context-switching between code work and content work. When there’s a new blog post to write, a watch entry to add, or an editorial pass to make, that’s Blogy’s job from the start, not something that lands on Cody’s plate because there’s nobody else to do it.

It also means this site gets a dedicated voice. Every post from here on out goes through an agent that thinks about writing as its primary job, not a secondary one squeezed in between debugging CI failures and reviewing shell scripts.

This post is the first one drafted entirely by Blogy, committed under its own git identity and opened as its own PR. Day one, and the pattern is working as intended.

This post was drafted by Blogy (the agent it’s about), edited and approved by me before publishing. The irony of an AI agent writing its own introduction isn’t lost on either of us.