How I Built ASI's Marketing Engine Around AI Agents

This is a long one, and I mean that as a recommendation rather than a warning. Most of what gets written about AI in marketing right now skips the part that actually matters — the specifics: what broke, what surprised you, what you'd do differently. This piece doesn't skip it. If you're building something similar, or wondering whether any of this is real, I think you'll find it useful.

Until last year, ASI's New Zealand business didn't have a formal marketing function. This was something we handled between other priorities — never quite as its own discipline.

I wear a few hats at ASI NZ, and marketing has always been one of them. Which in practice meant a long list of things we knew we should be doing, but never quite did, because nobody had the time.

So I built the marketing team I couldn't hire.

Today that "team" is eleven AI agents. They wake up on a schedule, do their work, and report back when they're done. They publish blog posts, generate social variants for LinkedIn, Facebook and X, run optimisation passes on Google Ads and Meta within strict guardrails, and produce a single Monday-morning report covering everything. The marketing engine ships work every day. I don't have to drive it.

I didn't buy a marketing platform to make this happen. The whole thing sits on top of Claude — eleven role-specific agents trained on ASI NZ's brand, a flat JSON file for state, and cron. I'm writing about it because most of what gets said about AI right now is either theory or vendor pitch, and the practical version is honestly more useful, and more buildable, than either of those suggest.

Agents as colleagues, not chatbots

Most "AI marketing" tooling is a souped-up text box. You prompt it, you copy what comes back, you paste it somewhere. That isn't automation; that's a faster intern.

Real automation looks more like this. A job runs at 9am, nobody is in the loop, and by 9:15 the right work has shown up in the right places. An article goes live. A LinkedIn post is published. Spend on a junk search term gets stopped. A Slack message in #marketing-ops sums up what happened.

To get there, I treated each piece of the marketing function the way you'd treat a new hire. Each agent has exactly one job. Scout does keyword research. Writer writes. Editor scores. None of them go off-brief. Each one gets a short list of permitted tools — a CLI, a Python script, a couple of APIs — and nothing else. And every action they take is logged with the rule that fired, the evidence behind it, and a timestamp. There is nothing the system does that I can't reverse.

The whole thing runs on intentionally unglamorous infrastructure. Python scripts handle the data and the pipeline plumbing. A single JSON file tracks every article through its lifecycle. The agents themselves are just markdown files in the repo — prompts that Claude loads when it runs them. Scheduling is cron: nine jobs, from "every day at 9am" through to "first of the month." No Kafka. No Kubernetes. No $40,000-a-year SaaS bundle. The most exotic component is Claude itself.

The eleven agents

Each agent lives as a one-page markdown brief that gets loaded when its turn comes. The full roster:

Beside the agents sits a smaller library of "skills" — reusable playbook files for things like landing page audits, backlink analysis, GBP optimisation, competitor monitoring. They're how I keep methodology consistent across whichever agents need them.

How an article moves through the pipeline

The work flows through four content agents, each picking up where the last one left off.

Scout does the work most teams skip because it's tedious — figuring out what to write about based on real data instead of a hunch. Tuesday nights it scans the pipeline to see what we've already covered, refuses anything that overlaps too closely with an existing article, then runs a few search strategies: question-led queries, competitor and trend research, seasonal angles. For each candidate topic it goes through the top SERP results, pulls out the "People Also Ask" questions, and bundles everything into a brief the Writer will pick up on Saturday. Two to four topic ideas a week, each one ready to write. Roughly the equivalent of a half-day of keyword research, done overnight, without anyone opening a browser tab.

Writer picks up the highest-priority briefs and produces full drafts — somewhere between 1,800 and 2,200 words, structured for SEO, FAQ included, metadata ready to go. The thing that stops the output sounding like a generic LLM is the brand profile. That's a single file with our positioning, our tone, the claims we're allowed to make, the claims we're not, and the messaging hierarchy that ties it all together. Writer reads it before it writes a word. Saturday night's run alone produces what used to take a content writer a full week.

Editor scores every draft against a 100-point rubric and either approves it or sends it back to the Writer with structured feedback.

Pass threshold is 75/100. When an article fails, the Editor doesn't just say "make it better." It writes specific feedback the Writer can actually act on:

"H100 vs L40S comparison is missing total cost of ownership analysis; SERP brief flagged this as a content gap. FAQ only addresses 2 of the 4 PAA questions from the brief."

