Building an Agent-Native SEO Department

This was not a writing demo. I designed an agent-native SEO production department: a system that could take a structured brief, coordinate specialized agents, assemble a media-rich article, move it through human approval, and publish it into a real company’s CMS.

The production claim is intentionally specific: 40+ articles were produced, 7–8 entered the first public rollout, and a typical article took about 90 minutes to create. The article copy and infographics were generated by agents; humans reviewed and approved the package before publication.

Published evidence

The output is public, not hypothetical.

The live article shows the actual content package: long-form structure, custom SVG infographics, embedded video, internal links, FAQs, and conversion paths.

Lead generation infrastructure infographic produced by the SEO agent system — Generated infographic 01
A production SVG embedded inside the published Marketing.MBA article.

Lead generation system diagram produced by the SEO agent system — Generated infographic 02
A second article-specific visual generated and packaged by the same workflow.

The business reality

The hard part was not prompting a model to write. It was fitting autonomous work into an operating business: managers needed control over what entered production, reviewers needed clear approval boundaries, and the existing Framer CMS needed to remain the publishing surface.

That meant solving for coordination and accountability as much as content quality. The system had to produce a complete article package, expose it to a human at the right moment, and keep publication operationally simple enough that a manager could run it from Airtable.

System architecture

A control plane around a four-agent production cell

Airtable control planeBriefs, production state, and manager-facing controls.
Manager agentPlans the run, delegates work, and assembles the result.
Three specialistsProduce the research, article, rich media, and packaging work.
Human approvalA person gates the finished package before it can go live.
Framer proxyTransforms approved output into a Framer CMS publication.

The moving signal illustrates orchestration, not a fixed linear runtime. Agents can hand work back for revision before the approval boundary.

The separation was deliberate. Airtable acted as the operational control plane, agents handled production, the approval gate retained editorial accountability, and the custom proxy isolated Framer-specific publication logic from the agent workflow.

System evidence

The run is inspectable at every boundary

These interfaces document the manager contract, the versioned writer skill, a real multi-tool research trace, and the persistent artifact produced by the run.

Configured SEO manager agent with research, writing, and outreach specialists, skills, GitHub, Airtable, and a human approval instruction — **Delegation and the human gate**
The SEO manager names its research, writing, and outreach specialists; attaches canon and Airtable skills; and explicitly stops with the final approval owned by a human.
Open full-size evidence →

One article, end to end

From a queued brief to a CMS-ready article

01
Queue the brief
A manager creates or updates the production item in Airtable.
02
Plan and delegate
The manager agent decomposes the job and routes work to three specialized sub-agents.
03
Build the content package
The system produces long-form copy, SVG infographics, video embeds, internal links, and page structure.
04
Review the whole artifact
A human reviews the assembled article rather than supervising every generation step.
05
Publish through the proxy
Approved fields are transformed and sent into the existing Framer CMS workflow.

Engineering decisions

The architectural value sits in the boundaries: where control lives, how work is split, and what an agent is never allowed to decide by itself.

Use Airtable as the operating interface

Constraint: The system had to fit the team's daily operating reality, not require employees to learn an agent framework.
Decision: Expose briefs, states, and approval actions in Airtable while keeping orchestration behind the interface.
Consequence: Managers could operate the production system from a familiar control plane, while the implementation remained replaceable.

Separate orchestration from specialist work

Constraint: A single prompt had to cover research, long-form structure, rich media, linking, and publication packaging.
Decision: Use one manager agent to coordinate three specialized sub-agents and assemble their outputs.
Consequence: Each capability could evolve independently without turning one prompt into the entire production department.

Put Framer behind a publication proxy

Constraint: Framer CMS was the required destination, while Airtable was the operational source of truth.
Decision: Build a custom proxy that translated approved Airtable-backed output into Framer CMS operations.
Consequence: CMS-specific mechanics were isolated from content generation, and publication could be triggered from the production workflow.

Keep the final boundary human

