Use case
Briefs arrive by email, phone call or RFP, and almost none of them are complete. Multiply reads what a project already contains — the brief, past decks, correspondence — and surfaces the knowledge gaps in it before the work starts, so implicit assumptions become explicit decisions. Teams then use the same context to pressure-test creative directions rather than only to draft them.
Today
The commitments that cause trouble are the ones never formally captured — something discussed on a call, a client request implied rather than stated. There is no system that surfaces what is missing or assumed, so teams rely on memory and judgement, and the mismatch shows up later as a mismatch of expectations. Meanwhile the brief itself lives in an email, the scope in a document, and the context in someone’s head.
How it runs
The brief on its own is rarely enough. Upload it alongside the client’s brand material, the last campaign’s deck, and the correspondence, and the project reads them together.
The context engine names what is absent as well as what is there — the audience nobody defined, the success measure nobody set, the constraint mentioned once on a call. Those gaps are the questions to take back to the client while it is still cheap to ask.
The more useful move is adversarial: ask what a direction assumes, what contradicts it in the material, and what a sceptical client would push back on. The context is already loaded, so the answer is about this client rather than about categories in general.
Insights flow back up to the client’s workspace when a project closes, so the next brief for the same client starts warmer than the last one. The cold-start problem shrinks with every project instead of resetting.
Plenty of tools will write you a brief. The harder and more valuable thing is knowing what a brief is missing, because a confidently written brief built on an unexamined assumption is worse than an obviously incomplete one — it hides the question instead of raising it.
So this use case leads with gaps and grounding rather than with generation. Agency teams we work with were unambiguous that a brief has to be editable and owned by a person to be worth anything, and that shapes how we build it.
Related: the product for how the pieces fit together, multi-client operations for running several of these at once, agency operations for the underlying idea, and the other use cases if briefing is not the job you want to start with.
Bring a brief you are unhappy with. Those are the useful ones to run.
Yes — that is the point of the modular design. Agencies build agents and workflows that match their own process rather than adopting someone else’s, and the frameworks worth keeping are usually the reason a client hired the agency in the first place. A platform that standardises those away wins on tidiness and loses the thing being sold.
That is the knowledge-gaps output. It is derived from the material rather than a fixed checklist, so it flags the absent audience definition or the undefined success measure for this brief specifically.
With research — a thin brief is a retrieval problem before it is a strategy problem. See research and insight.
The gaps are the output. We will run a live one on the walkthrough.