Editorial workbench for a B2C software publisher

One agent that builds the SEO-researched brief, runs it through the article pipeline to a styled Google Doc, and ghostwrites the CTO's external bylines with on-brand charts — three editorial jobs on one disciplined core.

build time
~3 months build · ongoing tuning · two writers
first published
last updated

In one paragraph

A small editorial team at a B2C software publisher runs three jobs that used to eat most of a week: researching the marketing brief that makes an article rank, turning that brief into a polished English article in Google Docs, and ghostwriting the company CTO’s external bylined pieces for third-party publications. This editorial workbench does all three off one disciplined core. A brief that took half a day of SEO spadework is researched and filled in minutes; a brief-to-published-Doc cycle that used to be most of a workday is roughly twenty minutes of mostly-machine work plus a short human polish; and an external byline arrives drafted in the CTO’s voice with on-brand charts ready to drop in. Every stage writes a file the operator can open, override, and re-run from — auditable Python transforms, not a black-box prompt. Three months of build by one person, two writers in daily production, seventeen articles shipped end to end.

0 min
brief → published Google Doc · was about a workday
0
editorial jobs one agent runs · brief · article · external byline
0
output languages on tap (de · es · ru · uk)
0
articles shipped end-to-end

The problem in business terms

Editorial output at a small publisher is constrained by writer-hours, not by the cost of words. The expensive parts are the spadework that brackets the writing: assembling a brief that will actually rank — real internal links, trustworthy citations, the questions searchers ask, the competitors to beat — and then, after drafting, the formatting and reconciliation that turns a draft into a published artefact in someone else’s house style. The drafting itself is the smallest slice; the research before it and the scaffolding after it eat the day, and the CTO’s external thought-leadership, which a two-person team can rarely afford to start from scratch, slips for months.

without the workbench
  • Hand-research each brief: hunt internal links, vet external sources, read the SERP, list the questions to answer.
  • Read the Russian-or-Ukrainian brief and mentally separate the marketing wishlist from the technical truth.
  • Format manually in Docs: heading levels, bullet punctuation, callout casing, table of contents, screenshots one at a time.
  • External bylines: relearn the target site's style and the CTO's voice from scratch, build every chart by hand.
  • Each new translation is its own pass through the same loop.
with the workbench
  • Hand the agent a topic; it researches the brief across three lanes and fills sections 1–2 — every link verified live.
  • Drop the brief in `inbox/`, run one command; the technical truth overrides the marketing wishlist by rule.
  • Styled Google Doc lands in the right Drive folder, screenshots inserted, house style enforced by validators.
  • External bylines draft in the CTO's voice against the target site's house style, with on-brand charts ready to place.
  • Translation staging is one command per language, against shared glossaries.

What makes this different from “one big prompt”

The workbench is a sequence of linear stages, and each one writes a real file the operator can open. When the article-type detector misclassifies a how-to as a comparison, the fix is change one field in the normalised JSON and re-run from validate — not re-prompt the whole pipeline and hope. House style lives in validators between stages, not in a long prompt asked to hold: heading levels, bullet punctuation, callout casing, table-of-contents structure all fail the pipeline before the publisher touches Drive. The brief builder draws the same kind of hard line in the other direction — it fills the marketing and SEO sections and never writes into section 3, the author’s own hands-on testing, which the article pipeline treats as the overriding source of truth. Each job knows exactly which part of the document is not its to touch.

Voice is data, not a prompt: a small JSON profile per writer carries tonal markers and preferred phrases, so two writers share one renderer and each gets drafts that sound like themselves — and the same mechanism raises the CTO’s external-byline voice when the job is a guest piece for a third-party site. Two publishing paths are kept architecturally separate, so the in-house publisher cannot apply external-article chrome whilst the external uploader cannot leak website scaffolding into a guest post. Three article shapes each get their own renderer rather than one polymorphic prompt; the cost is more lines of code, the benefit is that a listicle never bleeds comparison-matrix scaffolding into a how-to.

Renderer shape — the decision that aged best
criterion One mega-prompt covering every article type Three article-type renderers sharing a common core chosen Free-form renderer with house-style post-pass
Respects per-type structure rules partial yes no
Supports listicle cards / comparison matrices leaks yes leaks
Cheap to add a fourth article shape no yes yes
Debuggable when output is wrong no yes partial
Compatible with house-style validators partial yes no

Translation fan-out calculator

Plug in your editorial cadence — articles per month, manual translation effort, target languages, writer hourly rate. The output is the monthly time the renderer + glossary stack saves you on the fan-out alone.

— hours saved / mo— saved / mo

runs locally · 0 network calls · deterministic

A session in the room

Three exchanges — one of each job the workbench does, run consecutively. The agent investigates, decides, executes, and verifies; every scenario closes on a success line. The intro on the right stays pinned as you scroll; each scene below picks up the next task as its centerline crosses.

Before the work begins

The workbench takes one of three jobs at a time and carries it to a finished artefact: a researched brief, a published article, or an external byline in the CTO’s voice. Two files prime every session — CLAUDE.md sets the contract (how briefs are read, how article types are decided, where finished Docs land) and SKILL.md lists the editorial rules each renderer enforces.

The three exchanges that follow are one of each job: the happy-path pipeline run that turns a brief into a styled Doc, the brief builder researching and filling a brief from a bare topic, and the external-byline ghostwriter drafting for a third-party site with charts built to screenshot.

Each scenario closes on a success line — the agent decides, executes, verifies, and reports back. The “ask before destructive action” rule is governance around the catalogue; inside a single task, the agent closes the loop. [future-max]

It runs locally — brief content, screenshots, and the CTO’s drafts stay inside the publisher’s Drive estate; the only outbound calls are the web research and the drafting model. That trust property is what makes the case publishable: the architecture can be described because it doesn’t leak the publisher’s content on its way through.

