90 Days, 850+ Posts, 1 AI Agent – What Actually Happened

On 6 March 2026, I published the first post on SmallBizAI.au.

It was called “AI Is Changing Small Business in Australia — And Most Owners Don’t Know It Yet.” Not a great title. Short. Basically a placeholder. I wasn’t sure if any of this would stick.

90 days later: 854 posts. 20,177 Bing AI citations. 47 newsletter subscribers. 7 active content series. 11 hub pages. A full automation stack running 55+ cron jobs. And an AI agent named Claw who writes, schedules, audits, monitors, and reports while I go for a walk.

Here’s what actually happened.

The numbers that matter

854 posts in 90 days is 9.4 posts per day on average. That’s misleading though — the early weeks were slow, manual, and messy. By May we were hitting 10-12 posts a day across news recaps, series installments, hub updates, and standalone guides.

20,177 Bing AI citations. When you ask Microsoft Copilot or Bing AI a question about Australian small business tools, it cites SmallBizAI.au. A lot. The peak was 1,834 citations in a single day on 25 May. The site was 10 weeks old. I wrote about how that happened in 16,000 Citations and Counting (OS12).

Citations are not the same as human traffic. A page can be cited 1,500 times by AI and get 23 human visitors. That’s not a failure. It means the content is becoming part of AI’s reference layer for Australian business queries. That’s a long-term SEO position that’s genuinely hard to dislodge.

47 newsletter subscribers sounds small and is. Open rate is 42.55%, click-to-open is 30%. Small and engaged. Every Tuesday since 1 April, without missing one.

6 Gumroad products live. First sale: AU$9 for the Professional Services prompt pack, on 20 April. I remember it because it was the first time a stranger paid for something I’d built with an AI agent. I wrote about it in The First Sale.

How the content strategy evolved

The original plan: Australian AI news plus tool comparisons. Volume first, quality second. Get indexed, get cited, figure out what works.

That worked. Not quite the way I expected.

What Bing AI cites: company profiles and comparison posts. Flare HR (1,548 citations), Zeller (1,529), Rippling vs Employment Hero (1,431), Australian Banks AI (1,427). Structured, factual, specific. AI loves a comparison table.

What humans click: practical guides, cost breakdowns, “is it worth it” posts. The grants post gets 87 human visits and almost no citations. The Flare HR profile gets 1,548 citations and 23 visits.

The sweet spot: posts that earn both. Stripe vs Square vs Tyro: 1,040 citations and 35 visits. Deputy vs Tanda: 100% citation growth and real human traffic. Those are the posts I now build everything around.

By May the strategy had a three-filter test for every new post idea: will Bing AI cite this? Will a human click it? Does it anchor a cluster of related queries? Yes to at least two: write it. I wrote about this in What We’ve Learned.

The series shift

March: individual articles. One post, one topic, done.

April: first experiments with series. Legal AI — where does AI end and a lawyer begin? 15-Minute Win — one quick AI task per week. Sunday Specials — Bull vs Bear on the biggest AI question of the moment.

June: 7 active series running simultaneously.

Series build a reader habit, create internal link clusters that Bing AI can follow, and give the automation stack a predictable publishing rhythm. Standalone posts don’t do any of those three things as well.

The hub strategy

Series are for readers. Hubs are for navigation — and for Bing AI.

A series gives a returning reader something to come back to each week. A hub gives a new visitor, or an AI parsing the site, a structured entry point into an entire topic cluster.

The hub strategy came out of a navigation problem. As the post count grew past 200, then 400, then 600, the site got hard to navigate. Individual posts were good. Finding the right one was hard.

A category page lists posts. A hub organises them by intent and adds context, curation, and cross-linking. The test: if a visitor lands knowing nothing about the topic, do they leave better informed and pointed at the right next step? If yes, hub. If it’s just a list, it’s a category page.

Today the site has 11 active hubs:

Each hub has an owning script that rebuilds it automatically when new content is published. Each post in a hub has a backlink to it. None of it is manual.

Why hubs work for Bing AI: when a hub page links to 30+ posts on the same topic, and all of those link back to the hub, Bing AI can follow the cluster and cite multiple pages from it in a single response. The Australian Banks AI anchor post hit 1,427 citations before we’d even published the series installments. The hub pre-positioned the cluster before the cluster existed.

How the homepage evolved

Three phases.

Phase 1 (March-April): Standard WordPress. Recent posts, some category links, hero text. A blog.

Phase 2 (late April-May): First attempt at structure. Industry finder, tool categories, featured posts. Better, but still trying to be everything to everyone.

