Agentic content ops: running a full content cycle with an L2 agent

Direct answer: a full content cycle — research, fresh-idea discovery, analysis, drafting, approval, publish — runs end-to-end on an agentic pipeline in four stages: a curated source register, an automated RSS/search harvester, a digest with human gate, and structured publishing. Ours runs in under an hour a week on the analysis side, costs under $1 in paid scraping when social data is needed, and produces every intermediate artifact as an auditable file. This post is the working blueprint, with real payloads.

"Agentic SEO" is rapidly becoming industry vocabulary — Semrush ran "8 workflows on a live site" with an AI pulling its own data, vendors are packaging "agent memory" as product features, and we believe them for a non-obvious reason: we built the same shape independently, and it works.

That said, most "AI agent" marketing still describes a chat window bolted onto a tool. A real agent harness is different. It has:

Persistent structured memory that survives sessions (not chat history — a separate knowledge base with claim-level statuses),
Deterministic inputs — curated lists, not open-ended web scraping,
A human gate on every judgment call (what goes to the blog, what becomes a fact),
Audit trails with timestamps and source links, so every published claim is traceable.

We built ours this way because the Agent-works-in-a-website shape breaks down the moment you need reproducibility over three months of work; files with hashes do not.

The four-stage pipeline, with real artifacts

Here is our actual shape, described with the artifacts it produces, not abstractions:

[1] SOURCE REGISTER          [2] WEEKLY HARVEST          [3] DIGEST + GATE           [4] PUBLISH
    42 curated sources   →   RSS + search cluster    →   top picks, Jina     →   final draft,
    6 sub-topics, each        full-text extraction,       passages per URL,       human approval,
    with access type          grouped by topic            claim → wiki page       done

Stage 1 — Source register (the "who do we listen to" layer)

A curated register of 42 sources across 6 sub-topics (vendors, AEO specialists, agent platforms, content-ops media, social/video distribution, expert personas). Each entry carries: name, URL, type, why it matters, cadence, access type (RSS / direct read / paid scraper for social).

The problem most teams skip: half the web has no RSS feed. In our register, exactly 17 of 34 blog sources expose a live feed. For the rest, the fallback is search-based retrieval (call it "search harvest" — you poll the same way, just via a search provider instead of a feed). Registering explicitly which channel each source uses is what makes the harvest deterministic.

Real payload note: feed detection is a 15-line script — probe /feed, /rss.xml, /index.xml, /atom.xml and sniff for <?xml + <rss|<feed. Half the "no RSS" vendors actually have feeds on non-obvious paths.

Stage 2 — Weekly harvest (the "what's fresh" layer)

Every Monday, a cron job pulls every live feed, filters to the last N days, groups items by topic, and writes a dated harvest file. In our first full run: 92 items from 14 feeds, 21 days of window.

What matters here is honesty about the data. Some vendor sitemaps reset a build date every deploy, so a naive "100 posts in 30 days" reads as a lie. Our harvester carries an explicit caveat for this and clamps future-dated items. Small hygiene details like this make the difference between a trustable data asset and a GIGO widget.

When the harvest needs social data (say, a specific expert's last 50 LinkedIn posts), that runs through a paid scraper on a strict per-run budget — we cap it and abort at the cap. For this niche, a full persona's recent posts cost about $0.11 per run.

Stage 3 — Digest + human gate (the only stage with a judgment call)

From the harvest, an automated pick of the top strategic items gets a targeted text extraction — not the whole page, just the passages answering a specific question (this reduces token usage roughly 10× and keeps context small enough for the next step).

The output is a digest with: a topic-grouped list of top items, 2–4 key findings with source links, a table of "facts worth ingesting" each marked verified (primary source read) or pending (needs a second source), and a human gate — the owner decides which claims enter the knowledge base. Nothing enters the shared knowledge base without that gate. This single rule is what stops "AI slop drift": a confident but unverified claim never gains the credibility of a verified one.

Stage 4 — Publish (structured, auditable)

Every article that survives the gate is built to be extractable: answer-first first paragraph, one main query per page, visible FAQ blocks in HTML (not hidden answers), numbers from real payloads rather than invented ones, tables in text not images. Publishing routes through a check that contract-tests meta (slug pattern, title length cap, paired .md/.json, published date), so nothing reaches production that would break structured data.

What this costs (honest numbers)

Analysis time: about 1 hour per week, dominated by the human gate and the final read-through before publish. Harvest, register scans and digests run in the background (a cron, no human time).
Paid tools: ~$1/month total, dominated by one paid scraping actor used for social expert corpora. Feeds, search, text extraction, and scheduling are all free-tier.
Build effort: the register, harvester and digest scripts together are roughly 300 lines of standard Python. The expensive part is not code — it is curating the source register in the first place so that your "42 sources" are actually the 42 right sources.

What we got that the manual process didn't give

Evidence-based topics. Our register showed that in this niche AI citations dominate the discussion (19% of a top expert's 300 recent posts), FAQ markup is almost universally missing (0 of 21 competitors), and proprietary data studies are the highest-signal format. Those claims came with receipts, not hunches.
Zero-dogma data. Because our numbers are neutral (we are not selling a citation-tracker or a scraper), a data study published on our register carries credibility a vendor's cannot — the very insight that is, in our view, the biggest competitive edge available to a small content team right now.
Non-blocking distribution. A published post flows to sitemap, RSS and social handoff in one loop. The publishing step was already solved; what used to be missing was the trusted, structured feed of topics to publish about — which stages 1–3 produce automatically.

What we explicitly do not claim

We do not claim million-scale statistics. Anyone quoting "we analyzed 5M citations" is quoting a tool vendor's own data; the correct posture is to use their research as corroboration, not as proof. Our analysis is niche-scoped, and we say so where it matters.
We do not claim the human is optional. The human gate is one weekly step, and it is the most important one. It takes minutes, not hours.
We do not claim agents replace strategy. What the agent replaces is manual collection, manual triage, and draft assembly. The judgment calls inside the digest, and the decision of which data study to run, remain human — and should.

Frequently asked questions

Is this the same as "vibe coding" the content pipeline? No. Vibe coding produces scripts; a harness produces a system with state, gates and audits. An agent harness keeps every artifact — register, harvest, digest, publish — on disk with dates, hashes and human approvals, so an asset built over three months stays trusted, not just regenerated.

What's the minimal starting stack? A register of 30–40 sources (one curated list, freely available), a live RSS check on each, a cron job that runs the harvester weekly, and a single digest template. Everything above is standard library plus one scraping service for social data.

How does an L2 agent harness differ from an "AI marketing tool"? A marketing tool gives you a button; a harness gives you a pipeline whose stages are auditable, whose knowledge base accumulates verified claims over months, and whose outputs plug into any publisher (including one with its own scheduling layer). The agent runs the loop; the tool is just one stop in it.

Where do agent-native consumers fit? A harness like this exposes its pipeline stages to other agents as tools — a register read, a harvest trigger, a digest query — rather than as a bespoke UI. That is the difference between "we built a smarter dashboard" and "we built a capability any AI agent can call." The second shape is where this discipline is heading, and it is already cheaper to build than to maintain a monolithic app.