Context packs: projects, files and memory for content and sales

0:00 Context packs

Here's a truth that took the industry a while to accept. Most bad AI content isn't a prompting problem. It's a context problem. The model wrote the wrong price because it never saw the right one. It sounded generic because it never saw your best work. It invented a result because nobody gave it a real one. In this lecture you'll learn to build a context pack: six short files that give your assistant the stable truth about your brand, your offer and your customers. You'll learn where to store it in today's assistants, see an agency's before and after, and watch me build a pack and test it.

0:47 Why context engineering

Why does this matter so much in content and sales? Because these are the areas where wrong facts cost you. A wrong price in a sales email. A claim legal withdrew last month, back in an ad. A testimonial the customer never approved. When every writer pastes whatever facts they have to hand, you get inconsistency and errors. A context pack creates one source of truth. When the price changes, one file changes, and every future draft is correct. Here's the key idea. Context engineering means deciding deliberately what the model sees before it writes.

1:28 The new hire's welcome folder

Think about onboarding a new salesperson or copywriter. On day one, you'd give them a welcome folder. Here's how we sound. Here's what we sell and what it costs. Here are the claims we're allowed to make, and the proof we can use. Here's how our customers actually talk. Here are examples of our best work. And here's what we never do. A context pack is that welcome folder, for your AI assistant. And just like a real new hire, the assistant does much better work on day one when the folder is short, clear and up to date.

2:11 The six files

Here are the six files. The brand voice guide: personality, language rules, love and ban words. The offer sheet: products, prices, what's included, real guarantees and terms. Approved claims and proof: claims legal has approved, case study results with permission, testimonials with consent. Customer language: verbatim pains, desires and objections from reviews, calls and messages, anonymized. The example bank: your best posts, emails and scripts. And the do not list: claims that need sign off, sensitive topics, competitor rules and disclosure requirements. Keep each one short, about a page, and put a date on it. Six short dated files beat one forty page document every time.

2:57 Where to store it

Where do you keep it? In ChatGPT, a project with instructions and files, or a custom GPT for a repeatable task you share with a team. In Claude, a project with instructions and project knowledge. In Gemini, a Gem with saved instructions and files, or Gemini Notebook when you want answers grounded only in your sources. In Microsoft 365 Copilot, a Copilot Notebook or reference files in SharePoint or OneDrive. In Notion, a brand hub page that Notion AI can read. Whichever you choose, client and sales material belongs in a work approved workspace, because projects don't change which data terms apply.

3:41 Instructions that use the pack

Now the project instructions that make the pack work. Tell the assistant to always read and follow the voice guide, the offer sheet, the approved claims and the do not list. Use the customer language file for phrasing and the example bank for tone and structure, without copying phrases. If a fact isn't in the files, write check instead of guessing. And end every output with two lines: claims used, with the file each claim came from, and disclosure, noting any paid label or AI label needed. That claims used line is your secret weapon. It shows you exactly what the model relied on, so you can verify in a minute and spot anything it made up.

4:32 Example 1: the per-task lines

A simple example of how short prompts become. With the pack in place, a marketer at a yoga studio types three lines. Goal: fill the new Saturday beginners class. Segment: people who've never done yoga and feel inflexible. What's different: it's a new class, starting next month, with an intro price. The output uses a customer's phrase from the language file, the intro price from the offer sheet, the tone from the example bank, and ends with claims used, each mapped to a file, and disclosure, none needed. The pack supplied the stable truth. The three lines supplied the moment.

5:15 Example 2: the Riyadh agency

Now a business case, with illustrative details. A B2B agency in Riyadh writes content and sales emails for a logistics software client. Before the pack, every writer pasted different facts, some outdated, and one email quoted last year's pricing to a prospect. Embarrassing. After: a single project with six one page files and the instruction template. Every output ends with claims used mapped to files, so the account lead checks each draft in about a minute. When the client updates pricing, one file changes, and every future draft is correct. The client also noticed that emails started sounding more like their customers, because the customer language file came from real sales calls.

6:04 Watch me do it

Let me build and test one. I create a project for a route planning software brand and upload six rough one page files, each with the date in the filename. Voice guide, offer sheet, approved claims, customer language from five sales call notes, an example bank with three good emails, and a do not list. I paste the instruction template. Now the test. In a plain chat: write a cold email to a logistics manager about our route software. It claims we cut costs by thirty percent. We've never said that. Inside the project, same request. The email opens with a customer phrase, my drivers call me from the road all day, uses one approved result with the client's permission, the right price tier, and ends with claims used. Every claim maps to a file. That's the difference.

7:04 Memory, and common mistakes

A note on memory. Memory is great for your own preferences, like format and spelling. Keep client and prospect details out of global memory, and inside the relevant project. Review memory monthly. Now the common mistakes. One enormous undated document instead of short dated files. Stale offer sheets, which are the single most common source of wrong prices. Mixing several clients' packs in one project. And assuming the model read every file carefully. The claims used line is how you find out what it actually relied on.

7:42 Recap and try this now

Let's recap. Most quality problems are context problems. Build a context pack of six short, dated files: voice guide, offer sheet, approved claims, customer language, example bank and do not list. Store it in a project, GPT, Gem, Notebook or Notion hub in a work approved workspace. Use instructions that say check instead of guessing and end with claims used and disclosure. Then add three lines per task: goal, segment, and what's different this time. Here's your try this now. Spend forty five minutes building rough versions of the six files, set up the project, and test it on three real tasks. Then put a quarterly review in your calendar.