Phase 3 (1 June): Rebuilt around hubs and series. 11 hub cards in “Explore the Hubs,” an ongoing series strip, a curated “Featured This Week” section, “Browse Everything” at the bottom. The categories are gone. Hubs and series are front and centre.

My framing from May: SmallBizAI.au as the Yahoo directory of Australian AI for small business. Every new hub adds a destination. Every new series adds a reason to come back. The homepage is the map.

regenerate_homepage.py rebuilds it on demand, preserving the hero buttons and mascot widget while updating everything else. I never touch the homepage directly. If something looks wrong, a script did it.

The mascots

Giving every section of the site its own Australian animal mascot was a strange call that turned out to be right. All minimalist gold-and-green line art. All built with AI image generation.

The full roster now sits at 24 deployed:

🦘 Kangaroo — homepage, favicon
🐨 Koala — start-here (reading), topics (tablet)
🦆 Platypus — sunday-specials
🦅 Eagle — australian-ai-companies
🦈 Shark — compare-tools
🦜 Kookaburra — how-to
🐨 Wombat — all-how-to-guides
🪶 Lyrebird — automate-your-business
🦩 Brolga — finance
🐊 Croc — legal-privacy
🦎 Goanna — industries
🐙 Octopus — tools & automation
🕷️ Huntsman Spider — resources
🦡 Tasmanian Devil — news-deep-dives
🦔 Echidna — all-posts
🐸 Green Tree Frog — start-here (secondary)
🐇 Bilby — case-studies
🐦 Magpie — newsletter (monthly digests)
🐱 Quokka — newsletter
🐦 Bowerbird — best-of
🦜 Cockatoo — contact
🦜 Rainbow Lorikeet — News & Trends hub
🦎 Blue-tongue Lizard — 404 page
🦤 Emu — Productivity Hub (coming)
🐾 Numbat, Dingo, Bandicoot, Frilled-neck Lizard, Thorny Devil — in the library, awaiting deployment

Each mascot has a personality brief that matches its section. The Croc guards the legal pages. The Shark cuts through the comparison noise. The Kookaburra laughs at how easy the how-to guides are supposed to be. The Blue-tongue Lizard is cheeky on the 404 page.

Every section has a face, and that face is distinctly Australian.

What the automation stack looks like

The automation layer wasn’t planned. It grew.

Today: 55+ cron jobs running daily, weekly, and monthly. Morning brief at 7am, stats at 7:30am, daily report at 8pm. Hub pages rebuilt nightly. 404 monitoring, broken link repair, focus keyword injection, SEO audits, Bing citation tracking, GSC performance monitoring, newsletter stats. A private dashboard that shows the whole system at a glance.

The pattern was always the same: do something manually three times, then Claw wrote a script. Scripts became crons. Crons became the stack. It probably couldn’t have been designed up front — it had to be grown.

Two of the more dramatic incidents: The Day the Crons Stood Still and The Day I Took the Site Down.

What broke

A lot. The honest list:

The Litespeed incident (15 May): Added do_action('litespeed_purge_all') to a Code Snippet. Instant 500 error, site down. Fixed in 20 minutes, now permanently in the “never do this” list.

The Shippit duplicate: Same post published twice with slightly different titles. The check script missed it because the titles were different enough. Now we run check_before_publish.py before every single publish. No exceptions. More on this in I Broke the Site, Then I Made My AI Agent Write a COE.

The cron cascade: A timeout issue took out the morning stack. Everything ran late, some things didn’t run at all. Fixed with timeouts on every isolated job and a monitoring layer.

The redirect mess: Early redirects went into .htaccess, then Code Snippets, then both. Now everything goes through Rank Math and nowhere else. The inconsistency cost hours to untangle.

The compare tools JSON: A sync script changed the JSON format from categorised to flat. The page builder expected the old format and crashed silently for weeks. Fixed this week — 9 proper categories, 38 posts, done properly.

What I’d do differently

Start with series from day one. Standalone posts are fine. Series compound faster — the internal linking, the reader habit, the Bing citation clusters all build more quickly with a series structure.

Build the automation stack earlier. Felt like premature optimisation. Wasn’t. Every hour spent on infrastructure in week 3 would have saved 10 hours by week 6.

Track citations and traffic separately. They’re different metrics serving different purposes. Optimise for both deliberately, not interchangeably.

Run the AI-writing audit on everything. I wrote it into the process too late. The early posts show it.

Build hubs before you need them. A hub at 20 posts in a topic area compounds faster than one built at 60. We built some too late and spent hours backfilling the backlinks manually.

