Lesson 66.2 built the editorial operating system: files, a board, named owners per gate. Now the tempting question arrives — can agents run it? They can help enormously, and they can also turn your engine into a spam machine that publishes confident nonsense at scale. This lesson draws the line.

What agents are good for inside an editorial system

Reuse the agent theory from Part VIII directly: an agent is a bounded worker with defined tools, inputs, output expectations, and an audit trail. Inside the editorial OS from Lesson 66.2, that maps cleanly onto six safe jobs:

• Gather approved sources — collect links and quotes into the research folder without editorializing.
• Create first drafts — turn an approved brief into a rough draft, never into a publication.
• Generate asset variants — resize crops, caption alternatives, thumbnail directions from a locked master.
• Format metadata — titles, descriptions, tags, alt-text drafts, scheduling rows.
• Schedule approved posts — move locked, signed-off assets into the publishing queue.
• Log results — collect view, completion, and comment signals into the learning log for human interpretation.

Notice the pattern: every one of these starts from human-approved material and ends before publication. The agent accelerates movement between gates. It never owns a gate. That is the whole discipline in one sentence, and everything below is its application.

The safe chain: research to log with humans at the load-bearing joints

Here is the automation chain to memorize and enforce:

approved research folder
  → draft generation
  → human fact/brand review
  → asset production
  → human approval
  → scheduling/publishing
  → performance log

Two human gates are non-negotiable: fact/brand review after drafting, and approval before anything publishes or schedules. Asset production in the middle may be agent-assisted — variants, crops, formatted exports — but the master it derives from must already have passed review. The performance log at the end is agent-collected, human-interpreted; Lesson 66.4 teaches the postmortem that reads it.

Why this shape? Because errors compound downstream. An unverified claim drafted by an agent becomes ten variants, three clips, a newsletter, and a week of replies before anyone notices. Catching it at the draft gate costs minutes. Catching it after publishing costs trust, corrections, and sometimes a partnership. The chain puts the cheap catch before the expensive spread.

What must never be automatic

Some actions carry consequences no automation should absorb on your behalf. Keep these human-only, every time, no matter how reliable the agent seems:

• Unsupported claims — publishing any factual, scientific, or product statement the research folder does not support.
• Sensitive public replies — responses to criticism, complaints, distressed users, or controversy.
• Brand partnerships — commitments, negotiations, or sponsored statements involving another party.
• Pricing, financial, or consequential statements — anything that moves money or creates obligations.
• Unreviewed media — any image, clip, or audio the reviewer has not signed off.
• Unclear-permission actions — anything touching accounts, credentials, rights, or licensed material where authority is ambiguous.

Each item on this list fails the same way: the cost of being wrong dwarfs the time saved by automating. An agent that auto-replies to an angry customer with a hallucinated refund policy has not saved you five minutes; it has created a support incident. Design as if every automatic step will eventually misfire, because it will, and make sure the misfire lands in a draft folder rather than on a public feed.

Exercise: draw your automation map with permissions and stops

Diagram exactly one content automation — not three, not the whole operation. One path, for example research-to-newsletter or brief-to-scheduled-clips. Label every step with one of four permission levels:

Then add stop conditions: the explicit triggers that halt the chain. Examples: "draft cites a source outside the research folder — stop"; "claim confidence below verified — stop"; "partnership or pricing language detected — stop"; "permission scope unclear — stop and ask." A chain without stops is a conveyor belt to publication; a chain with stops is an editorial system that happens to use agents.

Write it up as CONTENT-AUTOMATION-MAP.md:

# Content Automation Map — [path name]

## Chain (in order)
1. [step] — [permission level] — owner/tool:
...

## Human gates
- Gate 1 (fact/brand review): [named owner]
- Gate 2 (final approval): [named owner]

## Stop conditions
- ...

## Audit trail (where each run is logged)
- ...

Done means: one CONTENT-AUTOMATION-MAP.md with every step labeled, two named human gates, at least three stop conditions, and a stated audit location. Verify: trace one hypothetical failure — an invented statistic in a draft — and confirm which gate catches it and where the stop is recorded. Common failure: labeling everything "approved-write" and listing no stops. That is not a map; it is permission for the spam machine. Redraw until the human gates are real people with real veto power.

Check your understanding

• Why must draft generation start from an approved research folder rather than open-ended model knowledge?
• Which two gates in the chain are always human, and what error does each catch?
• Name one action from the never-automatic list and explain what makes its failure cost higher than its automation savings.

In the next lesson you will close the loop the automation cannot close itself: the review cycle — checking quality before publishing, reading response after, preserving what you learned, and writing a better next brief.