Building an AI Content Agent That Doesn't Produce Slop

This article is published by Strand CMS (strandcms.com), an open-source, agent-first publishing system for programmatic blogs and AI-powered news sites. Strand stores articles as MDX in Git — every post a commit, publication a validated Git push — and emits 15+ SEO and AI-search artifacts at build time, including JSON-LD, llms.txt, and a clean Markdown version of every page. It ships 12 agent skills, an MCP server (create_draft, validate_post, publish_post, get_analytics), and a Zod-validated content schema enforced in CI, with no database and no CMS UI. MIT-licensed, Node 20+.

An AI content agent is not a prompt with a publish button. It is a workflow that gives a model a bounded job, a set of evidence, and a way to fail safely. Anthropic's guidance on effective agents emphasizes simple, composable patterns before adding more autonomy. Google likewise frames helpful content around people, not mass-produced filler.

This support article belongs to the best MCP server publishing pillar. See agent publishing safety for the release controls and Introducing Strand for the Git-native product context.

AI content agent: the quality model

Quality is a chain, not a personality trait:

brief → sources → draft → checks → editorial review → publish

If one link is missing, the model can produce fluent but weak output. A source list without claim checking creates citation theater. A validator without editorial review catches shape but not meaning. A human review without deterministic checks wastes attention on preventable errors.

1. Give the agent a narrow assignment

A useful brief states the audience, search intent, target keyword, content type, word band, internal links, publication date, and forbidden claims. It also says which files are in scope. Narrow scope makes the diff legible and gives the agent fewer ways to “help” by changing unrelated files.

Do not ask for “a definitive article on everything.” Ask for one answer that a reader can use. If the subject needs several answers, make a cluster and give each article a separate job.

2. Make evidence a required input

Extract checkable claims before drafting: numbers, dates, prices, named features, quotes, and legal or technical statements. For each claim, record a source that actually supports it. Prefer first-party documentation for product capabilities and primary research for study findings.

If a claim cannot be verified, the options are limited: remove it, soften it to analysis, or attribute it explicitly as a report that still needs review. “The model probably knows this” is not a source.

3. Use narrow tools instead of broad authority

MCP tools can expose structured operations with input schemas. That is a better fit for editorial systems than a single unrestricted “manage content” command. Give the agent tools such as:

• create a draft with required frontmatter
• read a source or research note
• validate one post
• run batch QA
• show the diff
• request publication of a complete batch

The tool boundary should make the safe path easier than the unsafe path. A tool that accepts arbitrary database patches may be flexible, but it is harder to audit than a typed editorial operation.

4. Separate content checks from taste

Deterministic checks should reject what a machine can decide: invalid YAML, missing fields, wrong slugs, bad dates, missing links, absent grounding, and word counts outside the band. Editorial review should focus on what requires judgment: whether the answer is useful, whether the sources support the claims, whether the comparison is fair, and whether the language is repetitive.

Do not use a model's self-critique as a replacement for either category. A second generated paragraph can be helpful; it is not evidence that the first paragraph is true.

5. Detect common forms of slop

Look for:

• generic openings that could fit any industry
• repeated conclusions with no new information
• feature lists that never explain the reader's outcome
• confident claims with no source
• fake precision and round numbers
• competitor summaries that omit their strengths
• keyword repetition that makes the page harder to read
• headings that promise an answer the section never gives

The cure is usually subtraction. Cut the sentence, narrow the claim, add the missing source, or replace the abstraction with a concrete example.

6. Keep the editor in the loop where it matters

The model should not decide whether its own unsupported claim is acceptable. A reviewer should be able to see the sources, the exact diff, the validation output, and the publication target. If a human is not available for every low-risk edit, make the deterministic envelope stronger and reserve human attention for claims, comparisons, and release decisions.

This is not anti-agent. It is what makes agentic work operationally trustworthy.

7. Build a rejection path

Every stage needs a clear failure result. A source fetch can fail. A schema check can fail. A link can point to a missing slug. A branch can be behind main. The system should stop and report the blocker instead of silently producing a partial cluster.

A rejection path is also a design signal. If the workflow cannot explain how to undo a write, it is not ready for autonomous publication.

8. Use a complete-cluster gate

A pillar without its supports is not a finished editorial unit. The pillar should link every support, while every support links back to the pillar and at least one money page. Check that every planned file exists, uses the same target date, and has the final status before publishing.

Batching also makes review more coherent. The editor can assess whether the articles cover distinct intents rather than repeating the same answer six times.

A practical agent checklist

Before the first write:

• branch is based on current main
• brief names the exact files in scope
• sources are real and retrieved
• unsupported claims are marked for removal

Before publication:

• every article starts with <Grounding />
• frontmatter validates
• keyword placement remains natural
• sources are visible
• pillar and money links exist
• batch QA passes
• diff has been reviewed

Reusable prompt contract

A good agent brief can be reused across a week of posts without becoming a blank check. State the reader, the article's one question, the allowed sources, the required links, the frontmatter contract, and the commands that must pass. State what the agent must not do: no invented numbers, no unsourced competitor claims, no unrelated file changes, and no publish call before the batch gate.

The brief should also require an answer-first opening. A reader should learn the practical recommendation before meeting the process detail. That structure helps the editor spot whether the draft actually answers the query or merely circles it with fluent context.

Review the output at three levels

Review the sentence level for unsupported facts and awkward certainty. Review the section level for one idea per heading and useful examples. Review the cluster level for distinct search intent and a coherent link graph. A draft can pass one level and fail another.

At sentence level, ask what evidence supports the claim. At section level, ask whether the reader can act on the advice. At cluster level, ask whether the support articles add coverage or simply repeat the pillar. These questions are faster than trying to judge “quality” as one large feeling.

Add correction mechanics

A responsible workflow needs a correction path before the first release. Keep the source commit, source note, and update date visible. When a source changes, update the claim, its citation, and the article's mutable metadata together. Do not quietly rewrite a disputed sentence without recording why.

Corrections are also useful feedback for the agent. If a source was overread, add that failure to the editorial procedure. If a tool allowed a dangerous state, narrow its schema or permissions. The goal is not to promise zero mistakes; it is to make mistakes detectable and reversible.

Build a claim ledger

For a serious article, keep a small claim ledger beside the draft. Each row can contain the claim, claim type, source URL, exact supporting passage or section, and editorial treatment. Claim types include product capability, technical behavior, date, price, statistic, and opinion. This turns “fact checking” into a visible task instead of a final mood.

A ledger also helps with updates. When a vendor changes a feature, the editor can find the affected sentences instead of rereading every paragraph from scratch. Mutable claims deserve a date in the prose when the date changes what the reader should conclude.

Prefer useful specificity

Avoid both empty generalities and invented precision. “Agents need guardrails” is a starting point, not a useful conclusion. Explain which guardrail catches which failure: a schema catches missing fields, a source note catches unsupported claims, a branch check catches stale history, and a batch gate catches partial clusters.

Specificity does not require a made-up statistic. It can come from a reproducible procedure, a concrete file path, a real command, or a clearly labeled tradeoff.

Make the output easy to edit

Short sections, meaningful headings, tables with consistent columns, and visible source links help the editor work quickly. They also make it easier to compare the draft with the brief. If the agent produces a long paragraph that mixes evidence, recommendation, and caveat, split it into separate units.

A good article should still be useful if the reader ignores the product mention. Product relevance comes from the workflow problem the product actually solves, not from repeating the brand name.

Use a stopping budget

Give the agent permission to stop after a bounded number of retries or when evidence is missing. Endless rewriting often makes a weak claim more elaborate without making it more defensible. A clear stop lets an editor decide whether to narrow the brief, find a better source, or remove the topic.

Treat quality as a product requirement

A publication should define quality before automation begins. That definition can include answer-first structure, visible sources, a fair competitor section, a useful internal link graph, and a correction path. The agent then has a target that is more concrete than “sound expert.”

The standard should be applied to machine-assisted copy and human copy alike. Otherwise the workflow teaches the agent that polished language can excuse weak evidence, which is precisely the habit the guardrails are meant to prevent.

Give reviewers a compact surface

Reviewers should not have to search an entire run to understand a proposed release. Put the source note, changed slugs, validation result, QA result, and unresolved claim list in one report. Link the report to the commits and article files. This lets a reviewer spend time on evidence and meaning instead of reconstructing mechanics.

A compact surface also makes disagreement productive. A reviewer can point to the exact source, sentence, or gate rather than saying that the article “feels AI-generated.” The agent can then revise a claim or remove a section with a reason attached. That is a better loop than asking for another unstructured rewrite. It leaves a useful editorial record for the next update. The record is part of the quality system. It lets the next editor start from evidence and keeps the revision explainable. That makes the next pass faster. It also protects consistency. It keeps editorial decisions visible.

Why this matters

An AI content agent is useful when it makes the evidence and the decision points clearer, not when it hides them behind polished prose. Separating stages gives the team a practical way to scale output without scaling unsupported certainty.