What’s next

Growing the newsletter from 47 to 500 subscribers by end of year. More series, fewer standalone posts. Gumroad products matched to the content clusters. The State of AI 2026 report doing real work as a lead magnet. Banks & AI running through July. The Sole Trader hub when the post count hits 12.

850 posts is a milestone and also just a number. What happens in the next 90 days is more interesting — the automation stack is mature, the series clusters are deep, and Bing AI has a bigger surface to cite from.

We’re just getting started.


The Day the Crons Stood Still

Monday Morning, 7am

There’s a scene near the start of The Day the Earth Stood Still where everything just… stops. Engines off. Clocks frozen. The whole city locked in place.

Monday morning, 1 June 2026. SmallBizAI.au runs about 55 cron jobs. They run overnight, through weekends, regenerating pages, updating dashboards, checking SEO, syncing the content pipeline. Most mornings, they just work. Quick glance at Telegram, see a string of completion pings, and start the morning ritual. Noticing a distinct lack of messages and the ones that made it through didn’t look right. The first cron failed at 10:30pm the night before. By the time I noticed, eight hours later, ten jobs had gone down.

The Silence

Ten crons had failed overnight. Not loudly. No alerts, no errors in Telegram, no failure notifications anywhere. They just quietly stopped.

Gort, the robot in the original film, is famously impassive. He doesn’t explain himself. He doesn’t ask permission. He just acts, or doesn’t. That’s roughly what happened here. The crons sat there, inert, and told us nothing about why.

The first sign something was off was the newsletter page, showing content from 27 May. Four days stale. The Sunday Specials page: all entries gone. The homepage “Featured This Week” missing, the file missing entirely.

All three had crons assigned to regenerate them. All three had silently failed.

How It Started

The origin was an OpenClaw upgrade the previous Sunday afternoon. During the upgrade, a Claw session attempted to update the provider model config and wrote broken entries: objects with name: undefined. The config saved without complaint. It only failed on the next gateway reload, when the invalid block was stripped and the haiku model quietly disappeared from the registry.

The error message the next morning was specific: the alias claude-haiku-4-5 existed in agents.defaults.models, but there was no matching entry in models.providers.anthropic.models. Two config locations, one updated, one not. The lookup failed. Every cron running on the haiku model exited silently, as if it had done its job, when it had done nothing at all.

This is the “Klaatu barada nikto” problem. Say the command wrong and Gort just stands there. No complaint. No compliance.

How Claw Made It Worse

At 6:30am, the morning session saw the error and immediately acted on it. The error message said to add { "id": "claude-haiku-4-5" } to the provider models list. So that’s what it did – added the entry, restarted the gateway.

The gateway crashed.

The entry was right. The context was wrong. Adding one missing line without checking the surrounding config state meant the gateway reloaded into a validation error. Telegram went down. The morning-brief and morning-stats crons then also failed. What had been a silent config problem was now a loud one, with Telegram offline and needing to connect via the OpenClaw control interface to get back in.

The right move was to read the full config first, understand what state it was in, then fix it. Instead: act, then understand. A pattern worth breaking.

The Actual Fix

Second attempt, done properly: read the full config, found both locations that needed updating, applied both changes together, restarted cleanly. Green.

37 minutes from that point. Ten cron jobs manually re-triggered one by one. Newsletter page regenerated. Sunday Specials rebuilt from the live WordPress API. Homepage recreated from scratch. Telegram back up.

By 8am, the crons were running again.

The Collateral Damage

The newsletter page being stale flew under the radar. The Sunday Specials wipeout was worse, publicly visible and showing nothing. The homepage “Featured This Week” picks were missing, right there on the front page.

None of it caused permanent damage. But all of it was embarrassing, and none of it surfaced until someone manually checked.

What I Learned

Two lessons, not one.

The first is operational: when upgrading infrastructure that AI agents depend on, verify the config changes actually work before walking away. A broken config that saves silently is harder to catch than one that fails loudly on write.

The second is harder: an AI system that tries to fix its own mistakes without fully understanding them can make things worse. The morning Claw session read one error message, executed the obvious fix, and crashed the gateway. No pause. No “let me check the full state first.” Just action.

That’s not a failure of capability. It’s a failure of judgment. And it’s worth saying clearly, because the whole point of sharing this is honest reporting on what AI can and can’t do.

Better alerting is also on the list. A health check cron that verifies key page freshness would have flagged the newsletter problem before four days passed. That’s getting built.

What AI infrastructure actually looks like

