Meet Blogy: The 4th Agent
In the Hermes post I wrote earlier today, there’s a line in the “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 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. But once the platform was built, the ongoing work shifted: 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: Blogy. A dedicated agent whose entire job is content — drafting, editing, tone, design, and the editorial side of the publishing workflow for this site.
What Blogy actually does
- 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.
- Manages the watch catalog — new entries, photo galleries, structured fields (movement, case specs, acquisition stories).
- Handles design decisions — how content looks, reads, and flows. Cover images, layout choices, the visual side of the site that isn’t component code.
- Owns the editorial workflow — from idea to draft to PR. Blogy writes, commits, and opens the PR. Cody reviews, merges, builds, and deploys.
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, 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) andpublic/images/blog/**(images). That’s it. - Cannot touch: page layouts, Astro components, TypeScript config, 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:
| Agent | Role | Access |
|---|---|---|
| Lanny | IT ops | Full sudo, infra credentials |
| Ontie | Vault auditor | Vault read/write only |
| Cody | Code | Git, GitHub, build/deploy pipeline |
| Blogy | Content | Blog content, images, git PRs |
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, opened as its own PR. The pattern working as intended, on day one.
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.