Job one — brief in, Google Doc out

A marketing-and-technical brief lands in inputs/briefs/inbox/, the operator runs one command, and roughly twenty minutes later a styled Google Doc sits in the correct Drive folder with screenshots inserted and a Docs-native table of contents. The shape of the run is normalise → validate → render → validate-format → publish, and every stage writes a file the operator can open.

The normalised JSON shows how the brief was parsed and which block won where the marketing wishlist disagreed with the technical truth. The validation report shows which house-style minimums passed — internal links, external links, FAQ candidates, screenshot metadata. None of it is black-boxed; all of it is debuggable.

House style is enforced by validators between stages, not by hoping a long prompt holds. A tired-Monday draft and a fresh-Tuesday draft pass through the same rules — which is exactly what lets two writers share one renderer without the output drifting between them.

One dry-run before any publish: the publisher proves the Drive call would succeed before it performs it, a safety belt that costs ten seconds and pays for itself the first time a folder ID is wrong. Eighteen minutes end to end here; the writer’s morning still has six hours in it.

Job two — a topic becomes a ranked brief

This is the spadework that used to bracket the writing: before anyone drafts, someone has to assemble a brief that will actually rank. The agent takes a bare topic and researches it across three lanes in parallel — the publisher’s own articles for internal links, trustworthy external sources for citations, and the live SERP for the titles, questions, and competitors the piece has to beat.

The discipline that matters is verification: every URL is fetched and confirmed live before it goes in, and the entities and terms the brief recommends are pulled from the corpus that actually ranks, not free-associated. A brief full of plausible-but-dead links is worse than no brief; this one is grounded in what resolves.

The boundary matters as much as the research. The builder fills the marketing and SEO sections and never writes into section 3 — the author’s own hands-on testing, which the downstream pipeline treats as overriding truth. The machine does the part the machine is good at and leaves the part only the author can do.

The honest moment is the formatting round-trip: the Docs API silently drops a grey of exactly 0.4, so the first fill comes back unstyled. The fix is known and codified — write 0.405, send one style field at a time, poll for an authoritative read-back. That whole class of quirk is paid for once, in code, not every time a brief is filled. [devil's-advocate]

Job three — the CTO’s external byline

Thought-leadership under an executive’s name is high-stakes and low-volume: it has to sound like the person, fit the target publication, and never read as vendor copy. The agent raises the CTO’s voice from a set of anchor pieces and the target site’s house style from a quick research pass, then drafts to that intersection.

The numbers are the credibility. The agent researches the real figures behind the argument — here, the rising cost-per-terabyte of the storage upsell — and builds them into on-brand HTML charts rendered to screenshot at retina. Legible data is the single biggest lever for these pieces getting featured; an illustrated argument lands where a wall of text bounces.

Voice fidelity is a discipline, not a vibe: open on a common assumption and puncture it, anchor every claim to a number or a file path, toggle “I” for observation and “we” for the company’s method, close on a principle rather than a call to action. The draft is checked against the house writing rules — no hollow negations, no asserting what cannot be known — before it ever reaches the Doc.

Delivery is the two-step path the external surface was built for: create the Doc in the external-articles folder, then upload with plain styling — 1.5 line spacing, space after each paragraph — the house format the editor expects. The CTO gets a finished draft with charts ready to place, not a blank page and a deadline.

What’s shipped

The three editorial jobs
  1. 01
    Brief builder
    researches internal links · external trust sources · SERP, PAA, competitors · fills brief sections 1–2, leaves section 3 to the author
  2. 02
    Article pipeline
    normalise → validate → render → validate-format → publish · in-house publisher with screenshot staging + dry-run
  3. 03
    External-byline ghostwriter
    raises the CTO's voice + target-site house style · on-brand HTML→PNG charts · plain-Docs upload
Renderers
  1. 01
    General-guide template
    linear steps · troubleshooting · FAQ block
  2. 02
    Listicle template
    per-tool meta cards · transposed comparison table · methodology section
  3. 03
    Comparison template
    feature matrices · verdict paragraphs · spreadsheet-blocking on inaccessible sources
Translation track
  1. 01
    German glossary
    house terms · casing rules · locale phrasing
  2. 02
    Spanish glossary
  3. 03
    Russian glossary
  4. 04
    Ukrainian glossary
  5. 05
    Eight-point QA checklist
    runs before the translated draft reaches the human reviewer
end-to-end publishing record 17 articles · 3 months
94% green
green 16 flaky 1 red 0

Sixteen clean publishes out of seventeen across two writers. The one warn day was a heuristic misdetection — a how-to whose outline carried a stray “vs.” got routed to the comparison renderer — caught by the format validator before it reached Drive, fixed in fifteen minutes, and locked out of the next occurrence by a test (commit 6fe500b). The validators do not exist to be quiet; they exist to make the unquiet runs cheap.

The verdict from the room

The compression is honest and it holds: a researched brief in minutes, brief-to-Doc in twenty, an external byline drafted in the CTO’s voice with charts ready to place. What ages best is not the speed but the uniformity — three different jobs, two writers, one set of boundaries, and nothing cross-contaminates: in-house chrome never leaks into a guest post, and the brief builder never overwrites the author’s technical truth. The workbench is finished in the sense that no further structure is planned; subsequent commits tune the heuristics and grow the glossaries.

Three months. One builder. Three editorial jobs, three renderers, two publishing paths, four-language translation. A brief in minutes, a published Doc in twenty, an external byline ready to send — holding steady across seventeen articles and two writers.


This case describes architecture and patterns. The publisher, its CTO, the third-party publications, and specific product names are deliberately left abstract; what matters here is the shape of the system — three jobs on one disciplined core — not whose logo is on the artefacts.