The Writer's next run picks the article up and works through the notes directly. This is the step most "AI content" pipelines skip. They generate, they publish, done. The Editor is what keeps quality from collapsing, and it's what turned a 45-minute editing pass on every article into a 5-minute final read.

PM runs every day. Its only job is to check that the pipeline is healthy — looking for articles stuck in progress, reviews sitting too long without scores, revision loops, a thin backlog, anything that failed to publish. Anything anomalous gets escalated for me to look at, and logged either way. Dull, essential, and the sort of thing a one-person operation could never do consistently by hand.

How the agents hand off to each other

The agents don't talk to each other directly. They talk to a shared file — pipeline.json — and each one only ever picks up work in a specific status. Scout adds topics to backlog. The orchestrator promotes the best ones to todo. The Writer claims items and moves them through in_progress to review. The Editor either passes them to done or sends them back to revision. The publisher only touches things in done. The PM escalates anything stuck.

It's the same pattern Unix pipelines have been using for fifty years — agents communicating through shared state instead of direct calls. The advantage is that it's easy to watch what's happening, easy to debug, and if an agent crashes mid-run nothing gets lost. The next run just picks up where the last one left off.

The same pattern, applied to ads

The four content agents are only half the story. The same architecture — a scheduled agent, a tight brief, a small tool list, and a guardrail policy that doesn't bend — runs the rest of the marketing operation.

Every morning at 9am, a daily-ops agent runs a handful of jobs. It promotes any articles that passed editing overnight, publishes the ones marked ready to WordPress as drafts, and posts one social update for the day — LinkedIn, Facebook, or X — pulled from a round-robin queue. Then it scans the last three days of Google Ads for any campaign quietly burning money on zero conversions. Net effect: a steady cadence across all three platforms, and nobody manually queueing a single post.

Twice a week — Monday for the full sweep, Thursday for a lighter check-in — the ads optimisation agents pull thirty days of search-term data from Google Ads and Meta. They classify each search term by intent and flag the spend that's going to terms that will never convert: job seekers, hobbyists, the occasional competitor brand that's somehow triggering us. They check conversion tracking is still working. They look for ad sets showing creative fatigue. And they draft budget proposals for the campaigns that are running well but bumping against their daily cap. Everything lands as a markdown file in the repo, and a summary turns up in Slack.

Auto-apply: the policy that turns reports into savings

For the highest-confidence, lowest-risk changes, the agent applies the change itself — ninety minutes after daily-ops, against a strict policy. This is what turns the system from "yet another report nobody reads" into something that actually saves money.

The policy is conservative on purpose. A flag file or stale upstream data halts everything. Brand-new campaigns (anything less than 14 days old) are off-limits to every rule. There's a hard daily cap of twenty mutations, with smaller sub-caps inside it: at most three budget changes, five pauses, fifteen negative keywords. Once a campaign's budget has been adjusted, it can't be touched again for seven days. That one rule eliminates a lot of oscillation. And every mutation gets logged — the rule that fired, the evidence behind it, the policy version stamp.

A typical rule looks something like this: a search term has at least $30 of 30-day spend with zero conversions, it contains a tier-1 non-fit token (free, cheap, salary, jobs, career, diy, tutorial, student), and its match type is phrase or exact rather than broad. Meet all conditions and the negative keyword gets added. Everything outside the policy stays as a draft for me to approve.

The practical effect is the part worth measuring. Ad budget that used to leak for a couple of weeks before someone noticed now gets stopped within 24 hours. That's real money.

A real example: the VMware migration article

When Broadcom acquired VMware, it created a real commercial opening for any business looking at alternatives, and the pipeline picked it up. Scout flagged "VMware migration alternatives" as high-intent, and noticed that mid-tier blogs were dominating the SERP — meaning we had a shot at outranking them with something more thorough. The Writer drafted a full-length piece covering the Broadcom fallout, the realistic alternatives (Nutanix, Proxmox, managed hosting), the migration timeline, and total cost of ownership.

The Editor passed it on first review. The Publisher pushed it live with SEO metadata. The Hero Image agent generated the cover. The Repurposer turned the article into a LinkedIn carousel, Facebook posts, an X thread, an email snippet, and Google Ads copy. The Ads Creator then stood up a dedicated campaign with the article as the landing page and conversion tracking wired through GTM.

Mid-cycle, the Optimiser noticed a sister campaign was running at zero conversions because of the wrong landing page, auto-paused it, and stood up a replacement pointing at the right one.

