Practical AI for Business Operations

Almost every owner I talk to is running ChatGPT or Claude as one long chat. A single thread, scrolled back weeks, covering a quote on Monday, a hiring question on Thursday and a vendor email the week before that. It works well enough at first. Then the answers get worse and nobody can say why.

Why one long chat stops working

There is a mechanical reason for it. The model re-reads the entire thread on every message you send. The longer that thread runs, the more it is reading and the less of that has anything to do with what you just asked. Your prices from March are still in there, and it will quote them back to you with complete confidence.

The larger cost is that nothing accumulates. You explain your business again at the top of every new chat. The job you worked out how to do in September is somewhere in a thread you will never find in November. You are putting in real work and throwing away the part that was worth keeping.

The two things that change it

Two ideas fix most of this, and in my experience most owners have not met either one.

The first is context: writing down what your business is, once, so the tool starts every conversation already knowing it. What you sell, what you charge, why customers pick you, what they push back on, and how you sound in writing. Loaded once, reused forever.

The second is connectors: letting the tool work inside the systems you already run instead of only on what you paste into the box.

This session covers the first one and the work that sits on top of it. Part 2 covers the second.

What you build

Three things, all from your own business rather than a sample company.

• A context pack, one or two pages, that any AI tool loads at the start of a chat. This is the asset. Build it once and every chat you start afterward begins informed.
• A procedure for one job that comes up every week. Quoting from job notes, the invoice follow-up, the price-increase letter. The steps, the output format, the checks before it goes out, and what the tool should refuse to do on its own. Every owner has at least one process that exists only in their own head. This is the evening where one of them gets written down.
• A rule sheet for what never goes into a consumer AI account, plus a 30-day plan you write at the end and read aloud to one other person in the room.

How the evening runs

The session opens with what the tool is actually doing when it answers you, kept to the parts that change your decisions. It predicts text. It does not look anything up unless you tell it to. That is why it invents a price or a phone number and sounds certain while doing it.

Then one task runs four times on screen. Each pass adds another layer of context about the business: what it sells and charges, then two emails the owner actually wrote, then the details of the specific customer. By the fourth pass the output is usually sendable with light edits. I run that comparison before teaching any framework, because the framework makes considerably more sense once you have seen the size of the gap it closes.

Three labs follow. You write your context pack and test it against the same task from the demo. You put the messy spreadsheet, the vendor contract and the price list through the tool, and I show you where to verify output before it leaves your building. Then you take that one process out of your head and write it down.

The evening closes on the risk side: what should never be pasted into a consumer account, and the scams that now run on this technology. Voice cloning on the phone, vendor-change emails, fake invoices. One defense covers most of them, and it is not a technical one.

Part 2: Connected AI, Safely

Coming soon.

Everything in Part 1 runs on information you hand the tool. Connectors let it work in your real systems: your email, your calendar, your files. That is the largest single jump available to a small business, and it is also where the risk arrives.

Candidly, Part 2 is a security course with a productivity title. You connect two business systems read-only. You read what a connector is asking permission to do before you grant it. You watch a prompt-injection attack land, practice revoking access and auditing what a connector did while it had access, and write a one-page policy covering who in your business may connect what.

Part 1 is the prerequisite, and the gap between the two sessions is deliberate. Part 2 lands differently for an owner who has spent two or three weeks running real work through a context pack. Dates will be posted here.