Constraint: The system was creating public, brand-bearing assets for a real business.
Decision: Automate production end to end, but require human approval before publication.
Consequence: People retained accountability for what went live without becoming the writing bottleneck.

The prompt contracts

The current “Reloaded” prompt set made the architecture operational. Writing, persistence, verification, and approval were separate responsibilities, while file-based artifacts preserved the full handoff between agents.

Prompt evidence

The architecture was encoded as enforceable roles.

Selected exact lines from the internal production prompts show the control boundaries behind the diagram. These are implementation evidence, not reconstructed marketing copy.

You do not do the specialist work yourself unless a tool or delegation failure makes that impossible. You are still accountable for confirming that the work actually happened.
SEO Manager — Reloaded
The manager owned delivery and verification without absorbing every specialist responsibility.
The Writer reads the file in full, so the file is the source of truth.
SEO Research Specialist — Reloaded
Agent handoffs were inspectable artifacts rather than lossy chat summaries.
This skill writes the article asset. It does not approve, publish, mark AI Done, or verify Airtable persistence.
/seo-writing — Reloaded
The newer contract separated generation from staging and independent verification.
You may set Status to "AI Done" only after all required acceptance checks pass. You must never set Status to "Approved" or "Published".
/seo-run-verification
The agent could advance work to human review, but it could not self-approve or publish.

Excerpts retain the original wording. Only architectural instructions are shown; operational identifiers, credentials, and client data are excluded.

What needed to hold up in production

The important questions were operational: could a long run preserve state, could specialist outputs be assembled consistently, could rich media survive the handoffs, and could publication be retried without turning the CMS into a mess?

The prompts, skill configuration, execution trace, artifacts, and Airtable state now document the control model directly. The remaining evidence gap is narrower: the Framer proxy lifecycle, retry behavior, and a multi-run timing sample would substantiate the final publication hop and the ~90-minute typical cycle more completely.

Internal system evidence

The production system behind the articles.

These are real Airtable production views, not staged mockups. They expose the workflow, structured content fields, publication state, and generated media payloads behind the public output.

Airtable production table showing AI-complete and published SEO articles with titles, hero images, slugs, target keywords, article bodies, metadata, funnel stages, and schema fields — Control plane · production state
The working production table shows AI-complete and published articles alongside their SEO title, hero image, slug, target keyword, article body, metadata, funnel stage, and schema fields.

Airtable table showing article records with multiple generated SVG infographic fields and placement instructions — Rich media · generated SVG payloads
The article queue carries multiple structured SVG fields per record, with placement instructions and production notes stored beside the content.

Internal evidence queue

Evidence I would add next

Reserved for real screenshots and traces. No mock data is presented as evidence.

IntegrationFramer proxy lifecycle
Explain field mapping, media handling, retries, and the final CMS write path.
RuntimeProduction timing sample
Use timestamps or traces to substantiate the ~90-minute typical cycle across multiple runs.
RecoveryFailure and retry trace
Show how a partial media or CMS failure resumes without duplicating or corrupting a publication record.

Outcome

The system produced more than 40 articles and moved 7–8 through the first publication wave. The first pages began generating impressions within days, but the rollout ended during an organizational transition before a meaningful analytics window matured.

So this case study does not claim a long-term traffic or revenue result. What it can demonstrate today is a working production architecture, a public output artifact, a ~90-minute production cycle, and the operational design required to put agent-generated work in front of a real audience.

Limitations and next evidence

Long-term SEO performance is not available yet, so early impressions are treated as a signal rather than an outcome.
The public article proves output quality and media packaging, but not the internal orchestration by itself.
Exact runtime failure examples and proxy retry behavior will be added only after the underlying traces and proxy code are reviewed.
The visible tool trace proves one research sub-run, not the full ~90-minute production cycle.

What this system proves

Production agents are not defined by how impressive one generation looks. They are defined by whether the surrounding system can coordinate work, preserve accountability, integrate with existing tools, and reliably turn an approved artifact into something the business can use.