Total human time from topic discovery to first ad live: under 30 minutes of review.

Without the agents, the same workflow would have needed a content writer, an SEO specialist, a designer, and a paid media manager — roles the NZ business didn't have to spare.

Where humans still come in

Humans aren't out of the loop here. I'm still in it, just doing different work. Strategy is mine. What we target this quarter, what messaging leads, what we won't say — that's not on the agents. The brand profile is hand-written, and I update it whenever something material shifts. Every article gets a five-minute final read before it goes live. Customer relationships, partner conversations, sales calls — those belong to the rest of the ASI NZ team, full stop. When something gets escalated or a tracking issue pops up, I investigate. And maybe one in five articles still needs a human-led revision the Editor wouldn't have caught — industry context the agent can't reasonably know, a customer reference that needs a careful hand.

The shift isn't humans out, AI in. It's one person doing the work of a marketing department by handing each repetitive task to a purpose-built agent and keeping the judgement calls for myself. The rest of my time at ASI NZ goes where it always should have gone — onto the rest of my job.

A week, end to end

Monday opens with a 7am cross-channel report dropping into Slack — Google Ads, Meta, GA4, Search Console, HubSpot, pipeline health, all in one message. At 9am the full ads optimisation runs, safe auto-apply executes, and landing pages get audited. From there, every weekday at 9am, daily-ops ships new articles and social posts and runs anomaly checks on yesterday's spend. Thirty minutes later the lead follow-up agent drafts Day-2 emails to the previous day's new leads. At 10:30 auto-apply runs against the morning's optimisation drafts. Around 11 the system verifies whether changes auto-applied a week earlier actually held up.

Tuesday night, Scout finds next week's topics. Wednesday morning, last week's articles get repurposed into ads and social. Thursday is a mid-week ads-only check. Saturday night, Writer drafts up to three articles. On the first of every month, a strategic review runs and the monthly newsletter is generated.

The whole orchestration sits in nine lines of crontab. No fancy scheduler. No DAG framework. Just cron, a bash wrapper, and a markdown file per job telling the agent what to do that morning.

Six things I learned

1 - Start with one job, not one platform.

I didn't try to "automate marketing." I started with keyword research. Once that worked, I added writing. Then editing. Then ads. Each agent had to earn its place — by saving real time without dropping quality — before the next one got built. If I'd tried to design the whole system upfront, I'd still be designing it now.

2- Brand voice is a file, not a vibe.

Until I sat down and wrote out our positioning, tone, proof points and the claims we make in one profile every agent loads, the output was forgettable. Once I did, it sounded like us. The profile is now treated as critical infrastructure. When a partner wins an award, when a new product launches, when our positioning shifts — the profile gets updated first, before any content runs.

3 - Auto-apply needs a narrow window and a wide audit trail.

The agents only act on the cases where they'd be right 95% of the time. Everything else is a draft for a human to look at. Every change is logged with the rule that fired and the evidence behind it. Nothing the system does can't be reversed. And the caps and cooldowns mean it can't run away with itself.

4 - Shared state beats inter-agent chat.

I tried building agents that called each other directly. It was brittle. Moving everything through a single shared file made the system easy to watch, easy to debug, and tolerant of individual agent failures. The old Unix philosophy of "do one thing, communicate through files" turns out to apply to AI agents too.

5 - Boring infrastructure is a feature.

Python, JSON, cron, git, markdown. Nothing in this stack is exotic. That's deliberate. When something breaks at 2am, I want to be able to read the code, not learn a new framework. Six months in, I haven't regretted any of the un-sexy choices.

6 - Measure the operational gain, not the model.

I don't track how many tokens Claude used. I track articles published per week. Ad waste prevented. Hours of review saved. Leads followed up within 24 hours. Those are the numbers that justify the system, and the ones that tell you whether it's actually working.

Closing thought

I'm writing this up not because it's finished — it isn't, and I'm still adding agents — but because most of the AI conversation right now is theoretical. The practical version is less glamorous. Pick a recurring task. Write the brief. Give the agent the right tools. Scope what it can do alone. Put it on a schedule. Log what happens. Review on a cadence.

The story of ASI NZ's marketing engine isn't really a story about AI. It's a story about a 40+ year old technology company giving one person the runway to build something useful, and using AI agents as the leverage that turned one person into a function.

If you're in a similar position, wearing multiple hats and watching a marketing backlog grow with no full team on the cards, this approach works. Start small. Write the brief. Put it on cron.