Most bad AI drafts are not a model problem. They are a brief problem. You handed a title and a rough idea to something that will happily fill any word count with whatever fits, and that is what you got back.
The fix is not a better model. The fix is a better brief. When you feed an AI writer the same inputs a good human writer would ask for, the draft comes back sharper, closer to the shape you wanted, and much easier to edit. When you skip them, no amount of prompt tweaking after the fact will save the post.
Here are the five inputs that pull the most weight, and a fill-in brief at the end you can copy into any agent.
Why a thin brief produces a generic draft
An AI writer is a very fast, very literal collaborator. It will infer whatever you leave out. If you do not tell it who is reading, it writes for everyone. If you do not tell it what to prove, it decorates. If you do not tell it what shape the post should take, it defaults to a listicle with an intro and a conclusion, because that is the average of every post it has seen.
The generic draft you keep getting is the model averaging its way through the ambiguity you left in the brief. That is not the model being lazy. That is the model doing the only thing it can with the material you gave it.
So the brief is the prompt. Everything upstream of the writer decides more than the writer does.
The five inputs that change the draft the most
1. The target query
Tell the writer the exact search the post is answering. Not the topic, not the theme, the query.
"AI writing tools" is a topic. "Best AI writing tool for a solo founder who hates generic drafts" is a query. The first gives you a survey post. The second gives you a post that argues a point for a specific reader.
A good target query is:
- Specific enough to picture the searcher. You can imagine the words they typed and why.
- Narrow enough to answer. If the post has to cover ten sub-questions to feel complete, split it.
- Written the way a person types, not the way a marketer writes. Lowercase, sometimes ungrammatical, honest about intent.
Hand the writer this query and it stops writing for "readers interested in the topic" and starts writing for one person who typed something into a search bar.
2. The reader stage
The same query can be asked by different readers, and each one needs a different draft.
A reader who is stage-one aware wants the concept explained. A reader who is comparing options wants a table and a recommendation. A reader who is ready to act wants the setup steps and the gotchas.
Pick one. Write down who the reader is, what they already know, and what they will do next if the post is any good. If you find yourself writing "beginners to advanced", you have not picked yet.
The writer will pitch the vocabulary, the detail and the calls to action to that reader. Skip this input and the draft tries to be useful to all of them and ends up useful to none.
3. The angle
The angle is the sentence the post is arguing. Not the subject, the argument.
"How to write blog posts with AI" is a subject. "The brief matters more than the model" is an angle. The angle is the reason a reader would send this post to a colleague instead of every other post on the same subject.
If you cannot write the angle in one sentence, you do not have one yet, and the writer will invent something bland to fill the gap. That is where the throat-clearing openings come from, and the polite both-sides paragraphs, and the endings that restate the intro. All of it is a model politely reaching for the middle when nobody told it where to stand.
4. The must-mention proof
Every claim in a post needs something behind it. When you write the brief, list the specific things the writer has to mention so the post is grounded in reality rather than in the model's general impression of the subject.
Proof can be:
- Facts about your product. Version numbers, pricing tiers you actually offer, features that actually ship.
- Named examples. A customer story you have permission to tell, a use case you have seen, a workflow you actually run.
- Numbers you own. Results from your own testing, survey answers you gathered, benchmarks you can back up.
- External sources. A study, a documented behaviour of another tool, a quote from a public interview.
The rule that matters: if a fact is not in the brief, and it is not in a source the writer can read, do not let it into the post. A model asked to write persuasively without ammunition will invent statistics. That is the single biggest reason people stop trusting their AI drafts.
If the proof does not exist, cut the section that would have needed it. A shorter, honest post beats a longer, invented one every time.
5. The structural template
Tell the writer the shape of the post. Headings in order, roughly what each one covers, and the format for the answer inside them.
A structural template can be as light as:
H2: What the thing is (one paragraph)
H2: When to use it (three bullets)
H2: When not to use it (three bullets)
H2: How to set it up (numbered steps)
H2: Common mistakes (short list)
Or it can be much more detailed. Either way, the writer stops guessing at the shape and spends its effort on the words inside the shape you asked for.
This one input alone kills the two most tiresome AI defaults: the pointless "introduction to the introduction", and the "in summary, we have discussed" ending. If you did not ask for either, and you gave the writer a structure, you will not get them.
The fill-in brief
Copy this, fill it in, and hand it to whatever agent you are using. Nothing here is precious. The point is that you have thought through the five inputs before the writer sees them.
Title:
Target query:
(The exact search this post answers, in a searcher's words.)
Reader stage:
(One reader. What they already know. What they will do next.)
Angle:
(The one-sentence argument the post is making.)
Must-mention proof:
(Facts, examples, numbers, sources. If it is not in this list, the
writer should not use it.)
Do-not-mention:
(Anything off-limits: competitors you will not name, claims you cannot
back up, features that are not shipped.)
Structural template:
(Headings in order and the format for each section.)
Tone rules:
(Voice, banned phrases, house style points that matter for this post.)
Success looks like:
(One or two sentences describing the draft you would happily edit and
ship, so you can compare the output to it.)
Two lines matter more than the rest. The angle, because it is the only thing that makes the post yours and not a mash-up of every other post on the same subject. And the must-mention proof, because it is the only thing standing between you and a plausible-sounding invented number.
Where the brief fits in a RankMill run
RankMill treats the brief as the moment before the writer runs, not something you tack on after.
When a topic hunt suggests a topic, it comes back with a title and an outline. It can also come back with up to four questions the research agent could not answer on its own: a price, a customer name, a date, an integration. You answer those in the app and your answers are handed to the writer as facts from the business. That is the research approval step, and it is where a thin brief becomes a thick one before anything gets written.
The website profile does a lot of the work for you. It holds who the business is, who it sells to, and how it sounds, so you are not re-typing the tone rules for every post. Writing rules on the project add the sentence-level house style. The topic and its answers add the target query, the angle and the must-mention proof. The outline is the structural template.
If you approve a topic with the questions blank, the writer writes around the gap rather than inventing to fill it. That is by design. A missing fact is safer than a made-up one, and a shorter honest post is more useful than a longer padded one.
Write the brief you would hand to a careful human, hand the same brief to the agent, and the draft you get back stops looking like generic AI copy and starts looking like something you would edit and ship.