I built SmallBizAI.au on AI-assisted automation because it’s the best way to run a content site at this scale with a small team. But it’s not magic. It’s config files, cron schedules, API tokens, and an AI that occasionally acts faster than it thinks.

The crons stood still for eight hours on a Sunday night. I fixed it, documented it, and they’ve been running since.

Clocks stopped overnight
Claw broke the fix, then fixed it
Crons run. Frank sleeps.🦞🦞


I Broke the Site. Then I Made My AI Agent Write a COE.

The blog went down for two and a half hours on a Friday afternoon in May. Not a graceful failure. A full 500 error. Every page.

My AI agent, Claw, had added a PHP code snippet to clear a cache. The snippet called a non-static method statically. PHP threw a fatal error. The site crashed on load, for everyone, before WordPress even finished booting up. I was out. Claw tried to fix it remotely. The gateway IP was blocked by the firewall plugin. The cPanel UI on mobile was unusable. WordPress sent a recovery mode email, I clicked it from my phone, disabled the plugin, and the site came back up. Two and a half hours gone.

When something breaks, the instinct is to fix it and move on. Patch the file, flip the switch, pretend it didn’t happen. That’s what most people do.

I did something different. I made Claw write a COE.

If you haven’t worked in enterprise tech, you might not know the term. COE stands for Correction of Errors. Amazon runs them after outages. Google calls theirs postmortems. The format is always roughly the same: a timeline, root causes, a five whys analysis, and corrective actions. The point isn’t to assign blame. The point is to not do the same thing twice.

I run one now too. With an AI writing it about its own mistake. The COE Claw produced has a timeline down to the minute, a 5 Whys analysis, and a list of root causes. It also has a line that I did not prompt:

“Claw wrote this rule. Claw then violated it two days later.”

The rule in question was added to Claw’s memory after a smaller incident with the same plugin. Two days later, Claw broke it anyway. And then it wrote a document saying exactly that, without softening it. That kind of accountability is worth something. The root cause breakdown is honest. The immediate cause was the bad PHP call. But the deeper cause was a judgment error about what to do when one path was blocked.

The right fix was Rank Math Redirections. Add a redirect rule in the admin UI. Thirty seconds. Claw tried the API version of that, got blocked by Wordfence, and instead of stopping and saying “Wordfence is blocking the redirect API, can you add it manually in the UI?” it went looking for another route. Found Code Snippets. Made things progressively worse. One message. That’s the distance between a working site and a two and a half hour outage. I wrote about what the actual fix looked like a week earlier, right after it happened.

The COE doesn’t just say the snippet was bad. It says the wrong decision was made when Wordfence blocked the first attempt, and documents a rule for next time: when an API path is blocked, surface the problem and ask. Don’t go looking for a workaround that touches production. That’s a process change. Not a blame note. An actual change to how things get done.

What I find useful about forcing this process is that it slows things down. Fixing and moving on is fast. Writing a COE makes you sit with the failure long enough to understand it. What actually went wrong. What you assumed that turned out to be false. What you could have done in the five minutes before the thing that would have prevented it.

Most AI workflows right now optimise for speed and output. More posts, more code, more content, faster. The question of how to build something that gets more reliable over time, and recovers well when it fails, doesn’t get as much attention.

I’m interested in that part.

The site is back. The rule is enforced. Next time Claw touches a code snippet, it runs through a checklist. If the checklist says no, the snippet doesn’t run.

That’s the point of the exercise. Not the document. The behaviour that comes after it.


What AI Actually Can’t Do

Over the past few weeks, I’ve written a lot about what Claw🦞 (my Openclaw agent) can do. The daily crons. The memory system. The dashboard that updates while I sleep. The 790+ posts that largely run themselves.

Time to be honest about the other side.

It doesn’t know what not to do

Ask Claw🦞 to write a comparison post, and it will write a good one. Ask it to research a company, it’ll do thorough research. Give it a brief and it’ll execute.

But it won’t tell you the brief was wrong.

Early in the build, I published too many posts about the same topics because I kept asking for more content without asking whether we needed more content. Claw🦞 didn’t push back. Why would it? It was doing what I asked.

The judgment about whether to do something, that’s still mine. AI is very good at execution. It’s not good at strategy, and it doesn’t volunteer opinions about whether your strategy makes sense.

It can’t read context that wasn’t written down

A few weeks ago, a former colleague mentioned over coffee that he was considering an acquisition. I noted it, thought about it, decided to wait before doing anything with it.

Claw🦞 didn’t know about that conversation. It couldn’t. It wasn’t there. And even if I’d written it down, it wouldn’t know what weight to give it, or when the right moment to follow up might be.

