A working playbook for running a multi-brand content, SEO, and AI-citation operation on scheduled AI agents.
This is not a concept post. It is the extracted, generalized architecture of a live system that publishes researched, sourced, on-brand content to five sites on a fixed weekly cadence, with no human in the loop on a normal day. It has been running since early 2026.
The docs are written to be handed directly to an AI agent (Claude Code, or anything with file and shell access) which then interviews you about your brands and builds the system. They also read fine as a playbook if you would rather build it yourself.
git clone https://github.com/hessabi/agentic-content-engine.gitThen point your agent at it:
Read all five docs in
docs/. Then interview me about my brands and stack, and build the setup described in doc 01. Start with one brand only.
Do not skip the intake questions in doc 00. Half of what makes this system work is brand-specific configuration, and an agent cannot guess it.
| Doc | What it gives you |
|---|---|
| 00-start-here | Prerequisites, the 14 intake questions, the 8-phase build order, honest expectations |
| 01-content-engine-setup | The full build: directory layout, both config files, the brief schema, both routine prompts, and the quality gate, all copy-paste ready |
| 02-seo-playbook | The content standard your routines enforce, hard technical rules, strategy sequencing, measurement scripts, traffic-drop diagnosis |
| 03-llm-geo-plan | Getting cited by ChatGPT, Perplexity, and AI Overviews: target prompts, on-page tactics, IndexNow, entity consistency, measurement |
| 04-agent-ops-patterns | The patterns that keep an agent system from rotting: grounding, gating, memory, alerting, cost control |
Split research from writing into two scheduled agent runs several hours apart, with a reviewable brief file between them. Keep all brand policy in flat config files the agents read at runtime, never in prompts. Ground every product claim in a document regenerated from the codebase. Put a self-review gate before the irreversible action and make "refuse to publish" a first-class success outcome. Write every page answer-first so an AI engine can lift a complete, correct, self-contained answer that names you. Push new URLs to Bing via IndexNow immediately, because ChatGPT search rides Bing's index. Post everything to a channel so silence becomes an alarm.
Most people ask one agent to "write a blog post." That produces generic, unsourced content, because the model has no time to think and nothing fresh to work from.
3:00 AM RESEARCHER
reads config + published log + live web + product truth doc
writes: data/briefs/<date>-<brand>.yml <-- reviewable checkpoint
|
(3 hour gap: you can intervene)
|
6:00 AM PUBLISHER
writes draft -> RUNS THE GATE -> fails? delete, alert, move on
| passes
commits + pushes -> deploys -> pings sitemap + IndexNow -> notifies
Research and writing are different tasks with different failure modes. The brief between them is a file you can read in 20 seconds, and when a bad post ships it tells you instantly whether the idea was wrong or the execution was wrong.
- Information gain is a compliance rule, not a nicety. Thin, duplicative auto-published content trips Google's scaled-content-abuse pattern and suppresses the entire domain. This is the biggest risk in automating content, and the reason the gate exists.
- A gate that has never blocked anything is decoration. Test yours by deliberately feeding it a fabricated statistic. If it publishes, you do not have a gate.
- Agents for judgment, scripts for determinism. Anything with one correct answer a computer can compute should be a script the agent calls, not something the agent reasons about.
- Name yourself in your own opening paragraph. If a model lifts a sentence that says "our platform," you supplied the answer and someone else gets the mention.
- Silence must be an alarm. The most common way these systems die is failing quietly for three weeks.
The default failure of an automated content system is that it settles. It publishes on schedule, nothing is wrong with any individual piece, and the whole body of work is forgettable. Consistency is what automation buys you cheaply, and consistency alone produces a competent B+ that nobody links to, quotes, or remembers.
Do not accept that as the ceiling. The bar is a piece a knowledgeable reader could not have written themselves and cannot find stated as well anywhere else. Three things get you there, and only the third is free:
- Cadence is the dial, not the goal. Quality per piece is a budget divided by frequency. Three posts a week at a fixed research budget is B+ arithmetic. Drop to one and every piece gets three times the research, a real revision pass, and room to be held back. Publish less on purpose.
- The gate checks the bar, not the floor. A gate that only asks "is anything fabricated" enforces a floor. Make it ask the hard question too: does this contain at least one thing, a number, a mechanism, a named comparison, a lived detail, that the reader cannot get from the first three results already ranking? If not, it fails, and the day is skipped. Your held-back rate should be visibly non-zero. See doc 04 section 3.
- Human taste goes into the brief, not the draft. The expensive judgment is deciding what is worth saying. Editing a finished draft is the wrong place to spend it. Read the brief, which takes twenty seconds, and change the angle there. That is the highest-leverage minute you will spend on the system.
Strategy, positioning, and taste are still not automated here on purpose. The system will faithfully execute a wrong strategy indefinitely without ever noticing, and it will publish a competent piece about nothing forever if the brief lets it.
The reference implementation is Next.js App Router on Vercel with MDX content and push-to-main deploys. Nothing here is Next-specific except a handful of gotchas that are labeled as such. Astro, Hugo, Eleventy, Jekyll, and SvelteKit all work identically, and the docs tell your agent to adapt paths and metadata shape while keeping everything else.
The one non-negotiable prerequisite: your blog has to live in your repo as files. If it lives in a hosted CMS, that is the first thing to change. Everything downstream depends on content being source code.
Issues and PRs welcome, particularly:
- Adapted setups for other stacks (Astro, Hugo, Eleventy) as additions to doc 01
- Gotchas you hit that belong in the lists
- Corrections where the search or AI-engine landscape has moved
The docs carry a July 2026 research snapshot. Anything time-sensitive should be verified against primary sources before you act on it.
MIT. Copy it, adapt it, ship it.
Built and maintained by Amir Hessabi, founder of Yikes Dude LLC, where this system runs in production across five brands.
I also do 1:1 Claude training and workflow automation: yikesdude.com/learn