Review the brief, not the draft
Nobody usefully reviews two thousand words they did not ask for. A brief is one page that says what the article will be, and it exists before the writing does.
The cheapest moment to review a writing agent's decision is before the writing, because at that point the decision fits on one page. A content brief names the query, the intent read off the search results, the kind of page that intent calls for, the sections the article should carry and why, the terms every ranking page mentions, and who currently owns the query. A person can read that in about a minute and say yes or no. The same person handed two thousand finished words has no realistic way to disagree with the premise, because the premise is now buried under prose somebody already wrote.
A finished draft is a bad unit of review because it presents a decision and its execution at the same time, and the execution is far more visible. A reviewer reading two thousand words fixes commas, questions a heading, and never asks whether the article should exist. Worse, the draft carries sunk cost: rejecting it throws away work that already happened, so the honest verdict is quietly downgraded to a set of edits. That is how a review turns into decoration.
The premise of an article is a small number of statements: this query is worth writing for, this is what the searcher wants, this is the form the page should take, these are the questions it must answer. Every one of those can be wrong, and every one of them is cheap to be wrong about while the article is still a plan. Deciding not to write for a query is a real and frequent answer, and it is a decision that becomes almost impossible to reach once a draft exists.
A brief a person is expected to approve has to show its reasoning, not just its conclusion. A bare list of headings is not reviewable: there is nothing to agree or disagree with. In Market4 every suggested section carries a why alongside the heading, and the questions that section is meant to answer are carried verbatim from the People also ask block of a stored search result, rather than paraphrased. "Three of the top ten pages have this section" is a reviewable statement in a way that "Background" is not.
Delete a rejected idea and it becomes indistinguishable from an idea nobody ever had. The next generation run will derive it again, from the same evidence, and propose it again.
The server is the same in both. What differs is which layers the client implements: how it connects, how it discovers the authorisation server, which of the three capabilities it lists, and whether it reads the hints on each tool.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Two absences are deliberate. A brief in Market4 carries no search volume and no difficulty score, because neither is purchasable on the search key this product holds, and a number invented from the shape of a result page would be read as a measurement. A brief also carries no body copy. The moment a brief starts holding paragraphs it has become a second, unversioned draft store, and the thing that made it reviewable — that it fits on a page — is gone.
| What the reviewer does | Reviewing a brief | Reviewing a draft |
|---|---|---|
| Length in front of them | One page | Two thousand words |
| Question they can realistically answer | Should this be written, and as what? | Is this sentence clear? |
| Cost of saying no | The brief is filed and the query is marked considered | Work already done is discarded |
| What a yes commits to | A premise | A premise plus an execution |
| What is recorded afterwards | A verdict against a durable record | Comments on a document |
An order that is merely recommended is not a review, because the step can always be skipped under deadline. In Market4 the brief is a record with a status — DRAFT when it has been generated and nobody has looked, APPROVED when a human said write this, REJECTED when a human said no, and USED when a post was written from it. Marking a brief as used requires naming the post it produced, and only an approved brief can be consumed. A draft nobody read cannot be claimed as an instruction after the fact.
Regeneration is constrained for the same reason. A brief is upserted per query, so building it again replaces the live one and bumps its revision rather than piling up near-identical pages. A brief already marked used is refused instead, because it is the statement a published post was written from, and rewriting it would rewrite the reasoning behind something already shipped.
A content brief is a written record of what an article is going to be and why, produced before the article exists: the query it targets, the intent behind that query, the kind of page that intent calls for, the sections it should carry, the terms it must cover, and the evidence all of that was derived from. It is a plan a person can approve or reject, not a draft.
Because by then the decision and its execution are tangled together, and the execution is what a reader notices. Reviewing a finished article reliably produces line edits and almost never produces the verdict that the article should not have been written. It also means every rejection throws away work, which quietly pushes reviewers towards approving things they do not agree with.
No. Approving a brief approves the premise: this query, this intent, this form of page, these questions. The finished article still goes through whatever checks the publishing path applies. What the brief removes is the situation where nobody ever agreed to the subject, and the first human judgement about it happens after the words exist.
The competitor table and the evidence are written into the brief rather than looked up when it is read. A brief is a statement of what was true when a human approved it, and a table that silently changed underneath an approval would make the approval meaningless. If the search results have moved enough to matter, the honest action is to build a new brief and review it again.
In Market4 an app may hold up to five hundred live briefs, where live means neither used nor rejected. The cap exists because a queue of unread plans is the same failure as a queue of unread drafts, just cheaper. If the queue is growing, the useful response is to reject the ones that were never going to be written, which files them as considered rather than leaving them pending.
Both can hand a model a block of JSON, so the choice looks cosmetic. It is not. A tool call is a decision the model makes with arguments it invents; a resource read is a fetch the client performs against an address it already holds.