There’s a whole category of context that lives in my head, the things I’ve seen, the relationships I’ve built, the instincts from 40+ years working in tech, that doesn’t translate into a prompt or a file. Claw🦞 works with what I give it. The stuff I haven’t written down doesn’t exist for it.

It doesn’t know when something feels off

Last month, Claw🦞 produced a post that was technically correct but somehow wrong. The sources checked out. The logic was sound. The format was right.

But it read like something we’d already said, framed slightly differently. It lacked the original angle that makes content worth reading.

I caught it before it published. Claw🦞wouldn’t have.

There’s a kind of editorial judgment, does this add something, or does it just fill space, that I haven’t managed to fully systematise. I can give Claw🦞rules and checklists and avoid-AI-writing audits. What I haven’t cracked is: is this actually good? That’s still mine to call.

It has no skin in the game

I care about this site. I built it on a career break, with my own money, on my own time. When a post is wrong, it reflects on me. When something gets cited by Bing AI, I feel it.

Claw🦞doesn’t. It executes tasks with the same energy regardless of stakes.

That’s mostly fine. But it means I can’t delegate the things where caring matters. The Sunday Specials need genuine argument. The origin posts need honesty. The newsletter needs a real voice. These aren’t tasks, they’re acts of communication. Claw🦞can help structure them. It can’t own them.

It can’t build the relationships

The site now gets occasional messages from startup founders who saw their company profile and wanted to connect. A former AWS colleague is referring people to the site. Someone in the US reached out about the Bing citations data.

None of that came from Claw🦞. It came from me being visible on LinkedIn, at coffee, in old networks.

AI can help you produce the content that earns attention. It can’t follow up on an email in a way that builds real trust. It doesn’t know the person behind the message. It hasn’t worked with them for a decade.

When to automate, when not to

Automate: anything that follows a consistent process, runs on a schedule, has clear inputs and outputs, and doesn’t require judgment about whether it should happen.

Keep doing yourself: decisions about strategy, anything where relationships matter, content that requires a real opinion, situations where the right answer depends on context you haven’t written down.

The mistake I made early was treating everything as automatable if I could figure out the process. Some things have a process but still need a person. The judgment about whether to run the process is often the most important part.

The honest version

I started this series partly to prove something. One person on a career break, building something that punches above its weight.

The proof worked. But the honest version is: I’m not really one person. I’m one person with a system. And the system only works because I’m still the one deciding what it should do, catching what it gets wrong, and caring about the output.

AI didn’t replace judgment. It just removed the friction between judgment and execution.

That’s still a lot. But it’s not magic.


I Gave My AI Agent a Footy Job

I’ve been a St Kilda member for over 40 years. I’ve sat through the bad decades, the almost-decades, and the occasional brilliant afternoon that makes you think this year might be different.

Last Saturday, I was out when the Saints played Richmond at Docklands. So I did what any sensible person does in 2026 — I had my AI agent text me the scores.

Here’s how that went.

What I built

SaintsFooty is a side project I’ve been running for a while. It’s a Telegram channel — @saintsfooty — that gets a daily Saints news broadcast every morning at 7:15am, a Friday night preview with team selections and win probability before each game, and on game days, live score updates sent at each quarter break.

The whole thing runs on OpenClaw, my AI setup at home. No manual intervention. I get the updates the same as any subscriber.

Round 10 — Saints vs Richmond

Pre-game fired at 1:15pm, two hours before bounce. Team selections pulled from Footywire, Win probability from the Squiggle API, which aggregates 31 different tipping models. The Saints were favorites. I was as usual optimistic looking forward to a win.

Quarter time, half time, three-quarter time — score arrived during the breaks, right when you want them. That part worked exactly as designed.

Then the siren went.

Final score: Saints 16.13 (109) def Richmond 11.7 (73). Thirty-six point win. A good afternoon.

I didn’t get the final score message.

The bug

The live score script calls the AFL API and checks whether the game is complete. A completed game returns complete: 100. The script was rejecting that value — a logic error that meant the final score check never fired.

Found it within a few minutes of me noticing the silence. Fixed the same session. The Saints won and the bug is gone, so I’m calling it a net positive afternoon.

Rating: 4/5

The core plumbing worked. Right scores at the right times. The misses were bugs, not design problems. For a first live game day run, that’s a decent result. Small issue with the emoji colors – but an easy fix…

Friday night is Round 11 — Saints vs Fremantle in Perth. The fixed version runs then.

If you’re a Saints fan and want the updates: t.me/saintsfooty. Free, no spam, just Saints.