Chihkai's blogThe Local Loop Behind an Agentic Blog
A blog can be maintained with an agent without turning publishing into a black box. The useful shape is a local loop: the agent writes against ordinary files, renders the exact result locally, and brings the work back for review before anything goes live.
The loop is deliberately small:
The point is not to automate judgment away. It is to make each pass cheap enough that judgment can happen more often.
Start with a request, not a CMS form
A post begins in conversation. That might be a rough idea, a few bullets, a request to revise an older draft, or feedback on a paragraph that is almost right.
The agent reads the blog’s settings and existing posts first. That gives it the surrounding context: the site voice, the kinds of topics already covered, and the metadata conventions that readers will encounter. It can then draft a new Markdown post, improve an existing one, adjust a description or tags, or prepare an image asset.
The content itself stays boring in the best sense. A post is a Markdown file with frontmatter for its title, date, description, tags, and draft status. The site’s identity—its title, author profile, theme, and publishing policy—lives beside the posts in a small settings file.
Treat the local render as the source of truth
Writing the Markdown is only half of authoring. A heading can be clear in a file and awkward on a phone. A long title can disturb the reading rhythm. A table of contents can be helpful on a wide screen and distracting on a narrow one.
After a change, the agent builds the static site locally using the same blog engine that will produce the public pages. It opens that build in a browser and captures desktop and phone views.
That check is a concrete part of the writing loop, not a ceremonial final step. It catches the places where content and presentation meet:
- whether the title, description, date, and tags read well together;
- whether Markdown elements render as intended;
- whether navigation, search, and topic links still make sense;
- whether the post remains easy to scan on a small screen; and
- whether the table of contents earns its space.
The preview is especially useful because it keeps feedback tied to a real page. Instead of discussing an abstract draft, we can say that a paragraph is too dense, a heading is too vague, or the opening needs more room to breathe—and immediately see the result of a revision.
Revision is the loop, not a detour
Once the local build is ready, the agent brings the draft and its preview back for review. Feedback returns to the beginning of the loop: revise the post, build again, inspect again.
That makes the system collaborative without making it fragile. The agent can handle the mechanical work—editing frontmatter, maintaining slugs, normalising tags, producing excerpts, and building the site—while the author keeps responsibility for the ideas, claims, and final wording.
The important boundary is simple: creating a draft is not the same as publishing it. A post is only committed and sent to the public site after an explicit approval.
Publish last
When the draft is approved, the managed content repository is committed and pushed. From there, the path is intentionally uncomplicated:
Approved content
↓
GitHub Pages publish
↓
Public blog
The blog engine and the content repository remain separate. The engine is responsible for rendering, layout, and preview capability. The content repository holds the writing, assets, blog settings, and publishing history. Keeping those roles apart means the writing remains portable and versioned even while the engine evolves.
For a personal blog, that is the real benefit of the loop. It is local enough to inspect, structured enough to manage, and lightweight enough to keep publishing.
Comments