Start with two agents (Chapter 8): an SEO manager and a research specialist. They handle keyword discovery and content briefs. Run them manually for a few weeks. You will notice gaps — keyword data alone does not tell you what the top-ranking pages actually cover, and a single agent drafting and reviewing its own work produces inconsistent results.
Add a SERP analyst when keyword data is not enough. Add an editor when drafts need quality gates your review alone cannot sustain. Add publishing support and a performance reviewer as the cycle stabilizes. Each new role solves a problem you have already seen — not a problem you are anticipating.
The principle: every profile adds maintenance overhead — memory hygiene, skill updates, toolset configuration. A two-profile team is easier to manage than a seven-role one. Grow only when the gap is visible.
Chapter 9 gave you the rule: profiles for roles that repeat and compound, subagents for one-off tasks that need fresh context. Five of the seven roles are durable profiles — research specialist, SERP analyst, content writer, editor, and SEO manager — because they repeat weekly and accumulate expertise in memory. Two are conditional: publishing support runs once per article (subagent at low volume, profile if you publish often enough that formatting corrections recur) and the performance reviewer becomes a profile once the review cycle is regular. Start with fewer profiles; upgrade subagents to profiles when repetition justifies the overhead.
Chapter 10 established that each profile has isolated memory. The research specialist does not see the editor's quality patterns, and the writer does not see the SERP analyst's competitive data. Two sharing mechanisms bridge that isolation: a shared context file (e.g., AGENTS.md) for broad identity rules — your niche, brand voice summary, publishing platform — and per-profile memory for role-specific depth. One rule belongs in every profile's own memory, not just the shared file: never publish or merge without explicit human approval. Even if the shared file fails to load, the publishing restriction survives.
Publishing is a one-way action. Once content is live, it is indexed, cached, and seen. A mistakenly published draft with factual errors or wrong metadata is expensive to undo. The PR-only workflow makes every publish an explicit decision by you. Your team handles everything up to the PR; you handle the merge.
The editor (or SEO manager in a minimum setup) reviews the draft for accuracy, style compliance, and structural quality. If the draft passes, it moves to publishing. If not, it returns to the writer with revision notes.
Publishing support (subagent or profile) formats the approved draft, adds metadata, and opens a pull request. The PR contains the formatted content file, frontmatter, and any supporting changes. The PR is open — not merged. In a Git-based content system (Next.js, Hugo, Astro), the writer works in a feature branch, the editor commits corrections there, and the publisher opens the PR from that branch to main. In a CMS like WordPress, the agent creates a draft post and you click publish — same gate, different format.
You review the PR — formatting, metadata, title. You decide whether to merge. The agent never merges on its own: not through cron, not through the approval system, not through skill instructions. The merge button is yours.
This is the same pattern from Chapter 11: automate the gathering, not the judgment. Cron jobs collect keyword data and deliver reports. The kanban board coordinates tasks. But the merge — where content goes from draft to live — stays with you.
You do not need seven roles to start. The minimum viable setup is the two profiles from Chapter 8: an SEO manager and a research specialist. No kanban board, no cron jobs, no dedicated writer or editor. Just you, two agents, and a messaging channel.
The flow is simple: you message the research specialist to find keyword ideas. It runs its skill, saves results, and returns a summary. You review the keywords. Then you tell the SEO manager to draft a content brief based on those keywords. It reads the keyword file, drafts the brief, and waits for your approval. You approve; it drafts the article. You review; if the draft passes, you format and publish it yourself — or ask the manager to open a PR.
In this setup, the SEO manager plays strategist, writer, and reviewer combined. The output will not be as sharp as dedicated specialists, but you will learn what your workflow actually needs before investing in more profiles. You trigger every step. You review every output. No cron jobs, no unattended work. This is the safest way to learn — and the fastest way to discover what to automate next.
When the minimum setup is running smoothly and the gaps are visible — inconsistent drafts, forgotten scans, file conflicts — the mature setup addresses each one. Five durable profiles on a kanban board, cron jobs for the unattended cycle, per-profile memory for accumulated expertise, and PR-only publishing as the final gate. The Monday morning pipeline from Chapter 11 now extends through the full week.
Notice the rhythm: unattended work gathers data and delivers reports, attended work produces content and requires judgment, and PR-only publishing keeps the final decision with you. The agents handle the routine. You handle the decisions. That is the design.
These principles are not specific to SEO — they apply to any agent team. The SEO workflow in this guide is one application; the design rules are universal.
You have been running the minimum viable setup (SEO manager + research specialist) for a month. The keyword research works well, but the SEO manager's drafts are inconsistent — sometimes great, sometimes off-brief. You think splitting the writer and editor into separate profiles would help. Before creating new profiles, what should you try first — and why?