Sonic City is a music gear platform — band profiles, guitar rig breakdowns, gear databases, and daily editorial content. It has over 300 band pages, hundreds of gear articles, and publishes new content every single day.

I'm the only person who works on it. And by "works on it," I mean I occasionally check a dashboard. The actual work is done by seven AI agents that run autonomously, 24/7, on cron schedules.

This isn't a demo project or a proof of concept. Sonic City gets real traffic, generates real revenue through affiliate links, and has been running on AI agents for months. Here's exactly how it works.

The Seven Agents

Each agent has one job. They don't know about each other. They don't coordinate. They just run on their schedule, do their thing, and report back.

1. The Article Agent. Runs daily. Picks a band from the database that doesn't have a full article yet, researches their gear and history, and writes a 1,500+ word editorial piece. Commits it directly to the repo, formats it with proper metadata, and the site rebuilds automatically. This agent alone has written over 200 articles.

2. The News Monitor. Runs every few hours. Scans music news sources for gear-related stories — new pedal releases, signature guitar announcements, artist rig updates. When it finds something relevant, it writes a short news piece and publishes it. Most scans find nothing noteworthy. That's fine. When a story breaks, it's covered within hours.

3. The Gear Database Agent. Runs weekly. Crawls manufacturer websites and gear databases to keep the product information current. Updates prices, checks for discontinued items, and adds new releases. The gear database is the backbone of the site — every article references it — so keeping it accurate is critical.

4. The Analytics Agent. Runs daily. Pulls traffic data from analytics, identifies trending pages, and generates a summary of what's performing and what's not. This feeds into the Article Agent's topic selection — if a band page is getting organic search traffic, it's a signal to write a deeper article about that band's gear.

5. The Artist Biography Agent. Runs on a schedule. Takes existing band pages that have basic information and expands them with detailed biographies, discography highlights, and career timelines. This turns thin placeholder pages into rich, comprehensive profiles that rank well in search.

6. The Affiliate Links Agent. Runs weekly. Scans all articles for gear mentions that don't have affiliate links yet, looks up the products on partner retailers, and adds properly formatted affiliate links. It also checks existing links to make sure they're not dead. Last run, it added 14 new links and flagged 3 broken ones.

7. The Social Agent. Runs after the Article Agent publishes. Takes the new article, generates social media copy tailored to each platform, and queues it for posting. Different tone for different platforms — technical detail for Reddit, visual hooks for Instagram, concise takes for Twitter.

How They're Wired Together

The infrastructure is deliberately simple. Each agent is a script that runs via GitHub Actions on a cron schedule. The scripts use AI APIs (primarily Claude) to do the actual thinking, and they interact with the codebase through Git — reading files, making changes, committing, pushing.

There's no orchestration layer. No message queue. No microservices. Each agent is a standalone script with its own cron trigger. They can run independently, in parallel, without stepping on each other because they work on different parts of the codebase.

The cron schedules are staggered to avoid concurrent runs hitting API rate limits. Article Agent runs at 4 AM. News Monitor runs at 8 AM, noon, and 6 PM. Affiliate Agent runs Sunday mornings. And so on.

When an agent finishes, it calls a single reporting function that logs the run to SureStack's Agent Manager. That's the only shared infrastructure — the reporting endpoint.

The Problem Before Monitoring

For the first few weeks, I ran agents without any monitoring. They ran on cron, and I occasionally checked the Git log to see if they were producing commits. This was a terrible system.

Here's what actually happened: the Article Agent silently failed for three days because the AI API was returning rate limit errors. No commits, no errors I could see, no alerts. I just noticed on day four that the site hadn't published anything. By then I'd missed three days of content.

Another time, the Affiliate Agent ran successfully but produced garbage — it was adding affiliate links to the wrong products because a manufacturer had reorganized their website. The agent reported "completed" because it didn't crash, but the output was wrong. I didn't catch it for a week.

Running agents without monitoring is like hiring employees and never checking their work. You might get lucky. But you won't know when things break until the damage is visible to your users.

The Fix: Agent Manager

The solution was embarrassingly simple. Each agent script already had a main function that did the work. I added one function call at the end:

await reportAgentRun({
  agent: "article-agent",
  project: "sonic-city",
  status: "completed",
  details: "Published: Best Guitar Pedals for Shoegaze"
});

That's it. One function call. It sends a POST request to Agent Manager with what happened, whether it worked, and a brief description of the output. If the agent crashes, the error handler sends a failure report instead.

Now I have a dashboard that shows me, at a glance:

I check this dashboard once a day, usually with my morning coffee. Three green dots means everything's running. A red dot means something needs attention. It takes 10 seconds to confirm that seven autonomous processes are all healthy.

What I've Learned Running Agents for Months

Start with one agent. Don't try to build seven agents at once. Build one, make it reliable, add reporting, run it for two weeks. Only then start on the second one. My first agent (the Article Agent) ran for a month solo before I added the second. Each subsequent agent was faster to build because I'd established the patterns.

Make it report before you make it smart. The reporting function should be the second thing you build, right after the basic functionality. Don't wait until the agent is "finished" to add monitoring. The monitoring is how you know if it's working while you're still developing it.

Agents fail silently. This is the most important lesson. Unlike a web app where users complain when something breaks, agents just quietly stop producing output. If you're not actively monitoring them, you won't know they're broken. The gap between "agent crashed" and "I noticed" is where all the damage happens.

Simple beats clever. I originally tried to build an orchestration layer where agents could trigger each other, share state, and coordinate work. It was a nightmare to debug. The current system — independent scripts on cron schedules — is boring and it works perfectly. Each agent can fail without affecting any other agent.

Cost management matters. Seven agents making AI API calls on cron schedules can run up a bill quickly. I learned to be strategic about which model each agent uses. The Article Agent needs Claude's best model for quality writing. The Affiliate Agent just needs to match product names — a cheaper, faster model works fine. Right-sizing models per agent cut my weekly AI costs from $45 to under $5.

Think in Agents, Not Tasks

Here's the mindset shift that changed everything for me: stop thinking about tasks and start thinking about agents.

A task is something you do once: "Write an article about Fender Stratocasters." An agent is something that runs forever: "Every day, pick a band that needs an article, research their gear, and publish a piece."

Tasks require your time every time they run. Agents require your time once — when you build them — and then they run independently. As a solo founder, your time is the bottleneck. Every task you convert into an agent frees up your time permanently.

You don't need seven agents. Start with one. Pick the most repetitive, most time-consuming task in your project — the thing you do every day or every week that follows roughly the same pattern — and turn it into an agent. Add reporting so you know it's working. Run it for a few weeks. Then pick the next one.

Six months from now, you'll have a team of agents running your project while you focus on the work that actually requires a human: strategy, product decisions, and talking to users. That's not a hypothetical. That's what I'm doing right now, and it's the best decision I've made as a solo founder.