How to Give AI Context About Your Business

If AI keeps giving you generic advice, it is because you gave it a generic question. The fix is a short written brief about your business that you paste in once and reuse everywhere. Not a document about your brand values. Six specific fields that change what a good answer looks like, and every one of them is a fact you already know.

This takes about twenty minutes to write and then improves every AI interaction you have from that point on.

Why generic input produces generic output

A model answering "how should I price my service" with no other information is answering the average version of that question, drawn from everything ever written about pricing. The answer will be reasonable, unobjectionable, and useless to you, because your constraints are not average.

The moment it knows you are a two-person landscaping business in a market with four competitors, charging by the job rather than the hour, with most work coming from one referral partner, the same question has a different and much more useful answer. Nothing about the model changed. The question got specific enough to have a specific answer.

Most people supply this context in fragments, differently each time, which is why quality swings between sessions. Writing it down once fixes the variance.

The six fields

Keep the whole thing under one page. Longer briefs get skimmed by both humans and models, and length is not what makes this work.

1. What you sell and to whom

One or two sentences, concrete. "Bookkeeping for independent restaurants with one to three locations" beats "financial services for the hospitality sector". Name the customer precisely enough that someone could go and find one.

2. Size and shape

Headcount, roughly how many customers, roughly what revenue range, how long you have been going. This is the field people resist and it changes the most answers. Advice for a solo operator with fifteen clients and advice for a twenty-person firm with four hundred are opposites in most cases, and without this the model splits the difference and helps neither.

3. How you actually make money

The pricing model, not the price. Retainer, per project, hourly, subscription, commission, per seat. Add where the margin actually sits, if you know, because it is often not where the revenue sits.

4. Your constraints

The real ones. No developer. No budget above a certain number. One person handles everything customer-facing. A regulator you answer to. A platform you cannot migrate off. This field alone kills more bad suggestions than everything else combined, because it is what stops you being told to build a mobile app when nobody can maintain it.

5. Your tools

What you already run. Accounting software, CRM, booking system, email platform, where files live. Any recommendation that ignores your existing stack is a recommendation to migrate, which is a much larger project than whatever you were actually asking about.

6. What you are trying to do right now

The only field that changes often. One sentence on the current objective. Grow a specific channel, cut a specific cost, launch a specific thing, survive a specific quarter.

A filled-in example

Short enough to paste, specific enough to work. If your business looks different, a worked example for dental practices shows the same six fields applied to a different kind of small business.

> We run a two-person landscaping business in a mid-size city, started 2019. Around 40 regular residential clients on seasonal maintenance contracts plus one-off design jobs. Revenue roughly 180k a year, split 70 percent maintenance and 30 percent design, and the design work carries most of the margin. Priced by the job, never hourly. Constraints: no employees beyond the two of us, no ability to take on more maintenance clients without hiring, and one of us does all the customer contact on top of doing the work. Tools: Google Workspace, a spreadsheet for scheduling, invoicing through our accounting software, no CRM. Right now we are trying to shift the mix toward design work without losing the maintenance clients that pay the bills.

Ask that business how to price a design job and you get an answer about anchoring against their existing maintenance relationships. Ask without the brief and you get a list of generic pricing strategies.

Where to put it

This is standing information that does not change per question, which makes it a textbook case for the split covered in system prompt versus user prompt, and it matches what vendors themselves recommend putting in a system message, as in Anthropic's prompting documentation. Depending on your tool:

• Custom instructions or profile settings. Most consumer chat tools have a field for information to apply to every conversation. Best option, because you never think about it again.

• A project or workspace. If your tool supports persistent projects, the brief goes in the project instructions and every conversation inside inherits it.

• A saved note you paste. Works fine, costs you five seconds per conversation, and is the honest answer for tools with no persistence.

• A system prompt. If you are building something on an API, this is exactly what the system message is for.

Keep the master copy somewhere you will actually update it. A stale brief is worse than none, because it produces confidently wrong-shaped advice.

What to leave out

Marketing language. "We pride ourselves on exceptional service" tells a model nothing it can act on. If a sentence would appear on your homepage, it probably does not belong here.

Customer personal data. Names, contact details, and anything from a customer record do not belong in a reusable brief that gets pasted into multiple tools. The retention and access questions in giving AI access to your data are worth reading before you decide what goes in.

Long history. How you got here is interesting and rarely changes the answer to an operational question. One clause about origin is plenty.

Everything. The temptation is to write four pages because more context sounds better. It is not. A tight page gets used fully, and a long document dilutes the fields that were doing the work.

Beyond the brief

The brief handles standing facts. Two other kinds of context are worth handling differently.

Documents. When the answer depends on your actual policies, contracts, or product data, pasting excerpts per question works for small volumes and stops working around the point where you are hunting for the right excerpt. That is where retrieval-augmented generation starts earning its keep, since it fetches the relevant section per question instead of you doing it.

Examples of good output. For anything repetitive, three examples of work you were happy with will teach tone and format faster than any description of tone and format. This is the fastest single upgrade for automating email replies or drafting anything customer-facing, and it is why customer support automation works better when you feed it real past tickets.

If you are using an app builder rather than a chat tool, the same context improves generated apps, and writing prompts for AI app builders covers the specifics of what those tools need on top of this.

Frequently asked questions

How long should the business context brief be?

Under one page, ideally 150 to 300 words. The six fields fit comfortably in that. Length past a page reliably reduces how much of it gets used.

Do I need a different brief for each AI tool?

No. One brief, pasted or stored in each tool. You may add a line about output format for a specific tool, but the business facts are the same everywhere.

How often should I update it?

Review it quarterly, and immediately after anything that changes a field: a hire, a pricing change, a new system, a shift in what you are working toward. The last field changes most often and takes ten seconds to edit.

Is it safe to put business details into an AI tool?

Non-sensitive operating facts of the kind described here are low risk on a paid business tier, which typically excludes your input from training. Avoid customer personal data, credentials, and anything under an NDA regardless of tier.

Will this work with any AI tool?

Yes. It is not a prompting trick tied to one model, it is supplying the information any advisor would need. The same brief works across chat tools, app builders, and anything you build on an API.

This is one piece of a larger discipline, covered in full in what context engineering actually is

For the mechanics of turning this into a running app, how to write a system prompt for a custom AI assistant covers the closely related task of encoding that same business context into a persistent system prompt.