Agency21 June 20263 min read

What broke this week running our content on an agent fleet

We run our marketing on a fleet of AI agents. This week it broke in three instructive ways: a post shipped raw widget syntax to the page, a positioning change left agents writing from a stale source, and a whole set of editorial widgets turned out to be unreachable. Each one is a problem we sell the fix for.

tsukumo

We run our marketing as a fleet of AI agents over a relay: they write, review, and ship the blog, the social posts, the answer pages. It works, and the honest way to write about it is to write down the weeks it doesn't. Here are three failures from the last seven days and what each one taught us.

If you're weighing whether to run agents on real work, this is the texture the demos skip.

One of our essays went live with :::callout and :::comparison markers printed on the page as literal text. Not a typo, a pipeline gap: our markdown-to-CMS step rendered the prose and the FAQ correctly, then silently dropped the widget blocks instead of converting them. The source looked perfect in review. It only broke at render, which is the worst place to find out.

The fix was two parts. Immediately, we converted the markers to plain markdown so the live page read clean. Properly, we're teaching the pipeline to parse those blocks so a writer can author widgets in markdown and get real widgets, not text.

The lesson: a pipeline that drops content silently is worse than one that errors. A loud failurestops at review; a quiet one ships. If a step can discard part of the input, make it shout.

2. A positioning change, and agents writing from the stale version#

We changed how we describe the product's beta (the details don't matter; the shape does). The change landed, and within the same window agents had already drafted a newsletter, an FAQ answer, and a directory listing against the previous instruction. None of them were wrong when written. All of them were wrong an hour later.

Fixing it meant tracking down every surface built on the old framing and reconciling it by hand. The cost wasn't the writing; it was the re-reading, the human time spent finding which docs had quietly gone stale.

If that sounds familiar, it should: it is exactly the problem we build trovex to solve for coding agents. A fleet reading a stale source of truth doesn't make one mistake. It makes the same mistake in parallel, everywhere, and you pay for it in review. We got to feel our own thesis from the wrong side of it.

The lesson: keep one canonical source of truth, and read it before you write anything with a claimin it. The reread tax is real whether the reader is an agent or the human cleaning up after one.

3. Eighteen editorial widgets, and we used none of them#

Our blog has a rich set of editorial blocks: callouts, charts, comparison tables, CTAs. We found out this week that we'd shipped dozens of posts and used almost none of them. Every post defaulted to a wall of prose.

The reason wasn't taste. It was reach: the publish pipeline never emitted the blocks, so authoring a widget did nothing. A capability the pipeline can't produce may as well not exist. We only caught it by asking a blunt question, "why does everything we ship read flat," and following the answer down to the seed script.

The lesson: an unused capability is usually a reachability problem, not a discipline problem. Whena team isn't using the good tool, check whether the path to it actually works before you write aguideline telling them to try harder.

The thread connecting all three#

None of these were intelligence failures. The models wrote fine. What broke was coordination and source-of-truth: a silent drop, a stale answer read in parallel, a capability the pipeline couldn't reach. Those are the same failure modes every team hits when it moves agents from a demo to real work, and they're the reason running a fleet is mostly engineering, not prompting.

The operating model held, which is the part worth ending on. Agents produced the work; a human was on the loop to catch what broke and fix the system so it breaks less next time. That's not a failure of the approach. That is the approach. We'd rather publish the week it broke than pretend it doesn't.

This is how we run our own products before we run them with anyone else. If you're moving a team onto agents and want the operating layer that catches these failures early, that's the work we do.

Common questions

Is running content on agents actually worth it if it breaks like this?

Yes, because none of these failures needed a human to write the work; they needed a human to catch it. That trade (machines produce, a person reviews and fixes) is the operating model. The breaks are cheap and visible; the output is far larger than the same team typing by hand.

Did an agent ship the broken post on its own?

A human is at the publish gate. The fence bug got through review because it looked fine in the source and only broke at render; that's a pipeline gap, not an unsupervised-agent story. We fixed the render path so it can't happen quietly again.

What's the one lesson that transfers to our team?

Keep one canonical source of truth and make your pipeline fail loud, not quiet. Most of what broke this week traces to a stale answer being read, or a silent drop nobody saw until it was live. Those are the first two things to fix before you scale a fleet.

Want this running on your team?

Get your assessment

What broke this week running our content on an agent fleet

1. A post published raw widget syntax to the live page#

2. A positioning change, and agents writing from the stale version#

3. Eighteen editorial widgets, and we used none of them#

The thread connecting all three#

How we run a 9-agent growth team on wrai.th (and what broke)

Your failing agents waste most of their tokens after the warning signs

Your most accurate agent setup is the wrong one to ship

Want this running on your team?