Case 03 / AI workflows & content operations
Content Persona ecosystem
“Sound authentic” defines nothing. This persona carries the real sources, the real voice and the rules, and a human approves the draft.
Outcome · self-reported scopeHistorical time-saving estimate: I estimate content-production time fell by about 80% across four executive profiles. That estimate remains unverified; the current demonstration covers one manual run.
The challenge
“Sound authentic” defines nothing. A draft can use the right vocabulary and still take the wrong side of the problem: in one iteration, review caught a buyer-facing draft written from the seller’s perspective. So the workflow checks audience, sources and voice separately, it never treats “sounds authentic” as approval.
My role
I designed the content operating system at Cello: the onboarding form, source selection, role-specific drafting rules, the review queue. The form captures what someone reads, the territory they own and the language they avoid; a voice profile from their own message examples carries how they actually write. A human approves everything, by design.
The approach
I feed one structured persona into sourcing and drafting: role, audience, reading diet, boundaries, voice. I judge sources on fit, provenance and freshness separately, exclusions count as much as interests. The implementation is forms, artifacts and workflow definitions across tools: deliberately not one autonomous app, and not a trained model.
The film shows the ecosystem as designed, profile and rules feeding a weekly routine, constraints in view at every stage. Below: what the system verifiably produced. Demonstration and evidence, apart on purpose.
System architecture
Run scope & provenance · one verified local run
- Google Form copy · 5 sections
- 18 questions · filled by hand
- Voice self-analysis, redacted
- 48 authored synthetic messages
- 6 communication contexts
- 311-word profile · literal quotes
- Persona-fitted public sources
- Fit · provenance · freshness
- Cap: 4 candidates
- 12 editorial checks
- Literal-evidence check
- Stop Slop 42/50 · uncalibrated
- Monday 09:30 CET cadence
- Paused · one manual run
- ≈140s observed · no nested calls
- Draft = final = handoff verbatim
- 0 revisions · NeedsHumanReview
- Human approval before anything
Figures describe that single manual run, not a scheduled delivery or a quality result. Stop Slop’s 42/50 is uncalibrated; the run applied the available main rules.
Selection collects negative context too: what someone reads, never cites, would find out of character. Exclusions shape the draft as much as interests.
Each person runs the Slack analysis themselves and shares a redacted profile, a deliberate privacy boundary. The rebuild uses a fictional profile: no Slack history, no impersonation, no automatic harvest.
Voice and sourcing are different inputs
Voice profile: tone, rhythm, vocabulary per context. Onboarding: audience, priorities, sources. Together they beat “sound authentic”.
Role-specific gates reject off-audience material; generation also checks provenance, recent hooks and privacy rules for sales-derived signals.
Persona records drift. Replay needs a dated persona and workflow version, old voice against new rules contradicts itself. The rebuild saves its profile first, binds source cards to it.
Review and failure handling
Review splits constraint checks, persona coherence, benchmarks and numeric claims before the handoff. One iteration caught drafts framing the buyer’s problem from the seller’s side, the real audience test.
The run’s shortlist shows the discipline working: four candidates, each scored on fit, provenance and freshness separately, each with its rejection kept. One unsupported promotional reply-rate claim was excluded; gated pages stayed “partial provenance”; the system recorded “no qualifying fresh signal” instead of inventing one. Publication dates come from extraction only, copyright years and asset filenames don’t count.
Missing sources, non-anonymized signals, persona mismatch, repeated hooks, all need visible handling. Rules describe intent, not enforcement; a genuine demo shows a rejected input and its correction.
Human approval is the publication boundary. The rebuild below produced drafts and a private synthetic database entry, not the production queue. The native run stopped at a local handoff: no LinkedIn, no Slack.
The setup
Runs across tools with manual handoffs: a real Google Form (restricted, unpublished) → voice profile → source cards → skills → one routine: Mondays 09:30 Europe/Berlin, paused after a single manual test run → local outputs → an isolated private Notion destination. Nothing auto-publishes.
Results and limitations
Evidence: the Cello Content Persona Survey, its onboarding spec, persona/source/format records, real generation/review definitions. The live form’s opening page was inspected read-only; remaining sections rest on the archived spec, not a fresh walkthrough.
The orchestration spans tools and manual handoffs. The standalone interface below was a reconstructed flow (19-question form, real public-source retrieval, drafting, review, revision, browser-assisted Notion handoff). The native rebuild supersedes it, both synthetic, neither a rerun of the historical deployment, whose state and time-saving measurement stay unverified.
No colleague voice samples, Slack exports, customer data or internal identifiers here; employer-specific code and artifacts need separate clearance. Demo setup: fictional profile, real public sources, isolated private Notion. Production systems stay disconnected.
Before you remove a field from your partner handoff checklist, ask the person who sends the next reply why they use it. In its article on Chesterton's Fence, Farnam Street explains the case for understanding an existing practice before changing it. A useful test for a partner handoff before campaign launch: 1. Pick one referral and ask the current owner to walk through the next reply. Note who sends it, what they need and where they check the next action. 2. Ask the receiving owner which fields they use. For any field you want to remove, record the job it serves and how the team would handle that job without it. Try the revised checklist on one sample handoff. Ask both owners to confirm the next action before you use it for launch. On your team, which handoff field would you ask an owner to explain before removing it?
What I learned
The human at the end isn’t the bottleneck, they’re the feature. Design the handoff instead of automating through it: the run showed the gate works best when it is visible.