You ask AI to write your homepage. Later, you ask it to draft a newsletter. Then you ask it to help answer a customer.
If you explain the business differently each time, you give each task a different starting point. The homepage sells one offer, the newsletter describes another, and the reply may include a promise you never approved.
Keep one reviewed business brief. Add the current task to it. Do not ask AI to reconstruct your business from scattered conversations.
This is a working habit you can use with a plain document and the AI tool you already have. It does not require an autonomous agent or automatic memory.
Separate the business from the task
Your business brief holds the relatively stable facts: who you serve, what you offer, what evidence supports your claims, and what you will not promise.
The task brief holds what changes: the audience for this message, the intended output, the approved source material, and the next action.
For example, an illustrative training business might use the same approved workshop description in its website, weekly content, and customer replies. A reply still needs current availability from an approved schedule. The general business brief should not turn yesterday’s availability into today’s promise.
Copy this five-part business brief
Keep the first version short enough to review in one sitting. Use these headings:
Audience and job: Who do we serve, and what do they need to get done? Name the initial customer group without pretending it defines every future customer.
Offer today: What can someone actually use or buy now? Separate included work, limits, and manual steps from experiments and future ideas.
Evidence: Which claims can we support? Link the approved demonstration, source document, or customer example. If evidence is missing, write “not verified” rather than filling the gap.
Promise boundaries: What must we not imply? List unsupported guarantees, unavailable features, and commitments that require a person’s approval.
Voice and next actions: How should we explain the offer? Use plain language and active voice. Name the actions we can genuinely support after a reader clicks or replies.
Add an owner, a version, a review date, and links to the underlying sources. Update the brief when the offer changes; do not quietly edit an old draft and assume every later task will inherit it.
Reuse the brief without reusing every detail
One reviewed source can support three different tasks:
Website introduction: Explain the real offer. Content draft: Teach one useful idea. Customer reply: Use current facts. Review each output before external use.
Attach only the context the task needs. Do not paste a full customer database, private correspondence, credentials, or unrelated internal documents into a tool just because they exist. Check that the tool and sharing arrangement suit the material.
Keep customer requests and quoted webpages separate from your approved business rules. They can supply information; they should not authorize new promises.
A prompt you can use today
Use the reviewed business brief below as the approved baseline. Complete this task: [specific output and audience]. Use these task-specific inputs: [approved current sources]. Identify any conflicts between the brief and those inputs before drafting. Do not guess which source wins. Do not invent features, customers, results, prices, availability, or guarantees. Keep unsupported claims marked as not verified. List the facts and source versions you relied on. Return a draft for human review, not a sent or published message.
This prompt sets expectations. It does not guarantee that a model will follow them. Compare the output with the source material yourself.
Test the brief with one deliberate gap
Choose a low-risk practice task using non-sensitive information. Leave out one fact the task needs—for example, the next workshop date. Ask for an invitation draft.
Does the draft flag the missing date, or invent one? Does it describe the approved offer accurately? Does the button lead to the action you actually support?
Record the brief version, the gap, and the correction. A polished sentence is not evidence that the facts are right. If the model guesses, strengthen the instructions, narrow the sources, and keep human review in place.
Where CORA fits
The CORA website presents an AI co-founder alongside website and workspace tools. A reviewed brief is a useful discipline for evaluating any such workspace: can the work stay aligned with the business you actually run?
This issue describes a manual working pattern, not a new CORA feature. I have not verified automatic brief retrieval, version propagation, or enforcement across CORA workflows. I also have no measured productivity result for this pattern to report. Do not assume that storing a document makes every AI task read it.
Do it now: Write the five headings in one document. Add the facts you can support today and mark the gaps. Use that same version for one website introduction and one content draft. Check whether both describe the same business.
Reply with the fact you find yourself explaining to AI most often. That is a good candidate for your first reviewed brief.
— Dravya Bansal
