A content brief is a stored record, not a message in a conversation, and the difference decides whether the same query gets planned the same way twice. An agent that reads a stored search result page and composes a plan in its head loses that plan when the context window rolls, so the next run re-derives a slightly different plan from a slightly different reading of data somebody already paid for. A brief is that reading written down: one row per query per result-page identity, with the intent, the artefact, the questions, the competitors and the evidence it was built from.
A brief is durable when it is addressed by something stable enough to find again. In this product the address is the app plus the SERP fingerprint — the query, the country, the language, the location and the device — under a unique index, so a brief for the US desktop result page is a different record from one for Germany on mobile. Regenerating a brief over the same question replaces that row and increases its revision number rather than piling up a second near-identical page, because the value of the record is that a person can read one page and decide.
Costing nothing to produce is not a nicety here, it is what makes the feature possible on a shared search key. Every input to a brief is a stored snapshot, so the evidence record carries the snapshot ids, the oldest and newest capture dates, the snapshot count and a searches-spent figure that is always zero. A non-zero value in that column would be a bug worth alerting on, which is a more useful promise than a sentence in a marketing page.
A prompt and a brief can contain the same sentences and still behave differently, because a prompt is addressed to one model in one session and a brief is addressed to whoever writes the page next. The practical differences are about storage, review and cost rather than about wording.
| Question | A prompt in a session | A stored brief |
|---|---|---|
| Where it is after the session | Gone | One row per app per result-page fingerprint |
| What happens when it is redone | A slightly different plan | The same row, revision increased |
| What a person reviews | A two-thousand-word draft | One page saying what the draft will be |
| What it cost to produce | Often a fresh paid search | No searches at all |
| When the result page is unclear | The model picks something | Intent UNKNOWN, artefact NO_ARTEFACT |
The review that matters happens on one page, not on a finished draft. Approve, reject or mark a brief used, and the rejection is kept so the query is not proposed 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.
A brief is bounded on purpose, and two of its boundaries are worth stating out loud. It carries no body copy — no paragraphs, no generated prose — because a brief that started carrying text would become a second, unversioned content store sitting next to the one that already has revisions, a preflight and a brand-voice check. And it carries no search volume and no difficulty score, because neither is purchasable on the key this product runs on, and a number invented from the shape of a result page would be read as a measurement.
What a brief does carry is what a result page can honestly support: the inferred intent with the signals behind it, the artefact that intent calls for, a proposed title, the sections with a reason attached to each one, the pooled questions and related searches, the terms that already rank, and the competing domains with their appearance counts and positions. The competitor table is copied into the record rather than looked up when the brief is read, because a table that changed underneath an approval would make the approval meaningless.
Every array in a brief is capped, because all of it is derived text and derived text grows without an editor to stop it. The caps are also a statement about what a reviewable page looks like:
Briefs do not expire. A tracked keyword is a statement of what somebody decided to pursue, and a brief is the same kind of statement about what to write and why, so it has no time to live even though the snapshots it cites do. That is exactly why the brief keeps its own copy of the conclusions instead of a promise to work them out again later.
An outline is a list of headings. A brief is the reasoning that produced them, which is what makes it reviewable: each section carries a reason such as which questions it answers or how many of the top ten results have that section. A reviewer can argue with a reason and cannot usefully argue with a bare heading, so a brief that omits the reasoning has kept the cheap half and dropped the half a human was supposed to check.
Only if you actually have them. Volume and difficulty come from paid data sources, and a brief that shows a number nobody bought is worse than a brief that shows none, because the number will be read as measured and acted on. What a result page can honestly support is intent, the questions people are asking, the terms that already rank and who is ranking, and a brief limited to those is still enough to decide with.
The existing record is replaced in place and its revision number goes up, rather than a second near-identical brief appearing next to the first. A brief that has already been used to create a post keeps its slot, which is deliberate: it is the statement the published post was written from, and silently rewriting the reasoning behind something already shipped would break the record of why it was written.
It should be able to, and that is what an artefact of NO_ARTEFACT means. A result page that carries no strong signal, or one dominated by a single brand answering a navigational query, is not a page to compete for, and defaulting every unclear query to a blog post is how a content plan ends up being entirely blog posts. Recording the refusal also stops the next generation run from proposing the same query again as if it were new.
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.
