We ran a business on seven AI agents for three months. Every failure had the same root cause.

We gave seven scheduled AI agents real jobs inside a small media business. One wrote articles. One logged KPIs every night. One produced a weekly board report. They ran on cron. Nobody watched them closely.

Three months later the business had published 21 drafts we could not use, served Google 11 dead URLs, and earned zero revenue.

This is the incident log, with the numbers. If you are putting agents into an operational loop, the specific failures matter more than the general advice, so they are all here.

Failure 1: the article factory produced the same article five times

The writing agent ran every morning at 9:00 and published directly. For weeks nobody read the output. When we finally audited it:

• One title — a fiber-internet comparison — appeared five times, published on five different days
• A second title appeared three times
• Several posts linked to affiliate programs we had never been approved for
• One post claimed an earnings figure with no basis behind it
• One post’s title was literally the model’s own error message asking the operator a clarifying question

Of 21 drafts sitting in the queue, zero were usable.

The pipeline itself never broke. It ran on schedule every single day. Only the output was broken — which is precisely why nobody noticed.

Failure 2: the morning agents ran two hours late, every day

Two agents were scheduled for 6:10 and 6:45. We measured when they actually executed: 8:18 and 8:20.

The cause was mundane. The scheduler only fires while the host application is running, and the machine was not awake at 6:00. Every morning the jobs queued and executed whenever the app opened.

One of those agents was supposed to prepare a 7:30 posting slot. It never once made it in time. That slot stayed empty for three weeks.

The same cause corrupted our measurement. The nightly KPI logger was scheduled for 22:00 — an hour when the machine was reliably awake — and it mostly ran. But across a 20-day window we had 12 days of data. Forty percent missing, and no alert, because a job that never runs produces no error.

The lesson we took: you can only schedule automation for hours when the host is reliably available. For us that was night, not morning. Check your actual execution timestamps against your intended schedule. They may not match.

Failure 3: two agents wrote to the same output

One agent generated social posts. Another scheduled them. Both had been given permission to publish to the same channel.

Neither malfunctioned. Each did its job correctly. The result was 1.25× the intended daily volume and the same link going out twice in one day.

We fixed it by making the output single-writer: one agent owns the channel, every other agent may only deposit material for it. That rule has held since.

Failure 4: four weeks of publishing that search engines never saw

This one cost us the most and we found it last.

We published an article and watched for a month. No impressions. We assumed it was ranking slowly — new sites take time. Then we inspected the URL directly in Search Console:

Last crawl: N/A
Referring sitemaps: none detected
Referring pages: none detected

Google had never crawled it. Not ranked low — never fetched.

Three things had gone wrong at once, and none of them were visible from the admin dashboard:

1. The sitemap had frozen three months earlier. It still advertised pages we had deleted — 11 URLs returning 404 — and listed none of the new ones.
2. The new article had zero internal links pointing at it. No sitemap entry, no inbound link, no path in.
3. The URL used non-ASCII characters, so every share turned into a wall of percent-encoding.

Index coverage at that point: 9 pages indexed, 20 not indexed. The largest single reason for exclusion was “Not found (404)” — the dead URLs our own sitemap was handing to the crawler.

All four had the same root cause

Nobody looked at the output for long enough.

That is the uncomfortable part. Automation removes the work, and it quietly removes the checking along with it. “It ran” and “it ran correctly” are different claims, and only the first one is self-reporting. The second requires a human to look.

Failure 1 needed someone to read one published article. Failure 2 needed someone to compare a timestamp. Failure 3 was visible on the channel itself. Failure 4 needed one URL inspection. None of them required expertise. All of them required attention that the automation had implicitly retired.

What we changed

Checkpoint long jobs. An agent told to “research, write, and generate an image” in one run would die partway and leave nothing. We now save a skeleton first and append to it. A failed run leaves partial work instead of none.

One writer per output. Any shared destination is owned by exactly one agent. Others deposit inputs. This single rule eliminated an entire class of collision.

Machine checks before publication. We wrote a gate that runs eight checks before anything goes live: every link resolves, affiliate links point only to approved programs, no unsupported earnings claims, no near-duplicate of existing posts, required disclosures present, no model artifacts in the text, and dates that are internally consistent. It fails closed — a failed check means the post becomes a draft, not a publication. We have since written up each of those eight checks in detail, including the ones that were wrong when we first wrote them.

We ran that gate against our existing published posts as a test. Every one of them failed. Problems the authors had not noticed were still sitting live on the site.

A human still reads it. This is the one we were most tempted to skip, and the one that matters most. A machine check catches broken links and duplicates. It cannot judge whether a piece is worth reading. Google’s 2026 guidance draws the line in the same place: the question is not whether AI drafted the content, but whether a knowledgeable person reviewed it. Sites publishing unreviewed AI output at volume have reported traffic losses of 50–80%.

The gate’s job, we decided, is not to approve content. It is to make sure only things worth a human’s attention reach a human.

The volume question

One more data point, because it cuts against the instinct.

On a separate property we increased published articles from 13 to 23 in a single push. In the days immediately after, followers went down, from 18 to 17. What moved the number later was not volume — it was fixing the profile and the navigation, and publishing one piece on a topic nobody else was covering.

Our most-read piece across everything we shipped was not the highest-volume output. It was the one thing we knew that others did not.

If you are about to do this

Decide your review cadence before you decide your automation scope. We did it in the other order and paid for three months.

Concretely, from our own logs:

• Compare intended schedule against actual execution timestamps, once
• Open your sitemap in a browser and confirm your most recent post is listed
• Inspect one published URL and check the “last crawl” field
• Read one full piece of output per week, start to finish

The fourth item is the one we skipped, and it was the one that would have caught everything.

We are running the same system again with those changes in place. We will publish what happens, including the parts that do not work.

---

Editorial note: written and fact-checked against our own operational logs and analytics. All figures are measured from our own properties, not estimates. Reviewed before publication by the site operator.

Disclosure: this article contains no affiliate links. Where we recommend tools in future articles, we will state clearly whether we have a commercial relationship with them.