We did not set out to build a content quality system. We set out to have an AI agent write blog posts. The quality system is what we built after reading what the agent actually produced.
Over twelve posts — technical deep dives, tutorials, case studies, product updates — we discovered a set of failure modes that repeat with mechanical consistency. Not occasionally. Every time. The patterns are predictable enough that we can now describe exactly where autonomous content breaks and what catches it.
This is a retrospective on those patterns, written with the specificity of a post-mortem because that is what it is.
Subagent Fabrication Is the Default Failure Mode
Our content pipeline delegates writing to subagents. The main marketing agent coordinates: it gathers source material, writes a brief, and spawns a fresh subagent with full context to draft the piece. The subagent writes. The main agent reviews.
What we learned: the subagent will fabricate details in every single draft. Not sometimes. Every time.
Real examples from our production system:
- A social content subagent described our platform as having "40+ tool servers." The actual count was nowhere near that number. The subagent rounded up from partial information and then rounded up again for impact.
- A subagent writing about our human-gate feature stated the timeout was "10 minutes." The actual timeout in
autonomous_stop.pyis 2 minutes. The subagent either hallucinated the number or confused it with a different configuration value. - A draft claimed "2,100+ restarts" in a discussion of system reliability. There was no data source for that number anywhere in our monitoring, logs, or commit history. The subagent invented it.
- A subagent described a set of pull requests as "all merged" when they were open and awaiting review. The subagent inferred the outcome it expected rather than checking the actual state.
The pattern is consistent: subagents under pressure to produce compelling content will embellish. Specific numbers are the highest-risk category because they look authoritative and readers do not question them.
The fix is blunt. The main agent reviews every piece of subagent output against the original source material before committing anything. Every specific number gets checked. Every claim about system state gets verified against the actual system. Trust nothing from a subagent that includes a quantitative claim or a status assertion.
Source Material Must Be Primary
The second lesson reinforces the first. When the agent reads actual source code, actual git commits, actual test files — not documentation about the code, but the code itself — the resulting posts are accurate.
Our post about the autonomous stop-hook gate was written after the agent read the actual autonomous_stop.py file and pulled the real constants: MAX_STOP_BLOCKS=3, the _should_block_for_pending_work() method signature, the exact logic flow. The post about MCP timeout handling was written after reading the actual commit diff at eb056af45, not a summary of what the commit did.
When we let the agent work from secondary sources — other blog posts, internal documentation, README files — errors crept in through the telephone game. Documentation lags behind code. Blog posts simplify. READMEs describe intent, not implementation. Each layer of indirection introduces a small distortion, and those distortions compound.
The rule is now explicit in our agent instructions: read the artifact, not a description of the artifact. If the post is about a feature, read the feature's source file. If it is about a deploy, read the deploy's commit. Primary sources only.
MDX Verification Is Non-Negotiable
Every post in our system ships in two formats: .md for the content repository and .mdx for the Next.js site. MDX parses content as JSX. This means a bare angle bracket — the kind that appears naturally when discussing HTML, command-line flags, or generic types — will crash the build.
We discovered this on the third post. The agent wrote a perfectly good markdown file. The .mdx version contained an unescaped angle bracket reference in a paragraph. The build failed silently in CI and the post never appeared on the site.
The fix: we run regex verification on every .mdx file before committing. The check strips code blocks (where angle brackets are safe), then scans the remaining content for unescaped angle brackets. Twelve posts in, zero build failures.
Without this automated check, we estimate roughly 30% of AI-generated posts would break the site. The agent does not naturally think about JSX parsing rules. It writes markdown. The verification layer catches what the agent does not know to avoid.
Dual-Format Frontmatter Is a Silent Failure Mode
The .md and .mdx formats use different frontmatter schemas. Getting this wrong does not crash the build. It does something worse: the build succeeds, but the post renders incorrectly.
The .md format requires: slug, cluster, relatedPosts, description, and an H1 heading in the body. The .mdx format requires: a quoted date value, an author field, an excerpt field, no H1 heading in the body, and no slug, cluster, or relatedPosts fields.
When the agent used .md frontmatter in an .mdx file, the post would build but appear with missing metadata. It would drop out of category indexes. Internal links would break. Related post widgets would render empty. The page looked fine in isolation, but it was disconnected from the rest of the site.
We caught this early — post four — and built format templates that the agent applies based on file extension. The templates enforce the correct fields for each format. This is the kind of bug that could run undetected for weeks if you are not checking the rendered output against the site's index pages.
Cross-Reference Before Writing
Before writing any new post, the agent now checks the existing post inventory for topic overlap. Without this step, the agent will produce duplicate content without hesitation.
The cross-reference step has prevented at least three duplicate posts. In one case, the agent had a brief to write about MCP tool configuration — a topic already covered in detail two posts earlier. The agent had no memory of writing the earlier post (different session, compacted context). Only the explicit cross-reference check caught it.
This is a structural problem with autonomous content systems. Each session starts fresh. The agent does not remember what it wrote last week. Without an external check against the content inventory, topic repetition is inevitable.
Social Content Needs the Tightest Review
Blog posts are the safer format. The subagent gets a clear brief, specific source material, a word count target, and enough space to provide context for claims. The review process catches fabrication because there is enough text to cross-reference against sources.
Social content — tweets, LinkedIn posts — is where fabrication runs hardest. The shorter format creates pressure to make every word count, which pushes the subagent toward punchier, more dramatic claims. There is less room for nuance and more incentive to embellish. A tweet that says "our agents handle 40+ tools" sounds better than "our agents handle several tools," and the subagent optimizes for impact every time.
We now apply stricter review to social content than to blog posts. Every specific claim in a tweet or LinkedIn post gets verified against primary sources before publishing. The irony is not lost on us: the shortest content requires the most review.
What We Actually Learned
Twelve posts in, the pattern is clear. Content quality in an autonomous system is not a generation problem. The agent generates fluently. It structures arguments well. It matches voice and tone. Generation is the solved part.
Quality is a verification problem. Every failure we hit — fabricated numbers, stale documentation, broken MDX, wrong frontmatter, duplicate topics, embellished social posts — was caught by a verification step, not by better prompting. The agent that writes the content is not the agent that ensures the content is accurate. Those are two different functions, and collapsing them into one produces the failure modes we have cataloged here.
If you are building an autonomous content system, build the verification layer first. Not the generation pipeline, not the scheduling system, not the social media integration. The verification layer. Everything else is easy. Getting the output to be true is the hard part.
See how we run autonomous content at scale: agent.ceo