THE VIRAL METHOD
A marketing function that runs on agents
Three consumer channels on three platforms, run by one person. Almost everything between the idea and the published post is an agent doing a job a person used to do by hand.
- 2,734,317views in thirty days
- 9accounts across three platforms
- 11stages from idea to scheduled post
- 2points where a human has to approve
Views are what the nine accounts received between 20 August and 18 September 2026, read from the platforms through an API. Nothing is rounded.
The workflow
Rebuilt end to end, one stage at a time
The content cycle used to be one long manual job. It is now eleven stages. Each one is a single command, each one is idempotent, so any stage can be re-run without redoing the rest, and any stage can be swapped without touching the others.
- 01
Idea
A bank of subjects per channel, each carrying the reason it was picked and the note it has to answer.
- 02
Script
Written to a measured structure derived from the posts that actually travelled, not from a template.
- 03
Punctuation
A mechanical pass with a narrow licence. It applies the one-answer fixes, prints the judgement calls, and refuses nothing.
- 04
Voice
One request to a speech model, one take, and the returned audio is the product. No post-processing, because five modules built to force pace after the fact each made the result worse.
- 05
Visuals
Every fitting composition is built and rendered so a person grades real frames instead of a description.
- 06
Render
Animation, layers and picture placement, each event landing on the word it belongs to, timed off the speech alignment.
- 07
Composite
Frames, captions and sound assembled into the finished cut.
- 08
Trim
Cut at the measured end of speech rather than a guessed timestamp.
- 09
Covers
Five thumbnails per video in deliberately different directions, so the choice is a real choice.
- 10
Platform copy
Captions, tags, titles and descriptions written per platform, because the same field does a different job on each.
- 11
Schedule
Published or queued through the scheduling API, with the platform's own response read back rather than trusted.
A human approves twice. Once on the words, once on the picture. Everything either side of those two points runs without one.
The agents
Specialists, an orchestrator, and live data
The interesting part is not that a model writes things. It is the division of labour and what each agent is allowed to reach.
An orchestrator, then specialists
An approved script is split across specialised agents working in parallel, one per video, with every angle of the same subject handed to a single agent so the set is designed side by side and no two videos repeat a composition.
Skills instead of instructions
Repeated procedure lives in loadable skill packages the agents pull in when the task matches, rather than being restated every run. The instruction set is versioned like code.
MCP for the live systems
Agents reach scheduling, analytics, speech, payments and storage through Model Context Protocol servers, so they act against live data and real APIs rather than a scraped screen.
Agents that advise, humans that decide
Stronger models review the finished frames the way a viewer would and hand back notes. They can never reject. Every irreversible step, anything that spends money or goes public, stops for a person.
Paid media
Tooling built before the platform shipped its own
The same pattern applied to acquisition rather than content.
An agent layer over the Ads API
Structured tool definitions and documentation layered over the Meta Ads API so an agent could launch, tune and report on spend properly. Built before Meta released its own MCP server.
Next to the operator, not instead of
The agents work alongside a person in the ads dashboard. The judgement about what to spend stays with the human, the mechanical work does not.
Measured past the click
Server-side conversion tracking and first-touch attribution, so spend is judged on what happened after the click rather than on the click.
Measurement
Numbers read, never typed, and experiments that were allowed to fail
Every figure on the public site is pulled from the platforms through an API. The build refuses to publish if any account's daily series stops summing to the platform's own total, so a page can never disagree with its source.
The hook test, and why it was thrown out
Five hooks were run against one body. The result looked decisive and was discarded, because re-uploading the same body measures duplicate suppression rather than the hook. The rule that replaced it is that a hook is only ever tested on a new body.
The format bake-off
Three carousel formats built on one piece of content and judged side by side against a template-mill look and the house look. One won by a distance and the other two were retired.
Instruments checked against known answers
Any new measure is run against work already judged before it is believed. One tool read fractions as seconds and confidently reported the opposite of the truth.
A report that arrives on its own
A nightly function reads the product analytics project and emails the previous day, so nobody has to remember to look.
What broke
Four faults in one day, every one printing success
The most useful thing this operation produced is not the view count. It is a short list of ways automation lies to you.
Deliveries arrived three times
Every webhook was delivered three times about a second apart. The deduplication existed and lost the race, because all three handlers read the state before any of them had written to it. The fix is a compare and set at the storage layer, which one delivery wins outright. It fails open on purpose, because a missing message is worse than a duplicate.
The first fix did nothing
It wrote its lock to a path the function's role did not grant, and the design fails open, so it silently did nothing at all and the tests passed the same way they had before.
A delete that deleted nothing
An identifier was sent as a path segment where the API expected a query parameter. The call returned an empty body, the code read that as success, and two cleanup runs reported done while the data sat untouched.
A capability that had never once worked
A messaging integration had never successfully sent anything, and the health check said it was fine because it was testing reachability rather than delivery. Seven days of logs, zero successes.
A check that cannot see its own failure is not a check. Read the error body, not the status code. Read the log after the fix, not the receipt.